Spammers use many techniques to flood your Exchange server with unwanted garbage. One technique that can be especially problematic for the recipient is a directory harvest attack (DHA). In these attacks, spammers send messages to mailboxes that may or may not exist in order to discover legitimate addresses. There are techniques you can use to protect your Exchange organization against these attacks, but first you need to understand how DHAs work.
Anatomy of a DHA
The basic idea behind a DHA is that there are many common names. If your company has many employees, chances are you have employees named John, Bob, Mary, and so forth. Spammers have therefore compiled long lists of common names. A mail-generating program attaches each name on the list to a known domain name. For example, if a spammer were targeting the contoso.com domain and had the names John, Bob, and Mary on a list, spam messages would be sent to [email protected], [email protected], and [email protected].
Keep in mind that there might not be a John, Bob, or Mary working at Contoso. The spammer sends messages to these addresses anyway, using common names in an effort to figure out which email addresses are valid. In addition to names, the spammer will also use words that are often found in email addresses; for example, the spammer might try [email protected], [email protected], or [email protected].
When spammers launch DHAs, they know that most of the addresses they're trying will be invalid. However, they also know that if they try enough names, some messages will go through. Spammers often have thousands of names on their lists.
In the example of spam being sent to John, Bob, and Mary, I showed you how the name from the list could be attached to a target domain name. In the real world, companies rarely use an employee's first name as the sole basis for an email address. More often, email addresses are made up of a combination of the employee's first and last name. Spammers know this, so they send messages to many different combinations of the names on their lists. For example, if a spammer wanted to target the name John Smith, some possible combinations might include JSMITH, John.Smith, or JohnS.
If the spammer's list contains thousands of names, you can imagine how many messages have been sent by the time the spammer has attempted every possible combination of names. Typically, first and last names would be separate lists, greatly increasing the overall number of combinations to try. A DHA sometimes produces the same symptoms as a Denial of Service (DoS) attack. The spammer might flood the recipient's email server with so many messages that legitimate messages can't get through.
Of course, this technique has many variations. Some spammers don't worry about using lists of names but instead perform a brute-force attack in which they try every possible combination of numbers and letters within a predetermined length of username in conjunction with a known domain name. This technique is extremely resource- and time-consuming for the spammer because of its brute-force nature. Some spammers prefer to use a less thorough, less time-consuming method.
Other spammers use spam databases to find a few known addresses associated with the domain, so that they can determine the email-address format that a company uses. If spammers know the address format, they can launch a much more efficient DHA. But because millions of domains exist, spammers are spending less and less time fine-tuning attacks against individual domains, preferring instead to send out millions of messages to a variety of address formats to find a few valid ones.
Sending messages to countless email addresses is only half the battle. Remember that the purpose of the DHA is to determine which email addresses are valid so that more spam can be sent to those addresses. Spammers can find valid email addresses in two different ways.
The most common technique that spammers use to find valid addresses is to look at the nondelivery reports (NDRs) that are generated. As you probably know, most mail servers are configured so that when a message is sent to a nonexistent email address, an NDR is returned to the sender. Spammers cross-reference NDRs against the list of email addresses that they sent messages to. Any address for which an NDR was returned is considered to be invalid and is therefore removed from the list.
Originally, spammers treated the absence of an NDR as confirmation that an address was valid. Today, however, spammers can't be completely certain that an email address is valid just because they didn't get an NDR. If a spammer floods a domain with directory-harvest messages and no NDRs are returned, the spammer knows that the company has disabled NDRs.
Spammers can still figure out legitimate email addresses, although not as many as they could if NDRs were enabled. To do so, spammers look for clues such as out-of-office messages. Spammers might also include a request for delivery receipts within directory-harvest messages.
Because of the way DHAs work, it's possible that even new email addresses that haven't been used could start receiving spam within hours of creation. Fortunately, there are several ways that you can fight this type of attack. The techniques I describe are intended for Exchange Server 2003, but most should also work with Exchange 2000 Server.
Disabling Delivery Receipts
One method to combat DHAs is to disable delivery receipts for the Exchange organization. The primary advantage of disabling delivery receipts is that doing so makes DHAs much less effective. Disabling delivery receipts might also save you bandwidth and other system resources. Think about it for a minute. If your mail server has to generate a delivery receipt for every message that a spammer sends, you could be wasting a lot of system resources. A single delivery receipt consumes a negligible amount of bandwidth, CPU time, memory, and other resources; cumulatively, however, generating large numbers of delivery receipts can have an impact on available system resources. The downside to this technique is that if a legitimate user asks for a delivery receipt and you've disabled delivery receipts, the user will think that his or her message wasn't delivered.
Disabling NDRs
Just as the process of generating and sending large numbers of delivery receipts can affect available system resources, so too can generating NDRs. A DHA sends messages to thousands (if not millions) of nonexistent mailboxes. The impact of these messages on your bandwidth and other system resources is bad enough, but the effect is compounded when your server replies to each invalid message with an NDR.
In some organizations, the thought of recovering bandwidth and system resources that were previously used in producing NDRs might be appealing enough to justify disabling them. But before you do, there are a couple of negative aspects that you need to consider.
One problem involves people who send legitimate email messages to your organization. If a client enters an email address incorrectly, the message won't reach its recipient. Without an NDR, senders never know that their message wasn't delivered and might think they're being ignored.
Another problem with disabling NDRs as a countermeasure to DHAs is that the technique can backfire on you. Remember how a DHA works: In the attack's simplest form, the list of names is compared with the list of NDRs to determine which email addresses are valid. Some of the less-sophisticated spam generators automatically assume that an email address is good if no NDR is returned for it. Once spammers have a valid address, they send a lot more spam to it.
Sending False NDRs
Some antispam applications can actually produce false NDRs, which can be used to defend an organization against an onslaught of spam. The antispam application contains all the typical filters (e.g., keyword, blacklist, Bayesian). When one of the filters detects a spam message, the antispam application returns a phony NDR to the spammer. The idea is to make the spammer think that the address is no longer valid and stop sending spam to it.
Sending false NDRs consumes a lot of resources. Also, because the messages used in DHAs are usually either empty or contain only one word, some antispam applications have trouble identifying these messages as spam. Besides, unless a message contains a valid email address for the sender, a reply is futile.
Atypical Address Formats
Another way to counter DHAs is to use atypical email address formats. For example, I've seen companies that include the year an employee was born as part of the employee's email address: If John Smith was born in 1973, he might be assigned an email address such as [email protected].
The logic behind this technique is that if spammers are using lists of names to launch attacks, no combination from the lists will produce a valid email address. However, email addresses that include numbers tend to be more difficult to remember, which can make it tough for legitimate senders to communicate with employees at your company unless they have the recipient's email address stored in an address book. Also, this technique works against only those spammers who use list-based attacks; a brute-force attack will yield valid email addresses regardless of their format.
Recipient Filtering
One last technique I'll discuss is recipient filtering. Recipient filtering takes place during the early phases of the SMTP conversation, which means that a message can be rejected before the message body is sent to the server. The benefit is that you conserve resources because the server isn't downloading the message body for rejected messages.
The problem with recipient filtering, though, is that when used by itself it can actually make a DHA more efficient and more successful. Remember that the key to a successful DHA is that the spammer must be able to match NDRs to the messages that were sent out. It takes time for an Exchange server to process a message, then generate and transmit an NDR.
Because recipient filtering works at the SMTP level, the entire process of receiving a message and generating an NDR is eliminated. The server simply won't accept a message for which the recipient doesn't exist. The spammer receives an SMTP-level message indicating that the message was rejected and therefore finds out much more quickly whether or not an email address is invalid. Fortunately, there is a countermeasure known as tar pitting, which involves throttling the bounce messages in a way that makes them impractical for a spammer to use. I discuss this technique in more detail in the next section.
As if helping spammers be more efficient weren't enough, using recipient filtering encourages spammers to use domain-name spoofing. If the spammer depends on receiving NDRs, in most cases the spammer will have to use a legitimate domain name so that the NDR can find its way back to the spammer. With recipient filtering, though, the rejection process occurs at the SMTP level. Spammers can hide behind a spoofed domain name and still get the information they need.
Tar Pitting
Because recipient filtering works at the SMTP level, Windows, not Exchange Server, actually directs the process of accepting or rejecting messages. Tar pitting is a technique that Microsoft included with the release of Windows Server 2003 Service Pack 1 (SP1). Tar pitting can slow down recipient filtering to the point that DHAs become impractical. Keep in mind that the spammer has thousands of email addresses to test against your mail server, which takes a lot of time. Imagine how much longer this process would take if you could insert a 10-second delay into the approval process for each message. That's exactly what tar pitting does: It lets you insert a delay before responding to invalid email addresses.
Before I explain how to enable tar pitting, I need to warn you about two things. First, by enabling tar pitting, you might end up slowing down legitimate email. It's therefore important to monitor your server's response time after tar pitting is enabled. Second, enabling tar pitting requires editing the registry, which can be dangerous. Making an incorrect modification can damage Windows and your applications. I therefore recommend creating a full system backup before continuing.
To enable tar pitting, open the registry editor (regedit.exe) and navigate to the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\SMTPSVC\Parameters subkey. Next, right-click the Parameters container and select New, DWORD Value from the shortcut menu. Enter TarpitTime as the name for the new registry entry. Double-click the entry you just created and set the value data to the number of seconds you want the SMTP address-verification process to be delayed. Five to 10 seconds is usually sufficient. Now just click OK, close the registry editor, and restart the SMTP service.
Fight Spammers
As you can see, DHAs can be an especially problematic spamming technique. But now you know several ways to mitigate the effects of such attacks. In order to reduce the effectiveness and impact of DHAs, I recommend taking advantage of recipient filtering and tar pitting. Using blacklist filters is also a good idea because they can deny a connection outright. Disabling delivery receipts and NDRs might also be effective countermeasures, but you need to consider the effect of such actions before doing so.
