Practice safe email!
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.
Prev. page
[1]
2
next page 
