For years, virus checking has been one of my favorite topics. I often speak and write about the need to protect email servers (see "Lessons from the Melissa Virus," Exchange Administrator newsletter, June 1999), and I'm always amazed by how many people take a lackadaisical attitude toward protection. The popular opinion is usually "It's only email; nothing bad can happen to me."
Now that the Melissa virus has kicked us all in the pants and the Worm.ExploreZip virus has bored its way through our companies, I want to stress the importance of running a virus checker.
The Nature of Email Viruses
Today's viruses typically come to you as attachments to messages. I haven't yet seen an HTML-based virus that can transmit inside a message's content, but that possibility's long-term potential certainly exists now that clients such as Microsoft Outlook 98 and Outlook 2000 support HTML as a base format for message composition.
Traditional viruses circulate as executables or Zip files. The most recent viruses leverage the capabilities of macro languages such as Visual Basic for Applications (VBA) to execute commands that propagate the virus and inflict its damage on the infected PC. Because VBA is the common macro language for Microsoft Office applications, it has become popular in the independent software vendor (ISV) community; many popular vendors build VBA support into their desktop applications (e.g., Visio). Therefore, virus authors can predict VBA's availability on a large percentage of the desktops they want to target. As we've seen recently, VBA's power—combined with easy access to complex objects (e.g., mail messages, mailboxes) through the Collaboration Data Objects (CDO) interface—gives virus authors many havoc-wreaking tools.
Unaware users' faith in their messaging system provides the last chink in the server's armor. Despite abundant warnings, people still implicitly trust whatever appears in their Inbox, especially if the message seems to have come from someone they know. Virus writers exploit this trust by instructing the virus to generate messages that users might expect to receive. Both Melissa and Worm.ExploreZip generate messages with straightforward text that you might see in a message from a coworker who wants you to review a file. Of course, the attachment contains the damaging payload, but users lured into a false sense of security proceed to open the attachment and examine the contents. A gap will always exist—albeit perhaps only a few days or even a few hours—between the first reports of a circulating virus and the moment that antivirus vendors update the signature files to let their virus scanners identify and disinfect the virus. Users need to be vigilant about the type of attachments they open; otherwise, they're susceptible to viruses.
Two APIs for Exchange Server
Microsoft Exchange Server is a powerful messaging engine, but its APIs leave something to be desired. Messaging API (MAPI) is the predominant API today, and almost every antivirus vendor has taken the approach of mimicking a connection to each mailbox. In other words, the virus scanner logs onto each mailbox and waits for new messages to arrive, then jumps into action to check any attachments for infections. This logging-on approach works effectively, but users can potentially open messages before the virus scanner checks the content, thus creating a vulnerability. Since 1996, I've run the most popular MAPI-based scanner, Trend Micro Antivirus for Microsoft Exchange (http://www.antivirus.com), and can't recall a virus getting past. However, the logging-on approach obviously has limitations.
An antivirus product that logs on and lurks in the background waiting for messages to arrive presents disadvantages at an architectural level. In practice, users and systems administrators probably won't notice these disadvantages. However, you need to know about them to better understand the solution.
Typically, when an infected message arrives, the antivirus product intercepts and disinfects the message at the mailbox level, then treats the disinfected content as an Information Store (IS) update. This process occurs just as if a user had opened the attachment, made changes (e.g., edited the attachment's content), then clicked OK to commit the changes to the IS. If 20 users receive the same infected message, the antivirus product must perform the disinfection process and update the IS with the new content 20 times. This activity results in a heavier demand on system resources (i.e., CPU and memory), as well as duplicated content in the IS. Twenty recipients shared the original attachment (i.e., the one attached to the message when it first arrived), so the IS keeps only one copy of the content. However, after a user updates the attachment, the IS keeps a separate copy for that user. These architectural restrictions have only a minor impact on your server, so using system resources to protect the server with an antivirus product is preferable to exposing your system to an undetected virus.
Sybari Software is the most recent antivirus vendor to announce Exchange Server support. The company's product, Antigen 5.5, uses the Extensible Storage Engine (ESE) API instead of MAPI as its route into the IS. ESE is the underlying database engine that powers the IS. Backup products such as Cheyenne's ARCserve and VERITAS Software's Backup Exec are the most common users of the ESE API; these products use the ESE API to attach to the IS and read data to storage media. The Antigen scanner uses the ESE API to monitor new attachments as they enter the IS, then disinfects them if necessary. Antigen uses a single point of contact instead of multiple logons to individual mailboxes. If an infected attachment arrives, Antigen detects and disinfects it only once, and all users then share the disinfected content. The technique sounds too good to be true, especially considering that Antigen supports both Alpha and Intel and will support Exchange Server clusters in its forthcoming 5.5 release (currently in beta).
Platinum, Exchange Server's next major functionality release, simplifies system integrators' jobs by providing a wider range of interfaces. For instance, serverside event processing is present in many components of the product, including the transport, routing, and storage subsystems. Platinum supports synchronous and asynchronous events, so an antivirus product can insert a synchronous event that fires each time an attachment arrives, and calls a scanner before committing any content to the IS. After Platinum ships, all the major antivirus vendors will probably upgrade their products to take advantage of serverside events.
A Hot Exchange Server Debate
If you follow the discussions in Swynk.com's Exchange Server Internet mailing list, you know that the Exchange Server community considers MAPI the favorable route into the IS. In fact, suspicion surrounds any product built on a different API, perhaps because Microsoft doesn't advertise that you can use any other API. Because some antivirus products have a reputation for corrupting Exchange Server databases, the suspicion is probably warranted. However, I believe that any corruption is probably because of a combination of circumstances (e.g., software, hardware, operations) rather than one product going haywire.
When Sybari announced Antigen, the company faced a barrage of questions. Sybari aroused further suspicion when it wasn't exactly forthcoming about the way Antigen accessed the IS. Quite understandably, the company viewed its silent approach as a competitive advantage and didn't want to discuss the matter in public. If you have any knowledge of the public APIs available for Exchange Server, Sybari's move from MAPI to ESE doesn't require a huge leap of logic. But the company's failure to communicate under pressure gave Antigen a bad name.
To some degree, Microsoft Product Support Services (PSS) has created further pressure by advising callers to remove antivirus products from Exchange servers if any problems arise in the IS. I suspect that this advice is simply a rote response from support staff who probably don't have much antivirus software experience in a production environment. Or perhaps the advice is based on Antigen's earlier troubles.
Running Antigen
The best way to test any product is to run it in as realistic an environment as possible. The company I work for has several Exchange Server organizations, and I opted to deploy Antigen 5.5 Release Candidate 1 (RC1) on the server where my mailbox resides. Call it foolishness or a leap of faith, but if the product works in my environment, it'll probably work anywhere.
Installation was easy. I wanted to see how effectively Antigen detects viruses. Because of some internal restructuring at my company, my server had been unprotected for about 2 weeks. Like most scanners, Antigen lets you perform a complete manual scan of the IS. A manual scan looks for every attachment in every mailbox in the IS. Obviously, the larger the IS, the longer a manual scan will take. Screen 1 shows two jobs enabled on the Antigen administration client. The Manual Scan Job is active and has detected and cleaned some viruses, and a Realtime Scan Job is also running. The realtime scan operates in the background to check attachments as they arrive.
Loading the CPU
Scanning for infected documents will consume some CPU cycles on your server, no matter what product you use. A manual scan generates the heaviest load because it searches for and checks a continuous stream of documents. In my case, using a server with dual 233MHz Pentium II processors, Antigen's manual scan process consumed between 20 and 30 percent of the available CPU cycles. Demand peaked when the manual scan encountered large attachments, such as a 10MB Zip file that contained 15 Microsoft Word documents. Equipping an Exchange server with dual CPUs is a good idea, even if you don't immediately need the extra power. The additional CPU can take the load imposed by high-intensity applications such as a manual scan, smooth out peaks in user demand, and deliver a more predictable response to clients.
Realtime scans make a relatively small demand on server resources. Quantifying the demand is difficult because demand varies with the volume of messages that pass through the server and the percentage of the messages that have attachments. The realtime scan I observed took no more than 5 percent of the available CPU cycles.
As hardware capabilities grow, the load that critical add-ons such as virus checkers and system monitors impose becomes less important. When Exchange Server 4.0 shipped in 1996, the typical server had a 100MHz Pentium processor with perhaps 128MB of RAM and 2GB of hard disk space. Today's servers are much faster, and many of them have multiple processors—not to mention radically improved disk subsystems. Although servers are supporting more users and running more applications, they also have more headroom to accommodate add-ons. Lack of system space and insufficient speed are no longer valid reasons to neglect a virus-checker installation.
Reporting Virus Incidents
Reporting virus incidents with Antigen is straightforward. You can view a virus incident onscreen or export the incident's details to a file for later analysis. Either way, you need to extract an incident's details and mail the information to affected users so that the users realize that they've received infected documents. Screen 2 shows Antigen's reporting options, which include summary statistics of the scanners' work. Exchange Server's single-instance storage model accounts for the difference between logical and physical attachments. Many users can share one attachment. Antigen counts a shared attachment as one physical file with multiple logical links.
In my example, a relatively small server (with a 3GB priv.edb) has 6,139,158 logical links resulting from 30,021 physical attachments. I can only assume that a bug in the beta software caused a miscount. The figures that the realtime scan reported—468 physical attachments with 828 logical links—are more in line with what I'd expect. These numbers provide a sharing ratio of 1.77, roughly equivalent to the value of the single-instance storage ratio counter that Performance Monitor reported on this server (i.e., 1.86). Sybari's development staff is aware of the glitch and promises to address it by the time you read this. Generally, the product's quality is high, and I didn't see any evidence of other bugs.
When I reviewed the virus report, I was intrigued to see that Antigen had detected and cleaned several messages that contained the Worm.ExploreZip virus. Although the scanner had downloaded the latest signature file and I expected that Antigen would detect any new message that contained the virus, I hadn't expected Antigen to detect viruses in messages that had been soft-deleted. Remember that Exchange Server 5.5 introduced the two-stage deletion concept. The software first soft-deletes an item by moving it into a logical deleted items cache in the database, then eventually hard-deletes the item to remove it permanently. You can set a deleted items retention period to retain items in the IS. This setting lets users recover items that they deleted in error. Items in the deleted items cache are soft deletes. Hard deletion occurs after the preset retention time expires. You can set the retention period on a per-user basis or as a default for the entire IS. Most companies choose a 5- to 10-day retention.
I received 22 messages containing Worm.ExploreZip soon after the virus struck one of my company's mail servers. My suspicions were aroused when I read the text of the first infected message; I wasn't expecting any mail from the apparent sender. My suspicions were confirmed when I received the other 21 messages with similar attachments and body text in quick succession. When I exited Outlook, the software deleted the messages in my Deleted Items folder. (I prefer Outlook to empty this folder each time I exit because I don't like to hang on to deleted messages. Others prefer to use the Deleted Items folder as a convenient place to temporarily hold messages.) No apparent trace of the offending messages existed until Antigen found them, because Antigen's manual scan checks every attachment in the IS, including attachments marked with the soft-delete flag that are waiting for their retention period to expire. The majority of messages that Antigen reported in Screen 2 were soft-deleted items. The Realtime Scan Job detected the last message in the list, proving the worth of running the realtime and manual scan jobs in tandem for extra protection.
Supporting Different Virus Engines
Most virus checkers rely on one virus-detection engine. Sybari has licensed three engines that you can integrate with the product. Companies often select a particular virus checker as part of their desktop environment, so the ability to use the same checker on both desktop and server is a plus.
Screen 3 shows that Antigen is using the Norman Data Defense scanner on my server. The screen's bottom pane controls how the software automatically downloads scanner updates (i.e., according to a desired schedule). Sybari offers network-based updates via an FTP connection to the company's Web site. The automatic download feature didn't work for me—probably because of FTP proxy problems—so I had to resort to a local update. Sybari facilitates local updates by offering mail-based update distribution, which requires you to move the updated files to a suitable network share from which Antigen can pick them up. This easy process is probably the way that you'd set up your virus checker in your corporate environment so that one download to a network share would update multiple servers.
Preventing Internet Problems
Most viruses come from the Internet, so guarding this avenue is essential. You can use products such as Trend Micro's InterScan VirusWall (http://www.trendmicro.com) or Content Technologies' MIMEsweeper (http://www.mimesweeper.com) to protect the relay hosts that you use to channel mail from the Internet to Exchange Server, but a vendor that builds this feature into its antivirus software is ahead of the game. Antigen checks both inbound and outbound queues of Exchange Server's Internet Mail Service (IMS). From a user's perspective, scanning inbound and outbound messages produces no discernible delay on message throughput. Again, deploying today's fast systems as bridgehead servers contributes to fast message transmission. The extra overhead won't create problems; it'll only provide greater protection.
Finding the Right Product
I didn't intend this article to be an endorsement of Antigen over all the other antivirus products on the market, but Antigen is an innovative solution to a problem we all encounter. The product isn't perfect—for example, it doesn't protect against viruses that arrive on 3.5" disks or via other non-email routes. However, Antigen protects Exchange Server impressively against infected files that arrive as message attachments or post directly to public folders.
Every product has a unique feature set, and a different product might be more appropriate for your installation. As with any solution, you need to download evaluation versions of a couple of products and conduct tests to see which one best suits your needs. You need to ensure that you're protecting your Exchange server as comprehensively as possible. You can bet that you'll meet a virus one day, so you need to be prepared.
| Antigen 5.5 |
|
Contact: Sybari Software * 516-630-8500 Web: http://www.sybari.com Price: $4995 (to protect 250 users) System Requirements: Windows NT 4.0, Microsoft Exchange Server 5.0 or later |
- Lab Reports: "Antigen 5.5" includes an incorrect email address for the author, Tony Redmond. His correct email address is [email protected]. We apologize for any inconvenience this error might have caused.
