|
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:
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.
|
|
|
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:
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:
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:
AOL Instant Messenger Perform the following steps to block the AOL Instant Messenger:
MSN Instant Messenger Perform the following steps to block the MSN Instant Messenger:
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:
HTTP Redirector ConfigurationAnother 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! Notes 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 www.isaserver.org message boards. You can also write to me at tshinder@isaserver.org and I'll get to you as soon as I can. Please put the title of this article in the subject line. Thanks! --Tom. | |
