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 and wherever your network connects to others, especially for virtual private network (VPN) connections to home users or business partners .

The easiest way to add perimeter protection is by adding a virus scanner to your Simple Mail Transfer Protocol (SMTP) gateway. You can do this by simply adding a scanner in front of your Exchange SMTP bridgehead. Scanners range from plug- ins for the Microsoft ISA Server to stand-alone products that use the Windows SMTP server to integrated SMTP products like Trend Micro s InterScan VirusWall ( http://www.trendmicro.com ) to multipurpose security appliances like CipherTrust s IronMail ( http://www.ciphertrust.com ).

One important change in Exchange Server 2003 relates to the way inbound messages are processed . You might think that an SMTP bridgehead wouldn t have any mailbox databases on it; actually, the SMTP core needs a single database mounted so it can create a mailbox to use for creating nondelivery reports (NDRs). However, the AVAPI interfaces that Microsoft wants antivirus vendors to use work on messages that are submitted to the store. The unfortunate result of this is that AVAPI-based scanners wouldn t do anything useful on Exchange 2000 SMTP bridgeheads. Exchange Server 2003 includes an updated version of AVAPI ”version 2.5 ”that provides a means for AVAPI-aware scanners to run on bridgeheads. Inbound messages are routed to the store, where AVAPI can scan them, but uninfected messages aren t persisted in the store after the scan; instead, they re sent on to the next routing hop, although with a property tag that indicates that they ve been scanned and found to be uninfected.

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 an 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 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 Server and Exchange Server 2003, 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 SecurityAgent, 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; when the bridgehead returns to service, the perimeter scanner will pass the queued mail on for delivery.

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. Microsoft goes one step further for its internal network by checking to ensure that its standard antivirus package is installed and running on all machines that connect to its 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). In fact, I know of several corporations that caught the Blaster worm when infected laptops were brought in and connected inside their network perimeter. Microsoft has a great white paper that describes the policy and tools it applies, which include the use of the Microsoft Windows Server 2003 RAS quarantine feature and a custom client-side script, or connectoid, that checks each VPN-connected system to ensure that it s running the Microsoft standard antivirus scanner. See http://www.microsoft.com/technet/itsolutions/msit/security/srutcase.asp .

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 ones you choose largely depend 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 in conjunction with Exchange-aware scanners, as long as you avoid scanning Exchange s databases, logs, and message transfer agent (MTA) queues . Microsoft Knowledge Base article 328841 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. Of course, fast is relative; what s important is that your vendor be fast compared to the emergence and spread of new threats like SoBig.F, which is a pretty high standard to meet.

Scanning Exchange Data

How well an Exchange-based scanner works depends on how it accesses data in the message stores. Exchange uses a private 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 approach 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 MAPI has no concept of 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 risk that a virus will leak through. 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 s certainly possible. Finally, MAPI scanners cannot scan outbound SMTP messages, nor can they scan Microsoft 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; AVAPI version 2 is included in Exchange 2000 Server Service Pack 1 and later, and AVAPI 2.5 is included in Exchange Server 2003. 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 was 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 a 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 versions for Exchange 5.5 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. The Microsoft support policy for these tools is that they are officially not supported by Microsoft Product Support Services (PSS), but if you turn off the tool, PSS will help you, as described in Microsoft Knowledge Base article 328841:

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.

Of course, it is critical that you turn your antivirus system back on when you re done troubleshooting it ”don t be like the firm I encountered that turned off their antivirus system for troubleshooting and didn t remember to reenable it until a full- blown outbreak was in progress.

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? Exchange 2003?) 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 logical or physical 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? (Remember, those front ends can only use AVAPI scanners if they re running Exchange Server 2003 and you re using an AVAPI 2.5 “compatible scanner.)

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. How flexible are the notification options? A growing number of sites are turning off those obnoxious You sent us an infected message notifications in the wake of the SoBig virus, which sends out staggering numbers of messages with forged headers. Can you silently drop messages? Can they be returned to the sender, or allowed to reach the recipient with the infected parts removed?

  3. 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.

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

  5. 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?

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

  7. Is the scanner s alerting module semi- intelligent ? If a new outbreak happens, do you really want 100,000 pager messages (one per infected message) at 3 A.M., or would you settle for a smaller number?




Secure Messaging with Microsoft Exchange Server 2003
Secure Messaging with MicrosoftВ® Exchange Server 2003 (Pro-Other)
ISBN: 0735619905
EAN: 2147483647
Year: 2004
Pages: 189

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net