anti-virus solutions for microsoft exchange 2000 server.doc

White Paper

October 200216EE-0302A-WWENPrepared by:Messaging and CollaborationHP Industry Standard Servers Solutions & Strategy

ContentsExecutive Summary..........3

Exchange 2000 and Exchange 5.5 Differences4

Phase 1 - Analyze the Problem......................5

Background on Viruses. .5Phase 2 - Plan for Solutions.....................7

Economic Justification....7Problem Definition.........7Defining Borders of Protection......................8Methods of Prevention or Detection.....................11

Phase 3 - Develop the Solutions...................15

Anti-Virus Software: Selection Criteria.........16Product Selection and Deployment.................19

Phase 4 - Conduct Pilot Testing......................23

Example Detection Circumvention Tests....26

Phase 5 - Deploy the Solution....................36

Comprehensive Solution Definitions....................36Network Security.........39Exchange Server Configuration...............41

Phase 6 – Manage and Maintain....................41

New Threats.................41Appendix: Additional Information...............44

Viral Definitions...........44Research Organizations45Sample Evaluation Criteria for Selecting Anti-Virus Products......46

Anti-Virus Solutions for Microsoft Exchange 2000 ServerAbstract: The continuing onslaught of viruses spread by e-mail has caught the attention of mail-system Administrators and the general public, acting as a reminder of the need to protect our systems. This paper discusses the software virus problem, and develops solutions for protecting Exchange 2000 Server mail systems from malicious software. This is an update to the original paper written for ActiveAnswers, based on Exchange Server version 5.5. Exchange 2000 is substantially different from its predecessor and the differences are covered here. With a variety of vendors and products on the market, there are many different methods to solve the problem. Example deployment scenarios are outlined and a comparison of product functionality and features is detailed. HP Best Practices for an organizational deployment are presented in a generic six-phase implementation methodology.

http://www.hp.com/solutions/activeanswers/exchange

Anti-Virus Solutions for Microsoft Exchange 2000 Server White Paper 2

NoticeThe information in this publication is subject to change without notice and is provided “AS IS” WITHOUT WARRANTY OF ANY KIND. THE ENTIRE RISK ARISING OUT OF THE USE OF THIS INFORMATION REMAINS WITH RECIPIENT. IN NO EVENT SHALL HP BE LIABLE FOR ANY DIRECT, CONSEQUENTIAL, INCIDENTAL, SPECIAL, PUNITIVE, OR OTHER DAMAGES WHATSOEVER (INCLUDING, WITHOUT LIMITATION, DAMAGES FOR LOSS OF BUSINESS PROFITS, BUSINESS INTERRUPTION, OR LOSS OF BUSINESS INFORMATION), EVEN IF HP HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.

The limited warranties for HP products are exclusively set forth in the documentation accompanying such products. Nothing herein should be construed as constituting a further or additional warranty.

This publication does not constitute an endorsement of the product or products that were tested. The configuration or configurations tested or described may or may not be the only available solution. This test is not a determination of product quality or correctness, nor does it ensure compliance with any federal, state or local requirements.

HP, Compaq Insight Manager, Deskpro, FASTART, NetFlex, NonStop, PaqFax, ProLiant, Prosignia, QuickFind, QVision, ROMPaq, SmartStart, and Systempro/LT are registered with the United States Patent and Trademark Office.

ActiveAnswers is a trademark and/or service mark of Compaq Information Technologies Group, L.P.

Microsoft, Windows and Windows NT are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries.

Intel, Pentium and Pentium® III Xeon are trademarks and/or registered trademarks of Intel Corporation.

Other product names mentioned herein may be trademarks and/or registered trademarks of their respective companies.

©1905 HP. All rights reserved. Printed in the U.S.A.

Anti-Virus Solutions for Microsoft Exchange 2000 ServerWhite Paper prepared by Messaging and Collaboration

First Edition (February 2002)Document Number 16EE-0302A-WWEN

16EE-0302A-WWEN


Executive Summary Secure electronic messaging is a relatively immature technology, and it presents an opportunity for intrusion into networked computer systems. E-mail may be used as the medium to attach viral applications, or may contain the virulent code itself, especially as the capabilities of e-mail are extended via HTML and active content. In the past, it was difficult to convince mail-system Administrators to protect their systems, as anti-virus scanners introduce a level of risk to servers and mailbox stores. Recent viruses spread by e-mail have caught the attention of the general public, increasing awareness of the problem, and forcing most, if not all organizations to address the problem.

This document is specifically targeted at Exchange Server Messaging Solution Architects and Mail System Administrators to protect against the threat that e-mail brings as a transmission vector for viruses. It should act as a condensed overview of the problem and provide a guide to the solutions. The structure of this document parallels a six-phase implementation methodology: analyze, plan, design, pilot, deploy, and manage/maintain. The better we analyze and understand the problem, the better information we will have to develop comprehensive solutions.

HP Best Practices are highlighted on how to test and deploy these solutions. Products designed to protect either SMTP gateways or Exchange mailbox servers are tested and the effectiveness and performance results of each method are compared. Exchange 2000 offers new methods or APIs to scan for viruses, and the results are substantial in performance and detection rates. With a properly sized server, the anti-virus resource utilization and load impact is not statistically significant.

The conclusion is that current virus-scanning prevention technology is ineffective by itself at preventing an initial viral outbreak, caused by a new virus. Current technology focuses on eliminating the recurrence of known viral code. Just as an e-commerce implementation involves more than pointing a Web server at a product database, an anti-virus solution involves more than installing scanning software on an Exchange Server. The most effective method of preventing losses due to viral payloads is to implement a comprehensive solution that involves defining and implementing organizational policies and procedures in the areas of network security, system operations, and messaging content. A coordinated effort is required, and securing the desktop operating system is recommended.

16EE-0302A-WWEN


Exchange 2000 and Exchange 5.5 DifferencesExchange 2000 brings substantial changes to the architectural design and deployment issues of anti-virus software. We will discuss each of these in greater detail in this paper:

Architectural Changes

Web Storage System exposes access into the Store via HTTP-DAV (Outlook Web Access)

EXIFS – The Exchange Installable File System exposes access into the Store as a drive (M:), folders, and items within the Store

Multiple Storage Groups (up to 4) and Mailbox Stores (up to 5 per SG) per Server, requiring Exchange 2000 aware anti-virus applications

New type of database file for Internet protocols, (.STM), requiring Exchange 2000 aware anti-virus applications

A New virus scanning interface: AVAPI and VSAPI v2.0 in Service Pack 1 (and later)

Transport Event Sinks and Store Events, which allow custom code to be executed on the server for functions such as anti-virus and content management

Deployment Changes

Front-End (FE) / Back-End design allows for anti-virus placement on different server types. FE servers can service Internet protocols such as POP3, IMAP4, SMTP, and HTTP-DAV as proxies for OWA clients

Revised clustering design on Microsoft Cluster Server (MSCS), including active/active cluster nodes

16EE-0302A-WWEN


Phase 1 - Analyze the ProblemThe first phase of the implementation is to determine the nature of the problem. To develop the best possible solution, we must first fully understand the problem. Without acknowledgement and awareness that there actually is a problem, it appears that no action needs to be taken. The introduction of new viruses has been fueled by improvements in ease of development (such as macro languages) and the ability to share information and transmission via the Internet. The viral problem would cease to exist, were it not for irresponsible individuals who lack the conscience or wisdom to prevent them from randomly harming others.

Viruses are not directly related to or dependent on messaging products such as Microsoft Exchange Server; however, e-mail has become the preferred transmission method for viral replication. Many smaller organizations are becoming exposed to the hazards of the Internet for the first time.

Background on VirusesSee “Appendix: Viral Information” for definitions of basic terminology. For the purposes of this paper, the generic name virus will refer to all malicious software such as viruses, worms, and Trojan horses. This section will briefly cover methods of attack and methods of transmission. The key point is that while transmission has been made easier by e-mail, the damage inflicted by the payload has escalated to the point of serious business risk and financial loss. The history of e-mail viruses dates back to November 2, 1988 when Robert Morris Jr. released a worm onto the Internet that replicated via SendmailTM.

Methods of Attack

Viral payloads typically fall into one of three categories:

– System modification (corruption to software, files or hardware) and invasion of privacy (unauthorized access to information) typically through installation of a backdoor program

– Unwanted traffic or files (unsolicited e-mail and unwanted “joke” files)

– Denial of service: overloading or crashing component services and systems

Historically, file-based personal computer viruses replicated via diskette were the prevalent form, but script viruses have been increasing in numbers because of the ease of authoring. The vast majority of viruses are files such as attachments to e-mail; however, it is possible now to send active content or links to active content within the e-mail message body. The scope of attack has been increasing as well; from isolated personal computers to networked computers.

16EE-0302A-WWEN


Payload Latency

One recent trend has been the shift from a delayed payload (a latency period, where the virus is present, but remains dormant in the system) toward an immediate payload, delivered when the user opens the message or file. For example, boot sector viruses delivered via diskette were forced to remain latent until the system was rebooted.

Table 1 illustrates how latency and payloads have changed, threatening entire networks and companies, instead of just isolated personal computers.

Table 1. Changes in Latency and Payloads

Viral Type Latency Payload

Boot Sector When computer rebooted Damage PC / boot

Executable When operator executes Trojan Horse Loss of files, corruption of system

Macro When operator opens document attachment

Loss of files, corruption of system

Applet When Web Page or HTML e-mail opened

Loss of files, corruption of system, security compromised, network intrusion or attack

Active Technologies1

Immediate Backdoor opened: Exposure of sensitive information, loss of business in e-commerce environment

Methods of Transmission

As the personal computer has changed from a stand-alone system to part of larger, networked systems, the methods of transmission have changed. Virus authors look for the most rapid method of sharing files. Transmission methods have evolved from storage based (floppy disks) to more efficient methods such as e-mail and potentially even browser-based. Viruses may now be contracted via FTP downloading or as attachments to unsolicited e-mail. The Melissa virus showed the world how easy it was to automate the transmission via e-mail. The method was not even ingenious, using widely publicized code. The payload was merely the transmission itself, expanding exponentially with each instance. However, the Worm.EXPLOREZIP virus advanced to the next logical level, not only delivering a destructive payload, but also changing the subject line of the message with each automated reply. The effect of receiving a reply to a previous message fooled the recipient into becoming a victim. The Nimda virus escalated the methods of replication used by the Code Red virus to include many methods of attack. Clearly, the methods of attack must be restricted in order to limit the viral power.

1 At the time of first publication of this white paper in 1999 these were emerging attacks, but are now quite prevalent.

16EE-0302A-WWEN


Phase 2 - Plan for SolutionsThe second phase of the implementation is to develop a comprehensive plan to solve the virus problem.

