How to Block Dangerous Instant Messengers Using ISA Server

I get a lot of questions about how can ISA Server be used to block dangerous applications. What is a dangerous application? I suppose that depends on whom you ask, but the following list includes some of the most frequently mentioned:
  • MSN Instant Messenger
  • AOL Instant Messenger
  • ICQ
  • Yahoo Instant Messenger

I consider all of these applications dangerous. These applications allow file transfer and communications to bypass the ISA Server’s normal filtering and content management systems. If you’re looking for a secure networking environment, it’s a good idea to block all of these.

Configuring ISA Server 2000 : Building Firewalls for Windows 2000
By Deb and Tom Shinder

Instant Messengers have more than just negative security effects. You should consider lost productivity due non-business related “chatting” and interruptions to the normal work flow. While Instant Messaging is useful for pre-teen girls checking up on the status of their Hello Kitty, they don’t have much use in a business environment.

The exception to this is when Instant Messengers are used to allow employees to communicate with each other on the corporate network. Instant Messengers can be put to good use on the internal corporate network as a supplement to phone calls and email messages.

We need some way to prevent these applications from interacting with Internet users. The best way to handle this is to devise a network usage policy that forbids the use of these applications and have the management back up this policy. Management support is a must if you want the usage policy to have some teeth in it.

After the network usage policy is in place, you can use the ISA Server Firewall service log and application inventory reports to determine who has been using forbidden programs. You can create a report based on these resources and present the information to the user’s supervisor. This is usually quite effective in getting the offender to stop forbidden behavior.

However, not all businesses are able or desire to prevent dangerous application usage in this sort of “up front” manner. Companies have different corporate cultures. You may find yourself with no support for a network usage policy. If this is your situation, you’ll need to implement “stealth” measures to prevent users from compromising network security.

A great way to do this is by taking advantage of the Firewall client. The Firewall client software can be installed on all Microsoft network capable operating systems except for Windows 3.x. You can still take advantage of the Firewall Service for Win 3.x clients by installing the Proxy Server 2.0 Winsock Proxy client on them. In fact, I recommend installing the Firewall client on all operating systems that the Firewall client can be installed on.

Blocking Network Applications Using Firewall Client Configuration

You can make changes to the mspclnt.ini file on the ISA Server. This file contains configuration information for Firewall client machines. It is downloaded from the ISA Server to the ISA clients every six hours by default. This file is stored in different locations on the client machines depending on the operating system.

Your first step is to figure out what the name of the executable file is for the offensive application. The following list includes the common dangerous applications and their .exe files:

  • AOL Instant Messenger – AIM.EXE
  • MSN Instant Messenger – MSMSGS.EXE
  • Yahoo Instant Messenger – YPAGER.EXE and YUPDATER.EXE

After you figure out the executable file name you can configure the mspclnt.ini file to block network communications from the application.

Perform the following steps to configure the mspclnt.ini file:

  1. Open the ISA Management console, expand Servers and Arrays and expand your server. Click on the Client Configuration node, and then double click on the Firewall Client entry in the right pane.
  2. You will see the Firewall Client Properties dialog box as seen in the figure below. Click the New button.

  1. After clicking the New button you will see the Application Entry Settings dialog box as seen below. Type in the name of the application without the file extension in the Application text box. Type the letter D in the Key list so that Disable appears. In the Value list, type the number 1. Click OK after making these changes.

  1. After making the changes to block the application, you need to wait until all clients have downloaded the new mspclnt.ini file. You either have to wait for 6 hours, or you can force the clients to download the file by going to each client and clicking on the Update Now button in the Firewall client configuration dialog box.
  2. After each Firewall client machine has downloaded the updated mspclnt.ini file, you must disconnect all Firewall Client sessions from the ISA Server. You can do this by going to the ISA Management console and manually disconnecting the sessions (as seen in the figure below), or you can restart the Firewall Service. Restarting the Firewall Service will cause all Firewall client connections to drop.

  1. If any of the clients are configured as SecureNAT clients, change their configuration by removing the default gateway address. The SecureNAT client will be able to get around the limitations you set in the wspclnt.ini file. You can configure the Windows 2000 Group Policy to block user access to the Network Connections Control Panel applet.

This is the first step in your access control configuration. Because some clients must be configured as SecureNAT clients, and because all of these applications can get around the mspclnt.ini configuration, there are some more steps you’ll have to perform.

Application Specifics

It would be nice if we could configure all computers as Firewall clients and leave it at that. However, like all good malware, these dangerous applications can allow outbound connections through alternative means. Many of these applications allow the user to configure them as Web Proxy or SOCKS 4 clients (ISA Server does not support SOCKS 5 out of the box).

In addition to having to deal with users who reconfigure their applications, you also have to deal with applications that can scan the network and find a hole. Some of the applications can use stealth techniques and grab the browser’s Web Proxy client configuration without your knowledge. Therefore, you’ll have to do more than just configure the mspclnt.ini file

Yahoo Instant Messenger

