[8543] in bugtraq
Sendmail DoS (was: Re: various *lame* DoS attacks)
daemon@ATHENA.MIT.EDU (net.ikon)
Fri Nov 13 17:54:30 1998
Date: Thu, 12 Nov 1998 16:56:48 -0500
Reply-To: "net.ikon" <jna@retina.net>
From: "net.ikon" <jna@RETINA.NET>
To: BUGTRAQ@NETSPACE.ORG
In-Reply-To: <3649c77a.777415828@tray.dynamsol.com>
While we're on the subject of incredibly lame DoS attacks, I thought I'd
take a moment to mention what occurred on our site in the last few days.
About three days ago a spammer sent a few thousand emails out to about 15
or so sites that stupidly forgot to block relay (if you haven't blocked
relaying yet, do so for the good of the net. see http://www.sendmail.org.)
As most sites check for a valid FDQN and valid domain name in the inbound
mail header, this spammer decided to insert a valid domain name with a
random username, like: asjfhsdf@fcl-us.net on each piece of outgoing mail
that he sent to confuse the recipient into thinking that the mail
originated from our (fcl-us.net) domain. Now, the main problem with this,
is that many mailers are improperly configured and don't parse mail
headers correctly, and would ues this address as the return/bounce address
when mail to a destination address would fail.
We ended up receiving a few thousand bounces from various sites around
the country, the worst coming from AOL, which delivers a 1k-2k bounce
message with every failed attempt.
When this occurs, it feels alot like a smurf attack. Hundreds of hosts
trying to contact the main MTA for a site which never participated in the
relay or transmission of the original mail message. This doesn't even
include the hundred or so messages we received from users trying to tell
us to stop spamming them(!)
The CPU time required for our MTA (Sendmail 8.8.6 on a four proc ultra
sparc 2 with NIS+) to look up in NIS, identify that the fake random user
didn't exist on our servers and deliver a bounce response to the relay's
bounce, multiplied across hundreds of inbound requests (causing 40-60
sendmail processes to be forked) was so severe that it took out our
mailserver for about three days.
Some of the solutions we used to stop it were to enter local password
entries for the random users (so that we'd just queue the mail and could
delete it) and to set up filtering for certain large-scale relays
(*.aol.com) while bounces were coming in, but it is extremely difficult to
block all of the bounces from coming back to you because for the most part
they are valid bounces (although your machine didn't create the outgoing
mail).
Like the ICMP Smurf attack, the only real solution to this problem is to
have adequate CPU and disk resources so that you can take the beating when
it comes your way from hundreds of hosts. Sendmail 8.9.1 offers some
relief from this sort of attack with queue-only modes and limits on the
number of running children, so I suggest you upgrade if you haven't done
so already.
We've also started to use Kai's SpamShield
(http://www.abest.com/~kai/spamshield.html) which seems to offer some
route-based protection against large-scale message floods like these, but
do not feel that it'd be useful in a "smurf" style attack such as this.
Any suggestions would be appreciated.
-john
--
J. Adams web: http://www.retina.net/~jna
mail: jna@retina.net irc: netik (#gothic)
"Your living room, is a factory. The product being manufactured... is you."
