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,
"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:
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:
- 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
- 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
- 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.
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.
- 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).
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.
- 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
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
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
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
@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
@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.
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 -- 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
Back to Technical Guides
Holland Consulting home
Contact Holland Consulting
since October 4, 2003
Copyright 2003, Nick Holland, Holland Consulting