Economic JustificationAs with any project impacting the financial affairs of the business, it is important to measure the cost / benefit ratio of the anti-virus implementation. Historically, figures have been difficult to obtain, but recent viral outbreaks have given organizations the opportunity to study and measure the cost of downtime, clean-up, and add protection. Traditional ROI (return on investment) measures are inadequate, as anti-virus protection can best be thought of as an insurance policy. The measure of benefit is the reduction of risk exposure to the organization. It is beyond the scope of this article to measure cost / benefit or to provide guidelines on how to measure. Look for information on cost of projects from consulting practices, while benefit information can be obtained from anti-virus vendors (who have measured the costs associated with down-time and recovering from attacks).

Problem DefinitionViral attacks have one (or more) of three characteristics: system modification, unwanted content, and denial of service or system overloading. The virus problem is really the intersection of these three areas. If we properly address each of these three areas, the virus problem can be eliminated. Figure 1 shows the intersection of the affected areas.

Table 2. Affected Areas

Type of Attack Affected Area

System Modification (corruption to software, files or hardware) and Invasion of Privacy (unauthorized access to information).

Network Security

Unwanted Traffic or Files (Unsolicited e-mail and unwanted “joke” files).

Content Control

Denial of Service: crashing systems or component services.

System Operations

16EE-0302A-WWEN


NNeettwwoorrkk SSeeccuurriittyy

UUnnwwaanntteedd CCoonntteenntt

SSyysstteemm OOppeerraattiioonnss

Figure 1: Intersection of Affected Areas Defines the Anti-Virus Problem

Defining Borders of ProtectionAs part of the plan to protect the organization, we need to define the borders of protection. Think of an organization as a closed system with limited points of entry (see Figure 2). A complete virus protection program will need to cover the points of entry into your organization. Intrusion can come actively as a break-in and attack, or passively as a virus. Software to detect active intrusion and provide detailed information is beyond the scope of this paper.

This section briefly discusses protecting your organization at the points of entry. Control over these borders may be out of the control of Exchange Server Administrators; however, protecting these points of entry is vital in preventing Exchange Server from becoming a transmission method for viruses.

Figure 2: Viral Entry Points into an Organization

Tier 1: Client Email and Desktops

Operating System

There are two primary methods of protecting clients or desktops: one is to run the same type of real-time and file-based virus scanning as on file servers – scanning files saved to disk, watching for a viral signature match. This method requires ongoing updates to the signature database. Due to recent outbreaks of viruses, some vendors even offer desktop anti-virus software, including future updates, for free. When combined with regular backups of critical files, this provides protection against known viruses. Another method of protection for the clients or desktops can be called “Dynamic Security” -- software that watches for the end result of viral behavior: destructive activity.

16EE-0302A-WWEN


The most effective method of preventing losses due to viral payloads is to implement a secure desktop operating system and limit the power of the current logon context. By limiting the power of the current logon context, viruses run under that context and can be defeated by limiting permission to access critical files.

Another concern for viral intrusion, is the installation of backdoor applications that send confidential data outside of the organization. Unless users are educated on the dangers of installing unapproved programs, the likelihood of so-called ‘spy-ware’ or other backdoor intrusion is high. Users need to be similarly educated on hazards of installing browser plug-ins such as ActiveX controls. In highly secure environments, consider using personal firewall programs to detect backdoor intrusion – these applications will pop up a warning when a program requests an outbound connection. Administrators will need to provide users with education on how to respond to backdoor detection when the pop up message appears.

HP Best Practice: Implement virus scanning on the client desktop and secure the client desktop operating system. Reduce automation such as active script associations (more detail later) and restrict the administrative power of the current logon as much as possible. In highly secure environments, consider personal firewalls for backdoor intrusion detection.

Email Client

The email client can be a source of virus outbreak or a last line of defense. Different solutions need to be addressed for different types of email clients. We will consider versions of Outlook, Outlook Web Access (OWA), and Outlook Express. Other POP3 and IMAP4 clients need similar solutions.

Outlook

In response to viral outbreaks, Microsoft has released a security patch starting with Outlook 98 and Outlook 2000. The security patch is built into Outlook 2002 in Office XP. The patch restricts access to attachments by type, either blocking access completely (active code types) or forcing save to disk (other file types that may contain active code). Control over file type definition can be administratively maintained (see Microsoft Knowledge Base article Q263297). The security update also restricts programmatic access to the address book, which can impact email applications. Microsoft has several Knowledge Base articles Q249780, Q264128, Q264130 on this subject. Unfortunately, users are able to bypass the security restrictions either through direct registry edits or Outlook COM add-ins, so access to these configurations needs restriction.

For organizations extremely concerned about security and the possible risks of incoming HTML email, it is possible to convert HTML email to plain text to avoid active HTML payloads. There are two methods for doing this in Outlook, the first being available in Outlook 2002 Office XP SP1. See Microsoft Knowledge Base article Q307594 for information on enabling this option via Registry key. The second method is available for all other versions of Outlook and uses an HTML to RTF Macro called ZAPHTML, which is available from www.slipstick.com.

16EE-0302A-WWEN

http://www.slipstick.com/


Outlook Web Access

Since Outlook Web Access uses a browser to open email, it is dependent on the browser security settings. In Internet Explorer for example, clicking on an executable attachment will result in the dialog shown below in Figure 3.

Figure 3: Opening an executable attachment in Outlook Web Access

Outlook Express

It is strongly recommended that organizations allowing usage of Outlook Express require an upgrade to the latest version (as of this writing, version 6). Outlook Express now offers attachment blocking and automation restrictions similar to the Outlook security update discussed earlier. On the Security tab of the Tools, Options dialog are two new options: Warn me when other applications try to send mail as me and Do not allow attachments to be saved or opened that could potentially be a virus. See Microsoft Knowledge Base article Q291387 OLEXP: Using Virus Protection Features in Outlook Express 6. Another solution for protecting against email viruses is to use a POP email proxy scanning solution such as the one in Norton SystemWorks.

Handling of email attachments can be further managed via the Control Panel: Folder Options, File Types tab, and the settings for each file extension type - Confirm open after download checkbox.

HP Best Practice: Update email clients to the latest version of security protection to get attachment blocking and prevention of other exploits.

Tier 2: File and Application ServersFiles installed or copied to servers may transmit viruses. Real-time scanning and file-based virus scanners should be run on Network File Servers. However, file-based anti-virus scanning should never be run against the application and database files of an Exchange Server. Doing so can result in false reports of a virus and corrupt Exchange databases when attempting to disinfect the file. If you choose to run a file-based virus scanner on an Exchange Server, remove the Exchange files and directories from the scheduled scans and real-time scanning.

HP Best Practice: When deploying file-based scanning on Exchange Servers, be certain that the Exchange database and transient file locations (such as the SMTP mailroot and MTA), and the M: drive is excluded from scanning. Ideally, the anti-virus product should be deployed via a package that is pre-configured for these exclusions.

16EE-0302A-WWEN


Tier 3: Firewalls and Gateways

Incoming Files

Monitoring at this entry point includes transfer methods of FTP and HTTP. The key point here for Exchange Administrators is that code downloaded directly to any Exchange Servers should be scanned.

SMTP Relay and Connector Servers

All points of entry must be included: connections to the Internet, other X.400 MTAs, and mail connectors to legacy mail systems (such as cc:Mail or MSMail). A recent trend has been the outsourcing of virus scanning systems to a Service Provider. Anti-virus scanning services are provided for all mail passing in and out of the connection and the Provider handles all anti-virus software installation, administration, regular updating and multi-system management. More information on this type of service is available from companies such as Lansoft or Trend Micro.

Methods of Prevention or DetectionThis section illustrates six methods of preventing viral intrusion into the organization, including both software and policy-based methods.

Blocking

The most recent form of viral payload has been through e-mail attachments. The destructiveness of a very small percentage of attachments has become a security headache for network administrators. One proposed solution is to disallow receipt of attached files; instead, the e-mail must send a URL linking to the file. This solution requires a unified network, and makes the assumption that the end-user will set proper security on the desired file. Otherwise there is nothing to prevent a hacker from replacing the original file with a viral file (if security has not been properly set). Another solution is to allow your mail system administrators to strip off incoming attachments and place them in a secure location where they can be isolated and scanned either for viral signatures or tested for destructive payload. Indirectly this may also cut down on the volume of rather large videos and animations.

The most complete protection is offered by preventing any and all attachments containing executable code to be transmitted to recipients. If code does need to be transmitted, it can be sent to an Administrative mailbox for verification or execution, as explained below. Limited blocking can be enabled, where known filenames are placed in an exclusion list, which is then referenced to determine whether to allow or deny entrance.

Microsoft has implemented file blocking to some degree in Outlook, starting with the Office 2000 Service Releases, and continuing into the current version of Outlook 2002, part of Office XP. Attachments are classified into one of two restrictive levels, and are either blocked completely (active scripts and executables) or the user is forced to save them to disk.

16EE-0302A-WWEN


For more information on Outlook security and attachment blocking, see the following:

– Outlook 2000: Information About the Outlook E-mail Security Update (Q262631) http://support.microsoft.com/support/kb/articles/Q262/6/31.ASP

– Outlook 2000 SR-1 Update: E-mail Security http://www.microsoft.com/TechNet/prodtechnol/office/support/fixes/O2KTOOL.asp

Content Filtering

Content filtering involves maintaining a list of words, statements, senders, or filenames that are denied entrance into (or exit from) the mail system. Organizations that explore this option are quite often looking for more than virus protection, such as the ability to prevent unwanted solicitations or offensive material. Viruses transmitted by e-mail quite often contain an identifying statement within the subject line that can be used to filter out the messages.

HP Best Practice: Consider content filtering as a supplement to anti-virus scanning that can limit unwanted messages from entering or leaving the organization. The best anti-virus programs now include content filtering, and some content filtering applications now include anti-virus.

False Positives

A problem with any method of detection is that some files may be incorrectly identified as suspicious code or unwanted content. However, the chances of this happening are quite small and certainly are greatly outweighed by the value of preventing the outbreak of true viral mechanisms. For this reason, messages must be quarantined or stored temporarily until it is quite certain that they are unwanted and can be deleted. The quarantine directory becomes another point of administration, as it must be included in the monitoring systems for disk space usage.

Code Execution

A new virus can be identified because it behaves in a certain way. By definition, it is the behavior that makes the program a virus. Code Execution is a method of viral prevention, where a computer is set up (often called a "sacrificial system") in an isolated network zone and all incoming applications are executed and monitored for suspicious behavior. The process must be automated for optimal efficiency, otherwise the support burden is overwhelming.

16EE-0302A-WWEN

http://www.microsoft.com/TechNet/prodtechnol/office/support/fixes/O2KTOOL.asp

