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
_______________________________________________ Pam-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/pam-list
