Firewalling against Instant Messaging and File Sharing Services

Overview

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, "messenger.hotmail.com", 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:

• Set up a local DNS resolver: Rather than using your ISP's DNS resolver, run your own. I use Dan Bernstein's djbdns program -- a simple, secure and flexible DNS package, offering both a DNS resolver and a DNS content server, both of which are used for this project. Most DNS packages should be able to do this with little difficulty. I'm not giving keystroke-by-keystroke details here, anyway. If you don't understand how to use your DNS server of choice, this isn't going to help you.
• Set up a local authoritative DNS content server: This server should have delusions of grandeur -- it should think it knows all about the .COM, .ORG and .NET, and any other Top Level Domains (TLDs) you might be having trouble with. Any query for any domain within those TLDs should produce one answer: the address of some machine within your network. I usually use the external IP address of the DNS server. You could also use 127.0.0.1 (which will bounce the user back to their own machine), if you desire, though I prefer the DNS server, sometimes you can give a more intelligent reply, for example, a web server responding "you have attempted to go to an unauthorized site. It has been logged."
• Configure your DNS resolver to point troublesome domains to the DNS content server, which replies with the DNS server's address. While this may seem strange, it is basically just a standard "Dual Horizon" DNS configuration -- one where the outside world and the inside network get different IP addresses for the same name.

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:

C:\>ping doubleclick.net
    Pinging doubleclick.net [192.168.1.252] with 32 bytes of data:
    Reply from 192.168.1.252: bytes=32 time=10ms TTL=255
      ...

So, doubleclick.net 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 "aimexpress.aol.com" 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.

Advantages:

• Quick and easy to kill.
• Darned effective.
• Very little processor or resources needed. You could serve a very large office off a surplus computer. Easily.
• Easy and fast to set up -- I did one of these systems in about half an hour one day (granted, I was able to "steal" the config from another machine with almost identical needs, but this still is an easy setup).

Disadvantages:

• In theory, someday the services may get around this by either hard-coding IP addresses in the programs (I don't think this would be very effective -- not only could you block the addresses easily, every time you saw "You must upgrade your AIM client", you would know they had an address change, so you know to update the blocked addresses!) or by combining the "first contact" servers -- i.e., to kill Yahoo Instant Messenger, you would end up killing all or much of Yahoo, perhaps making the "kill" politically unpopular among the management, tracking their stocks through Yahoo. Would Yahoo risk losing those people, though? I don't think so.
• Users could hard-code the "key" addresses in their local machine's "hosts" file, bypassing your DNS server for the services in question. I don't see this as a huge problem -- if your corporate policy includes a "Don't modify your hardware or software to circumvent company policy" clause (and it should), and you see undesired traffic on your firewall, you have grounds for termination: a deliberate and willful act of sabotage. Fire them. Publicly. Won't happen again, I suspect. While this is a theoretical limitation in this procedure, I have never actually seen someone do it, and this requires a small amount of knowledge, and any plea of, "I didn't know!" is obviously false.
• I have some ideas how it *might* be possible for the authors of these programs to get around this strategy, but they aren't in use currently, and most other "solutions" are toast, then, too. This would also be very resource intensive, and I suspect instant messenging services and file sharing services are not profitable enough to pursue what I'm thinking of.

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:

• AOL Instant Messenger: login.oscar.aol.com, aimexpress.aol.com (the first blocks the traditional AIM, the second blocks the "AIMexpress" service, AIM through a web browser. Leaves the rest of AOL service available.
• Yahoo Instant Messenger: msg.yahoo.com, rest of Yahoo services are still available.
• MSN Instant Messenger: messenger.hotmail.com. Rest of MSN and Hotmail still work.
• Kazaa: Just kill kazaa.com. No reason not to that I can think of.

Finding out "the" magic name to block

In some cases (Kazaa.com, 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 scs.msg.yahoo.com.

So, we can pretty well hose YIM if block scs.msg.yahoo.com... HOWEVER, repeating the experiment after blocking just scs.msg.yahoo.com, I see that while I seem to have killed YIM, it keeps querying other sites:

@400000003f7ebfc40c7d1714 query 21 c0a801ae:041b:0125 1 scs.msg.yahoo.com.
    @400000003f7ebfc50a8f3964 query 22 c0a801ae:041d:0126 1 scsa.msg.yahoo.com.
    @400000003f7ebfc60aa10fcc query 23 c0a801ae:041f:0127 1 scsb.msg.yahoo.com.
    @400000003f7ec0250b8b6be4 query 4 c0a801ae:0429:0128 1 scsc.msg.yahoo.com.

(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 msg.yahoo.com domain, I'm just going to block msg.yahoo.com, 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.

Conclusion

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:

adserver.com
atwola.com
doubleclick.net
instacontent.net
vibrantmedia.com
x10.com

I don't even recall why some of them are blocked -- x10.com because of their annoying pop-up ads (I even used to buy a fair amount of their stuff. Not anymore!), doubleclick.net because of their annoying privacy issues, etc.You may also opt to block "spyware" sites like gator.com. 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*).

If im not mistake, these can be changeable and also apply to other matter regarding unavailable site view.