Blocking Public Instant Messaging
by David M. Piscitello, President, Core Competence, Inc.
Party line telephone service was, and remains, a unique telephone application. Implemented to deal with circuit scarcity in rural areas, party lines multiplexed handfuls of residential phone users onto the same common local loop pair, and all the parties shared a common phone number. To determine whether the ring from your phone was your incoming call or your neighbor's, you had to distinguish ring cadences (two short rings mean, it's for us!) or frequencies (that lower-toned ring is for the neighbors). Party line users had to refrain from monopolizing the shared line, and they had to recognize that neighbors could listen in on phone conversations.
Today, the media, courts of law, and even Internet standards describe instant messaging (IM) and Internet Relay Chat (IRC) as the Internet generation's corollary to the party line telephone service. But the security implications of permitting any of the public IMs (Microsoft, AOL, Yahoo) in a business LAN environment should be more worrisome to Internet-connected organizations than snoopy Mrs. Malarkey eavesdropping on phone conversations:
- Flaws have been found in the client software for all the major IMs, exposing serious vulnerabilities, including buffer overflows that facilitate arbitrary execution of scripts and programs that can upload viruses.
-
None of the major IM protocols use encryption, so any sensitive topics discussed using messaging tools are transmitted in the clear.
-
Certain IM logins protect passwords by using weak encryption methods that are easily cracked.
-
File transfers and sharing capabilities do not offer adequate access controls to prevent misuse and unauthorized access, local file path disclosure, system crashes, and denials of service.
-
With many IMs, you can embed images in instant messages, transfer files, and talk to your "buddies" (voice chat). These tools create direct connections between user hosts. The pointers to images, files, etc., exchanged by the IM clients contain the IP addresses of the correspondents, revealing information about your trusted network you usually masquerade behind your firewalls.
-
Automatic logins, saved password, add-ins, and other "convenience" features create opportunities for impersonation, mischief, and abuse of company resources (e.g., gaming).
-
Privacy advocates raise serious questions about unauthorized disclosure and information sharing associated with IMs and their login features.
Public instant messaging services, like party lines, are designed for the residential Internet user. If you have business applications that make instant messaging necessary, consider running an "enterprise-grade" IM server for your organization; otherwise, you may wish to prohibit IMs and block users from accessing them.
Before you block IM, inform ‘im
If you do choose to block instant messaging services, then explicitly identify instant messaging as a prohibited application in your Acceptable Use Policy. State that installation of IM client software and all related tools -- voice chat, file transfer and sharing, etc. -- is also prohibited on company computers. Clever employees may try to use "firewall evasion" proxies (explained below) to access AIM, so prohibit this as well.
Monitor your networks for IM activity using your firewall logging features. If you are blocking AIM (see below), you'll want to log denied attempts. Special purpose LAN analyzers like Rogue Aware from Akonix can gather utilization statistics of public instant messaging services. Install such software near your Internet access router or firewall so it can capture all IM traffic emanating from your trusted networks and provide you with a report of all user activity. Use the report to identify and politely (or sternly, a matter of policy) advise abusers to cease and desist IM use.
Blocking IMs at your firewall(s)
Blocking IMs is like playing the arcade game Whack-a-Mole: AIM clients, for example, are configurable and users can specify any port to connect to AIM servers, including port 80/HTTP. So merely blocking the well-known port for AIM (5190) won't get the job done, entirely. Clever employees may try to use a publicly accessible "firewall evasion" proxy such as HTTport3.snf and Socks2HTTP to tunnel AIM conversations out through your firewall, using Secure Sockets Layer (SSL) to evade detection. These proxies are run on public gateways (e.g., by TotalRC.Net, the folks who sell SOCK2HTTP) and personal (read "rogue") gateways, so don't bother trying to block host IP addresses of these.
Fortunately, AIM is a client-server application that requires a login to AOL's OSCAR (Open System for Communication in Realtime) servers. Thus, a more effective strategy is to block access to the AIM authentication (login) servers. You can do this several ways:
- Identify and block outbound connections to all the IP addresses that resolve to the DNS name login.oscar.aol.com. Log denied attempts so you can identify would-be abusers. An nslookup shows these to currently be 64.12.161.153, 64.12.161.185.
-
Create a static route that redirects all AIM login server traffic to a destination you know to be unreachable from your networks. For example, choose an unused address from your trusted IP subnet (say 172.19.14.0/24) and create a route that says, "to get to host 64.12.161.153, route to 172.19.14.253". You know 172.19.14.253 is unreachable, so you are spoofing an unreachable condition on your would-be AIM users. You also ensure this traffic will never make it out of your network and become an inadvertent attack on someone else. Two drawbacks to this solution are that you must remember the address you assigned as the unreachable target, and you can't avail yourself of firewall logging to identify would-be abusers (unless you log ICMP unreachable messages).
Remember that AOL is responsible for domain name and IP address bindings for aol.com, and they have renumbered the AIM servers (the OSCAR servers had previously been on three class C subnets: 205.188.3.0, 205.188.5.0, and 205.188.7.0). You can check them periodically. If this doesn't thrill you, then you can:
- Make your Domain Name Server the authoritative DNS for AIM related names (e.g., login.oscar.aol.com, or if you are truly nasty, aol.com entirely). AOL is less likely to change names than IP addresses. Resolve the names to the IP address of localhost 127.0.0.1. This forces subsequent packets sent from the client PC to "loop back." Since the client PC won't have a server listening on AIM ports, such packets will be discarded. The packets won't leave the client machine, so they won't add load to your LAN. Note: users could attempt to override this by adding the true IP addresses of the login servers or aol.com to their hosts files; if so, combine with (1).
Combine these firewall, routing, or name server measures with a monitoring tool and you should be OK.
Conclusions
IMs aren't as innocuous as they seem. To protect my home office, I've placed my "production" computers behind one Firebox, and my IM-enabled family computers behind a second. Unless you want to roll your own instant messaging service, or until public IMs offer better security and more stable client software, you are better off without them.
In this article, I've only described ways to block AOL Instant Messenger (AIM). If you want to learn more about blocking other IMs, read Al Berg's article in Information Security Magazine. ##
Resources
Users of WatchGuard Firebox II and III models can find more about instant messaging in these Advanced FAQs (LiveSecurity login required):
Copyright© 2003, WatchGuard Technologies, Inc. All rights reserved. WatchGuard, LiveSecurity, Firebox and ServerLock are trademarks or registered trademarks of WatchGuard Technologies, Inc. in the United States and other countries.