pam_tally with sshd: ssh password-based failures not tally'd

[Andy Armstrong]

George Hansper wrote:
> I hate to contradict you, but this is what I get (Fedore Core 3 for this 
> test):
[snip]

I /think/ that's just regular host locking, no?

> My /etc/security/pam_abl.conf is:
> 
>     host_db=/var/lib/abl/hosts.db
>     host_purge=2d
>     host_rule=*:5/1h,10/1d
>     user_db=/var/lib/abl/users.db
>     user_purge=2d
>     user_rule=*:3/10m
> 
> If user-locking _really_ only considers the username, it is important to 
> add an "unlocking"
> command. Otherwise, a malicious user may take delight in locking out 
> legitimate users.

That's the reason for being able to define which users the rules apply 
to. I agree though: the inability to unlock a locked account is a 
glaring omission which I'll fix in the next couple of days.

> I notice that the user-counter continues to increment, even after a host 
> is locked out.

That's by design - otherwise it would oscillate during a prolonged attack.

> eg "hacker.com" tries 100 attempts on root, user1, user2, etc. Even 
> though all
> attempts are unsuccessful, the "Failed User" counter is still at 100 at 
> the end of it,
> and these users cannot access the system remotely until the timers in 
> the DB have elapsed.

Yes, that logic (IMO) makes sense for host based lockouts but not so 
much for user based lockouts.

> Personally, I think the user-host locking behaviour above is more useful 
> that user-only locking.
> It avoids the Denial-Of-Service vulnerabilty I mention above.

Yup.

> An unlocking command would still be useful, because a legitimate user 
> may try many logins before
> calling the relevant help-desk, and may have inadvertently locked their 
> account or host.
> (eg entering an old password, or a user-id for another system).

Indeed.

-- 
Andy Armstrong, hexten.net