Designing Defense in Depth

Most administrators think of virus defense as a single layer: put a virus scanner on your Exchange server and you’re done. In practice, this is a workable approach, but it ignores the fact that viruses can enter the messaging network in several different ways. To build the best possible defense, you should understand the various entry points and the strengths and weaknesses of protection systems that scan each of them.

Note

Agronomists talk a lot about crop diversity and monoculture, because a farmer who plants only one strain of a given crop is more vulnerable to crop failure than one who plants several different variants. Antivirus software works the same way. Even though antivirus product vendors usually offer attractive package deals, you should consider using desktop, perimeter, and Exchange scanners from at least two different companies. Why? The more diversity you have, the greater the likelihood that at least one of your vendors will produce a signature update that catches the next big virus before you get a major infection.

Perimeter Protection

The best way to block viruses is to stop them from entering your network in the first place. In turn, the best place to stop viruses is at the perimeter entry points; in the case of an Exchange organization, that means scanning for viruses at the messaging perimeter. The easiest way to do this is by adding a virus scanner to your Simple Mail Transfer Protocol (SMTP) gateway. You can do this by simply adding an Exchange-aware scanner to your Exchange SMTP bridgehead; if you prefer, you can use a separate machine running something like Trend Micro’s InterScan VirusWall (http://www.trendmicro.com) or an appliance like CipherTrust’s IronMail (http://www.ciphertrust.com).

No matter how you implement it, the goal of your perimeter protection is simple: scan all inbound messages and quarantine any that are infected. Every message you catch at the perimeter cannot infect your store or any of your mail clients, connected or disconnected. As a bonus, perimeter scanners typically scan both ingoing and outgoing mail. The first time your scanner catches an infected message addressed to a customer or business partner, you’ll be glad you invested in a perimeter scanner. You can also think of perimeter scanners as warning devices: if you see the scanner catching infected outbound messages, that’s an effective warning that you have an infection somewhere on your network.

SMTP-based virus scanners come in a variety of forms. The simplest are SMTP proxies that look like regular SMTP servers. They accept mail just like a regular SMTP server would, then they scan it. Infected messages are quarantined, released, or dropped (usually with a nondelivery report [NDR]). In essence, these proxies are SMTP filters that inspect your SMTP traffic and pass it on to the Exchange server without interacting with Exchange in any way. Virus scanning is often bundled with other features that make sense to put in SMTP proxies, including content inspection (see Chapter 9, “Content Control, Monitoring, and Filtering”). Some proxies are implemented as software that runs on a Windows server (usually leveraging the built-in Microsoft Windows 2000 SMTP server, on which Exchange’s SMTP engine is based), whereas others are built into firewalls or security appliances.

Another, somewhat more complex, implementation involves scanners that run on your Exchange server. For Exchange 2000, these are most often implemented as event sinks that catch incoming SMTP messages before they are processed for delivery; some products run as SMTP services that accept mail on the default port and reroute it to a different port (requiring your Exchange server’s default virtual SMTP server to be assigned the new port number, which is a big hassle for message routing). One difficulty with these scanners is that you usually cannot combine an SMTP scanner with one that scans the Information Store, meaning that if you use a single Exchange server (or if you combine the mailbox server and SMTP bridgehead roles for other reasons) you might have to choose between implementing these two layers.

Which type of perimeter scanner is right for you? For small or low-budget sites, you’ll probably want an event-sink-based scanner that can run on your SMTP bridgehead. Examples of this class of product include GFI’s MailEssentials for Exchange and Nemx’s Power Tools for Exchange package. For larger sites, or those with higher mail volumes, an SMTP proxy, like Trend’s InterScan VirusWall, GFI’s DownloadSecurity for ISA Server, Sybari’s Antigen, Cisco’s PIX, or CipherTrust’s IronMail might be more effective. These products give you the luxury of an additional degree of separation—an “air gap,” if you will—between your Exchange servers and the world of Internet SMTP mail. As a bonus, the perimeter scanner also can provide redundancy so that mail will be accepted and queued in the event your SMTP bridgehead server has an unexpected failure.

Desktop Protection

Well before desktop e-mail became commonplace, desktop virus scanners like Norton AntiVirus and McAfee’s line of products had moved from luxuries to being desktop essentials. The inventiveness and destructiveness of virus writers (not to mention the relentless media hype that accompanied viruses—remember the stir over the Michelangelo virus?) meant that most desktop users opted to protect their systems themselves. This trend has continued, as most of the major consumer-level hardware vendors (including Dell and HP/Compaq) include some type of desktop antivirus scanner on their machines, and at most corporations the norm is to require the use of a specified antivirus package for all systems connected to the network.

You might wonder whether desktop scanners can really help provide better messaging security, and the answer is an emphatic “Yes!” Let’s start with the obvious fact that a decent desktop scanner protects you from the many ways in which your users can introduce infected material into your network. These ways range from the preventable (opening virus-infected attachments received through an external mail account) to the accidental (installing software from a CD that came from the vendor with a virus). Because some viruses can infect executables and then spread themselves through e-mail, every virus you catch at the desktop is one that can affect your messaging environment. This is particularly true for Trojans, because they can easily steal passwords or other sensitive information that can be used to compromise other systems. From a messaging perspective, then, the most important attribute of your desktop scanner is its existence. There are a wide range of desktop scanners out there; the one you choose largely depends on whether you’re trying to avoid a monoculture, whether the scanner runs well on your hardware, and whether your users are comfortable with it. (For extra security, choose a scanner that can be controlled through Active Directory group policies; this is a nice way to ensure that users don’t circumvent your scanning policies.)

Exchange Server Protection

Many administrators think that they’re getting adequate protection if they have a virus scanner installed on their Exchange servers. Of course, adequate is a loaded term. After learning about risk and threat assessment in Chapter 4, “Threats and Risk Assessment,” and Chapter 5, “Physical and Operational Security,” you might find that what was once adequate is now insufficient. First, there is one key thing you must know and do: if you’re going to run an antivirus scanner on your Exchange server, you have to do one of two things, either make sure that the scanner is an Exchange-aware product, or prevent it from scanning the Exchange databases, log files, queues, and files on the M pseudo-drive.

Exchange-aware scanners are smart enough to scan the message and public folder stores using Exchange’s interfaces (described in the next section) and quarantine or fix items at the message or attachment level. Ordinary file-based scanners have no clue about Exchange or its databases, so a file-based scanner might very well find a virus-like signature in the middle of one of your EDB or STM files, then decide to “fix” it in such a way that the database is rendered useless.

Caution

It’s perfectly acceptable to use a file-based scanner on your Exchange server, as long as you avoid scanning Exchange’s databases, logs, and Message Transfer Agent (MTA) queues. Microsoft Knowledge Base article Q328841 also recommends not scanning the Site Replication Service (SRS) databases (Exchsrvr\Srsdata) and any files in %SystemRoot%\System32\Inetsrv. However, most of the Exchange-specific scanners can also do file-level scans on the server, so you don’t gain anything by using a non-Exchange-aware product on your servers.

Understanding Exchange Antivirus Tools

The Exchange antivirus market is booming as administrators and information technology managers fight to keep viruses out of their messaging systems and off their networks. That’s good news for vendors, but it can be difficult to keep track of the solutions available. The two key variables to understand when choosing a server-based antivirus tool are which scan engine the tool uses and how it accesses Exchange data.

Choosing a Scanning Engine The various antivirus product vendors all make claims about the efficiency of their scanners and the timeliness of their signature updates. Some vendors, like Symantec and Trend Micro, build their own scan engines; others license engines from third parties (one popular choice is the Sophos engine). There’s not a great deal of difference between these engines: the computer science behind efficient scanning of blocks of data is well understood, and all of the existing engines do a good job of scanning. However, the scanning engine is only a small part of the overall antivirus software. It’s more important to choose a product that integrates well with Exchange and has a history of fast signature updates.

Scanning Exchange Data How well an Exchange-based scanner works depends on how it accesses data in the message stores. Exchange uses an essentially undocumented set of application programming interfaces (APIs) for storing data in EDB files, so antivirus product vendors have generally been limited to using two supported methods for scanning message contents.

The first method is very familiar: MAPI-based scanners log on to each mailbox in a message database and scan messages by requesting them using MAPI procedure calls—exactly the same way that Outlook works. This has the advantage of being well-supported and well-understood, but it has some serious disadvantages as well. First, MAPI scanners typically suffer from the same problem that afflicts other MAPI-based server products: MAPI is a very slow way to enumerate and process all messages on a server. Its native lack of speed is exacerbated because it doesn’t understand single-instance storage. If I send a large message to 2000 recipients, that message has to be retrieved and scanned 2000 times even though there’s only one “real” copy of it in the database! As if that weren’t bad enough, MAPI scanners also pose a small but real security risk. Consider the case in which a message addressed to Joe Worden arrives in the store. A new message notification is sent to Joe’s client. Joe just happens to be sitting in front of his computer, so he opens the message—before the MAPI scanner has had a chance to scan it. Although this is relatively rare, it can certainly happen. Finally, MAPI scanners cannot scan outbound SMTP messages, nor can they scan Outlook Web Access, Post Office Protocol version 3 (POP3), or Internet Message Access Protocol version 4 (IMAP4) traffic, because none of those protocols use MAPI as a transport.

For these reasons, Microsoft realized that MAPI wasn’t the best possible means of scanning for viruses, so they developed and released AVAPI (also known as VAPI). Version 1 of AVAPI shipped with Exchange 5.5 Service Pack 3, and AVAPI version 2 is included in Exchange 2000 Service Pack 1 and later. AVAPI scanners use the AVAPI interfaces to scan message bodies and attachments using a queue-based system. There’s a single scanning queue; to scan a message, the antivirus tool adds it to the queue with either high or low priority.

• Items submitted to the store (either by a client or by the transport core) are tagged for proactive scanning and added to the queue with low priority. If the queue fills up, items are removed on a first-in, first-out basis. This isn’t as bad as it sounds, because any item that doesn’t get proactively scanned on submission is still marked for a scan when it’s next opened.

• When the user opens an item, AVAPI checks that item (and its enclosing folder) for a special MAPI property (ptagVirusScannerStamp) that indicates whether the item has been scanned with the current virus signature. If it has, no further scanning is necessary. If it has not, the item is marked as high priority. If the user tries to open an item that’s already in the queue for a proactive scan, the item’s priority is upgraded so it can be scanned immediately.

• A background scan process opens each message folder and checks for the ptagVirusScannerStamp value. If the stamp is up to date, the folder and its contents are skipped. If not, each item in the folder is scanned if necessary and stamped once the scan completes. This might sound like a haphazard approach, but it’s not: remember that background scans are designed to recheck already-scanned items after a signature change, so it’s fine to skip folders that have been recently scanned. New items that are added to the folder are scanned either when they’re submitted or when they’re opened.

AVAPI has a number of advantages, not least among them that it’s a supported API that Microsoft has promised to support and improve (contrasted with MAPI, which gets an occasional bug fix but which has been largely moribund since 1996). However, it has some flaws, too. In particular, many administrators are unhappy with the notion that the AVAPI queue can fill up and leave some messages unscanned during a proactive or background scan. In addition, early versions of AVAPI didn’t expose much of the information needed to accurately report the location of the virus (this has been fixed in AVAPI 2). To combat these complaints, some vendors use AVAPI for on-demand scanning but fall back to MAPI for proactive scanning.

At the start of this section, I said that antivirus product vendors have generally been limited to using AVAPI or MAPI. There’s actually third way for antivirus products to access the database: using the Extensible Storage Engine (ESE) routines that Microsoft uses internally. As you might imagine, the ESE APIs aren’t public, so vendors that use them have had to do a significant (and technically impressive) amount of work to get their products to work with the ESE routines. Sybari’s Antigen and Trend Micro’s ScanMail (for Exchange 5.5, not Exchange 2000) use this approach, as either a supplement or replacement for the other methods. They accomplish this by loading their own “shim” dynamic link library (DLL), which in turn loads the real Ese.dll. By doing so, their shim’s functions get first crack at data written to the EDB and STM files. Microsoft’s support policy for these tools is that they are officially not supported by Microsoft’s Product Support Services (PSS), but if you turn off the tool, PSS will help you:

Customers who contact Microsoft Product Support Services may be asked to disable the Sybari Antigen service to help identify issues, but customers are free to enable the software again after the root cause of the issue is properly diagnosed. Microsoft and Sybari agree that this is a valid troubleshooting step to determine the cause of issues.

Evaluating Exchange Antivirus Products

When selecting a set of antivirus products, there are a lot of questions to consider. In the earlier sections on perimeter and desktop scanners, we covered some points to consider. However, the most critical piece of your antivirus design is probably the part that runs on your Exchange server. It is most likely to see heavy use during an e-mail-borne virus outbreak, and if it breaks (or breaks some other component), you’re more likely to notice it than you would be if a single desktop or perimeter scanner malfunctioned. Some of the questions here are applicable to desktop and perimeter scanners, too, but most of them are focused on choosing the best possible server-based solution for your needs.

The first set of questions revolves around your messaging infrastructure:

1. What kind of servers (Exchange 5.5? Exchange 2000?) do you have, and how many of them are there? Are any of them clustered or multiprocessor machines? Not all antivirus products are cluster-aware, so if you use a non- cluster-aware product and your cluster node fails over, the surviving node might not get any antivirus protection. AVAPI is multithreaded, so it can take advantage of multiple CPUs if they’re present.

2. How are your servers organized? Do you have separate SMTP bridgeheads that you want to protect with perimeter scanners? How about Exchange front-end servers that accept SMTP traffic?

The second group of questions focuses on the actual scanning mechanisms that the product uses:

1. What can you do with infected messages or files? All most sites want is the ability to delete the infected attachment or message and log an event, but some sites want or need to quarantine suspected infections for further investigation.

2. Are there any content or message types that cannot be scanned? Be sure to verify that your scanner of choice correctly identifies encrypted attachments (including .zip files) and digitally signed or encrypted messages sent using Secure Multipurpose Internet Mail Extensions (S/MIME). You might prefer to have a product block or quarantine any messages that it cannot scan.

3. What interface do you want your scanner to use: AVAPI, MAPI, or ESE?

4. How flexible are the scanning criteria? Can you exclude selected folders from manual scans? Does the scanner support any kind of heuristics that attempt to catch macro viruses that don’t exactly match known patterns?

5. How configurable are the notification options? Can you silently drop messages? Can they be returned to the sender, or allowed to reach the recipient with the infected parts removed?

6. Is the scanner integrated with (or perhaps compatible with) any content- filtering software?