Time to add exponential backoff for SSH interactive login failures?

[Jay Libove]

I'm looking at this from the point of view of the attacker who is trying
to successfully break in, not deny service. The attacker doesn't mind if
he causes a denial of service, but that's not his goal here. There are
easier ways to do that than the current SSH Worm.

Whatever is most expensive to the attacker, without causing a true
denial of service, is a good thing.  While multiple invocations of the
SSH daemon are more expensive to the attacked as well as to the
attacker, the goal is to make the attack less likely to succeed.
Defense often has a cost.

Actually, this makes me suggest yet another feature - a deliberate delay
before even the FIRST interactive login password prompt, in addition to
exponential backoff thereafter.  

Perhaps this really is not in scope of the SSH daemon itself .. it's
just that I don't have a reactive IDS / IPS lying around which can
detect abnormally high numbers of SSH connections from a particular IP
address in a short period of time and create a temporary firewall filter
for it...


I am very open to other suggestions on how I can at once
1. allow myself to SSH in using a password from unpredictable locations,
and
2. slow down anyone who would try to brute force (or even just run
through a few hundred
already-found-elsewhere-but-not-existing-on-my-machine user ID and
password combinations)

Were it not for #1 above, I could simply turn off access except from
known locations, or only allow access using pubkey, or a variety of
other things.. but I need this to be available from random places where
I cannot necessarily copy in my private key.


Thanks for the thoughts and suggestions.
-Jay

-----Original Message-----
From: Damien Miller [mailto:djm at mindrot.org] 
Sent: Thursday, December 16, 2004 12:23 AM
To: Jay Libove
Cc: openssh-unix-dev at mindrot.org
Subject: Re: Time to add exponential backoff for SSH interactive login
failures?

Jay Libove wrote:
> With the growing number of username/password pairs being tried by the
low
> level SSH attack which we've all seen in the past few months (I am now
> seeing some series of attempted logins through SSH which try
fifty-plus
> different IDs, some with more than one password; I've seen 60 hits on
> "root" in a row), 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.

>From the victim's point of view, multiple connections are far more
DoS-like than multiple brute-force attempts: each new connection
requires a TCP PCB slot (persisting well after the connection is gone)
and a key-exchange (including an expensive GEX) in addition to all
the other accept-time processing, whereas multiple auth attempts are
usually just additional crypt() calls.

Maybe something like this would be useful in addition to a client-puzzle
(e.g. finding a truncated hash collision before auth), but I think it
has the potential to alter attacker behaviour in a way that is inimical
to server operators.

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.

-d