Securing E-Mail

Securing e-mail takes a concerted effort of many defenses, including blocking malicious file attachments, disabling HTML content, securely configuring the e-mail client, blocking unauthorized e-mail clients, authenticating HTML links, antivirus scanning, blocking spam, anti-phishing protections, enabling e-mail authentication and encryption protocols, and securing DNS. Although these defenses can be applied to any e-mail program, Outlook and Outlook Express will be used to demonstrate the various techniques in this section.

Block Malicious File Attachments

Currently, the single best thing an e-mail administrator can do to stop the current wave of e-mail malware is to block any file type that is highly likely to be used maliciously. For example, is there any valid reason for executable files or Control Panel applets to be sent via e-mail in most organizations, as shown in Figure 11-2? In most cases, no, so block them by default. The high-risk file types covered in Chapter 5 apply here as well.

Administrators may even want to consider allowing only one file extension in and denying all others. End users can be instructed that anyone sending them a file via e-mail must rename the file to some otherwise unknown extension. For example, if your company is called Banneret Computer Security, maybe the file extension can be .BCS. All users wishing to do legitimate business with the company can be told ahead of time what the only valid extension is. This will stop any other file attachment, most of which are malicious.

Unfortunately, many file attachment blocking mechanisms don't allow a deny-by-default rule. Instead, they only allow "block by file extension" rules to be set. If that is the case, follow the recommendations in Chapter 5 and block those file types by default, essentially creating a crude deny-by-default rule.

Where e-mail file attachments can be blocked depends on the environment. Common locations include the following (going from external to internal):

• E-mail value-added service provider

• Internet router/gateway

• E-mail relay servers

• E-mail antivirus devices

• E-mail servers

• Client software

There are many good questions to ask when deciding which device or software should be used to block file extensions, including the following:

• How are file types blocked — by file extension or some other more intelligent method?

• Can new extensions be added?

• Can a deny-by-default rule be configured?

• Can file attachment blocking rules be applied to some users and not to others?

• What mail protocols can be examined — SMTP only, IMAP, POP, RPC, HTTP?

• Are intended recipients notified of blocked e-mail?

Most file-blocking mechanisms block by simply examining the file extension. While this may work most of the time, it ultimately is very inaccurate. A better mechanism would be for the file's header to be examined (and maybe more of the file's content beyond that) to accurately determine the file's true type. Make sure any e-mail file attachment blocker can handle multiple file extensions on the same file (e.g., Readme.txt.shs) and MIME-type mismatches.

Is it possible for some users, but not others, to be affected by the file blocking rules? If users complain that they don't want any files blocked because it gets in the way of legitimate work, it may be possible to let users who understand the risks of file attachments have more freedom (sort of like giving an e-mail driver's license to those users that are not likely to execute malicious code). Meanwhile, users who cannot be trusted to make the appropriate decision can be assisted by the file attachment blocking mechanism.

Many file attachment blocking mechanisms only work on SMTP and POP3, and maybe FTP and HTTP. The IMAP e-mail server and client protocol is becoming more popular for managing users' mail. Remote Outlook to Exchange connections may use RPC or RPC over HTTP connections. Can the file blocking mechanism monitor and block files on those protocols as well? Figure 11-4 shows the file blocking functionality provided by an anti-spam appliance.

Figure 11-4

Microsoft Exchange and Outlook File Blocking

Microsoft Exchange server allows high-risk file attachments to be blocked by default. By default, Microsoft blocks the following file extensions: ade, adp, bas, bat, chm, cmd, com, cpl, crt, exe, hlp, hta, inf, ins, isp, js, jse, lnk, mda, mdb, mde, mdt, mdw, mdz, msc, msi, msp, mst, ops, pcd, pif, prf, reg, scf, scr, sct, shb, shs, url, vb, vbe, vbs, wsc, wsf, and wsh. These are known as Level 1 files. Any defined Level 2 files, for which there are no default entries, force the user to save the file attachment separately. The user cannot simply click the file attachment to launch. This seemingly simple step of forcing the end user to do a few additional mouse-clicks will prevent many e-mail attacks.

Both Level 1 and Level 2 file extension lists can be customized by the administrator or user (if allowed by the administrator). New file extensions can be added via the registry or in Exchange. In Exchange, an Offline template called Outlook Security must be downloaded from the Microsoft Exchange Resource Kit Tools, installed, and configured. Although it's a bit cumbersome at first, the template allows file blocking to be instituted on a per-organizational unit level and allows Level 1 and 2 file extensions to be easily modified. In order for Microsoft Exchange's method to work, the client must use Outlook and store messages in either an Exchange Mailbox (MDB), an Offline folder file (OST), or a Personal Folder (PST). Starting with Microsoft Exchange 2003, Outlook for Web Access (OWA) clients can also be managed.

