User: Password:
|
|
Subscribe / Log in / New account

Blocking brute forcing

Blocking brute forcing

Posted Jun 27, 2011 21:13 UTC (Mon) by solardiz (subscriber, #35993)
In reply to: Blocking brute forcing by nye
Parent article: A hole in crypt_blowfish

I guess I shouldn't have commented on this topic in here, which is only indirectly related to the article's topic. Anyway, here's a bit more detail: the approach that popa3d uses, and which I like so far (compared to possible alternatives), is based purely on connection rate per source address. In fact, its primary purpose was/is to improve availability of the service when under connection flood (whether intentional or not) from one or from a handful of source addresses. It is also reducing password probing as a nice side-effect. Default settings are: 500 sessions max, 50 per-source max (yes, NAT is considered here), a session is considered active for no less than 10 seconds after its startup. This allows for up to 5 new connections (and thus authentication attempts) per second per source IP address on average (but it also allows for spikes for up to 50 when not under flood from the address). Indeed, these settings may need to be tuned on larger/smaller servers.


(Log in to post comments)

Blocking brute forcing

Posted Jun 29, 2011 16:07 UTC (Wed) by nye (guest, #51576) [Link]

Ah, right. So the point here is that if you didn't block some users, *all* users could be affected, so even if you get some collateral damage it's still better than not doing it. That's somewhat tangential to blocking for the purpose of preventing dictionary attacks (as you say) and does make more sense.


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds