Blocking Chat Services

Blocking Chat Programs - Mar. 15, 2006

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.

Background:

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.

[back to top]

A 3-Pronged Approach

There are three areas to consider when trying to block the programs from accessing their 'login' servers.

1. Filter Outbound Traffic

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)

2. Block Access to Login Servers via Proxy

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

• AOL Instant Messenger: login.oscar.aol.com:443
• AOL Instant Messenger: login.oscar.aol.com, possibly toc.oscar.aol.com and login.icq.com
• MSN Messenger: gateway.messenger.hotmail.com (was login.gateway.hotmail.com)
• ICQ: login.icq.com and http.proxy.icq.com (Was icq.mirabilis.com and login.icq.com previously)
• Yahoo! Messenger: msg.edit.yahoo.com/*
• (Yahoo! Messenger: Might also need to block messenger.yahoo.com/*andhttp.pager.yahoo.com/* Be sure to type in the http on that last URL).
  

[back to top]

3. Redirect Traffic to Login Servers via Dummy Static Routes

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.

Entering a static route in NetWare:

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.

To redirect AOL Instant Messenger:

AOL's login servers (login.oscar.aol.com, and also login.icq.com) are on these subnets/addresses, as of May 20, 2004:

• host 64.12.161.153
• host 64.12.161.185
• host 64.12.200.89
• host 205.188.153.121
• host 205.188.179.233

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)

To redirect ICQ:

Redirect the networks (as of May 20, 2004)

• Same as AOL Instant Messenger

[back to top]

To redirect MSN Messenger:

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).

To redirect Yahoo! Messenger:

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

Finding Out How A Program Gets Through HTTP Proxy

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.

Return to the Main Page