Every version of Outlook and OE since 1998 has some version of file blocking, although Outlook 98 and 2000 required service packs to be applied. Outlook 2003 blocks the same Level 1 files as Microsoft Exchange does, plus adds the following: app, csh, fxp, ksh, prg, and xsl. Expect more and more file extensions to be added in each new Exchange and Outlook version. Outlook Express file attachment blocking functionality can be controlled using group policy administrative templates. Select User Configuration\Administrative Templates\Windows Components\Internet Explorer\Configure Outlook Express (see Figure 11-5).

Figure 11-5

Hopefully, one day Microsoft will add a deny-by-default and an allow-by-exception rule to e-mail file attachments. Also consider using the other file and registry blocking techniques covered in Chapters 5 and 6. NTFS permissions can be a strong defense against high-risk malicious files. Unfortunately, you cannot block every file extension that is high-risk in e-mail using NTFS when the file type is used frequently outside of e-mail. For example, you cannot use NTFS or registry permissions to prevent the execution of .EXE or .CPL files because those types are routinely used outside of e-mail. In these cases, you are better off blocking the file attachments sent in e-mail versus applying file and registry security permissions. Ultimately, e-mail administrators want to stop users from blindly running every e-mail attachment. Stop most file extension types by default and educate trusted users about how to receive any file type if this functionality is desired.

Disable HTML Content

As e-mail attacks move from malicious file attachments to embedded URL links, it is important to limit the ability of users and their systems to easily and automatically connect to Internet content via e-mail. Most e-mail clients support the parsing and displaying of Internet content, and disabling this functionality causes many legitimate e-mails to display very poorly. However, as discussed above, most of the e-mails on the Internet today are malicious. The percentage of rogue e-mails versus legitimate e-mails is even higher when considering just e-mails containing embedded links. And because e-mail worms often prey on patched and unpatched HTML vulnerabilities, links do not always require that the user click on the link to activate.

Administrators should disable the displaying of HTML content by default. HTML content can be disabled in Outlook 98 and later and in Outlook Express 4 and later. The latest Microsoft Outlook and Outlook Express clients can be configured to display all e-mails in plaintext by default (see Figure 11-6). In Outlook 2003, the user can simply right-click any HTML-enabled e-mail that has been converted to plaintext back to its HTML-enabled representation. The idea is to prevent the automatic displaying of HTML-content — another deny-by-default rule.

Figure 11-6

Outlook 2003 goes one better. Even when HTML content is enabled, it will prevent the downloading of remote graphic files off the Internet (see Figure 11-7). This effectively prevents spam web beacons from verifying the existence of an active e-mail address. Figure 11-8 shows the handful of settings Outlook 2003 has regarding its ability to download HTML content in e-mail. All of these options can be accessed by selecting Tools ð Options ð Security.

Figure 11-7

Figure 11-8

Configuring Outlook 2000 takes a registry edit. Under the key HKCU\Software\Microsoft\Office\10.0\Outlook\Options\Mail, create a new key: DWord: ReadAsPlain. Add ReadAsPlain as the value name and 1 as the value. In OE 6, choose Tools ð Options, and select Read all messages as plain text. Previous versions of Outlook and Outlook Express may be able to use the NoHTML add-on program (www.ntbugtraq.com/NoHTML.asp) that is widely available on Internet. It turns HTML e-mail into plaintext.

If the administrator doesn't mind more effort, they can create an e-mail security policy that doesn't force the user to choose between everything enabled or only plaintext content. Using Internet Explorer's security zones (covered in the last chapter), you can selectively allow or block different types of HTML content if plaintext e-mail is not possible. For instance, you can customize one of the default security zones (and select it under the e-mail Security dialog box) to disable scripting and ActiveX controls, while allowing the normal HTML formatting to come through. Many other e-mail programs allow this type of customization directly within the e-mail client.

Many e-mail administrators are concerned about the end user frustration they will create if they disable the displaying of HTML content by default. It's essential that administrators convince management and end users of the benefits of this tactic. The coming decade will be full of malicious attacks that launch using embedded URL links. Not only will users be protected from current threats, but many future threats as well. And displaying HTML-enabled e-mail is often as simple as one mouse-click or copying the link to an Internet browser. The cost/benefit measurement is easy to justify.

If the e-mail client used is HTML-based, this recommendation is considerably harder to implement. Still, attempt to configure any HTML-based e-mail client as securely as you can. Configure the browser involved to the minimum set of privileges that will allow the authorized HTML e-mail client to function correctly. Ensure that HTML e-mails are scanned for malicious code. If users are allowed to download files from their HTML e-mail, make sure the files are scanned before execution or launch.

Securely Configure E-Mail Client

It almost goes without saying that e-mail clients should be configured to be as secure as possible. They should not allow the execution of malicious file attachments or devious embedded URL links by default. Most e-mail clients can be configured with varying levels of security. Outlook 2003 and current versions of Outlook Express, like most current e-mail clients, come with relatively secure settings by default. Most content is opened in the Restricted sites Internet Explorer zone (previous versions opened content in the less secure Internet zone). This will prevent nearly any content besides pure HTML code from being launched. Figure 11-9 shows the zone settings. As Outlook will warn you, if you modify the zone settings associated with any zone shown in this Options window, it will modify the settings in Internet Explorer as well.

Figure 11-9

As suggested in the previous section, make sure the e-mail client converts all HTML-enabled e-mails into their plaintext counterparts by default. Outlook allows HTML content in e-mail by default. This option should be disabled under Tools ð Options ð Preferences ð E-mail Options (see Figure 11-10). Don't confuse this plaintext setting option with the formatting option controlling outgoing e-mail. The latter option isn't nearly as important as the former.

Figure 11-10

Turn Off Reading/AutoPreview Pane

Consider turning off the AutoPreview and Reading pane features (see Figure 11-11). By default, many e-mail clients, including Outlook, will display a portion of a message when the message summary is highlighted. This feature is supposed to allow users to quickly browse through all of their unread mail to determine what is and isn't a priority. Unfortunately, many e-mail clients will auto-execute HTML-content in the AutoPreview and Reading panes. In Outlook 2000, Outlook 2002, and Outlook Express 6, the AutoPreview and Reading panes are placed in the Restricted security zone, which should prevent scripts and active content from executing. Previous versions will execute any HTML content, including scripts, ActiveX controls, and plug-in content.

Figure 11-11

Consider Blocking Unauthorized E-Mail

Even if an administrator secures the official e-mail client, if end users use additional e-mail clients and services beyond the corporate authorized clients, it increases security risk. If Outlook is the primary e-mail client and Microsoft Exchange server is the primary e-mail server, then the SMTP protocol is not used between client and server. Instead, Outlook utilizes a randomly chosen RPC port and Exchange sends and receives client e-mail on it. If the Outlook/Exchange combination is the only officially supported e-mail client in an organization, then the client's PC should never use the SMTP protocol port, TCP port 25. Firewalls should only allow port 25 traffic to and from the authorized SMTP servers. If SMTP traffic is noticed on firewalls between workstations and the Internet, it is highly likely that an SMTP worm is active.

Similarly, if corporate e-mail users are allowed to use unauthorized HTML e-mail, P2P, or instant messaging services, the risk of a security exploit increases. If clients are allowed to continue to use unauthorized e-mail clients or e-mail, every effort should be made to either eliminate them or secure them.

Authenticating E-Mail Links

If HTML-enabled e-mail is allowed, the e-mail client or the related browser involved should be configured to prevent URL link spoofing. For instance, Internet Explorer 7 comes with several anti-spoofing mechanisms, but so, too, do many other browsers. Figure 11-1, at the beginning of this chapter, shows Outlook 2003/IE 7 revealing a spoofed link in a phishing e-mail. There are also browser add-ons that can be installed if your browser does not have special anti-spoofing mechanisms already included.

Antivirus Scanning

With tons of malware arriving via e-mail, an antivirus product that scans incoming e-mail is a must, and most antivirus clients directly support e-mail scanning. Antivirus products can be implemented at the following locations:

• Value-added e-mail service provider

• Internet router/gateway

• Authorized mail forwarding server

• Message content scanning server/appliance

• E-mail server

• E-mail client

Most corporations implement an antivirus scanning engine at centralized location (e.g., a gateway) and on the local client. This is a great cost/benefit decision. Scanning at the centralized location allows most of the e-mail malware to be caught prior to entering the local network or entering the client's PC. Scanning again on the local client will hopefully catch any malware arriving outside the normal e-mail service and provide addition protection from outgoing threats.

There are several different methods that antivirus vendors can use to scan your Exchange server:

• File-level

• MAPI-based scanners

• VAPI-, AVAPI-, VSAPI-based scanners

• ESE-based scanners

File-level scanners individually scan each physical file and aren't aware of Exchange-specific structures. These types of scanners can be very slow and problematic, and lock up Exchange server and its log files. If you must use a file-level scanner on your Exchange server, it should not scan the following folders and files:

• \Exchsrvr\MDBDATA, \SRS (all versions)

• \DSAData (only in Exchange 5.5)

• File extensions .edb, stm., and .log on an Exchange server

File-level scanners do not provide help with outgoing e-mail worms with their own SMTP engines and will not protect end-user workstations from e-mail worm attacks initiated from other vectors (macro viruses, embedded links, etc.).

Mail Application Programming Interface (MAPI)-based antivirus scanners were the first generation of scanning methods built for Exchange. They use the MAPI interface to log in to mailboxes and scan individual messages, not files. MAPI and newer Exchange-based scanners can usually scan messages whether they are using SMTP, POP, IMAP, or OWA. Unfortunately, MAPI-based scanners suffered a few problems. Under heavy workloads, they cannot guarantee that all messages are scanned before the user opens them. MAPI-based scanners cannot scan outbound messages, and under heavy workloads are extremely slow.

Microsoft remedied the problems of MAPI-based scanners by creating APIs just for Exchange-based antivirus scanners. Virus API (VAPI), Antivirus API (AVAPI), and Virus Scan (VSAPI) were created for a new generation of mail scanners. VAPI 1.0 was released in Exchange 5.5 SP3. While these types of scanners could scan Exchange servers without causing corruption or performance problems, file attachments were only scanned on access, and they could not tell you what viruses were removed. VAPI 2.0 released in Exchange 2000. It was not backwardly compatible but allowed proactive message scanning, with virus removal details and counters. VAPI 2.5 was released for Exchange 2000. It contained new features, bug fixes, and performance enhancements.

ESE (Extensible Storage Engine)—based scanners, such as Sybari's Antigen, turned out to be very fast and reliable. For years Microsoft refused to officially support ESE-based scanners, although they gave an unofficial tacit approval. Microsoft must have eventually really liked Sybari's approach, because in 2005 they purchased Sybari Antigen and will use it in their own upcoming anti-malware products.

Just remember that although server-based scanning methods work well, there are still ways e-mail-based malware can circumvent server-only scanners. The most obvious way is that it often takes antivirus vendors up to a complete day to include new detection signatures when a new malware outbreak is released. If an e-mail client bypasses Exchange server (picking up external POP, IMAP, and HTML-based e-mail), then e-mail malware could still end up in the Outlook/OE client and be executed. And malware can still end up transmitted to clients using any other method (P2P, IM, etc.). For these reasons, a client-side scanner should also be implemented.

Block Spam

Anti-spam solutions are based on a set of common technologies but are implemented in different ways and at different points in the spam trail. This section will cover the various methods used to identify and stop spam and then describe the most appropriate place to locate an anti-spam device or service. The various technologies used to catch spam are as follows:

• Address lookups

• Challenge-response

• Rate controls

• Real-time blacklists (RBLs) and whitelists

• Message analysis

• Human analysis

Address Lookups

One of the most common anti-spam methods is to read the incoming e-mail message's header, pull out origin information, and then use one of many types of address lookups to prevent message origination spoofing. Address lookup methods include the following:

• DNS lookups

• Reverse DNS lookups

• HELO lookups

• Sender confirmation

• Sender domain verification

A very simplified address lookup decision tree looks similar to this:

1. The e-mail says it came from this address.

2. Is the address valid?

3. If not, reject the e-mail.

A receiving e-mail server, officially called a Mail Transfer Agent, or MTA, can use a DNS lookup query to resolve the mail server identified in the incoming message's origination field to the IP address currently sending the message. Conversely, an anti-spam mechanism can first record the incoming IP address and compare it to the DNS name of the sending e-mail server identified in the message.

The HELO lookup method relies on the fact that incoming SMTP servers send a HELO command to initiate a send mail connection with another e-mail server and put their e-mail server name in the HELO command. The receiving MTA can use a DNS lookup to verify the e-mail server stated in the HELO connection. Sender confirmation happens when an MTA can verify that the sender's domain exists or that the sender's e-mail address is a valid e-mail address with the other server.

Unfortunately, these early types of address lookups suffered from their own simplicity. For instance, if the spammer simply uses valid domain or e-mail addresses, then the address lookups will return a high rate of false-negatives. This is further compounded by the problem that many legitimate MTAs do not have valid or accurate DNS lookup records, creating an offsetting high rate of false-positives. Lastly, spammers can subscribe to a "No-IP" service that will register a temporary domain address with the spammer's temporarily assigned IP address. These first-generation address lookup techniques have led to the latest anti-spoofing experiments and emerging standards.

Sender ID and Other Identity Authentication Schemes

There are several competing anti-spam proposals that attempt to defeat spam using spoofed origination domains by confirming the validity of either the incoming e-mail's SMTP reverse-path (i.e., where the e-mail claims it's from on an SMTP protocol level) or from the domain indicated in the sender's MAIL FROM field. When implemented, the receiving SMTP server can query the sender's DNS server to determine whether the sender's origination address is from the domain it says it is from and whether the message arrived from an e-mail server authorized to send e-mail in the originating domain.

At least four different proposals are trying to become the one and only standard. One of the first serious attempts was the Sender Policy Framework (SPF). SPF-aware servers read an incoming message's origination IP address and compare it to e-mail servers authorized to transmit e-mail for the origination domain. The idea is that if the spammer spoofed the domain, the registered SPF records on the origination domain's DNS server will not match the detected IP addresses. And if a client on a valid origination domain becomes infected with a worm that has its own SMTP engine, the client will not be authorized to send e-mail from the originating domain.

SPF-aware domains must identify valid MTA agents by adding SPF-specific records to their DNS servers and using SPF-aware server software. SPF uses the SMTP reverse-path (also known as return-path) on the message's SMTP connection, and cannot prevent a forgery in the MAIL FROM field. SPF, and other standards based on it, isn't really capable of stopping spam per se on their own, but its widespread use will prevent spammers from sending messages with spoofed domains. This means it will be easier to detect, track, and block spammers.

Microsoft proposed its own solution, based on SPF, now called Sender ID Framework (SIDF). Although Microsoft hopes its standard will become widely accepted, and the license to use it is free, because it is a patented, proprietary protocol, several entities refuse to accept the standard. Many groups hope that whatever standard is developed and widely used is open source or public domain. Sender Policy Framework (SPF), DomainKeys (invented by a Yahoo! employee), Cisco's Identified Internet Mail, and the Trusted E-mail Open Standard (proposed by the ePrivacy Group) are competing alternatives.

The DomainKeys and Identified Internet Mail standards have merged into one solution called the DomainKeys Identified Mail (DKIM) specification, which hopes to become an IETF standard. This specification also protects the entire e-mail's authentication from sender to receiver. SIDF and SPF can only prevent domain spoofing, but cannot guarantee the validity of the message or even the sender's name. DKIM uses asymmetric cryptographic keys to create a digital signature on each message.

In August 2004, dozens of large vendors (e.g., Microsoft, Cisco, eBay, Earthlink, Symantec, Postini, etc.) asked the FCC to approve both standards. They want the IP-based, anti-domain-spoofing solutions to be recommended first, followed by the more difficult, and still emerging, digital signature standards. As of this writing, the FCC has not made an official recommendation. Microsoft and many others are supporting the Sender ID solution. Yahoo is supporting the DKIM solution, and many other entities have proposed their support for the pre-Microsoft SPF solution (now called SPF Classic).

A spam bot that infects a PC to generate spam and utilizes the PC's e-mail client to send the spam will not be detected by any of the proposed solutions, although a password-protected digital signature tool will probably make it harder. Indeed, these solutions were created only to address the problem of spammers using spoofed e-mail addresses and domains. Some experts claim that these emerging standards will cure nothing. There is some evidence of this, as most of the early adopters have been spammers. Spammers are rushing to change their spam to meet the new validation requirements of the solutions. The spammers are using dynamically created domains and registering their own SPF records. In essence, they are using the anti-spam tool to generate more spam.

Rate Controls

When spammers do something, they do it big. They don't send 50 messages, they send 5 million. They don't send a single message to 50 people; they send 5 messages to 50 million. By limiting the rate at which something in an SMTP e-mail can occur, it is hoped that many spammer attempts will be rejected. Here are some common rate controls:

• Connections per client

• E-mails per client

• Number of recipients per e-mail

• Distribution analysis

• Connections per client

• E-mails per client

• Number of recipients per e-mail

The first three rate controls are usually set on MTAs, something like Reject any message with more than 100 recipients. Rate controls have a high false-positive rate, but they can be fine-tuned and legitimate sources needing higher rates can be whitelisted.

Distribution Analysis

Distribution analysis is the process of watching one location send out thousands to millions of e-mails around the world to many different domains. Normally this can only be done on an anti-spam service value-added network that is able to review thousands to millions of e-mails very quickly. Because they get millions of e-mails a day for thousands of domains, they can see one sender sending out thousands of e-mails at once, and block all e-mails from the sender before they ever get to the recipient. Overall, distribution analysis has a pretty good false-positive and false-negative rate, but occasionally false-positives will result from legitimate broadcast e-mails from legitimate services (i.e., alumni newsletters, yahoo news flash bulletins, etc.). Vendors learn to whitelist those domains.

Real-Time Blacklists (RBLs)

Many third-party databases keep track of reported and known spamming domains, services, and (innocent) vulnerable open relays. RBLs are also known as real-time blackholes or DNS black lists. An MTA can link to RBLs, download the most current list, and then reject e-mails from entities on the list. There are several types of RBLs:

• Relay Spam Servers (RSSs) — A list of open mail relay servers.

• Dial-up List (DUL) — A list of dynamically assigned IP addresses from which an MTA can reject direct SMTP connections. Dynamic IP addresses are usually given to home-based client computers, which should be sending all their e-mail to their local ISP's SMTP servers. Hence, if e-mail is being sent directly from a home-based computer, it is probably from a spam bot.

• Exploits Block List (XBL) — A list of IP addresses with exploited computers (open proxies, spam worms, etc.) that are sending spam.

• Personal Black and White Lists — Most anti-spam products allow users to add their own blacklists and whitelists.

There are a handful of popular RBLs, including the following:

• www.spamhaus.org

• www.mail-abuse.org

• www.ordb.org

But there are hundreds of RBLs. For a larger list of RBLs, see www.dnsbl.info. Most anti-spam services and devices allow administrators to pick and choose between one or more RBL lists and to add their own personal lists (see Figure 11-12).

Figure 11-12

RBLs are not without their problems. Some have been shut down by heavy DDoS attacks by spam worms, after which their owners decided to take down the site (which they had been posting for free), rather than spend more of their money to fight the attack. But the biggest RBL problem is that of true positives. Innocent companies with an open relay can be placed on an RBL with one confirmed report. Being added to an RBL list can take 1–3 seconds, and being added on one list guarantees placement on dozens more automatically. Rarely is the infringing victim company ever directly notified by the RBL site of its placement on the RBL list. Normally the first indication that a company has that it has been placed on the RBL list is an e-mail being kicked back from a business partner days after being placed on the RBL. Once alerted to the open proxy, it only takes 15 minutes to fix, but it takes days to get off all the RBL lists so that a company can send and receive e-mail normally again.

Message Analysis

Up until now, most anti-spam methods have been directed at IP- and domain-level defenses. Anti-spam mechanisms also analyze message traits to determine whether a message is spamlike or not. Message analysis includes the following:

• Header analysis

• Keyword analysis

• URL analysis

• Image analysis

• Filtering

• Bayesian filtering/learning

• Fingerprinting

• Human-filtered lists

• Message analysis

Header Analysis

It's essential that anti-spam technology analyze message headers. This is where spammers often reveal their tricks. It is often used in combination with name address lookups. Header information that disagrees with displayed content will reveal spam.

Keyword Analysis

Keyword analysis looks for simple word searches, such as *porno* or "weight loss" appearing in the same e-mail with other popular spam tricks, such as "Click here" links. It is not very accurate when done simply but becomes more accurate as patterns become unique to spammers.

URL Analysis

Spammer URLs often point to one-time or temporary web sites. Anti-spam services can compare these against a database (sort of a URL RBL) of known spammer web site URLs.

Image Analysis

Intelligent engines typically look for porno image characteristics such as too much skin color in the entire image, and shape recognition technology, along with key words in the image. It may scan pictures looking for words with OCR technology or look for web beacons. Spammers are now sending text messages as image files in order to defeat keyword filters, so image analysis is becoming more and more important.

Filtering

Filtering is a more complex set of searches than simple keyword searches. For example, if an e-mail contains x, y, and z, and has links in it, then it is spam. Filters must be hard-coded and defined before they can recognize spam. They can be updated for fine-tuning to become more accurate, but Bayesian filtering is better.

Bayesian Filtering

Bayesian filters look at the entire message, looking for predefined keywords, like a filter, but they rank keywords and techniques known to be used often by spammers and infrequently by legitimate users and sites. With regular filtering, every distinguishing feature marked as potentially spamlike has an equal rating. Bayesian filtering recognizes that the phrase "Buy Viagra" should have a higher ranking than the word "teen." Both are frequently used in spam, but the former is almost always spam and the latter is often used legitimately. Words like "frog" and "Einstein" will never rank as high as "Nigeria," "viagra," and "stimulant." And e-mails with the word "teen," an FF0000 HTML tag (for bright red), and containing web beacons should be very highly weighted as spam.

When a Bayesian filter analyzes a message, the findings are ranked statistically and assigned a value, usually between 1 and 10. A 1 would be a message that is almost certainly not spam and a value of 10 would indicate something almost certainly spam. Bayesian filters can be adjusted to be more accurate: to error on the side of false-negatives (see Figure 11-13). In this instance, as with several other anti-spam services and devices, the administrator can choose the values that will determine whether the message is marked as spam and detected, suspected as spam and quarantined, or passed as legitimate.

