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 john@contoso.com, bob@contoso.com, and mary@contoso.com.
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 sales@contoso.com, service@contoso.com, or info@contoso.com.
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 jsmith73@contoso.com.
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.