http://www.microsoft.com/TechNet/prodtechnol/office/support/fixes/O2KTOOL.asp

http://support.microsoft.com/support/kb/articles/Q262/6/31.ASP


Attachment Scanning

Scanning is the most common type of viral prevention. Incoming files are compared against a known database of viral signatures or fingerprints. The database is usually static and must be updated frequently (see the section on “Definition Updates”). Viral scanning can be done in real-time as messages arrive or on a periodic scheduled basis. The keys to anti-virus effectiveness are listed below. Considerations that impact the effectiveness are the program API that is used to access Exchange Server as well as the speed and efficiency of the program (both explained later in the product evaluations).

Content Filtering

Content filtering has long been the realm of products designed for that sole purpose. However, anti-virus vendors are adding this capability to their products. For example, leaders in the Exchange Server anti-virus market, such as Trend Micro, have added this capability to their products for Exchange 2000. The Trend Micro product is known as eManager, and is available with their 6.0 release. Content management is even available for smaller organizations through simple but powerful tools such as Nemx Power Tools for Exchange.

Selective Attachment Blocking

Essentially a subset of content filtering, selective attachment blocking allows for preventing specific file types from entering the organization. This can be useful for screening against unwanted file types (scripts such as VBS, or large media files such as MP3) at all times or just during a virus outbreak. For example, the Sybari product is known as Antigen File Filtering™ (AFF), and filters e-mail attachments by filename or type and can use wildcards selection.

Virus Purging

In the past, viruses tended to attempt avoiding detection and further propagation by attaching to useful information or by using the Trojan Horse method. Most recent outbreaks have been self-propagating and infected e-mails contain only the virus and no useful information. In response, anti-virus vendors are offering the ability to completely remove the offending message, rather than deliver a useless virus-generated message with a cleaned attachment. In Sybari Antigen this is known as Worm Purge™ and in Trend Micro ScanMail for Microsoft Exchange 2000 this is known as the Active Message Filter.

16EE-0302A-WWEN


Selection by File Type

Typically, scanning programs increase efficiency by checking only file types known to carry viruses (EXE, COM, DOC, etc.) or a list provided by the administrator. Recently, the Symantec AntiVirus Research Center (SARC) put out a notice that the W97M.Melissa.A virus was spreading again via an infected Word document with the file extension of RTF instead of DOC. The document is a Word format file that has had the file extension renamed so that anti-viral software not configured to scan the "RTF" file extension, will not detect the virus. To detect the virus, the "RTF" file extension must be added to the scanning and real-time protection lists. If you create a subset of file types to scan, here are some recommendations:

Table 3. Attachment types recommended for scanning or blocking

Complete List of File Extension Recommended by SARC for Scanning:

386, ADT, BIN, CBT, CLA, COM, CPL, CSC, DLL, DOC, DOT, DRV, EXE, HTM, HTT, JS, MDB, MSO, OV?, POT, PPT, RTF, SCR, SHS, SYS, VBS, XL?

Additional list of file attachments that may contain active content

??_, 00?, ACM, APP, ARC, ARJ, ASP, AX?, BAT, BO?, CAB, CDR, CHM, CMD, CNV, DEV, GMS, GZ?, HLP, ICE, IM?, LZH, MPD, MPP, MPT, MSI, MSG, MSM, MSO, MSP, MST, OBD, OBT, OCX, OLE, PCI, QLB, QPW, RAR, REG, SMM, TAR, TD0, TLB, TSP, VS?, VWP, VXD, WBK, WIZ, WPC, WPD, WSI, XML, XSL, XTP, ZIP

Rather than use string comparisons to identify filename extensions some anti-virus products determine the content type by reading the file header. This method requires more processing overhead, but prevents lack of detection merely due to the file being renamed (see section “Detection Circumvention Tests” for an example of this test and the section “Effectiveness: Summary” for the results).

HP Best Practice: Ensure that anti-virus scanning or content filtering scans all file types and is not bypassed by invalid file types or extensions.

Heuristic Scanning

Heuristic scanning studies suspect code to classify it by type of behavior. This method does not rely on virus signatures; instead it inspects a program’s structure, programming logic, instructions, file data, and other attributes to assess the likelihood of viral intention. Heuristic scanning is important for scanning macro viruses due to the ease of viral authors creating variants of the original macro virus. False positive alerts are an issue however, as the anti-viral software must essentially make an educated guess to identify viruses.

Recursive Decompression

Another factor that impacts effectiveness of anti-virus scanning is called recursive decompression. This is critical for compressed (ZIP) files placed within other compressed (ZIP) files. Often this is a configurable setting (number of levels). This is also a known point of attack, where very large files are nested deep within the zip files and the anti-virus program must be capable of protecting itself against this threat.

16EE-0302A-WWEN


Real-time and Manual Scanning

The most effective anti-virus scanning is done in “real-time” as messages traverse the system. However, manual scanning should also be performed, especially in areas where products were found in test results to be somewhat ineffective. In the past, it was quite possible for a virus to slip past some scanners, usually under heavy load or from the inadequacy of MAPI to provide 100% priority to the anti-virus scanner over the client (which may be moving the e-mail message to a personal folder (PST) based on a rule or mail delivery location -- see the section on “MAPI versus VSAPI” for more details). To completely protect the system it may be necessary to run a manual scan, often scheduled during the night.

HP Best Practice: At a minimum, Implement real-time scanning on entry points into the organization. Schedule manual scanning for access points that may be less than 100% protected.

Policies and Procedures: User Education

Mail recipients need to be educated on proper handling of mail attachment types, such as executables, documents containing macros and links to Web applets. For deployment of AV Solutions to be truly successful, it must also encompass end-user education. A thorough organizational policy mandates that incoming media be scanned or turned over immediately to system administrators. End users need to be aware that retrieving Internet mail from a Service Provider (such as through Outlook Express or another POP3 client) may circumvent anti-virus scanning efforts on corporate mailbox servers, and should be avoided or protected by a client-side virus scanner such as the Norton POPPROXY (a part of SystemWorks).

HP Best Practice: Establish and distribute an organizational policy explaining what file types contain active content and how computer operators should handle those files. Educate users to treat incoming attachments and Internet e-mail with suspicion and to err on the side of safety.

Being Prepared

The mission of most virus authors is to wreak havoc, demonstrate superiority over defense systems, and come up with new ways to avoid detection. Anticipate and expect viral outbreaks by following these Best Practices:

HP Best Practices:

– Limit access to network information and systems, such as installation of untested code on Exchange Servers

– Monitor suspicious activity, by enabling and checking Security Auditing and Event Logging

– Implement a reliable Backup and Disaster Recovery Strategy, and perform regular recovery exercises

– Prepare an Outbreak plan for Administrators (detailed later)

16EE-0302A-WWEN


Phase 3 - Develop the SolutionsThis section focuses on software solutions to the virus problem for Exchange Server systems. With the variety of Exchange Server designs and implementations, there is no “one-size-fits-all” anti-virus product. The primary value of this section is in generating a thorough list of questions that must be answered before choosing a product to implement. There are certain crucial requirements that must be met (such as protection at points of entry into the Web Storage System, Public Folders and PST files) and other considerations that affect the ease of product use and manageability. The first question to answer is where to draw the borders of protection, on connections to the outside world or on internal mailbox servers.

Anti-Virus Software: Selection CriteriaThere are two methods for product selection; the first one is to choose the product with the most desirable feature set, perhaps seeking a critical feature that cannot be done without. This method may be easiest, especially if the choice of products with this feature set is limited. The other method is through the process of elimination, choosing the product that passes effectiveness and performance testing with the best results. The following section illustrates both methods, starting with an attempt to prioritize product features and assist in determining “must-have” features. The section Sample Evaluation Criteria for Selecting Anti-Virus Products in the appendix summarizes the selection criteria that you may wish to use to evaluate several products side by side.

Exchange 2000 versus Exchange 5.5

Exchange 2000 brings substantial changes to the architectural design of Exchange 5.5. These will have deployment implications and affect the choice of anti-virus software. Most likely, anti-virus software designed for an Exchange 5.5 server will no longer be compatible.

Architectural Changes

The most significant architectural change in Exchange 2000 in the area of virus protection is in the API (Application Programming Interface) provided for virus scanning. There are two main factors that impact the effectiveness of an Exchange Server specific scanning product: the first is having the virus definition database up-to-date and the second is the method or API (Application Programming Interface) used to access Exchange Server. A new virus-scanning interface VSAPI v2.0 was introduced in Service Pack 1 for Exchange 2000.

16EE-0302A-WWEN


Anti-virus APIs

The previous version of this white paper and the testing conducted illustrated that the existing API known as MAPI used for virus scanning was not 100% effective in preventing transmission of known viruses. Essentially the anti-virus product acts as a mail client, and attempts to get to the mail before the user does. MAPI also has a disadvantage of not providing any means to scan outbound messages without implementing additional anti-virus software on the client. One vendor, Sybari developed its own method for interfacing with the Exchange 5.5 Store inserting a shim (loading the Antigen DLL before the ESE DLL) between the ESE API (which is used for Exchange online backups). The ESE shim was found to be very effective and offer high performance, giving the product the ability to catch outbound viruses before they can even leave the Outbox and be sent.

But the ESE shim was not a supported or endorsed method. It is still available as a scanning method for the Sybari Antigen product for Exchange 2000, but Antigen also offers the VSAPI method. Trend Micro also developed an ESE shim version for Exchange 5.5 only, but it was not tested as part of this paper.

As part of Exchange 5.5 SP3 and also the initial release of Exchange 2000, Microsoft developed an improved Virus Scanning API (VSAPI, also referred to as version 2). This is the version tested for this white paper, as it includes several much needed improvements over the AVAPI version 1. The VSAPI passes committed database transactions to a vendor-supplied anti-virus scanning DLL. Even though the attachments are in the store, e-mail clients cannot open the attachments until they are scanned. Outlook (MAPI) clients will be able to open the message, but not the attachment, and Internet protocol clients such as OWA will not be able to open the entire message until scanning is performed.

The following are the methods or APIs available for virus scanning:

– MAPI – Original API used for Exchange 5.5 scanning and Outlook e-mail clients.

– ESE shim – Vendor developed workaround, not fully endorsed by Microsoft for Exchange 2000.

– AVAPI – Version 1 of Exchange 5.5 and Exchange 2000 scanning, with limited functionality

– VSAPI – The official method for protecting Exchange 2000 Service Pack 1 (SP1) and later. VSAPI is backwards compatible with the older AVAPI, so anti-virus software should continue to work after SP1 is applied.

– Combination approach – in order to gain the advantage of each API, it is possible for the anti-virus vendor to use a hybrid or multiple API approach.

