Chapter 10: Virus and Junk E-mail Protection | Monitoring and Managing Microsoft Exchange Server 2003 (HP Technologies)

< Day Day Up >

10.1 Protecting yourself from e-mail viruses

Electronic mail (e-mail)–based security attacks have existed almost as long as e-mail has been used. Viruses spread quickly once they enter a messaging system, and the malicious code overloads networks, destroys data, infects files, crashes systems, and significantly affects user productivity. Microsoft’s combination of Outlook and Exchange is a target for malicious code writers because Microsoft has such a large profile and because Outlook and Exchange dominate the marketplace. The virus epidemic has yet to be controlled, and the threat will continue to increase despite the best efforts of Microsoft and antivirus product developers. Any Exchange environment without protection against viruses is a disaster waiting to happen.

The creators of e-mail viruses count on the curiosity of the recipients. Despite the multitude of well-publicized virus attacks, an IDC survey found that 37% of business e-mail users would still open the attachment included in an e-mail message with a subject line of “ILOVEYOU.” In addition, the majority of users would not hesitate to open e-mail with other common virus subject lines if the e-mail appeared to have been sent by someone they knew.

Clearly, part of the solution to the virus problem is user education. Users and Exchange administrators need to learn from each virus attack. E-mail attachments—especially from an unknown sender—are inherently unsafe because they may contain active content or have hidden file extensions. In addition to attachments, HyperText Markup Language (HTML)–formatted messages are also fertile ground for viruses. Simply opening an HTML-formatted message can trigger the virus.

There are several methods that can be used to detect and attempt to prevent viruses from entering your Exchange environment, including the following:

Blocking. You can disallow receipt of attachments or isolate incoming attachments until they can be checked. Blocking has been included in all versions of Outlook since the release of Outlook 2000. Outlook can classify attachments into one of two restrictive levels. Attachments can either be blocked completely (for those with active scripts and executable images) or the user can be forced to save the attachment to a file rather than being able to open the attachment within Outlook.
Virus scanning. Incoming files can be compared against a known database of viral signatures. Of course, the database is static, and you must update it frequently to keep one step ahead of new viruses.
Content filtering. You also can maintain a list of words, statements, senders, or filenames that are denied entrance into (or exit from) your mail system.
Policies and procedures/user education. You can (and should) establish a policy about the file types that contain active content and how operators and users should handle these files. Policy establishment should be accompanied by user education so that users will learn to treat incoming attachments and Internet e-mail with suspicion and will err on the side of safety.
Preparation. You should limit access to network information and systems, such as installation of untested code on Exchange Servers. You should monitor suspicious activity by enabling and checking security auditing and event logging. You should implement a reliable backup and disaster recovery strategy and perform regular recovery exercises to prepare for a particularly nasty virus that may slip into your network.
Code execution. You also could set up a “sacrificial system” in an isolated network zone where you can safely execute and monitor all incoming applications for suspicious behavior.

Although it is possible for you to write your own antivirus scanner using the published Application Programming Interface (API), virus scanning is an area best left to the experts. I recommend that you use the commercially available products. One key concept for virus scanning in your Exchange environment is to provide multiple layers of virus scanning at three vulnerable points in your environment:

Firewalls and gateways. You should use an antivirus scanning product on all external connections—Simple Mail Transfer Protocol (SMTP) relays, connections to Internet, X.400 Message Transfer Agents, and legacy mail connectors.
Exchange Information Store. You should use an Exchange-aware antivirus scanning product to protect the Information Store. You should not run non-Exchange file–based antivirus scanning tools on directories containing Exchange application and database files.
Client desktops. You should perform virus scanning on the desktop systems and secure the desktop operating system. You should reduce automation, such as active script associations, and restrict administrative power of the user as much as possible.

There are several good Exchange-aware antivirus scanning products that you can use to protect the Information Store. The scanner’s effectiveness (i.e., its detection rate) is obviously important, but there are some additional factors you should consider when selecting a product. First, you want to ensure that it supports Exchange 2003, including multiple storage groups, multiple databases within storage groups, attachments, compressed files, HTML-formatted messages, public folders, outbound mail, digitally signed e-mails, encrypted e-mails, front end/back end configurations, clusters, and other Exchange 2003 features that you may have in your environment.

How the antivirus scanner works also is important. You want one that uses the Exchange Virus Scanning API rather than one that uses the Messaging Application Programming Interface (MAPI) interface. MAPI-based antivirus products were the only choice for the first few years of Exchange, and they tended to work fine on systems with few users and a relatively low number of messages. However, they show weaknesses as the number of users or messages increases. MAPI-based products scan message attachments after they arrive in each recipient’s mailbox. They access the newly arrived message using the same MAPI interface that Outlook uses. Because they use the same MAPI interface, a race condition exists between the antivirus software and the user. Because of limitations with the MAPI interface, MAPI-based antivirus products will scan the same attachment multiple times when it is sent to a distribution list. They also cannot scan encrypted messages or outbound messages. Virus Scanning API-based antivirus products scan message attachments—both inbound and outbound—as they are copied to the Information Store, before they arrive in the user mailboxes, thus eliminating the race condition. Virus Scanning API-based products still cannot scan inbound encrypted messages, but they can scan outbound encrypted messages before encryption.

From a management perspective, you want to be sure to select antivirus products that support scheduled, automatic updates of the virus signature files; can distinguish between externally and internally generated messages; support remote installation, monitoring, updating, and management on all your Exchange servers; provide a choice of mechanisms to alert you about attacks; allow you to customize the alert messages that are sent to administrators, to the intended message recipient, and to the sender; and provide an administrative console that is either web-based or integrated into Microsoft Management Console. You also will want to ensure that you provide enough processor horsepower for the antivirus scanner. Inadequate processor horsepower will increase the number of messages queued waiting to be scanned, will increase delivery times, and will decrease user satisfaction. Just as important as having the antivirus products is ensuring that the virus definition files are updated frequently to ensure the best possible protection of enterprise data.

< Day Day Up >