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..