Spamhaus...

James Hess mysidia at gmail.com
Mon Feb 22 04:59:08 UTC 2010


On Sun, Feb 21, 2010 at 1:16 PM, Patrick W. Gilmore <patrick at ianai.net> wrote:
> You should not randomly respond to packets at arbitrary rates.  If you do, you are being a bad Netizen for exactly this reason.  See things like amplification attacks for why.   ...
> --

Whether it's  SMTP,  TCP,  or ICMP spam involved the  reflection
attack result is still the same, and still a DoS, even if there aren't
  "arbitrary rates of transmission"  from any player.  Sure,  _your_
host A's  TCP stack  may  only respond at a  maximum rate of   1
packet per second  to ICMP queries  from all sources,  but there are
hosts B, C, D, E, and F, too.

Just like mail servers  block single IP addresses  that hit more than
X invalid recipients  or graylist on more than  Y  SMTP
transactions/recipients  in Z minutes.

But the  spammer  is  sending  out massive  forged ICMP ECHOs or TCP
SYNs  with 1,000,000+  different spoofed source addresses that
correspond to operational internet hosts,  with semi-randomized TTL
values.

No  "one host"   creates a problem,  you have an emergent  property,
where the attacker abused all the hosts put together.    The result is
very much from the attacker,  not the hosts involved,   they have
simply  propagated the attack.

"Backscatter"  is  spam from the person who created the fake origin,
not spam from the fooled mail servers.      Obviously  SMTP servers
should try to do the best they can to stop it.

But if the origin domain has not provided SPF records,  there are some
unusual cases left open,  where a bounce to a potentially fake address
may still be required.

E.g.   The  recipient was  valid at the time the message was accepted,
BUT  while the message was still queued,  their account got deleted,
now the  user is gone, and the message cannot be delivered to
something that no longer exists.

Or they ran out of disk quota  allocated to their mailbox.
This is impossible to know in advance,  since  they haven't run out
until several other queued messages are delivered to them.

> TTFN,
> patrick
--
-J




More information about the NANOG mailing list