– Transport Event Sinks and Store Events allow custom code to be executed on the server for functions such as anti-virus and content management. See the Exchange SDK for Microsoft’s documentation in this area.

16EE-0302A-WWEN


MAPI versus newer Virus Scanning APIs

When Microsoft introduced the Anti-Virus API (AVAPI) in Exchange 5.5 Service Pack 3, it presented some difficulties to virus-scanning vendors. When a virus was detected in an e-mail attachment using AVAPI, the anti-virus scanning program received no information on the sender or recipient of the message. In addition, only the e-mail attachments could be scanned, and not the message body. This presents a severe limitation when attempting to detect viruses such as the KakWorm, which can infect the body of the e-mail message. Vendors using the AVAPI were often forced to develop hybrid solutions. For example Trend Micro (ScanMail) and McAfee (Groupshield) revised their products to use both MAPI and AVAPI interfaces, in order to scan the message body, and also obtain sender and recipient information. McAfee also released a utility to identify items in the quarantined virus database and attach names.

The new Virus Scanning API 2.0 (VSAPI) in Exchange 2000 SP1 offers the following improvements: the ability to get full message details such as senders and recipients. It offers the ability to scan native MIME/MAPI content, and perform proactive scanning, before the message is requested from the client.

All message types are scanned by the VSAPI to prevent receipt of binary viruses labeled as plain text. The VSAPI offers priority-based queuing and background scanning. And it offers full event logging and Performance Monitor counters. Since VSAPI is capable of providing on-access scanning (when the e-mail attachment is requested), it provides an extra measure of safety even without performing manual scan jobs to detect undiscovered viruses (for which there was no signature when received).

In summary, the new VSAPI2 offers these three methods

1. Proactive Scanning - as new messages arrive at the server

2. On Access Scanning - when messages are opened or accessed via the email client

3. Background Scanning – administrator requested scanning of messages, primarily used for re-scanning the Exchange database when virus signatures have been recently updated

The combination of these three methods provides a comprehensive solution for anti-virus vendors to deliver scanning applications.

Multiple Information Stores

Exchange 2000 provides Multiple Storage Groups (up to 4) and Mailbox Stores (up to 5 per SG) per Server, requiring Exchange 2000 aware anti-virus applications, as this is a different architecture than Exchange 5.5. Exchange 2000 also introduces a new type of database file, (.STM), requiring Exchange 2000 aware anti-virus applications, as clients are able to access this database file using Internet protocols such as POP3, IMAP4, SMTP, and HTTP-DAV (OWA).

16EE-0302A-WWEN


Exchange 2000 provides additional methods of clients to send and retrieve messages from the Exchange private and public information stores. The Web Storage System exposes access into the Store via HTTP-DAV (Outlook Web Access), and is not protected against viral transmission using MAPI or AVAPI scanning methods. The VSAPI (and also ESE shim) does provide protection for OWA clients, however only when running on the back-end server and not on the front-end server, as described below.

The Exchange Installable File System (EXIFS) exposes access into the Store as the M: drive and folders that can be shared out, just as on a file server. To protect against viruses being saved into the M: drive, Exchange-aware anti-virus should be run using the Service Pack 1 VSAPI (or the ESE shim). Anti-virus products designed for file-servers should not be run against the M: drive or database corruption may occur.

Deployment Changes

Server Roles

Anti-virus software for an Exchange Server environment is available in three designs. The first is for an SMTP server regardless of the SMTP gateway version, usually relaying on TCP/IP Port 25 to the Exchange Server system. The second design is to be installed on Exchange Servers dedicated as connector servers (in Exchange 5.5 Internet Mail Connectors). Both of these designs primarily protect against inbound and outbound viruses from Internet e-mail. Exchange 2000 introduces a front-end (FE) / back-end design which allows for anti-virus placement on the FE servers. The FE servers service Internet protocols such as POP3, IMAP4, SMTP, and HTTP-DAV as proxies for OWA clients. The third type of design runs directly on the final delivery point, and protects the Exchange Server Mailbox Store. This is often the preferred design, as it should protect all internal e-mail and collaboration transactions from infection.

HP Best Practice: When deploying Exchange 2000 and Outlook Web Access make sure to place anti-virus on the back-end (mailbox) servers, as anti-virus on the front-ends does not scan incoming or outgoing OWA e-mail

Cluster Support (MSCS)

Exchange 2000 takes advantage of the revised clustering design of Microsoft Cluster Server (MSCS), including active/active cluster nodes on Windows 2000 Advanced Server and N+1 nodes on Datacenter Server. In an environment where Exchange 2000 Server is run on Microsoft Cluster Server, the choice of anti-virus products is further limited. Trend Micro ScanMail and Sybari Antigen have long been designed to operate in a cluster fail-over situation. Clustering is also available in the Windows 2000 Datacenter product and several anti-virus vendors are actively testing compatibility of their products.

16EE-0302A-WWEN


Product Selection and Deployment

Server Sizing and Performance Impact

The most often asked question is “How much additional hardware will I need to implement anti-virus scanning software into my Exchange System?” The answer depends on the existing load and resource utilization on the servers, which is a function of message flow during normal and peak periods, and the number and size of attachments. For new deployments the impact of deploying anti-virus scanning software is lessened by the fact that no user expectations exist for what system response should be.

Performance Impact: Existing Load

Anti-virus software primarily utilizes the resources of CPU and memory. If either of these resources is near becoming a system bottleneck, additional resources will need to be added before the anti-virus program is installed or performance will suffer. Before implementation it is important to measure the existing load during normal and peak operations. In the event that they do become a bottleneck in the scanning process, the disk subsystem will then be impacted as the processing queues build up. It is therefore recommended that the disk subsystem design also be considered in selecting anti-virus placement.

HP Best Practice: Measure the existing load during normal and peak operations (using PERFMON) to establish a baseline before deploying anti-virus solutions.

Performance Impact: Enhancing Performance

Whenever possible it is best to plan, develop, test and deploy anti-virus when the Exchange Server system is first rolled-out. However, in lieu of that it is possible to use the scalability of Exchange Server to resolve the issue either through horizontal or vertical scalability. Horizontal scalability is also known as functional decomposition, and it means offloading services, or functions of the Exchange Server to additional servers. Mailboxes can be moved to a new server, lessening the load on the existing system as anti-virus protection is added, thus keeping the user responsiveness optimized. Vertical scalability is achieved by adding more resources such as additional memory or processors to the server.

Performance Impact: User Response versus Throughput

Another important consideration is the impact on the e-mail system, especially when deploying into an existing production system where end-users may have already created expectations of how well the system should perform. The effect of deploying on mailbox servers is to delay the responsiveness of the system (to end-user operations, such as opening and sending mail), while the effect of deploying on connector servers is usually to delay delivery rates (throughput). The latter is often a more acceptable impact to an existing system, so placing anti-virus scanning on the gateways is less noticeable to the end-user community.

16EE-0302A-WWEN


HP Best Practice: Before deploying anti-virus solutions understand the impact to the organization on the mail system, whether it will be in responsiveness or delivery times.

Handling Infected Files

The best anti-virus software gives the administrator the ability to control how to handle files suspected of being a virus. In the unlikely event of a false positive it is important that the original file be preserved and not damaged. The choice of whether to attempt repair, quarantine or just delete the file should be made available. In the event of quarantine, most programs will only allow the administrator to specify a root directory. It would be easier to manage if a hierarchy was created based on recipient name.

HP Best Practice: Place the quarantine location on a RAID protected drive subsystem, away from the Exchange Server database and log files. Regularly monitor the free space on this drive location and clean up as needed.

Definition Updates

Every anti-virus vendor would like to be able to claim that they have the fastest response time to discovering and protecting against new viruses. The reality is that no one vendor can always be first. Discovery of new viruses released “into the wild” depends on the network of contacts, customers and research that the company does. The “Holy Grail” of anti-virus technology is software that detects suspicious files automatically and never requires updates. In the meantime, updates are made available for automatic, scheduled distribution via the Web or FTP. Anti-virus vendors must certify the stability of engine (or virus definition) updates before making them available. However, it has been known to happen that a specific server configuration will result in problems. For this reason, it is recommended as a best practice to update a less-essential server first and monitor the stability before applying the update to other production mail servers.

Verify that the anti- virus software you are considering for purchase allows configuration of scheduled, automatic updates from a specified location. In the event of a problem with the engine update, the software should be designed to rollback to the previous version.

Distribution Architecture

Most likely the server selected to automatically pull the definition update will not have a direct connection to the Internet, and must be able to access through a proxy server. Verify that the anti-virus software will allow for this configuration. To reduce the amount of traffic over the Internet connection it should also be possible to use fan-out distribution architecture, where the first update is placed on a shared network location and remaining servers are updated from that source.

HP Best Practice: Configure frequent, automatic updates and apply first to less critical or non-production Exchange Servers.

16EE-0302A-WWEN


Notification

The best anti-virus software gives the administrator the ability to control the types of notifications sent out on detection of a virus. Notifications should be configurable for administrators and mail system end-users. Choice of methods includes Broadcast Alerts, E-mail Alerts, and Pagers. In addition, the message that is sent out should be fully customized to ensure that the desired information is conveyed to the recipient, and also allow for multi-lingual messages.

One anti-virus product, Sybari Antigen, in addition to allowing customization and control over messages, allows separate control and definition for external senders and recipients as well as internal senders and recipients. This helps to reduce the flood of traffic that notifications can create during a viral outbreak.

Additional information can be written to the Windows Event Log or Application-specific Reports. Most anti-virus software creates a log, which can be exported to other formats. This information can be quite useful. For example, one program, NAV (Norton Anti-Virus) for Exchange logs information to the NT event log when an encrypted ZIP file enters the organization. This could be quite useful, as the encrypted ZIP file may represent a breach in security.

HP Best Practice: Choose notifications carefully, as they can create additional load on the system during a viral outbreak.

Server Status and Monitoring

As with most any software, introduction of anti-virus scanning application to a production e-mail server represents a risk of introducing harm or disruption to that server. The need to monitor the server becomes increasingly important. Allegorical stories have circulated of store corruption (-1018 errors) perhaps induced by the anti-virus scanning. Confirmation or isolation of these issues is difficult, and quite often the first priority of support personnel is to reduce interference and request that anti-virus scanning be removed until the problem can be resolved.

Management Console

Various products provide a management console in either a native Windows program or an HTML-based browser allowing for administration of remote servers across the network, or perhaps both. The functionality of each version may not be exactly the same, as the browser versions tend to aim for portability at the loss of features. Add the type of management console to your selection criteria when considering a product for purchase.

16EE-0302A-WWEN


PERFMON Objects

Most anti-virus products (such as Trend Micro ScanMail and Sybari Antigen) add PERFMON counters for their product for scanning and detection rates. These can be used in addition to monitoring the following recommended counters for measuring anti-virus product resource utilization:

