On Tue, 2008-01-01 at 18:38 -0500, Dean Brooks wrote: > On Tue, Jan 01, 2008 at 11:21:50PM +0000, Stephen Usher wrote: > > Actually, a better method which would not inconvenience real users is > > to have an accumalative delay, i.e. the first error has a 1 second > > delay, the second 2 seconds, the third 4 seconds and so on. This > > should tar-pit any brute force attack, at least until the script > > kiddies just blast the server with a huge number of new connections to > > do the job. > > Unfortunately, most of the dictionary attacks that we've been seeing > will open and attack multiple simultaneous connections. After a > single attempt, they'll drop the connection and reconnect. > > The only way to mitigate the attacks is a long delay even on a single > authentication failure.
I'd think that if longer delays become more common, the attackers will just disconnect before the auth reply is received. So maybe I should remove the auth_failure_delay setting after all. A growing delay based on remote IP address would be nice, but it would require keeping track of that information, which pretty much means that there would have to be a new separate process doing that. All of this would be so much easier to implement for v2.0 framework..
signature.asc
Description: This is a digitally signed message part
