Updated Mar. 15, 2006, with new access rule to help block on AOL Instant
Messenger on port 443. (Thanks to Peter Boehlke!)
Updated May 20, 2004, with new information on AOL Instant Messenger.
Updated Feb 20 with a correction to the AIM login server name and some other information.
Updated Nov 29, 2001 with some more information on MSN Messenger subnet in use and Yahoo!
Messenger addresses.
Updated Nov 12, 2001 with changes for ICQ, thanks to Adrei Fisenko.
Updated Nov 9 with some more information on blocking MSN Messenger.
Updated August 29, 2001, with changes to AOL and ICQ subnets. Thanks to Kevin Sinclair).
A lot of people seem to have problems blocking Chat programs, specifically AOL Instant Messenger, MSN Messenger, Yahoo! Messenger and ICQ. Here is some information that may help you cut these programs off at the BorderManager server. Thanks to Kevin Sinclair for his input on the IP subnets and Yahoo Messenger on this.
Chat programs are very popular, and many are designed to be 'easy to use'. In order to
be easy to use, they are designed to work under a wide variety of connectivity conditions, and
automatically configure themselves for connection by whatever means is available. This automatic
configuration makes it both easy to use, and harder to block, because the programs themselves will go
through a trial-and-error sequence of looking for open ports to connect through, and use proxies if
possible. Often, proxy settings will be picked up from Internet Explorer, but the programs usually
want to make a direct TCP connection to a central server to start.
The way these programs work is that a connection must be made to a central server, through which
communications to other users are established. This is the key to blocking these programs - deny them
access to the central servers, and they cannot work.
There are three areas to consider when trying to block the programs from accessing their 'login' servers.
This method is the most basic, and used to work well before the programs got more
sophisticated. It is ESSENTIAL to have at least the BorderManager default filters installed and
enabled! The default filters WILL BLOCK ALL of these programs when they try to access the
Internet, but they will NOT block the programs if those programs use your proxy server. You have a
problem only if you have not installed the filters (use LOAD BRDCFG to do so), are not running the
filters, or you have set up exceptions that allow traffic. The problem I see lately is that most
firewalls do allow some outbound traffic through filter exceptions, and the newer chat programs
(like AOL Instant Messenger) will do port scans on many ports and often find openings.
If you do not feel comfortable working with filter exceptions, call in a
consultant who does, or learn about filtering yourself - here's a link to
my book on configuring filters and exceptions for BorderManager.
AOL Instant Messenger, as of Feb. 2002, will try a wide variety of TCP port numbers, and is
quite likely to connect on some port number that is designed to allow some other traffic (such as
FTP) if you set up custom filter exceptions. AOL Instant Messenger almost certainly will require you
to use method 3 below. MSN Messenger tries to use TCP destination port 1863. Yahoo! Messenger uses
port 80. ICQ uses a range of port numbers, defaulting to UDP destination ports 2000-4000, but has so
many options it is almost futile to try to figure them out. Recent versions of ICQ (2000b) may
default to the AOL port 5190, since AOL bought ICQ.
All of these programs are revised often enough that you need to research each new version that comes
out to see if something has changed. This documentation was written to AOL Instant Messenger
version 5.2, MSN Messenger 3.5.0077, and ICQ versions 99a and 2000b.
Once you have blocked a direct connection, the programs must try to connect via a proxy. The default
filters should block all of the Chat programs listed above from connecting by bypassing a proxy.
But if you have opened up a port with a filter exception and dynamic NAT, some of these program may
make connections through otherwise safe port numbers, like DNS! (See approach number 3 in this
case)
The programs generally have options to connect behind a firewall by entering proxy
information, such as HTTP, SOCKS, or other. Some will pick up the proxy configuration information to
try from Internet Explorer settings. Blocking a connection through a proxy is generally pretty easy
as all you have to do is enter the proper Deny URL rule. Generally, the only proxy that will be
used here is the HTTP Proxy, possibly the Transparent HTTP Proxy.
The key here is to deny whatever login server is called out in the configuration options for the
chat program. Some may show you a configurable entry, while others (like MSN Messenger) hide it.
Login server names - set up a Deny URL access rule for these sites
The first method should stop the usual connection routines, and the second should stop
access via a proxy (HTTP or SOCKS), but what if the chat program piggybacks onto a DNS proxy
(which ignores access rules) or you have configured filter exceptions to allow outbound traffic on
some port that the chat program discovers?
This is where we, the all-powerful firewall admins, get evil and tricky. We must determine the IP
subnet of the login servers, and use a series of static routes to reroute traffic to those subnets
to the bit bucket. As long as all traffic to the Internet has to go through the BorderManager server,
this method will ALWAYS work. However, it is subject to those login servers staying on those same
subnets! If the login servers are relocated to another subnet, this method will have to be updated
with new addressing information. This method is also a real sledgehammer approach - you won't be
able to make an exception for the admin (you) to get through and block everyone else.
A related method here would be to enter dummy DNS entries for the login hosts (such as in the
BorderManager HOSTS file and any internal DNS servers), but that is relatively easily countered by
someone knowing what the real IP addresses of the login servers are.
I have two methods for finding out what addresses are being used. The first is to do a DNS lookup
using some sort of nslookup program to find addresses for the login hosts (like login.oscar.aol.com).
The second is to use a packet sniffer like Ethereal (www.ethereal.com) to capture packets from my PC
when I tell the chat program to configure itself. Then I analyze the requests made from my PC to
see what the chat program is trying to do.
LOAD INETCFG, go to Protocols, TCP/IP, and go into LAN Static Routing Table. Make entries for Network with the network numbers listed below, using a next hop of an IP address that is within a network directly attached to the BorderManager server. (Don't use an IP address actually assigned to the server, or 127.0.0.1). For instance, if you have a private IP address of 192.168.1.1 bound to the BorderManager server, you can use a next hop address of 192.168.1.2 through 192.168.1.254 and it should work. If you were to put in an address such as 10.0.0.1 (with no 10.x.x.x network address bound to the server), it will be ignored, and the traffic will still be sent out via the default route.
AOL's login servers (login.oscar.aol.com, and also login.icq.com) are on these
subnets/addresses, as of May 20, 2004:
AOL's web-based chat server uses toc.oscar.aol.com, on a variety of addresses in the
64.12.163.0 (255.255.255.0) network.
I suggest redirecting the following subnets, but this will also likely block AOL entirely, not just
instant messenger
64.12.161.0 (255.255.255.0), 64.12.200.0 (255.255.255.0), 205.188.153.0 (255.255.255.0) and
205.188.179.0 (255.255.255.0)
Redirect the networks (as of May 20, 2004)
Dec. 3, 2002 - A sysop reports MSN Messenger now uses network address
207.46.96.0, subnet mask 255.255.224.0.
I tested on Nov. 9, 2001, and there were multiple login servers, where in the past there was only
one. By Nov. 29, it appeared that there were login servers at addresses 64.4.13.170 through
64.4.13.190.
Microsoft may be adding even more in the future. I was still able to block MSN Messenger with just
default filter exceptions and the Access Rule listed above, but should a new version of MSN
Messenger come out that is able to slip by the proxy rules, try redirecting an entire subnet.
Redirecting subnet 64.4.13.160 (255.255.255.224) will prevent traffic from reaching all addresses
from 64.4.13.161 through 64.4.13.191. (Changing that subnet to 64.4.13.128 and the subnet mask to
255.255.255.128 would expand the blocking to 64.4.13.129 through 64.4.13.255).
So far I have not had to redirect Yahoo! Messenger, but simply used an Access Rule as
listed above (like MSN Messenger). However, a reader reports the following addresses in use on Nov.
29, 2001, should you want to try the redirection technique.
csXX.msg.yahoo.com Series
216.136.175.143-145
216.136.225.83-48
216.136.225.12
csXX.msg.sc5.yahoo.com Series
216.136.226.209-210
216.136.227.166-167
Here's one technique I use to find out what needs to be blocked. I used this to track
down what Yahoo Messenger was connecting to, so I could set up access rules to block it.
1. Use a user account that doesn't have a lot of traffic, or is set up just for this test. This is
so you can easily see what is being accessed in your testing.
2. Enable proxy authentication. This is so that the user account you are testing with shows up in
the logs.
3. Set up an Allow All URL access rule at the top of the rules list, with Source = the NDS user
account you are testing with. Enable rule logging.
4. Connect to the web site/service. (For Yahoo Messenger, try to login.)
5. Check the Access Rule logs for the last 30 minutes or so to see what was allowed, find the test
user account, double-click on it, and look at the URL's.
6. Set up a Deny URL rule right above the Allow URL for the test user, enable logging on it, and
enter a URL to deny. Wildcards are allowed.
7. Test again. If the Deny rule worked, you will see that in the Access Rule logs. If the login
worked, the software may have tried a second option you also have to deny, or your Deny rule may have
the wrong syntax. Also, when the access rules deny a site, you should see, in the Proxy Console
screen on the BorderManager server, an immediate increase in the "Failed" statistic.
Please post feedback in the Novell Public Forums, BorderManager sections, if you find that the
above methods no longer work.