– % Processor Time: Total

– % Processor Time: AV Processes

– Memory Used: AV Processes

– Message Delivery Times

– Disk Usage: % and Queue Length

IMPORTANT: the disk measures require that the disk counters be enabled by toggling “diskperf -y” and should only be used during testing to ensure that the disk subsystem can handle the required load during scanning and quarantining. Be sure to disable “diskperf” during production).

Exchange 2000 now includes anti-virus counters as part of the VSAPI (Virus Scanning Application Programming Interface), but the anti-virus scanner must make use of the VSAPI for these counters to gather information.

Monitoring Service StatusThe anti-virus services need to be included into existing or new monitoring systems. In the case of most products (except Sybari Antigen, which places a dependency key in the registry so that the Antigen Service must be running or the Exchange Information Store will not start) it is possible for the anti-virus service to be stopped and messages will continue to pass through unchecked. This represents a point of attack for virus authors if they can use a Trojan-Horse virus to fool an administrator, then the virus can use the logon context of that administrator to stop the anti-virus service and deliver its payload.

HP Best Practice: Add the anti-virus services to monitoring systems (third-party or Exchange Administrator Console) and configure notifications so that the Administrator is alerted if the scanning service is offline.

Product Issues: Pricing, Licensing, and Support

Other considerations for selecting an anti-virus product are pricing and licensing, and support issues. A product may be favored for selection due to aggressive pricing strategy, such as a “trade-up” price. Licensing may be favorable when another product by the same vendor is used for client desktop or file server protection.

It is recommended that the vendor’s support policy be investigated before selecting a product. Important to consider are they type of contact supported (telephone, e-mail, Web-based discussion list) and the availability during normal business hours for all time zones that the organization has a presence in.

16EE-0302A-WWEN


Another important factor, although much more difficult to assess, is the longevity of the product. How quickly will the vendor respond to service packs or upgrades to the Exchange Server product? What is their commitment to having their product ready so that you can keep your Exchange systems up to date?

HP Best Practice: Expect a long-term relationship with the anti-virus product vendor and get a clear commitment on support policies and product longevity.

Viral Identification and Effectiveness and Performance Testing

Finally, and perhaps the most important factor in product selection is how well it performs in preventing viral intrusion. The next section details the testing of various products in a lab environment.

Phase 4 - Conduct Pilot TestingOnce the product selection is narrowed down based on the information in the previous section, a performance evaluation and comparison of products can be considered. For the purposes of this research paper, a comprehensive evaluation of anti-virus software for Exchange Server and the messaging environment in general was done. New products are released quite frequently, especially considering the large number of vendors and products tested; so, these test results should only be used to determine what to look for in conducting your own comparisons.

The testing involved three main parts: (1) attempting to pass a virus file through detection, (2) measuring performance impact and (3) assessing the usability of program features. The table below lists the viruses and problem files that were introduced while the servers were under increasing load, to determine how well the Anti Virus programs detect viruses and handle problem files (such as a ZIP file with no contents and a zero-byte COM file).

16EE-0302A-WWEN


Table 4. Viruses and Problem Files Introduced

Type of Attack

Description Desired Result

Category: Known viruses

Known Executable Virus

Example: TROJ_EXPLOREZIP (also known as Worm.EXPLOREZIP) an email worm containing a damaging payload.

Remove Attachment

Known Macro Virus

Valid document with macro infection. Example: The W97M_Empirical Word Macro virus.

Clean document

Disguised Known Virus

Known virus signature: well-known virus renamed as *.JPG to avoid detection if only scanning on active content extension types (e.g. .EXE and not .JPG).

Remove Attachment

Known Active scripts, and HTML message bodies

Viral payload is contained in message body as opposed to attachment. Example: KAK or Bubbleboy

Purge message

Known Worm

Entire message is unwanted content. Example: Klez - a mass-mailing email worm that attempts to copy itself to network shares. Uses random subject lines, message bodies, and attachment file names. Exploits vulnerability in Microsoft Outlook and Outlook Express to execute when you open or preview the message2.

Purge message

Archived and Nested Virus

Known virus, zipped and placed within an Outlook message (.MSG) file, which is then attached to the outgoing message.

Clean virus out of archive

Virus Embedded in Document

Known virus placed within a document, which is then attached to the outgoing message.

Clean virus out of document

.com URL format

Rename known virus to .com file that appears as a hyperlink e.g. www.badfile.com (e.g. exploited by www.myparty.yahoo.com)

Remove Attachment

Category: Illegal MIME Structures

Invalid content type

e.g.Content-Type: text/plain; name=?us-ascii?Q?eicar.com?=

Viral attachment passes but in form ATT00xx.txt which is saved as text attachment

Invalid name structures

e.g.Content-Type: application/binary; name=?us-ascii?Q?eicar.com?=

Viral attachment passes but in form ATT00xxx.DAT which is saved as attachment

2 Information from Symantec Security Response: http://securityresponse.symantec.com/avcenter/venc/data/[email protected]

16EE-0302A-WWEN

http://www.badfile.com/

http://securityresponse.symantec.com/avcenter/venc/data/[email protected]


Type of Attack


Invalid name syntaxes

e.g.name=.”eicar.com”name=eicar .comname=”eicar.com

Detection

File name not specified – determined by MIME type

e.g.Content-type=application/hta

Viral attachment passes but in form ATT00xxx.DAT which is saved as attachment. (Not a real threat)

Illegal 8.3 file name

e.g. additional dot in filename stripped when saved to disk in Windows PC.

Detected when scanning all attachments and not just specific extensions

Category: Problem attachments and messages

Zero-Byte .COM file

Zero-byte file with .COM extension. Designed to test a known issue with some scanning programs, reported in August of 1999, where a zero byte file could cause the scanner to hang.

Remove Attachment or pass without error to scanner

Zero Byte ZIP file

Zero-byte file with .ZIP extension Designed to test a known issue with some scanning programs, reported in August of 1999, where a zero byte file could cause the scanner to hang.


Extremely Large Zipped Nested Attachment

Office Document of several hundred megabytes placed into a zipped file along with a known virus.


Category: Potential virus threats

NTFS Stream

Alternate Data Streams threat with the extension “*}”. See http://www.sans.org/infosecFAQ/threats/win_NTFS.htm for more information.

Remove Attachment

IFRAME tag When an HTML email with a URL in an IFRAME tag embedded in the message is opened in Outlook the user is prompted to open (run) the file, save or cancel with no warning that the URL may point to a dangerous executable file. The default choice is open (run).

Purge or Remove HTML

"about:" or "javascript:"

Even though scripting is turned off by default in Outlook, an HTML email message containing JavaScript code embedded in an "about:" or "javascript:" URL as an HTML <a href=> tag can still be executed.

Purge or Remove HTML

16EE-0302A-WWEN

http://www.sans.org/infosecFAQ/threats/win_NTFS.htm



Type of Attack


Predictive Stay current on exploits that can be easily prevented. See http://www.microsoft.com/technet/security/

Varies

Example Detection Circumvention TestsThe following tests were devised to measure detection rates and attempt to defeat scanning detection.

Table 5. Detection Circumvention Tests

Test Expected Test result

To Uninitialized Mailbox Ideally: Initialize mailbox to scan incoming mail, otherwise first time logon to mailbox may allow access to virus (previous problem with MAPI-based scanning).

Delayed Send Detection (immediately on send)

With Invalid Return Address No problems (expect NDR if notifications to sender)

Embedded in Outlook Form Detection

To Distribution List Address Detection, including outbound SMTP (Custom Recipient) member of Distribution List

To Public Folder via Post Detection

To Public Folder via an SMTP address

Detection

Drag and Drop File to Public Folder

Detection

Exchange Settings: Private Detection

Attempt to catch virus while AV Service stopped or starting

Detection

Message in Sent Items Cleaned copy of message sent should be kept; but no active virus should be kept.

.PST as delivery location (Client logged on)

Detection

Invalid inbound address (creates NDR, but should not scan attachment)

Return without Scanning Attachment; NDR message should come back with virus intact. (Note: Consideration when under attack during viral break-out such as “Melissa” created)

Invalid Address (create NDR) with valid CC

Detection

Digital Signature Unable to detect without affecting signature (Ideally: Integrate with Certificate Server to scan mail)

16EE-0302A-WWEN

http://www.microsoft.com/technet/security/


Test Expected Test result

Signed and Encrypted Unable to detect, encrypted (Ideally: Integrate with Certificate Server to scan mail)

Example Test Environment

Figure 3 illustrates the test environment for evaluating anti-virus software.

Figure 4: Exchange 2000 Test Environment

HP Platform for Testing

The table below shows the ProLiant platform configuration for testing.

Table 6. ProLiant Platform Configuration for Testing

Computer Role CPU + RAM Drive Subsystem

ProLiant 8000

ProLiant 6000

Active Directory Servers

Global Catalogs and DNS

8-way 500Mhz512MB RAM

4-way 400Mhz>1GB RAM

Smart Array 4250ES RAID Controller

Smart Array 3250ES RAID Controller

ProLiant DL360 4 Front-End Servers (SMTP, POP3, IMAP4, HTTP-DAV/OWA)

1 CPU 800Mhz512 MB RAM

Internal Integrated Smart Array Controller RAID1

ProLiant 1850R Back-End (Mailbox) Servers 2 CPU 550Mhz1 GB RAM

Smart ArrayExternal

ProLiant 1850R Back-End (Mailbox) Servers 2 CPU 500Mhz384 MB RAM

External RA4000 Fibre Channel

2x ProLiant 1850R

Clustered Back-End (Mailbox) Servers

2 CPU 500Mhz384 MB RAMeach

External RA4100 Fibre Channel

Deskpro EN LoadSim and Mailtest load generators

233-700MHz256-384 MB RAM

IDE

16EE-0302A-WWEN

COMPAQDrive 0 Open Drive 1 Open18 GB 18 GB




ProLiant DL360 front-endservers FE360L9 - 12Version 6.0 (Build 4712.4:Service Pack 1)

ProLiant ML ActiveDirectory GlobalCatalog ServersDNS, DHCP

ProLiant DL MailboxServer Version 6.0 (Build5762.4: Service Pack 2)

ProLiant 1850 MailboxServer Version 6.0 (Build4712.4: Service Pack 1)

Test Clients

RG

1A

G1

toR

G1

AG

2

EXVS1 -- ClusterVersion 6.0(Build 4712.4: ServicePack 1)

First Routing Group

Second Routing Group

Active Directory Organization


Example Test Plan

