hi, I wrote a patch to openssh sshd.c which enables "exponential backoff", so that an attacker cannot brute force your password by making hundreds of login attempts. here is the code: http://sam.nipl.net/sshd-backoff/ An attacker who fails to login is locked out (by IP address) for 1 minute, and the lockout period doubles for each failed login after that. Normally three logins are allowed before an ssh connection is terminated. This patch is "beta" software and might lock you out of your sshd, so be careful and make sure you are prepared for that. You can "test" the patch by attempting to break in to this server, nipl.net ssh is running on port 22 The patch creates and uses a db-4 database in /var/lib/ssh/backoff.db I think my code is written carefully, but it might have some bugs. Also I think this problem might be better solved outside of sshd (maybe in pam). I'd be very grateful for any constructive feedback. Thanks! Sam ( I wrote a similar hack in shell-script a while ago, to prevent pppd running up a huge phone bill in that case that a dialup connection fails. )
Hey Sam, This is a really nice idea. However, I'm not so hot on making a core utility such as OpenSSH reliant on a library that isn't by default available on most platforms. -rob On Jan 23, 2009, at 1:05 AM, Sam Watkins wrote:> hi, > > I wrote a patch to openssh sshd.c which enables "exponential backoff", > so that an attacker cannot brute force your password by making > hundreds > of login attempts. > > here is the code: > > http://sam.nipl.net/sshd-backoff/ > > An attacker who fails to login is locked out (by IP address) for 1 > minute, and the lockout period doubles for each failed login after > that. > Normally three logins are allowed before an ssh connection is > terminated. > > This patch is "beta" software and might lock you out of your sshd, > so be > careful and make sure you are prepared for that. > > You can "test" the patch by attempting to break in to this server, > nipl.net ssh is running on port 22 > > The patch creates and uses a db-4 database in /var/lib/ssh/backoff.db > > I think my code is written carefully, but it might have some bugs. > Also > I think this problem might be better solved outside of sshd (maybe in > pam). I'd be very grateful for any constructive feedback. > > Thanks! > > Sam > > > ( I wrote a similar hack in shell-script a while ago, to prevent > pppd running up a huge phone bill in that case that a dialup > connection fails. ) > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Sam Watkins wrote:> I think this problem might be better solved outside of sshdI agree. For example by using the firewall. At most maybe sshd needs more to the point logging of failed attempts, but I think it's already possible to reliably distinguish those errors for external processing, or? //Peter
Sam Watkins wrote:> I wrote a patch to openssh sshd.c which enables "exponential backoff", > so that an attacker cannot brute force your password by making hundreds > of login attempts.I read "hundreds of login attempts" in order to brute force a password. But it actually takes orders of magnitudes more to brute force attack a password. This is okay. You really do want the best attack available to be a brute force attack. The present safeguards will prevent the attack from succeeding before the end of time. Avoiding passwords entirely and using rsa pub keys instead also avoids the issue. That is a good security measure. I think it would be an interesting whitehat project to build an attack program against ssh using a password guesser. Then people who fear that ssh passwords can be guessed too easily can play with it and be assured that a successful brute force attack against ssh by password guessing is actually quite difficult. The advantage of your patch over an external process such as fail2ban is that fail2ban is quite large and hard to use on smaller systems due to resource constraints. A disadvantage of your patch is that I think exponential backoff creates too long of delays. A non-exponential backoff seems more desirable to me than an exponential backoff. Bob
Hi, On Mon, Jan 26, 2009 at 09:32:43AM -0700, Bob Proulx wrote:> Sam Watkins wrote: > > I wrote a patch to openssh sshd.c which enables "exponential backoff", > > so that an attacker cannot brute force your password by making hundreds > > of login attempts. > > I read "hundreds of login attempts" in order to brute force a > password. But it actually takes orders of magnitudes more to brute > force attack a password. This is okay. You really do want the best > attack available to be a brute force attack. The present safeguards > will prevent the attack from succeeding before the end of time.The problem is that people still pick poor passwords. So the attacker might not have to test (70^8) combinations (lower+uppercase+digits+ few special caracters, 8 of them long) but might succeed after a few hundred probes. ... and slowing down attackers might actually help things here. (I use fail2ban for that, which works quite well) gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany gert at greenie.muc.de fax: +49-89-35655025 gert at net.informatik.tu-muenchen.de