[Dshield] Protection against spammer dictionary attacks

Jon R. Kibler Jon.Kibler at aset.com
Sun Oct 5 19:16:02 GMT 2003

We have seen a big jump in the number of dictionary attacks against our mail system in the past few days. I don't know if it is just the domains we manage, or whether it is more widespread. However, I thought I would pass on a schema that we use to limit the impact of such attacks. These options are specific to sendmail, but most MTAs have similar configuration options.

These attacks typically try to send to 10 to 50 recipients per envelope. Our strategy is two-fold:
   1) Slow down the rate at which the spammer can attempt to harvest addresses.
   2) Clog up the spammer's queue and/or confuse their address harvester program.

The sendmail options we use to accomplish this are:
> define(`confBAD_RCPT_THROTTLE',`2')dnl
> define(`confMAX_RCPTS_PER_MESSAGE',`5')dnl

The first option says that after 2 bad recipients in a given envelope, sendmail will wait 1 second after each 'RCPT To:' before responding. Thus, instead of being able to slam 50 or so probes into our mail system in less than a second, it would drag out such probes for almost a minute. This both reduces the load on our MTA and slows down how fast the spammer can collect email addresses (probably by about 2 orders of magnitude!).

The second option limits the number of recipients per envelope. After 5 recipients are received per envelope, the rest are temp failed. (Note: This does not limit the number of "To: recipient"s, etc., it only limits the number of recipients your mail server will process in a single attempt to send a message.) For legitimate senders, this has minimal impact: if a sender tries to send to more than 5 recipients on your mail system at one time, the first 5 receive the message immediately, and the other experience a slight delay while the message is requeued. However, for spammers, this option causes one of three things to occur on their address harvester:
   1) All the temp failed addresses are queued for later retry (which really slows down the spammer). Whereas this will cause some additional load on your MTA should the spammer's software actually retry these addresses, we find that retries seldom occur in reality.
   2) The spammer uses a 'dumb' address harvester that treats the temp fail as a permanent error, and the addresses that are temp failed are judged to be bogus addresses.
   3) The spammer uses an even dumber address harvester that cannot handle temp fails, and their harvester dies.

Of course, it is needless to say, no one should ever use a common name for an email address (like joe at ...) -- unless, of course, the address is intended as spam bait.

Anyway, just some thoughts on protecting yourself against one form of email address harvesting. Hope someone finds them useful.

Jon R. Kibler
Chief Technical Officer
A.S.E.T., Inc.
Charleston, SC  USA
(843) 849-8214

Filtered by: TRUSTEM.COM's Email Filtering Service
No Spam. No Viruses. Just Good Clean Email.

More information about the list mailing list