openssh unix dev - Feb 2005 - Feature request: FAIL_DELAY-support for sshd

Hello!

My Linux-server is every day attacked with brute-force password cracking 
attacks. I use openssh-3.9p1 (SuSE Linux 9.2) with standard setup (PAM, 
LoginGraceTime 2m, MaxAuthTries 6). Unfortunately, I see cracking 
attempts with very short delays (1 second):

Jan 31 00:46:53 XXX sshd[10774]: Invalid user backup from 
::ffff:66.98.176.50
Jan 31 00:46:54 XXX sshd[10776]: Invalid user server from 
::ffff:66.98.176.50
Jan 31 00:46:55 XXX sshd[10778]: Invalid user adam from ::ffff:66.98.176.50
..
I want to slow down this attacks with a login delay for failed logins. I 
tried FAIL_DELAY (in /etc/login.defs) for this, but unfortunately 
openssh has no support for this and ignores it.

I searched this day in the net for solutions and tried some things in 
the source code. This are my experiences:

1) Very much people ask for a FAIL_DELAY-feature (Source: Google, 
Newsgroups, Mailinglists, ...)
2) The work-arounds are not perfect:
    a) Some people suggests using /lib/security/pam_tally.so (this 
PAM-module denies access to accounts after too many login failures). 
Unfortunately this module can result in denial-of-service.
    b) MaxStartups-Option in /etc/ssh/sshd_config. This drops new 
connections if there are too many unauthorized login attempts. It may 
help a bit against cracking attempts, but it doesn't use delays. Because 
OpenSSH checks the usernames before PAM-authentication, this feature 
will not help against testing usernames.

I played a bit with OpenSSH's source code to enable a FAIL_DELAY:

In auth-pam.c: sshpam_thread I inserted

    pam_fail_delay(sshpam_handle, 10000000 /* micro-seconds */ );

before

    sshpam_err = pam_authenticate(sshpam_handle, flags);

This results in a 10 seconds delay after an login attempt with an 
existing user, but a wrong password.

Unfortunately this introduces new problems, because an attacker can now 
see, if the user exists or not:

Case 1: existing username, but wrong passwords
$ ssh  existing-user at localhost
Password:
(10 sec delay)
Password:
(10 sec delay)
Password:
(10 sec delay)
Permission denied (publickey,keyboard-interactive).

Case 2: non-existing username
$ ssh -p 112 non-existing-user at localhost
Password:
(no delay)
Password:
(no delay)
Password:
(no delay)
Permission denied (publickey,keyboard-interactive).

The problem is, that OpenSSH checks the username without PAM, so that 
pam_fail_delay() has no effect, if the username is wrong.

Could someone help here? I think, the FAIL_DELAY feature is very 
important for better security and many users wish it and will use it.

Regards, Bj?rn

On Tue, Feb 01, 2005 at 08:33:23PM +0100, Bjoern Voigt wrote:
> The problem is, that OpenSSH checks the username without PAM, so that 
> pam_fail_delay() has no effect, if the username is wrong.
It seems that sshd's checking of getpwnam() before trying to
authenticate with PAM causes many issues.  For example, some PAM
modules want to change the username after authenticating; the
user passed in to PAM might not even exist.  (Of course the
user returned by PAM must.)  This can be used to allow role-
account logins, if the user authenticates using something like
radius.

That said, however, I think OpenSSH is designed to follow the
same code path for authentication with valid/invalid users.  I
believe it should call pam_authenticate also for users that 
don't exist.  Are you sure pam_authenticate isn't being called?

Bjoern Voigt wrote:
> My Linux-server is every day attacked with brute-force password cracking 
> attacks. I use openssh-3.9p1 (SuSE Linux 9.2) with standard setup (PAM, 
> LoginGraceTime 2m, MaxAuthTries 6). Unfortunately, I see cracking 
> attempts with very short delays (1 second):
[...]
> I want to slow down this attacks with a login delay for failed logins. I 
> tried FAIL_DELAY (in /etc/login.defs) for this, but unfortunately 
> openssh has no support for this and ignores it.
3.9p1 should insert a delay on fail if PAM is configured to do so (it 
does on my RH9 box) for password authentication.  -current fixes that 
for keyboard-interactive too.

None of this is going to make any difference for your situation, though.

Notice that the pids for each attempt are different?  Even if each sshd 
delays it's not going to slow down an attacker much if at all since the 
requests are effectively pipelined.  It would mean that the resources 
for each connection are tied up on your server for longer.

What would help is restricting the rate of connections permitted from 
each source.  (Such a feature was recently added to OpenBSD's pf, and 
may exist in other filters.)
> 1) Very much people ask for a FAIL_DELAY-feature (Source: Google, 
> Newsgroups, Mailinglists, ...)
> 2) The work-arounds are not perfect:
>    a) Some people suggests using /lib/security/pam_tally.so (this 
> PAM-module denies access to accounts after too many login failures). 
> Unfortunately this module can result in denial-of-service.
There's also a module to blacklist the source of such connections 
(although I've not used it):
http://www.hexten.net/sw/pam_abl/index.mhtml
> Case 1: existing username, but wrong passwords
> $ ssh  existing-user at localhost
Please try repeating this test with either:
  - "PasswordAuthentication yes" and
"ChallengeResponseAuthentication
no" in sshd_config
  - a current development snapshot from 
ftp://ftp.openbsd.org/pub/OpenBSD/OpenSSH/portable/snapshot/

-- 
Darren Tucker (dtucker at zip.com.au)
GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4  37C9 C982 80C7 8FF4 FA69
     Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.

On Wed, Feb 02, 2005 at 05:59:42PM +0100, Bjoern Voigt
wrote:
> But, how you deal with the following situation: Two users (a
"good"
> user and a "bad" user) are behind a firewall with one public IP.
> Now the "bad" user tries 3 wrong passwords. After that, the
"good"
> user can not connect to his host (denial-of-service attack).
I would probably set up a VPN between the two networks.


//Peter