RE: Re: [spf-help] SRS for Exim

> From: Stuart D. Gathman
> Sent: Wednesday, April 28, 2004 8:53 PM

<...>

> Yes - although it's *much* simpler to just always rewrite - even when
> not forwarding.  This allows you to reject those annoying bounces of
> spam and worms you didn't send - plus those worms that try to "worm" their
> way past spam defences by pretending to be a DSN.  If you always rewrite,
> then any bounces (MAIL FROM: <>) that come to your machine are spams
> and worms.

Very true.

>
> In fact, always rewriting is often called SES - and if receivers
> implement CBV, you don't need SPF.  However, SPF is better because
> TCP connections are comparatively expensive.  With only SES, anyone could
> easily DOS your system by propagating lots of spam with your
> return address.
> Millions of recipient systems calling your system to check whether the
> sender is valid is not something you want to suffer through.

Actually, you are no more immune to a DDoS attack with SPF than with SES.
The attack method is slightly different, but the bandwidth and CPU
consequences are virtually identical.  If you have an SPF-enabled MTA, an
attacker could use a number of compromised machines on broadband lines where
the provider does not do outbound port 25 blocking and rate limiting (in
plentiful supply).  Let's say the attacker has 1,000 such zombies under his
control (a conservative number, based on DDoS attack descriptions I have
seen) and each machine sends 100 messages to your MX per hour.  That is 100K
TCP connections per hour, and the attacker can scale up the number of
zombies very easily and reduce the number of messages coming from each one
making it virtually impossible to identify them.  Your MX will reject every
one of those messages based on SPF, but each one was still a TCP connection,
so your overhead is about the same as receiving a CBV that fails.  If you
can reject the connection earlier than the SPF check by means of black lists
or IP heuristics, you could do the same for a CBV, so the two cases are
quite similar in terms of overhead.

For the case of 1,000 zombies each sending you 100 messages per hour (or
10,000 zombies each sending you 10 messages per hour), that is 100K TCP
connections per hour or 2.4 million TCP connections in a 24 hour period.
Depending on your bandwidth, that could be just a minor annoyance or a big
problem.

By its very nature, there is no reasonable way to stop a DDoS attack, as
long as not too many connections come from any single source and there is
nothing "unusual" about the packets used that you can write a router rule to
null route (assuming that you control your own border router).  Since the
attack "appears to be coming from everywhere at once", blacklisting the
zombies one at a time is pointless since the attacker can find new ones
faster than you can blacklist them.

The only real defense is having enough bandwidth to weather the storm until
the attacker gets bored.  If you have the good fortune to have a domain that
sends no mail attacked, as Stuart did, you can then take the satisfying
action that he did, but that is not the general case.


>
> (I had this happen to me.  My solution: I changed the MX of the domain
> to point to some spammer machines.  Kind of drastic, but it worked.  No,
> the domain was no longer used, so no legit mail got sent to the spammers.)

Payback!  A rare opportunity but no doubt very satisfying.

--

Seth Goodman