Time to add exponential backoff for SSH interactive login failures?

Jefferson Ogata Jefferson.Ogata at noaa.gov
Fri Dec 17 01:54:08 EST 2004

Jim Knoble wrote:
> Circa 2004-12-16 16:23:25 +1100 dixit Damien Miller:
> : Jay Libove wrote:
> : > [...] I propose that it is time to add exponential backoff for
> : > SSH interactive login failures.
> : 
> : If you raise the cost of subsequent password attempts much, then it
> : will be cheaper for an attacker to make multiple connections instead.
> Combining exponential backoff on login failures with tarpitting for
> hosts that have too many connections during a given interval could
> reduce the effectiveness of password guessing regardless of how many
> connections were made, unless the attacker performed a distributed
> attack (against which sshd is currently defenseless anyway).

Personally, I think the problem is pretty easily solved with a 
portsentry-type tool. Just watch the logs; when you see a bunch of 
failed logins with password auth, add a rule to hosts.allow, iptables, 
ipfw, etc. for the attacking IP.

I don't think it's a good idea to try to add this code to sshd. It's 
complex enough as it is, and if the backoff code isn't carefully 
designed it creates a denial-of-service risk.

> : I am surprised that these trivial password guessing worms are working
> : at all - it is amazing that people have learned so little in the last
> : 20 years.
> Folks still write passwords on sticky notes attached to their monitor,
> send them via cleartext email messages, and satisfy the "must contain at
> least on number" requirement with the string "123".  I'm a little
> surprised that the worms aren't more effective than they are....

A big issue remains default passwords for some operating systems... the 
silly IRIX demo logins spring to mind. People who switched away from 
telnet to ssh got a grace period of a couple of years, during which they 
forgot about the requirement to disable these types of accounts. Then 
they reinstall, install ssh, put the system back on the net, and 
eventually the automatic ssh scanners wander in nail them.

Jefferson Ogata <Jefferson.Ogata at noaa.gov>
NOAA Computer Incident Response Team (N-CIRT) <ncirt at noaa.gov>

More information about the openssh-unix-dev mailing list