Perform the following steps to block the Yahoo Instant Messenger:

  1. Block the YPAGER.EXE and the YUPDATER.EXE executables in the mspclnt.ini file
  2. Create a Site and Content rule that blocks Remember to create a Destination Set that includes this site so that you can create the Rule.
  3. The SOCKS4 Application Filter must be disabled. Users can reconfigure the Yahoo IMer as SOCKS 4 or SOCKS 5 clients. ISA Server does not support SOCKS 5, but they can get out using SOCKS 4. Since few legitimate applications require SOCKS, you can safely disable the filter.

AOL Instant Messenger

Perform the following steps to block the AOL Instant Messenger:

  1. Block the AIM.EXE executable in the mspclnt.ini file.
  2. From my testing, the AOL IMer doesn’t seem to be able to get around the mspclnt.ini file configuration, even if you set it up as a Web Proxy client in the AIM configuration dialog box. Therefore, you do not need to create a Site and Content Rule to block the domain.
  3. Like the Yahoo IMer, AOLer can get around the mspclnt.ini file configuration by setting up the application to use SOCKS 4. Therefore, you will need to disable the SOCKS4 application filter to keep this application locked out.

MSN Instant Messenger

Perform the following steps to block the MSN Instant Messenger:

  1. Block the MSMSGS.EXE executable in the wspclnt.ini file.
  2. It appears that “sometimes” the MSN Instant Messenger is able to detect the proxy settings in the web browser. From my testing, it appears that it does not find the browser settings when IE 5.0 is the browser, but will find the browser settings on an IE 5.5 machine. It could also be an issue with “point” releases of the MSN IMer.  This stealth discovery of the browser settings is not a configuration option. It is done in the background and without your knowledge.
  3. Create a Destination Set that includes the IP address range – Then create a Site and Content rule that denies access to this Destination Set. Keep in mind that this network ID might change in the future. If you find users are able to connect using the MSN IMer in the future, review Firewall Service logs to determine the new network ID.
  4. Note that creating a Site and Content rule that blocks will not prevent access.

ICQ 2000b

We only tested the latest version of ICQ, which appears to be ICQ 2000b. Perform the following steps to block this version of ICQ:

  1. Block the ICQ.EXE file in the mspclnt.ini file.
  2. Create a Destination Set that includes the following sites:
  3. Create a Protocol Rule that denies access to the Destination Set you created above.
  4. Setting the ICQ client to use SOCKS 4 does not appear to allow the client outbound access when the above steps are taken. However, it is still a good idea to disable the SOCKS 4 application filter in order to block the other IMers.

HTTP Redirector Configuration

Another thing you can do to help take a bite out of crime is to configure the HTTP Redirector Filter to drop all requests from Firewall and SecureNAT clients.

After configuring the HTTP Redirector Filter, go to the Outgoing Web Requests listener and force authentication.

Many of the IMers do not know how to send client credentials to the Web Proxy service. If the client cannot properly authenticate, it will not be able to gain access to the Web Proxy service. If it can’t access the Web Proxy service, it won’t be able to use HTTP to connect to the offending site.

Note that some of these IMers, such as the Yahoo Messenger, will not work if you require any sort of authentication. I ran into this when I was actually trying to make this work for a client who I could not convince regarding the security hazards of IMers (he ended up receiving a virus from a “friend” through the fire transfer later).

I had a Protocol Rule that allow all IP traffic and used the default Site and Content Rule. However, I couldn’t get the dreaded Yahoo IMer to work. The problem was that my Bandwidth Rules were based on users and groups. The funny thing was that the rule governing HTTP access was configured to let everyone through. It was an NNTP Bandwidth Rule, which was not being used, that prevented access!


When investigating how to block these applications, I was surprised to discover the various methods that each one used to get around the Firewall client configuration. What was even more interesting is how it appeared that some of them could get around the Web Proxy Service configuration and use SOCKS, while other ones could not get around the Web Proxy service.

I found the behavior of the MSN Instant Messenger to be particularly annoying. In the configuration dialog box for the network connection there is an option to use a proxy server. One would assume that if you choose to not use a proxy server, the client would have to use the Firewall client in order to connect to the ISA Server. However, the MSN IM’er was able to get around this on some machines, apparently probing the system for the browser proxy settings.

A good general practice whenever you create a Deny Site and Content Rule is to redirect the request to an internal web site. Some of the applications locked up or created memory faults if you did not redirect the request. This is more of an issue with how Site and Content Rules work than it is an issue with blocking these IMer applications.

If you use Windows 2000 Professional network clients, you can block these applications through Group Policy. Group Policy allows you to prevent the execution of program files used for each of these Instant Messaging applications. However, users can get around this restriction by simply renaming the file. You could prevent users from having access to the Windows Explorer or the Run command, but when you get to this level of lock down, machine usability becomes an issue.

A last trick you might want to keep in your bag is to configure a Bandwidth Priority of 1 for those users that want to use IMer’s. When the users call you and ask why the Internet is so slow, ask them if they are using an IMer. If they say yes, tell them that is “interfering with the Internet and they must remove the application immediately”. That is usually good for initial reconnaissance. They you can watch them for future abuses.

I hope you found this article interesting and/or helpful. If you have any questions on the issues brought up in this article, please post them on the message boards. You can also write to me at [email protected] and I’ll get to you as soon as I can. Please put the title of this article in the subject line. Thanks!  –Tom.

About The Author

Leave a Comment

Your email address will not be published. Required fields are marked *

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top