Figure 11-13

Bayesian filtering can "learn" what is and isn't spam when the administrator marks it as such. It finetunes the filter for each environment and can be used to re-fine-tune at any time. Bayesian filters must be trained over hundreds of spam and legitimate messages, and include message header evaluation. If an anti-spam filter can't learn, it isn't Bayesian, it's just plain filtering. Bayesian filtering can be very accurate — over 99.5% accurate, with 0.03% false positives.

Spammers fight Bayesian filtering by intentionally misspelling words, such as viiagra, v1gra, viaggra. Bayesian filtering fights back by installing the misspelled words into its filter lists. Spammers are using HTML tricks (e.g., columns, etc.) to bypass Bayesian filters — it's a war of sorts. But as filtering becomes better and spammers are forced to misspell their ads more and more, they become less effective.

Fingerprinting

Fingerprinting occurs when an anti-spam vendor captures a spam message and runs a CRC checksum against the included contents. New incoming messages can be compared against the stored CRC checksum, and if the results are the same, then a spam match has been identified. It's a nice adjunct technique that some anti-spam vendors add to their products to stop very popular spams with static content. Unfortunately, with so much spam generated on a daily basis, and each spam message made to appear unique, fingerprinting isn't overly reliable.

Human Analysis

Sometimes no matter how great the tool is, you can't beat a human for recognizing spam. Many solutions augment their technologies with a human team that delineates the hard-to-decide spam. The human decisions are passed along to the products as additional blacklists entries, keyword blocking, message analysis, and Bayesian filtering. Services and devices using human analysis are very accurate, of course, but slower than automated techniques.

Table 11-1 summarizes the benefits and disadvantages of the different anti-spam technologies.

Table 11-1

Anti-Spam Technology	Accuracy	False-Positives	False-Negatives	Comments
Address Lookups	Moderate	High	Moderate	Many legitimate companies are not configured right.
Challenge Response	High	High	None	Cumbersome
Rate Controls	Moderate	Low	Low, but Some
Real-Time Blacklists	High	Low to Moderate	Low, but Some	Can cause more harm than good
Message Analysis	High	Low	Very Low	Bayesian filtering is the way to go
Fingerprinting	Low	High	Very High	Not a reliable option when used alone
Human Analysis	High	Low	Very Low	Slow, but adds to overall accuracy

Anti-Spam Device Location

The anti-spam device's location often has a big impact on its efficiency. Listed below are the most common locations for anti-spam devices and software:

• Hosted services

• Gateway

• Server

• Client

Hosted Services

Value-added e-mail providers are an excellent option to stop spam. Another company's MTA intercepts e-mail intended for your company (and maybe from your company) and filters out the spam. You have to point your DNS MX record to the vendor, but this option tends to be among the most accurate solutions in the field. They usually have all the anti-spam technologies running at once. These types of services are usually priced on an annual subscription per-seat basis, with costs running between $15 and $70 per seat/year. The benefits are as follows:

• "Lease it and forget it"!

• High accuracy

• The problem is stopped before volume hits your network.

• High customer satisfaction rate

• They usually offer multiple services, such as anti-porn and antivirus as either a default service or an add-on.

• Not server- or client-specific

• Can be managed anywhere you can get to a web browser

• Updated frequently

Disadvantages include the following:

• You're not truly managing your own e-mail (i.e., they can read it).

• It doesn't work with encryption.

• Tech support is a phone call away (in another country).

• They tend to be less customizable than other solutions.

• You may have problems sending out normal levels of bulk e-mail to clients and not having it marked as spam.

• Some services try to stop outgoing bulk e-mail as a default and it takes special arrangements to get legitimate customer e-mail through without a rate control blocking the e-mail.

The two most popular vendors in this category are Postini and MessageLabs. Both are great choices. Other enterprise class services include FrontBridge Technologies and Mi8. Smaller vendors include AlienCamel, ChooseYourMail, CleanMessage, and Spam Interceptor.

Gateway

The anti-spam solution can be placed on an Internet gateway chokepoint and can be either software or hardware. Software can be placed on another network perimeter device (i.e., firewall, e-mail antivirus server, etc.) or on a dedicated server. Hardware appliances are typically the client's software running on a Linux box.

Gateway Appliances

Gateway appliances are usually placed in front of your MTA. They offer the following benefits:

• Tend to be very accurate.

• Tend to be very fast.

• Not all are e-mail server or client-specific.

• You control your e-mail.

Disadvantages include the following:

• Requires that MX and/or reverse DNS records be changed to the intercepting gateway

• Spam volume is still making it to your network.

• Technical support can be spotty.

• Documentation can be weak.