The overall purpose of this testing is to evaluate representative anti-virus products based on differing detection methods or APIs, and measure the results of server performance impact and viral detection rate, just as you are encouraged to do with products that you are considering. The scope of these tests is to evaluate anti-virus products in Exchange mailbox server, and Internet protocol (SMTP, IMAP4, POP3, HTTP) front-end server versions. In practice, you would narrow the testing down to one or two products to make sure that they meet your expectations. Several tests were devised, listed below:

Exchange 2000 Server Mailbox and Public Folder Store virus protection

– Test Suite 1: Normal Load

– Test Suite 2: Peak Load (Stress Test)

– Test Suite 3: Impact of Multiple Storage Groups and Mailbox Stores

SMTP Front-End virus protection

– Test Suite 4: Measure throughput and resource utilization with and without anti-virus scanning

The testing methodology involves creating the sample environment using LoadSim, including Active Directory accounts and fully populated mailboxes. The test load is then run, allowing LoadSim to achieve a steady state over an 8 hour run, during which performance monitor counters are captured. Results are then analyzed during the 4-hour window after the initial 2-hour ramp-up time. Several tests were run until consistent results were achieved.

Example Test Results

IMPORTANT: The following test results are not meant to represent your expected production performance. Every environment will be different based on existing server load, message sizes, attachment sizes, and percent of attachments. Note that some values (italicized) are out of range.

Exchange 2000 Server Mailbox and Public Folder Store virus protection

Test Suite 1: Normal Load

The first test suite involves creating a test load on the Exchange Servers (multi-server environment) using LoadSim for MAPI MMB2 e-mail, and MailTest for inbound SMTP e-mail. The viruses and known problem files listed in Table 4 are then introduced. The test settings on all products were as follows: scan all attachment types, on detection notify sender, administrator and recipient via e-mail, repair if possible, quarantine if not.

Effectiveness: Summary

All anti-virus scanners tested using the VSAPI passed the detection tests with essentially 100% detection rates (unlike in previous versions using Exchange 5.5 and MAPI, as discussed in the section on virus scanning APIs).

16EE-0302A-WWEN


Load Impact

The following table shows the results of running the LoadSim tests. The conclusion is that the load impact of anti-virus does vary from product to product and can affect the processor utilization significantly.

Table 7. Test Results for Load Impact on Exchange 2000 Mailbox Server with 1,000 MMB2 Users

Configuration: Mailbox Server, 2 Storage Groups, 8 Stores total - 1,000 MMB2 Users

Baseline No AV

VSAPI Product A

VSAPI Product Y

LoadSim 95th percentile Response 134 193 200

PerfMon Object Counter

% Processor Time Total 32% 58% 36%

Memory\ Pages/sec 4 16 7

Process Working Set (MB) AV n/a 5 2

Store 813 862 864

MSExchangeIS\Connection Count 1,250 1,251 1,244

MSExchangeIS\

Virus Scan MBytes Scanned n/a 3,113 3,153

MSExchangeIS\

Virus Scan Messages Processed n/a 951,685 890,360

MSExchangeIS Mailbox(_Total)\

Messages Delivered 96,778 99,535 101,640


Messages Sent 25,982 27,176 27,292

Physical Disk

% Read / % Write Data 94 / 250 111 / 280 167 / 324

Logs 0 / 6 0 / 8 0 / 7

Current Disk Queue Length (averaged over time period) OS - - -

Data 2 3 3

Logs - - -

Calculated: Physical Disk

% Read : % Write Data 27 : 73 28 : 72 34 : 66

Logs 0 : 100 0 : 100 0 : 100

Load Impact and Clustered Servers

16EE-0302A-WWEN


The following table shows the results of running the LoadSim tests against 2-node (Active/Standby) clustered Exchange Servers. The conclusion is that the anti-virus products were stable and performed well in a cluster environment. Note that even with anti-virus, the user response times could actually improve, indicating that the load impact of anti-virus was not statistically significant.

16EE-0302A-WWEN


Table 8. Test Results for Load Impact on Clustered Server with 500 MMB2 Users

Test Run Baseline No AV

VSAPI Product A

VSAPI Product B

LoadSim95th percentile Response 99 97 80


% Processor Time Total 14.3% 18.9% 14.8%

Process Working Set (KB) AV n/a

15,674 3,319

Store 283,540 284,200

287,672

MSExchangeIS\

Connection Count 530 528 538

MSExchangeIS\

Virus Scan MBytes Scanned

VSAPI not used 225 3,044

MSExchangeIS\

Virus Scan Messages Processed n/a 88,185

436,109


Messages Delivered 55,403

48,623 47,851


Messages Sent 13,253

11,561 11,816


Single Instance Ratio 1.18 1.15 1.15

% Read / % Write Data 35 / 69 38 / 72 42 / 78

Logs 0 / 3.7 0 / 3.9 0 / 3.8

Current Disk Queue Length (averaged over time period) OS 0.01 0.05 0.04

Data 1.50 1.17 0.96

Logs 0.02 0.02 0.04

% Read : % Write Data 34 : 66 35 : 65 35 : 65

Logs 0 : 100 0 : 100 0 : 100

Load Impact and Varying RAID Levels

The following table shows the results of running a baseline, anti-virus “Product A” and then anti-virus “Product B” on RAID1+0. Then the RAID array was converted to RAID5, the Stores were moved to the new array and the tests run again. The conclusion is that using RAID5 (to provide more disk space) instead of RAID1+0 does have a significant negative impact on performance, as measured by the client response time. In fact, the load impact is much greater when multiple Stores are placed on the same RAID array, as shown in the next section and in the separate paper “Impact of Exchange 2000 Information Store Partitioning” available at www.hp.com/solutions/activeanswers.

16EE-0302A-WWEN

http://www.hp.com/solutions/activeanswers


Table 9. Test Results for Load Impact with Varying RAID levels - 1,000 MMB2 Users, 8 Stores total

Test Configuration: Mailbox Server, 2 Storage Groups, 8 Stores total - 1,000 MMB2 Users

Baseline No AV

VSAPI Product V

VSAPI Product A

VSAPI Product A

RAID Level RAID1+0RAID1+0 RAID1+0 RAID5

LoadSim95th percentile Response 135 158 193 238


% Processor Time Total 33% 40% 58% 40%

Memory\ Pages/sec 26 33 16 11

Process Working Set (KB) AV - 13 5 4

Store 836 834 862 863

MSExchangeIS\Connection Count 1,251 1,248 1,251 1,187

MSExchangeIS\

Virus Scan MBytes Scanned

VSAPI not used 2,011 3,113 1,852

MSExchangeIS\

Virus Scan Messages Processed

VSAPI not used 192,218 951,685 771,466


Messages Delivered 127,161 97,279 99,535 28,115


Messages Sent 33,023

26,307 27,176

7,199

Physical Disk

% Read / % Write Data 98 / 241110 / 279 111 / 280

108 / 254

Logs 0 / 6 0 / 7 0 / 8 0 / 7

Current Disk Queue Length (averaged over time period) OS - - - -

Data 2 3 3 3

Logs - - - -


% Read : % Write Data 29 : 71 28 : 72 28 : 72 30 : 70

Logs 0 : 100 0 : 100 0 : 100 0 : 100

Load Impact of Multiple Stores

16EE-0302A-WWEN


The following table shows the results of running a single store baseline, with and without anti-virus “Product X” and then two stores, four stores, and then two stores in each of two storage groups (all on RAID1+0). The conclusion is that using multiple stores has an impact on anti-virus scanning (as evidenced by the increased resource utilization such as processor, and connection count), however the end result as measured by client latency was not significant.

16EE-0302A-WWEN


Table 10. Test Results for Load Impact of Multiple Stores

Test Configuration Single Store 2 Stores 4 Stores 2x2 Stores & SGs

500 MMB2Baseline No AV

VSAPI Product

XBaseline No AV

VSAPI Product

XBaseline No AV

VSAPI Product

XBaseline No AV

VSAPI Product

XLoadSim 95th percentile Response 70 70 72 69 80 95 93 90


% Processor Time Total 6% 9% 7% 9% 9% 12% 8% 12%

Process Working Set (MB) AV n/a 21 n/a * n/a 647 n/a *

Store 544 483 543 592 612 633 637 *

MSExchangeIS\ Connection Count 428 434 463 467 539 544 554 556

MSExchangeIS\

Virus Scan MBytes Scanned n/a 53 n/a 175 n/a 346 n/a 319

MSExchangeIS\

Virus Scan Messages Processed n/a 34,628 n/a 34,236 n/a 50,655 n/a 51,582


Messages Delivered 14,175 11,110 16,084 14,705 15,490 15,743 15,288 15,743


Messages Sent 5,781 4,580 6,963 6,031 6,632 6,794 6,555 6,794

Physical Disk

% Read / % Write Database 7 / 15 7 / 15 8 / 31 11 / 33 10 / 53 10 / 52 10 / 35 11 / 38


% Read : % Write Database 32 : 68 32 : 68 21 : 79 25 : 75 16 : 84 16 : 84 22 : 78

22 : 78

* = counter missing

16EE-0302A-WWEN


Test Suite 2: Peak Load (Stress Test)

The second test suite involves creating a very heavy test load on the Exchange Servers (multi-server environment) using LoadSim for MMB2 e-mail (Outlook MAPI simulation), and MailTest for inbound SMTP e-mail. The viruses and known problem files listed in Table 4 are then introduced.


All anti-virus scanners tested using the VSAPI passed the detection tests with near 100% detection rates (unlike in previous versions, as discussed in the section on virus scanning APIs). The new VSAPI performed exceptionally better under peak load than previous anti-virus APIs – in some cases, depending on the anti-virus product, the virus-infected e-mail would appear in the inbox under heavy load, but would be scanned and removed when the e-mail client attempted to open the message. There were a few rare exceptions where the anti-virus scanners let a virus slip past when primary mail-delivery was set to a personal folder (PST) under extreme load, but this was primarily seen on beta code, and is expected to be a non-concern for shipping products. The only other circumstance where the VSAPI products may not be 100% effective is on outbound e-mail under very heavy load, if the Exchange Server is able to send to an Internet connection. This circumstance can be prevented by having multiple types of transport scanning, such as VSAPI on the mailbox servers and SMTP-based scanning on the Internet connections.

Load Impact

Since this test was a stress test, the relative load impact of anti-virus was not measured. Suffice it to say that the new VSAPI has the ability to queue messages for scanning and can prevent viruses from bypassing scanning even under heavy load, as demonstrated above.

Test Suite 3: Impact of Multiple Storage Groups and Mailbox Stores

The third test suite involves creating a test load on the Exchange Servers (multi-server environment) using LoadSim for MAPI MMB2 e-mail, and MailTest for inbound SMTP e-mail. The viruses and known problem files listed in Table 4 are then introduced. The results are measured for a single mailbox store, and then additional mailbox stores (two then four) are created, and mailboxes moved to those stores for additional test. Finally, multiple stores are created within multiple storage groups and the tests repeated.


