Controlling IM Traffic

Perhaps you’re more interested in controlling where IM traffic goes than you are in who can send and receive instant messages in the first place. Given the regulatory requirements imposed on many industries and organizations, this is perfectly understandable. IM traffic control usually falls into three basic categories: blocking inbound instant messages from the outside world, blocking IM users on your network from sending messages to the Internet, and restricting or disallowing file transfers initiated by IM clients.

Blocking Inbound Traffic

The nature of Exchange’s IM architecture gives you several ways to block inbound traffic. The first step is not to publish SRV records for IM. SRV records, which are optional, allow an outside user to query for the server in a given DNS domain that handles a specified protocol, in this case RVP. The existing IM server requires you to manually create SRV records; if no SRV record for the domain exists, the sender’s client has to make an educated guess at the correct URL for the recipient’s home server.

The next architectural countermeasure is to block traffic to the IM server itself. Whether or not you’re using IM routers, your IM servers always receive and send all their traffic on Transmission Control Protocol (TCP) port 80. To effectively cut off outside access to your IM servers, just block inbound port 80 requests to those servers. This is easy if you’re using dedicated IM servers; if your IM home servers are running other applications, though, you might not be able to block out all port 80 traffic. In that case, enable IP Address restrictions using Internet Service Manager, as described earlier, to block all requests outside your intranet. Alternatively, you can put your IM server behind Internet Security and Acceleration (ISA) Server or another firewall that allows publishing of specific Web directories, then publish the directories you want without including the virtual directory used by the IM server.

Blocking Outbound Traffic

If you want to prevent your users from using their IM clients to talk to users outside your firewall, the easiest way to do this is to deploy the Exchange IM client only, because it cannot talk to MSN Messenger clients. Generally, however, administrators are more concerned with blocking all IM traffic, not just that for a particular service—it might not do you any good to block, say, AOL Instant Messenger if you still allow ICQ and Yahoo! Messenger packets to pass through unmolested.

You can certainly block selected traffic at the network level by blocking specific ports, although this can be a bit of a hassle for some IM systems. If you want to completely disallow particular IM services, there’s good news: all of the existing IM services require users to log on. By blocking logon traffic from your network, you can effectively prevent users from using selected IM systems. Table 16-1 shows the ports to block for various types of IM control.

Table 16-1: Throttling Specific IM Service Features

IM System	Feature	How to Block It
AOL ICQ Instant Messenger	Logon	Block outbound TCP port 5190, User Datagram Protocol (UDP) port 4000, and UDP port 4001 to login.icq.com
	File transfer	Block TCP port 3574 (inbound and outbound)
	IM (including voice & video)	Block TCP port 5190, UDP port 4000, and UDP port 4001 inbound and outbound
AOL Instant Messenger	Logon	Block all ports, TCP and UDP, to login.oscar.aol.com
	File transfer	Can’t be blocked; the client dynamically searches for open ports
	IM (including voice and video)	Can’t be blocked; the client dynamically searches for open ports
	Image transfer	Block inbound and outbound TCP port 4443
MSN Messenger	Logon	Block TCP port 1863 to *.msgr.hotmail.com
	Application sharing	Block TCP port 1503
	File transfer	Block TCP port 6891, inbound and outbound
	IM (including voice and video)	Block UDP ports 13324 and 13325
Yahoo! Messenger	Logon	Block all ports to *.msg.yahoo.com and http.pager.yahoo.com
	IM (including voice and video)	Block TCP port 5010

Tip

For extra fun, if you’re using ISA Server and the Microsoft firewall client, you can add the executables used by various IM systems to the Mspclnt.ini file, which has the desirable effect of preventing the named executables from getting any network access. Disable Msmsgs.exe for MSN Messenger, Ypager.exe and Yupdate.exe for Yahoo! Messenger, Aim.exe for AOL Instant Messenger, and Icq.exe for AOL ICQ.

Restricting File Transfers

Table 16-1 shows which ports you should block to turn off file transfer functionality for the four major services. Because these services all depend on nonstandard TCP or UDP ports to transfer files, most firewalls block this feature by default, which is a good thing. If for some reason you want to enable file transfers, be certain that your desktops have adequate antivirus protection: one common hacker trick is to entice gullible users into accepting files that supposedly contain something desirable but that actually contain Trojans. As an alternative, consider deploying a perimeter network solution like ISA that can scan inbound IM traffic for file transfer requests, either throwing those requests away or scanning the file before allowing it to the desktop.

Using Firewalls with Exchange IM

The Exchange IM server includes a component called the Firewall Topology Manager (FTM). The whole purpose of FTM is to tell your IM servers and routers which IP addresses belong to “internal” networks (those that don’t require traversing a firewall) and which ones are external. FTM settings apply to all IM servers in an organization; you control them using the Firewall Topology tab of the Instant Messaging Settings Properties dialog box, shown in Figure 16-3 (look in Exchange System Manager under the Global Settings node). You can specify where the firewalls are, so that the home servers and routers can route packets appropriately.

Figure 16-3: Use the Firewall Topology tab to tell the IM server which networks are directly reachable.

You can also use this tab to tell the IM server to use an outbound HTTP proxy. The National Security Agency’s Exchange 2000 security guidelines recommend doing so, so that all outbound IM traffic is concentrated at a single point where it can be more easily analyzed. This is particularly useful if you’re using a third-party IM content control product to analyze or monitor your IM traffic.

Encrypting IM Traffic

Exchange IM and MSN Messenger use the client/server model to get text IM messages from one client to another. On the face of it, this would seem to preclude the use of IPsec with IM. This is only partly true, though: you can’t use IPsec to secure your MSN Messenger traffic, but you might be able to use it to protect communications for your Exchange IM network. If your IM servers and clients are all on a network you control, then you should be able to create an IPsec policy to opportunistically protect all port 80 traffic from clients to the IM server, as well as between the IM servers themselves.

Voice and video conversations work a bit differently, as the IM clients communicate directly without an intermediate server. (The clients still use their respective home servers and routers to find each other and establish their initial connection.) This is both a problem and an opportunity: it’s a problem because it means that securing server access alone doesn’t help you, but it’s an opportunity because you might still be able to use IPsec to protect conversations between computers on your network. Of course, there’s no guarantee that you’ll be able to establish an IPsec connection between a computer on your network and an arbitrarily chosen outside machine, so be sure to test your IPsec filters and rules before you conclude that your traffic is always being properly protected.

If you want to protect MSN Messenger traffic, Secway (http://www.secway.fr) offers a free client called SIMP (Secway’s Instant Messenger Privacy) that does the trick. SIMP must be installed on each end of the conversation; once activated, it does a Diffie-Hellman key exchange and uses Bruce Schneier’s Twofish-128 cipher to protect the conversation.