On 12/03/2015 10:48 PM, Russ Allbery wrote:
Ted Lemon <mellon(_at_)fugue(_dot_)com> 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?
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.
Hi Russ, it's been a long time since we last were in the same place
(physically or otherwise ;-)
One of the most depressing indicators I've seen is watching thousands of
different IPs only attempt one or two submissions, and not trying again
EVEN THO both submissions succeeded and none failed.
Secondly, we have full instrumentation, and the passwords they're trying
are pretty obviously not "common password" dictionaries or brute-forcing
attempts.
Clearly they're not lacking in compromised accounts.
So, the problem is much larger than "brute force or common password
dictionaries"
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.
Yeah, it's obvious that the authentication point is the best place to do
it, but the reality is that most of them don't (we're working on that),
so...
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.
you have to do it for them so that _you_ can block what they should have
and didn't.
Furthermore, intelligent botnet operators will aim their cannons away
from the sites successful at MSA-blocking to the ones who aren't.
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp