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.
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).
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 188.8.131.52
- host 184.108.40.206
- host 220.127.116.11
- host 18.104.22.168
- host 22.214.171.124
AOL’s web-based chat server uses toc.oscar.aol.com, on a variety of addresses in the 126.96.36.199 (255.255.255.0) network.
I suggest redirecting the following subnets, but this will also likely block AOL entirely, not just instant messenger
188.8.131.52 (255.255.255.0), 184.108.40.206 (255.255.255.0), 220.127.116.11 (255.255.255.0) and 18.104.22.168 (255.255.255.0)
To redirect ICQ:
Redirect the networks (as of May 20, 2004)
- Same as AOL Instant Messenger
To redirect MSN Messenger:
Dec. 3, 2002 – A sysop reports MSN Messenger now uses network address 22.214.171.124, 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 126.96.36.199 through 188.8.131.52.
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 184.108.40.206 (255.255.255.224) will prevent traffic from reaching all addresses from 220.127.116.11 through 18.104.22.168. (Changing that subnet to 22.214.171.124 and the subnet mask to 255.255.255.128 would expand the blocking to 126.96.36.199 through 188.8.131.52).
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.
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.
Source : Novell Public Forums, BorderManager sections
Filed under: Tips and Trick |