Anti-spam appliance leaders include Barracuda Networks' Spam Firewall, MailFrontier, and Tumbleweed E-mail Firewall. Other appliance vendors include McAfee SpamKiller, Mirapoint Message Director, Dymeta Trimail Inbox, and Concentrico Keep/S. Prices start at about $1,200.

Gateway Software

Gateway anti-spam software can be installed on an already existing network perimeter device or on a dedicated server. If installed on an existing network device, the software must be compatible with the network device. Benefits include the following:

• Dedicated server products are usually e-mail server independent.

• Usually feature-rich and highly customizable

• Usually have other e-mail security features built in

• You control your e-mail (no privacy issues).

• Many choices (or is that a disadvantage?)

Disadvantages include:

• It isn't as accurate as the preceding solutions.

• Spam volume is still hitting the network (but not the server).

• May be a Unix-only product.

Popular vendors include Aladdin's eSafe, Symantec's Antivirus for SMTP Gateways, Sunbelt's iHateSpam, Spamassassin (open-source Unix), Brightmail Anti-Spam, and Trendmicro Spam Prevention Solution.

Server Software

Anti-spam server software is installed directly on the e-mail server. Benefits include the following:

• Can be highly integrated with Microsoft Exchange/Outlook

• Often from very familiar vendors

• Easy install

• Larger vendors offer stronger, consistent support

Disadvantages include:

• Spam volume is hitting the server.

• Not as accurate as previous solutions

• If the anti-spam feature isn't the main feature (i.e., product was originally antivirus only), the anti-spam feature set can be lacking.

• Anti-spam technology isn't updated as often.

Client-based Solutions

Client-based anti-spam solutions are installed on each end-user machine. Benefits include:

• Can be highly integrated with Outlook and several popular e-mail clients

• Can easily be managed by end users individually

• Often integrated with antivirus and anti-pop-up ads

Disadvantages include:

• Spam volume is hitting the network, server, and client.

• Lowest accuracy rating of all anti-spam tools in both false-negatives and false-positives

• A lots of terrible tools, even spam generators that pose as client products. Evaluate from new vendors at your own risk!!

• Harder to centrally manage

Popular vendors include Microsoft Outlook 2003 (some anti-spam features), Norton AntiSpam 2004, Clearswift MIMEsweeper, SpamCatcher, Cloudmark SpamNet, Sunbelt's iHateSpam, and McAfee Spam Killer.

Table 11-2 summarizes the benefits and disadvantages of each solution location.

Table 11-2

Anti-Spam Technology	Accuracy	Features/Customization	Comments
Host Services	Best	Moderate	A great choice if you can afford it and don't mind sending e-mail elsewhere
Gateway-Appliance	High	Moderate to High	Fast performance, low cost
Gateway-Software	Moderate to High	High	Feature rich, best reports
Server-based	Moderate	High	Often already bundled along with AV software
Client Side	Low	Moderate	Poor accuracy makes it hard to recommend

Administrators should pick an accurate anti-spam solution that works for their environment. If your solution is not 99% effective or better, get another solution.

Authenticate It

There are several ways to authenticate and encrypt e-mail. The most popular solutions are as follows:

• S/MIME

• PKI

• Digital IDs

• PGP

There are several new anti-spam initiatives, which authenticate the e-mail's originating domain or mail server, including Sender ID (http://searchexchange.techtarget.com/sDefinition/0,290660,sid43_gci1005711,00.html). Most of these early-generation solutions do not authenticate or encrypt e-mail back to the sender, which may prevent some types of phishing, but won't do much to stop spam using legitimate origination locations. Your environment should begin to implement an e-mail standard that will encrypt and authenticate critical e-mails.

Secure DNS

Pharming attacks rely on exploiting vulnerable DNS servers. Often the servers do not even have to be your own servers. In most environments, the company's internal DNS servers forward to an ISP's external DNS servers. Since you have no control over your ISP's DNS security, consider pointing your internal DNS servers to the root Internet DNS server for forward lookups. This will prevent DNS poisoning attacks on upstream DNS servers from poisoning your internal DNS servers. Also, use an updated DNS server. The latest BIND DNS services are immune to most DNS poisoning attacks, as well as any Microsoft DNS service after Windows 2000 SP2. Lastly, make sure your domain's name is secured with the registrar to prevent domain hijacking.

End-User Training

As covered in the introduction of this book, I do not put my trust in end-user education. If all end users could be educated, they would no longer be clicking on malicious e-mail attachments, clicking on devious URLs, or falling prey to phishing attacks. Still, end-user education does have value if you can teach them the risks of unauthenticated e-mail and about all the slimeballs out there trying to steal their money and infect their machines.