Re: [Shutup] [ietf-smtp] Levels of proposals

[Russ Allbery <[e-mail]>]

Ted Lemon <[e-mail]> writes:

> I am still a bit puzzled: how does increasing the number of attackers
> help to bypass the throttling mechanism?  Why isn't the throttle per
> id/password pair, rather than per ip-address/password/id triple?

Why would you throttle per id/password pair?  The attacker doesn't try the
same pair more than once.  That would be pointless.

Let me try explaining this from a different direction.  Suppose you are an
attacker.  You have a list of 10,000 common account names, and a list of
10,000 common passwords.  You want to try each of those passwords with
each of those account names and try to find a combination that works.

If you connect from your compromised host and start plowing through the
100 million combinations, after the first few thousand that you try from
that host any decent authentication system will go "hey, there are tons of
failed authentications from this one IP address" and block all further
attempts, successful or not, from that IP address.  That's pretty easy to
implement.

So what the attacker does instead is use their botnet of a million
compromised personal computers (that's sadly not really an exaggeration),
and has each one of those hosts try 100 combinations and then disconnect.
This is now below (or at least near) the threshold for an actual customer
typoing their address or password or something, and rate limiting becomes
fairly useless as a defense.

> Secondarily, if distributed processing makes throttling per id/password
> pair difficult, why is it hard to do the botnet IP address matching at
> the authentication point?  This seems like it would avoid a _lot_ of
> extra processing.

Chris addressed this quite well in his message.  I don't really have much
to add to what he already said.

The TLDR in case something about that message was confusing is that only
the authentication point can block the IP addresses at the authentication
point, but you can analyze Received headers to do a bunch of other things,
such as determine compromised botnet IP addresses that someone else
*didn't* block but that you *do* want to block for *your* service.  It
improves the scale and flexibility of what you can do by basically giving
you more threat intelligence.

-- 
Russ Allbery ([e-mail])              <http://www.eyrie.org/~eagle/>