Give your Exchange environment defense in depth
Since the Melissa virus gave everyone a wake-up call in 1999, administrators understand the need to protect their Microsoft Exchange Server servers against incoming threats. From an Exchange administrator’s perspective, establishing effective defense against email-borne viruses was the immediate priority, followed closely by educating users about how viruses infect systems and how to recognize suspicious content. Today, most servers are well protected against viruses but perhaps less so against spam. Now is a particularly good time to review your antispam protection because Microsoft has included some new features in Exchange Server 2003 that Independent Software Vendors (ISVs) can leverage in antispam tools.
The concept of defense in depth means using multiple layers of suppression to block as much spam as possible between initial penetration through mail servers to final mailbox delivery. Defense in depth also means increasing user awareness of the likelihood that they'll receive spam if they contribute to Internet newsgroups and other forums, and of the techniques that spammers use to discover addresses that they can't harvest. Of course, like antivirus protection, defense in depth is expensive to establish. Some companies—especially small to midsized enterprises—choose to implement one suppression method rather than multiple layers. If you go this route, server-based suppression is smart because it affords maximum protection to clients (including Microsoft Outlook Web Access—OWA) without requiring you to upgrade desktop software. Let's take a look at some of the tools and techniques you can use to implement defense in depth, as well as the new features in Exchange 2003 that Microsoft has introduced to combat spam.
Defending the Perimeter
Large companies such as HP commonly deploy bastion servers to watch incoming SMTP traffic and make the decision whether to pass messages through for further processing. You can certainly use Exchange 2003 as a bastion server, particularly if you deploy Exchange 2003 on Windows Server 2003 and use an antispam package rather than the software's built-in connection-filtering capability. Although you can also deploy Exchange 2003 on Windows 2000, Windows 2003 is a more secure platform, primarily because of Microsoft Internet Information Services (IIS) 6.0 and the overall effect of Microsoft’s Trustworthy Computing initiative.
Perimeter-defense servers accept SMTP connections for a domain (e.g., abc.com) and perform two quick checks: first, to ensure that the inbound messages don't contain known virus payloads; and second, to check against a recognized Real-time Blackhole List (RBL) provider such as the Mail Abuse Prevention System (MAPS), Spamhaus, or the Open Relay Database (ORDB) to immediately detect spam. Blackhole lists contain entries for known spammers and servers that act as open relays, which spammers can hijack when they want to use someone else’s computing power to send their messages. So, checking incoming messages against a blackhole list is a good way to suppress a lot of spam, assuming the blackhole list is up-to-date. (Don't forget to test traffic against an RBL filter before you introduce the filter into production. Some RBLs let a lot of spam through, whereas others suppress traffic that you need. You might want to combine lookups against multiple RBLs to ensure that you catch as much spam as possible—a capability that Exchange 2003 supports.)
Optionally, bastion servers can validate that a given message is addressed to a valid recipient within the target organization. To do so, the server checks the address against directories such as the Exchange Server 5.5 Directory Store, Active Directory (AD), or another Lightweight Directory Access Protocol (LDAP)–compliant directory. As an example, HP's bastion servers handle approximately 30 million messages per month addressed to hp.com recipients and drop 70 percent of the traffic, leaving roughly 9 million messages to pass through to email servers for processing. Unfortunately, a rising proportion of these validated messages contains spam—a tribute to the skill of spam generators as they combat efforts to suppress their messages.
If you aren’t yet ready to deploy Windows 2003 and Exchange 2003, you can choose from a variety of available commercial perimeter-defense products, such as Clearswift’s CS MAILsweeper for SMTP (which monitors gateways and network connection points) and CS MAILsweeper for Exchange. To avoid the preponderance of attacks against Microsoft systems, some administrators prefer to deploy Linux or UNIX servers as their connection points to the Internet, then adopt antispam and virus-checking solutions that work with sendmail or Postfix Message Transfer Agents (MTAs).
Exchange 2003 Defense
When Microsoft designed Exchange 2000, spam wasn't the annoyance that it is today. Viruses represented the major threat to Exchange servers, so Microsoft concentrated its energies on developing the Virus Scanning API (VSAPI) and convincing major ISVs to support VSAPI by including it in its products. You can configure filters on Exchange 2000 SMTP virtual servers to reject messages from specific users or domains, but this approach isn't sufficiently sophisticated to combat today’s spammers. As Exchange 2003 progressed through development, Microsoft understood that it would need to boost the server’s ability to suppress spam. Exchange 2003 therefore introduces connection filtering, which you can configure through the Exchange System Manager (ESM) console's Global Settings node. Select the Message Delivery object, choose Connection Filtering to define the rules that are applicable for the organization as a whole, then apply the new filters to the SMTP virtual servers on the Exchange servers that host SMTP connections to the Internet.
Figure 1 shows how to configure lists for connection filtering. To ensure that you catch as many unwanted messages as possible, you can configure multiple filters and elect to look up multiple RBLs (or Block List Services). You can also configure exceptions so that Exchange doesn't regard messages from important partners or other correspondents as spam—even if they contain potential spam signatures, such as an offer to "get rich quick." In addition to connection filtering, Exchange 2003 lets you define recipient filters and sender filters. Recipient filters apply blocks to incoming messages that are addressed to specific recipients. You can also create a recipient filter that checks all incoming messages against AD and refuses any messages that aren't addressed to a valid recipient. Spammers routinely use automatically generated addresses in an attempt to send messages to everyone in a domain, so recipient filters let Exchange avoid incurring the overhead of accepting spam and processing it through the routing engine.
Sender filters are similar to recipient filters except that you define a list of email addresses from which you never want to accept messages. When Exchange detects an incoming message from one of the addresses on the "dump" list, it immediately drops the connection. You can also use sender filters to drop connections for messages that have blank sender information—another favorite trick in the spamming community.
In Exchange 2000, Microsoft replaced the X.400-based MTA with an extensible SMTP-based routing engine. Ever since, ISVs have been able to implement transport sinks that include code to examine messages as they arrive at the SMTP service (before Exchange accepts them for categorization and further processing). Blocking spam at the SMTP entry point is an efficient use of system resources because Exchange doesn't need to resolve email addresses, expand distribution groups, determine the most effective routing path, or any other message-routing processing. Also, immediately scanning and dumping spam is preferable to propagating spam within the Store. After spam gets into user mailboxes, it typically requires further server overhead in the form of storage, management, transport, and backup—not to mention user annoyance. Finally, server-based spam suppression lets you protect many types of clients without needing to worry about implementing antispam software on Outlook, Outlook Express, and different Web browsers. And wireless-device users will appreciate that spam isn't wasting valuable wireless bandwidth.
Relatively few ISVs have taken up the challenge of developing transport sinks to combat spam, largely because viruses have been the major threat to servers and therefore represent a more lucrative product market. However, some software developers have recognized the possibilities that event sinks offer for spam warfare. A good example of a product that uses an event sink to suppress spam in Exchange 2000 is martijnjongen.com's ORFilter, a freeware tool that checks incoming SMTP messages against lists of open-relay servers and rejects those that come from a known open relay.
I've recently noticed an increased interest in the use of transport sinks for spam suppression among both antivirus vendors (who want to increase the functionality and competitiveness of their products) and developers of purpose-designed tools. Sybari Software’s SpamManager is a good example of a company using a transport sink to extend the capabilities of a well-known antivirus product to provide spam suppression. Sybari's newly introduced Advanced Spam Defense product takes an innovative step by incorporating Commtouch technology that uses digital signatures and network probes to detect, stamp, and suppress spam.
The SCL Hook
Microsoft introduced VSAPI in Exchange 2000 as the platform for antivirus tools to gain access to Exchange components such as the Store. Microsoft has updated VSAPI in Exchange 2003, but the most important upgrade that ISVs can exploit to protect servers against email threats is a new "hook" that antispam products can leverage.
The Spam Confidence Level (SCL) is a new Store property that antispam products can update, using whatever techniques or algorithms they want to engineer into their transport sink. And the Store SCL Processor is a new Store component that looks for SCL values, then takes action based on the value—as well as certain client settings if the client supports features such as Outlook 2003’s Junk E-Mail Filter. The higher a given message's SCL value, the higher the probability that the message is spam. To determine the SCL value, antispam utilities use different algorithms to analyze data in message headers and contents.
The threshold values that Exchange 2003 uses for SCL processing reside in three attributes that Exchange 2003 adds to AD when you run the Setup program's ForestPrep component. These attributes are
- Enabled Flag (ms-Exch-Uce-Enabled)
- Block Threshold (ms-Exch-Uce-Block-Threshold)
- Store Action Threshold (ms-Exch-Uce-Store-Action-Threshold)
To establish whether Exchange performs SCL processing within an organization, the Enabled Flag is set to 0 or 1. The Block Threshold determines the value at which antispam products take action to block a message—either by dropping it completely or moving it to a quarantine area. The Store Action Threshold tells Exchange how to deal with messages that pass through for delivery. If the message has an SCL value higher than the threshold, Exchange puts the message into the Junk E-Mail folder; otherwise, it goes into the Inbox as usual. Vendors are still working out the exact details about how their antispam products will manipulate and interact with these settings, but I like to see that Microsoft has put the fundamentals in place.
If you desire, you can deploy multiple antispam utilities or perhaps an antispam product that uses several scanning techniques (similar to the way that some antivirus products use multiple virus-detection engines to ensure that they catch a higher percentage of suspect messages). In any case, the desired outcome is to either discard spam or permit messages to pass through for further processing—with an SCL score in their Properties that will help client-side utilities process the messages.
For example, Outlook 2003’s Junk E-Mail Filter feature lets you choose to delete suspected spam messages. (The default setting is to place these messages into a Junk E-Mail folder.) Typically, Outlook’s junk-email processing algorithm determines whether to file these messages in the Junk E-Mail folder after they arrive in the user’s mailbox. However, on an Exchange 2003 server equipped with suitable antispam software that sets the SCL, the Store can make the decision and refile messages that an antispam utility has determined have a high SCL value—before they go anywhere near the client. This scenario is preferable because the client doesn't need to download messages, so you save bandwidth and processing.
If you decide to deploy antispam products with Exchange 2003, I recommend selecting products that support SCL processing. At the time of this writing, such products are in still in beta, but you should be able to get SCL-compliant antispam products soon after Microsoft ships Exchange 2003. You'll find detailed information about the SCL in the Exchange 2003 software development kit's (SDK's) Solutions section in the Microsoft Developer Network (MSDN).
Not everyone is ready to deploy Exchange 2003. Thankfully, a healthy commercial market exists for add-on antispam products that protect Exchange 2003 servers. Sunbelt Software’s iHateSpam Server Edition is a good example of a standalone antispam tool that supports Exchange 2003 and Exchange 2000. (A gateway version is available for Exchange 5.5.) Sunbelt Software also offers a client edition of iHateSpam that protects Outlook 2002 and Outlook 2000 clients.
The server edition monitors incoming SMTP traffic and checks it against the blackhole lists and whitelists that you configure, as well as any additional policies that you want to use. (For example, you might treat any message that mentions "viagra" as highly probable spam.) Installing and configuring iHateSpam is easy and doesn't affect users, nor does the tool require any updates to the AD schema. The product boasts impressive reporting capabilities that let you see information such as spam volume and the user who receives the most spam, but you need to channel data to a Microsoft SQL Server 2000 database before you can report on it. The software also inserts a "spam rating" into the message header to give users a quick spam evaluation. (To see SMTP message headers in Outlook, open a message and click View, Options. Outlook displays the message-header information in the Internet Headers field.) Sunbelt is reportedly planning a new version of the product that will let you use the Microsoft Data Engine (MSDE) instead of SQL Server. This modification will reduce complexity and let small sites avoid the cost of SQL Server licenses.
Other server-based antispam products include CS MAILsweeper for Exchange, Brightmail Anti-Spam Enterprise Edition, GFI MailEssentials for Exchange/SMTP, and McAfee Security's McAfee Spamkiller. (You can find more antispam products at Slipstick Systems' Content Control Tools page at http://www.slipstick.com/addins/content_control.htm.) Expect current interest in spam protection to drive the development of other products in this space. All the aforementioned products support Exchange 2003, although some of them require software updates to support Exchange 2003's antispam SCL hook. As with most software products, I recommend downloading evaluation copies from vendors' Web sites and running the software on test servers to see which product best suits your environment. The cost of deploying these products varies from country to country and depends on the level of support that you require. You also need to factor in the cost of a subscription to an RBL provider, should you decide to use these services as a definitive source of information about known spammers.
Antigen’s Antispam Barriers
In Antigen 7.5, Sybari integrates antispam processing through a transport sink. Antigen has a good antivirus reputation in the Exchange market. An updated version that supports the Exchange 2003 SCL feature will be available in late 2003.
As with most antispam products, you can set various options in Sybari Spam Manager to suppress or identify spam as it arrives at the Exchange SMTP virtual server. The options are mailhost filtering (which lets you set up blackhole lists), content filtering (which lets you determine the type of content Antigen passes through to Exchange), file filtering (which lets you determine permitted file types), and keyword filtering (which lets you set up lists of words that Antigen looks for as it examines new messages). As Figure 2 shows, Antigen provides prepopulated lists of keywords that cover profanity, racial discrimination, sexual discrimination, and common spam words, such as "viagra." You can add words to these lists, but the prepopulated lists are fairly comprehensive and will stop most spam.
After you set up your keyword lists, you then decide how you want Antigen to treat spam. You can have Antigen drop messages immediately after it detects them as spam—an effective way of suppressing spam, but you run the risk that some messages that resemble spam might be important messages that you want to keep. The best practice is to first deploy the antispam product in "detect only" mode so that the product informs you about new spam and you can examine the notifications to determine the effectiveness of the filters. After you're happy that the filters are accurately detecting spam and ignoring other messages, you can start blocking (i.e., dropping) spam or moving messages into a quarantine directory. Figure 3 shows how Antigen informs administrators when it detects a spam message. You can configure Antigen so that it sends these notifications to as many administrators as you want.
Considering the amount of spam that can arrive at a server, you should be cautious about enabling notifications for administrators. Spam-generated messages can easily swamp a mailbox, particularly on servers that act as the initial line of defense. If you permit spam to pass through, you can configure Antigen so that it marks the spam with a SUSPECT prefix in the Subject line, as Figure 4 shows, before passing it through to Exchange’s routing engine.
Suppressing spam after it arrives at the client is a last-ditch effort. You've already incurred the cost of transporting, delivering, and storing the spam on its route to the client, and now the user gets to view the spam, if only to review the contents of the folder in which the client moves suspect messages. Of course, you can configure Outlook to delete any spam it detects, but again, you then run the risk of losing an important message mistakenly identified as spam. Ensure that the level of junk-mail protection you select, as Figure 5 shows, is appropriate for the traffic you receive.
Both Outlook 2003 and OWA 2003 feature client-side junk-mail filtering. Outlook 2003 supports connections to Exchange 2003, Exchange 2000, and Exchange 5.5 servers, but OWA 2003 is dependent on Exchange 2003. Outlook 2003’s Junk E-Mail filtering works only if you operate in cached Exchange mode. The logic is that Outlook must download the full content of messages before it can filter them. Attempting such downloads in a classic client-server connection would be far too expensive in network terms—you don't want to download giant attachments just to check their content. In an attempt to prevent spammers from gathering intelligence about their victims, both Outlook 2003 and OWA 2003 don't automatically download pictures in HTML-format messages unless you explicitly choose to view the pictures or establish new default settings for picture downloads.
In their messages, many spammers include pointers to small (1 × 1 pixel) graphics with the intention of forcing you to make a network connection to their site to download the image file. Because the file—called a Web beacon—is so small, you don’t experience any network delay during the download, and because the spammer typically hides the file, you don’t see it in the message. The spammer uses this tool to determine the effectiveness and destinations of its messages. Ideally, the spammer also wants to discover which email addresses on its lists are real and active so that they can sell these addresses to other spammers or include them on other lists they maintain. To do so, spammers can include instructions in the URL to pass information about you back to their server.
Figure 6 shows a captured Web beacon. In this example, I received a message that Outlook recognized as spam and filed into my Junk E-Mail folder. To see the HTML source and determine whether the message contained any Web beacons, I right-clicked the message content and selected View Source. As Figure 6 shows, the image references point to files on a remote server, and the circled file points to a small hidden file.
If you don't yet want to upgrade to Outlook 2003, you can still add antispam support to your client by installing products such as Cloudmark's SpamNet, iHateSpam, MailFrontier's Matador, and Mailshell's SpamCatcher. All these products support Outlook 2002 and Outlook 2000, and some offer versions to support Outlook Express clients—but those come with an additional cost to buy, deploy, and support. The actual per-client purchase cost is fairly low (between $20 and $30 per seat, subject to corporate discounts), but the total cost can mount up if you're deploying to thousands of seats. At this point, an upgrade to Outlook 2003 becomes more attractive, particularly when you factor in other Outlook 2003 features, such as cached-mode Exchange.
Although we've witnessed great progress in securing messaging servers and protecting them against viruses and spam, we shouldn't become complacent. Virus authors and spam generators are constantly searching for new methods to exploit email. For example, we haven't yet seen the first attack against Instant Messaging (IM) networks. Your job now encompasses the tasks of keeping a close eye on new developments and deploying software to defend servers, and those tasks are unlikely to go away anytime soon.