The anti-virus software saw no measurable impact in effectiveness from Information Store partitioning, as the single incoming e-mail message is scanned before it is delivered to multiple Information Stores. However, if the virus is not caught through real-time scanning then multiple messages must be scanned and cleaned through manual or scheduled scanning.

Load Impact

16EE-0302A-WWEN


Conclusion: The anti-virus software saw no measurable impact in performance from Information Store partitioning, as the single incoming e-mail message is scanned before it is delivered to multiple Information Stores. However, there was a measurable performance impact (primarily on the storage subsystem) due to Information Store partitioning, either with or without the anti-virus scanning. See the document “Impact of Exchange 2000 Information Store Partitioning” available on http://www.hp.com/solutions/ActiveAnswers for full information. The net result is that multiple Information Stores will shift the read-write ratio on the Exchange database volume to a higher write percentage, negatively affecting performance, especially on RAID5 volumes.

SMTP Front-End Virus Protection

Implementing anti-virus scanning and content filtering on the SMTP gateways or Exchange front-end servers can reduce the processing of unwanted content done at the back-end Exchange in a multi-layered approach. However, as the following tests indicate, virus-scanning at the front-end servers is very processor intensive and can become the bottleneck, significantly affect e-mail throughput. Without virus-scanning the SMTP disk queue is normally the bottleneck. Tests were performed moving the SMTP disk queue to a very fast disk (solid state) to determine maximum STMP throughput.

Note: Running SMTP anti-virus scanning on front-end Exchange Servers does not protect against viruses sent by Outlook Web Access users who connect to the front-end servers. It is necessary to run anti-virus designed to protect Exchange mailbox servers.

Test Suite 4: SMTP Throughput

To evaluate the effectiveness and impact of placing anti-virus on the SMTP front-end servers, a mix of test messages was sent to the SMTP server. Throughput was measured by timing the receipt of a mix of messages, some of which contained viruses. Relative throughput compares the length of time to process delivery of these messages compared to raw SMTP numbers without anti-virus scanning. The test messages varied in size from 22 1-KB messages, 1 200-KB message with a virus attached, and 1 4-MB message in the test pool. The table below shows the impact on throughput and processor utilization of anti-virus.

Table 11. STMP Throughput with and without Anti-virus.

Without anti-virus During anti-virus

How fast can the SMTP Server process inbound messages?

6.4 msg/sec 1.8 msg/sec

What are the key resource utilizations? Processor 8%

Disk Queue 1.5

Processor 70%

Disk Queue 0.8

Are any messages dropped or missing under load? No No

16EE-0302A-WWEN

http://www.hp.com/solutions/ActiveAnswers


A second set of tests was performed to determine the maximum throughput without and with virus-scanning. When running virus-scanning the processor is the bottleneck, and disk response is not as critical. To determine the maximum throughput of the server, the SMTP mail queue was moved to a solid-state disk to maximize performance and compare the result.

Table 12. SMTP throughput with and without anti-virus on front-end

SMTP Tests Messages Sent / Sec

Bytes Sent / Sec

CPU

Inetinfo

CPU

Total

Disk queue on STMP root

During anti-virus 2 318,422 6 90 1.4

Without anti-virus 6 1,250,577 13 19 1.4

Without A-V (SMTP queue on solid state disk to eliminate disk bottleneck)

16 6,711,215 39 54 N/A

Phase 5 - Deploy the SolutionThe solution chosen, and the level of effort placed in virus detection and prevention depends on the level of commitment in the organization. There is no one common solution, yet there are many actions that can be taken. The following section outlines different approaches to solutions.

Comprehensive Solution DefinitionsSolution Architects and Deployment Managers must make a decision about the level of protection needed. The following section defines three levels of solutions, depending on what the customer or organization deems as a comprehensive solution. Selection of the solution is determined by assessing the risk of damage and loss caused by viral outbreak that the organization is willing to assume.

HP Best Practice: Establish the appropriate level of protection for your organization, balance the risks associated with being less protected versus the cost and administrative overhead of maximum protection.

Table 13. Solution Level 3 - Points of Entry

Level of Protection Implementation

Overall Implement all 3 tiers and use the methods of prevention and detection discussed in the previous section “Borders of Protection” as outlined below.

Tier 1: Client Desktops Implement Real-time Anti-Virus Scanning or Dynamic Security

System Deployments Back-up system information and automate deployment of standardized desktops (this aids in recovery of systems)

Hardware Use hardware that offers built-in virus protection

Tier 2: File and Application Servers

Implement Real-time Anti-Virus Scanning

Tier 3: Firewalls and Gateways Implement Real-time Anti-Virus Scanning on SMTP Gateways

Exchange Server Schedule nightly sanitizer (if not scanning )

16EE-0302A-WWEN


Policies and Procedures Create on Organizational Policy on Network Security, Content Control and System Operations

User Education Conduct training and distribute information to educate end-users on what viruses are, how they are transmitted, and to prevent them

Procedures Establish a procedure for handling suspicious files or activity

Disaster Recovery Back-up critical data. Minimize potential loss due to viral disruption

Internet

Your Organization

Poi

nt o

f Ent

ry

Point of EntryPoint of Entry

Removable storage

Gateway / Firewall

SMTP Relay(email)

Exchange MailboxServer

Network Server

Figure 5: Solution Level 3 - Points of Entry

For a high level of security with less administrative overhead, follow these guidelines

Table 14. Solution Level 2 - Points of Access


Overall Implement all 3 tiers and use the methods of prevention and detection discussed in the previous section “Borders of Protection” as outlined below.

Tier 1: Client Desktops Implement Real-time Anti-Virus Scanning and Dynamic Security. Deploy a secure desktop operating system and limit the administrative powers of the current user logon context.




16EE-0302A-WWEN




Exchange Server Implement Real-time Anti-Virus Scanning on Mailbox Servers

Schedule nightly scanning


User Education Conduct training and distribute information to educate end-users on what viruses are, how they are transmitted, and to prevent them.

Procedures Establish a procedure for handling suspicious files or activity.

Disaster Recovery Back-up critical data. Minimize potential loss due to viral disruption.

Internet

Your Organization

Poi

nt o

f Ent

ry


Removable storage

Gateway / Firewall

SMTP Relay(email)


Network Server

Figure 6: Solution Level 2 - Points of Access

While Level 1 creates the tightest security, it also requires the most administration and can interrupt the flow of valid business information.

Table 15. Solution Level 1 - Zero Tolerance


Overall Implement all 3 tiers and use all six methods of prevention and detection discussed in the previous section “Borders of Protection” as outlined below.

16EE-0302A-WWEN



Tier 1: Client Desktops Implement Real-time Anti-Virus Scanning and Dynamic Security. Deploy a secure desktop operating system and limit the administrative powers of the current user logon context. Add personal firewalls to detect intrusion. Convert HTML email to text to avoid active HTML payloads.


Hardware Use hardware that offers built-in virus protection




Exchange Server Block Content Type that is active code; quarantine and test in isolation.

Implement Real-time Anti-Virus Scanning on Mailbox Servers for Content Type that is not actively blocked

Schedule nightly scanning


User Education Conduct training and distribute information to educate end-users on what viruses are, how they are transmitted, and to prevent them.

Procedures Establish a procedure for handling suspicious files or activity.

Disaster Recovery Back-up critical data. Minimize potential loss due to viral disruption.

Internet

Your Organization

Poi

nt o

f Ent

ry


Removable storage

Gateway / Firewall

SMTP Relay(email)


Network Server

CodeBlocking

CodeBlocking

16EE-0302A-WWEN


Figure 7: Solution Level 1 - Zero Tolerance

To implement the above recommendations for maximum protection, enhanced security services such as HP Security Enhancements for Microsoft Exchange can be contracted. See http://www.compaq.com/services/security/nt_exchange_se.html for more details.

Network SecurityFrom a network security perspective, e-mail transports are typically wide open to authentication and transmission of messages. Therefore, e-mail transports have been a target for viral transmissions. The following section applies network security to messaging systems.

Generic Network Security consists of six levels (in addition to Level 0, which would be no control of access to information). The first level is Identification of who will be accessing the information, usually through assignment of logon credentials. An example is anonymous FTP, where an e-mail address is given as logon credentials, though no attempt is made to match it with a valid address or password. The second level is Authentication of the user by matching the identification with a known set of users. To limit access to the user identification, passwords are assigned. The third level is Authorization, where the supplied credentials are matched against an access control list to determine if the current user should have access to the information. The fourth level, Privacy, may not be intuitive, as it involves determining if the user should be accessing the information (even if they have rights to do so). An example is mail system Administrators who have the power to access mailboxes for troubleshooting purposes, however they should not be doing so without the users’ permissions. The fifth level is to verify the Integrity of the information; to ensure that the represented form is consistent with the original source and that no accidental or intentional corruptions have taken place during transmission. The sixth level is known as Guardianship or Ownership, which determines who is responsible for securing, maintaining, and verifying the information.

These levels of security need to be applied to Exchange Server systems to address security issues. The final section of this document illustrates such an application.

Messaging Security

The following table applies the six levels of network security to messaging, and illustrates the solution components required for a fully implemented, secure messaging environment. Some aspects deal with restricting Internet mail or digitally securing e-mail and are beyond the scope of this article, but need to be addressed in order to create a fully secure environment. From this view, it can be seen that anti-virus scanning is just one component of a larger solution.

Table 16. The six levels of security as applied to Messaging and Exchange Server systems

16EE-0302A-WWEN

http://www.compaq.com/services/security/nt_exchange_se.html


Levels of Control Solution Component

1. Identification Reverse DNS look-ups (matching IP address to claimed domain name of sender)

2. Authentication Digital Signatures

3. Authorization Denying SMTP relaying and setting Inbound Domain Restrictions (anti-UCE)

4. Privacy Content Filtering and Digitally Secured Mail

5. Integrity Anti-Virus Scanning

6. Guardianship Establish Organizational Policy and Procedures

16EE-0302A-WWEN


Exchange Server Configuration

Procedural Changes

Systems Administrators are learning that they cannot always keep up with the introduction of new viruses, and must educate their users on what to expect and how to deal with viruses.

Viruses such as Melissa and its variants took full advantage of automation to exploit these systems. The end result is that full automation of systems must be turned down a notch. Specifically, Exchange Administrators need to limit the number of recipients that can be sent to at one time (limiting the power of the virus): It is recommended as a best practice that message “send throttling” be enabled on systems as well, to prevent an automated viral attack from recursively selecting recipients from the Global Address List even one at a time. This will monitor the rate of sending from a recipient and prevent it from exceeding a configurable threshold, one that can be expected on reasonable, human terms. To do so currently requires a third-party add-in for system monitoring and management. NetIQ will be adding such a feature to their product in response to this suggestion.

