Firewalling against Instant Messaging and File Sharing Services


For various reasons, many system administrators and managers wish to prevent various Instant Messenger and file sharing services services. They are security nightmares, and often used for swapping copyrighted material, and are horrible wasters of time and bandwidth. There is plenty of good reason to block them. Unfortunately, these programs are famous for slipping through firewalls through any port possible.

Firewalling by port is pointless -- these services will use any outgoing port that is available. Firewalling by IP address is difficult -- and as the services grow, they are continually adding new servers, new addresses. So, what can you do to block them?

The usual answer is a proxy server -- a server sitting between your internal network and the external Internet, which examines each packet and passes only permitted traffic. Proxy servers can offer some significant advantages -- total content management of your Internet traffic, bandwidth reduction (by caching traffic), very good audit trails of where your users are going on the Internet and what they are doing. However, there are some serious disadvantages to proxy servers: they do require a fairly powerful computer and disk system, they require a lot of configuration and setup, and typically, a fair amount of maintenance. Many people may not wish to set up a proxy server for their network. Worse, it is not possible to proxy secured (encrypted) HTTP traffic, so some of the apps we wish to block simply mimic HTTPS traffic and use the HTTPS port (TCP 443), so if this traffic isn't blocked in other ways, the apps win, and if it is blocked, your users are prevented from using secured websites (which may or may not be desirable). This is the motivation for the blocking system I have here -- it is very effective and very simple to implement.

Filtering by DNS

The strategy is fairly simple. These services don't hard code IP addresses in the application, they code in the DNS (Domain Name Services) name of a referral server, for example, "", and ask that server for an available messenger server. Rather than trying to block that server, which may move from IP address to IP address, why not just intercept any queries for that server?

This technique is often called a "Poisoned DNS server" -- the name originally refering to a type of DNS attack, where you fool a DNS server into giving invalid information to an unsuspecting user (you just THOUGHT you knew where you were punching your credit card number into). A similar concept can be used constructively to solve problems, however.

Here is the procedure I have used successfully:

So now, when an application goes looking for the address of one of the names you have blocked, it gets directed to something INSIDE your network, for example:
    Pinging [] with 32 bytes of data:
    Reply from bytes=32 time=10ms TTL=255
So, is harmlessly redirected inside my own network. You will have to make sure that only your internal DNS resolver can make queries to the external internet to port 53, otherwise users can simply select a more "friendly" DNS resolver, defeating your system.

How it works

When one of these programs starts, the first thing it does is look for a server (by name) to guide it in its quest. My investigations has shown that virtually all these services start with just one name, which has the task of relaying the user to another server, which actually handles the user's needs. Sometimes, these services will then look up a lot of names but always seem to start with one name.

If you kill that first query (and any "fall back" queries it might make), though, the programs will sit and whimper.

My experience has shown so far, you can be very selective on what you pass or block. For example, blocking "" will kill the new AOL "AIM through a web browser" feature, without hurting AOL, AOL mail-through web browser, or even the AIM program itself (obviously, you would want to block BOTH AIM and "AIM through the web browser", usually, but that's just another server). You can kill Yahoo Instant Messenger without killing Yahoo mail or other Yahoo services.



Considering the effectiveness and ease of implementation, I consider this an excellent solution. If you need a more "perfect" solution than this, you need to go to a "block everything but these sites" solution. Some might argue that "Kazaa and its kin are peer-to-peer services, they don't rely on central servers!" This is untrue. We aren't blocking the peers that people are fetching files from, we are blocking the machines that keep track of who has what -- or more accurately, we are blocking the machines that direct the clients to the machines that know who has what. Doesn't really matter who you can access if you don't know who you need to access.

Naming names

Here are some popular services and what I have found blocks them:

Finding out "the" magic name to block

In some cases (, for example), you can pretty well guess the name to block, and if there is any collateral damage, who cares.

In other cases, you want to be more strategic... You want to kill one part of a service (say, Yahoo Instant Messenger) without killing the manager's stock quotes...

As indicated earlier, I use DJBDNS as DNS toolkit of choice. DJBDNS provides very extensive logging, which is very useful for this kind of stuff:

Start watching the log:

    DNS1 /service/dnscache/log/main # tail -f current |grep query
(The "grep query" part of the command limits the amount of fluff djbdns will be telling you.) At this point, start the application you wish to block A huge burst of queries will take place, but look at the VERY FIRST things:
    @400000003f7ebd5e3969b73c query 127 c0a801ae:136e:0119 1
So, we can pretty well hose YIM if block HOWEVER, repeating the experiment after blocking just, I see that while I seem to have killed YIM, it keeps querying other sites:
    @400000003f7ebfc40c7d1714 query 21 c0a801ae:041b:0125 1
    @400000003f7ebfc50a8f3964 query 22 c0a801ae:041d:0126 1
    @400000003f7ebfc60aa10fcc query 23 c0a801ae:041f:0127 1
    @400000003f7ec0250b8b6be4 query 4 c0a801ae:0429:0128 1
(yes, I'm editing out a lot of irrelevant stuff and other machines in the house doing various queries)

As it is probing other things in the domain, I'm just going to block, and it is quite successful. When started, Yahoo Instant Messenger basically hangs, looking for its primary servers.

Note, when doing this from a Windows NT/2000/XP workstation, you have to remember that Windows caches DNS queries. So, your first attempt to see what the application is looking for will load the relevant data into Windows's DNS cache, and when you attempt to block that site, you will see the application still works, as Windows isn't querying your server at all, but is answering the query itself. Use the "IPCONFIG /FLUSHDNS" command to clear the Windows DNS cache between trials, and exit the application completely (many IM programs leave themselves resident)

Also note that the kill will not be "immediate" -- if someone already has a service running, it is unlikely to suddenly stop running. You will need to wait until they reboot their workstations. Fortunately, it IS Windows applications we are usually talking about here, this is usually not a problem. If it is, an accidental trip of the main breakers will resolve it effectively.


I've used this technique to block sites I didn't want users going to in schools, I've also used it to block sites in my own office that I found annoying for one reason or another. Here are some of the sites I currently have myself blocked from:
I don't even recall why some of them are blocked -- because of their annoying pop-up ads (I even used to buy a fair amount of their stuff. Not anymore!), because of their annoying privacy issues, etc.

You may also opt to block "spyware" sites like I developed a list of these sites by taking a student computer which was desparately in need of a wipe and reload -- I isolated it in a DMZ with a the logging DNS resolver, and watched what it did. I will admit to a certain amount of glee of blocking names and watching applications go into serious distress (*grin*).

Back to Technical Guides
Holland Consulting home page
Contact Holland Consulting

since October 4, 2003

Copyright  2003, Nick Holland, Holland Consulting

Published: 10/4/2003
Revised: 10/6/2003