HP Best Practice: Limit the number of recipients that an automated sender can access.

Phase 6 – Manage and MaintainFor the anti-virus deployment project to be considered complete, it must achieve a level of stability and self-sufficiency. This document has covered maintaining system operations and receiving updates to viral definition files. However, the system must be prepared for future developments in the viral problem. This section discusses problems and outlines how the system administrator can best stay prepared.

New ThreatsAs new development technologies are introduced, they bring with them new opportunities for exploitation. Current scanning technology focuses on detecting viruses in attachments. It is now possible to deliver payloads via active content within message bodies; however, proper system configuration and user education can effectively prevent damage. With the increasing usage and popularity of additional features to the core of e-mail based messaging, such as Instant Messaging and the Universal Inbox (using Exchange Server to host voice, fax and other data types), it is only a matter of time before we see these become vectors for viral transmission.

HP Best Practice: Protect against future threats announced in security resources listed below, such as protecting against active scripts, HTML message bodies, and the Alternate Data Streams threat by blocking incoming attachments with the extension “*}”. See http://www.sans.org/infosecFAQ/threats/win_NTFS.htm for more information.

16EE-0302A-WWEN



Administrative Outbreak Plan

Since the threat of viral outbreak may never be completely eliminated, it is recommended to have an Administrative outbreak plan in place.

– First, shut down SMTP outbound and internal mail hub bridgehead servers to restrict virus flow.

– Identify infected systems and take them off the network (unplug cable or hard power down).

– Conduct research on type of infection and clean up procedures.

– Download and distribute updated anti-virus signatures and clean-up scripts. Apply security patches as necessary.

– Determine criteria for completion of clean-up and when it is safe to re-connect systems and email connectors.

Other Security Issues

Digital Signatures and Encryption

PKI (Public Key Infrastructure) will see increasing usage as lack of trust becomes widespread. Digital signatures are used to verify authorship and ensure that messages are transmitted without alteration. Digital encryption is used to protect the contents of messages from unauthorized access during transmit. At this point, signatures and encryption effectively eliminate the possibility of anti-virus scanning. As the market momentum for PKI increases, vendors will integrate with anti-virus products. Testing of anti-virus products will need to be extended to integrate with the PKI.

Restricting Transmissions

The most restrictive method is to block all incoming addresses except those allowed by the administrator. However, this can become quite an administrative hassle. Alternatively, a list of restricted sending domains can be tied into an Internet database such as the APS Real-time Blackhole List (http://mail-abuse.org/rbl.), the MAPS Dial-Up User List (http://mail-abuse.org/dul. These databases are propagated using the same methods as DNS, making integration into SMTP servers reasonably simple. During the SMTP connection establishment phase, the receiving end will check the IP address of the connecting site in the appropriate list via DNS. If a match is found, then the receiving MTA will drop the connection before accepting any mail from the known mail abuser.

16EE-0302A-WWEN

http://mail-abuse.org/dul

http://mail-abuse.org/dul

http://mail-abuse.org/rbl


Reducing Unnecessary Automation

One of the consequences of continued viral outbreaks is that many companies are finally heeding the advice to reduce the level of automation in their systems. When the first Visual Basic Script (VBS) viruses hit, many companies disabled Windows Scripting Host, the engine that allows these scripts to run. However, this reduces the functionality of the personal computers as they are now no longer able to run VBS files at all. Instead, it is recommended that the default actions for VBS files be changed to Edit so that Notepad is launched instead. It is still possible to run VBS files using the right-click menu. The following Registry import file can be disseminated via login scripts or e-mail attachment:

REGEDIT /S VIRUSFIX.REG[HKEY_CLASSES_ROOT\VBSFile\Shell]@="Edit"[HKEY_CLASSES_ROOT\VBEFile\Shell]@="Edit"[HKEY_CLASSES_ROOT\JSFile\Shell]@="Edit"[HKEY_CLASSES_ROOT\JSEFile\Shell]@="Edit"[HKEY_CLASSES_ROOT\WSFFile\Shell]@="Edit"[HKEY_CLASSES_ROOT\WSHFile\Shell]

@="Edit“

HP Best Practice: Reduce system automation, by changing the default actions for active scripts on desktop computers.

Staying Informed

It is highly recommended to keep current on network security issues by regularly checking news reports and websites. Many sites listed in the Appendix offer e-mail subscriptions to obtain alerts automatically.

16EE-0302A-WWEN


Appendix: Additional Information

Viral DefinitionsVirus: A software program that replicates itself by exploiting another computer system. The end user is usually not aware of their presence or function. The initial forms of virus introduced to the PC environment, attacked the boot sector, executables or data files.

Signature: The part of a computer virus’ code that uniquely identifies it. In rare instances, a legitimate software program will also contain that same code, triggering a false positive.

Payload: The destructive part of a computer virus, causing damage to files or the computer system itself.

Worm: Unlike a virus, does not infect other files, but replicates from computer to computer as a self-contained, stand-alone file. Can also contain a payload causing performance problems and corruption to other files.

Trojan Horse: A destructive software application that masquerades as a legitimate, desirable application. May also be viral, and replicate itself.

Coded virus: Contains encryption code within the virus to hide the virus from detection. Can then escape detection by some anti-virus software when compared to an inventory of known viruses. A decryption routine restores the virus when it executes. Makes scanning based detection slower, more complicated, and less reliable, forcing scanning programs to decrypt the virus before finding an identifiable signature.

Polymorphic virus: When a virus is given the ability to change with each new infection, making it difficult to identify a static signature.

Stealth virus: Contains code to intercept a request for the file that it has infected and un-infects the file to avoid detection, then re-infects the file.

Macro virus: Rather than being a compiled executable uses the macro language of Microsoft Office applications to replicate and deliver its payload.

UCE: Unsolicited or unwanted e-mail, usually sent in large volume. Included here in the context of a transmission means for viral information.

16EE-0302A-WWEN


Research Organizations and Information SourcesTable 17. Research Organizations and Information Sources

Anti-Virus Research Network Security

http://www.eicar.org/ http://www.cerias.purdue.edu/

http://www.cert.org/nav/alerts.html/ http://www.gocsi.com/

http://www.virusbtn.com/ http://www.icsa.net/

http://www.uta.fi/laitokset/virus/

http://www.wildlist.org/ Microsoft

http://www.microsoft.com/security/bulletins/current.asp

Anti-Virus Software Vendors

http://www.antivirus.com/vinfo/alerts.htm HP ActiveAnswers

http://www.avertlabs.com/public/datafiles/valerts


http://www.sarc.com/

http://www.sybari.com/alerts/

16EE-0302A-WWEN

http://www.sybari.com/alerts/

http://www.sarc.com/


http://www.avertlabs.com/public/datafiles/valerts/

http://www.avertlabs.com/public/datafiles/valerts/

http://www.antivirus.com/vinfo/alerts.htm

http://www.microsoft.com/security/bulletins/current.asp

http://www.wildlist.org/

http://www.uta.fi/laitokset/virus/

http://www.icsa.net/

http://www.virusbtn.com/

http://www.gocsi.com/

http://www.cert.org/nav/alerts.html/

http://www.cerias.purdue.edu/

http://www.eicar.org/


Sample Evaluation Criteria for Selecting Anti-Virus Products Table 18. Sample Evaluation Criteria for Selecting Anti-Virus Products

Criteria Product A

Product B

Verify Exchange 2000 Compatibility: protects multiple stores and client access from MAPI, OWA, Internet protocols and the EXIFS (M: drive).

Product licensing and support (additional cost)

Virus entry points protected (Front-End or Back-End, SMTP, Store, or client version)

API Method used: MAPI, AVAPI, VSAPI, other (ESE), or Combination?

Does it support any special hardware, such as multi-processor or clusters?

Remote installation, configuration, monitoring, updating, and management?

Administrative Console type: Web, MMC, both?

Enterprise (Multi-Server) Console and remote administration?

Scheduled, automatic updates of the virus signature files, push or pull? Firewall/proxy settings? Can it fan out from an internal http or \\UNC share?

Scan Engine used (or multiple scan engines)

Does it scan in memory or must it write attachments to disk?

Scans all message content (attachments and compressed files, message body, HTML)

Heuristics or other technology to detect and prevent macro viruses and new viruses

Does it provide selective attachment blocking? What types of special features for dealing with virus outbreaks?

Does it provide any other form of content filtering?

Does it provide purging or deletion of entire worm messages?

Any special features for dealing with virus outbreaks?

Can you customize alert messages to administrator(s), sender, and recipient? Does it distinguish between external and internal? Choice of transports or alerting mechanisms such as NET SEND as well as e-mail?

Can it break digitally signed or encrypted e-mails to scan for viruses?

Can you exclude certain folders from manual scanning (e.g. Organizational Forms Library)

Any other custom features that are required?

e.g. control over depth of attachment scanning (levels of compression before flagging the message for quarantine)

Product Evaluation

What is the measured performance impact in our evaluation, and will it require changes to our existing server platform?

What is the measured effectiveness in our evaluation, and does that meet our standards?

What is the administrator perception for ease of deployment and ongoing maintenance / management?

16EE-0302A-WWEN


Best Practices Summary List

The following list is a compilation of best practices from ISS Solutions & Strategy on preventing or reducing the impact of viruses transmitted via email.

Organization level

Announcement of Corporate Policy and Anti-Viral Program

Education Campaign – e.g. Dealing with unsafe email and attachments

Establish Level of Commitment (eg 99% --> 99.9% --> 99.99%)

Desktop Desktop file-base anti-virus scanning (with automatic updates)

User Education program (dealing with attachments)

Browser Settings: Set Internet Zone and Restricted Zone security

Change scripting default e.g. Edit VBS instead of Open

Reduce power of Logon Context

Un-Hide File Extensions

Consider PC Firewall to block backdoors

Email client

Upgrade Outlook to latest version or service pack

Upgrade Outlook Express to v6 (attachment blocking)

Turn off HTML (option in Office XP SP1)

Email servers

Server side virus scanning and/or content filtering

Do not rely on attachment extensions (cannot trust MIME) for scanning

Outbreak plan in place for Administrators

Other Servers

Keep up to date on security patches (automatic updates)

File-base anti-virus scanning (very carefully!)

Change share permissions – (Everyone not Full Control)

Admin Logon Context - Use RunAs or Remote Desktop

Active Directory

Consider Group Policy to restrict applications

Consider Group Policy to restrict zones

Network Close or protect points of entry/exit (e.g. pop3 and unauthorized SMTP)

16EE-0302A-WWEN

anti-virus solutions for microsoft exchange 2000 server.doc

Documents

highly secure

application

multiple storage

transport

proliant platform

trend micro

viral attachment

handling suspicious