LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Linux - Security (https://www.linuxquestions.org/questions/linux-security-4/)
-   -   pam_cracklib not locking user after 3 bad password attempts (https://www.linuxquestions.org/questions/linux-security-4/pam_cracklib-not-locking-user-after-3-bad-password-attempts-563591/)

legcard 06-21-2007 06:32 PM

pam_cracklib not locking user after 3 bad password attempts
 
I am new to linux but not to unix. I am trying to harden my redhat with pam so that users trying to login, after 3 bad password attempt, get locked. I have tried a number of things but the user can still get in when entering his good password after 5 or 6 bad passwords. I am getting all tangled up between changing password process and locking out at login. I need both but this one is for (tho not working) locking the user after 3 bad login attempts.

Any ideas what I am doing wrong??
Linda
This is login
#%PAM-1.0
auth required pam_securetty.so
auth required pam_tally.so file=/var/log/faillog onerr=fail \
deny=3 per_user no_magic_root
auth required pam_nologin.so
auth required pam_unix.so
account required pam_unix.so
account required pam_tally.so per_user deny=3 \
magic_root reset
password required pam_cracklib.so retry=3 minlen=8
password required pam_unix.so use_first_pass use_authtok md5 remember=5
# pam_selinux.so close should be the first session rule
# session required pam_selinux.so close
session required pam_unix.so
session optional pam_console.so
# pam_selinux.so open should be the last session rule
# session required pam_selinux.so open

This is passwd
#%PAM-1.0
auth required pam_stack.so service=system-auth
account required pam_stack.so service=system-auth
account required pam_cracklib.so
password required pam_cracklib.so retry=3
password required pam_unix.so

This is system-auth
#%PAM-1.0
# This file is auto-generated.
# User changes will be destroyed the next time authconfig is run.
auth required /lib/security/$ISA/pam_env.so
auth sufficient /lib/security/$ISA/pam_unix.so likeauth nullok
auth required /lib/security/$ISA/pam_deny.so

account required /lib/security/$ISA/pam_unix.so
account sufficient /lib/security/$ISA/pam_succeed_if.so uid < 100 quiet
account required /lib/security/$ISA/pam_permit.so

password requisite /lib/security/$ISA/pam_cracklib.so use_authtok \
minlen=9 lcredit=-2 ucredit=-2 dcredit=-2 ocredit=-2 retry=3

password required /lib/security/$ISA/pam_unix.so nullok use_authtok \
shadow
session required /lib/security/$ISA/pam_limits.so
session required /lib/security/$ISA/pam_unix.so

unSpawn 06-24-2007 07:36 AM

Here's an example of how to test the pam_tally mechanism. I'll be using a CentOS-3 box w/o SELinux (don't affect this anyway AFAIK), using the PAM service "su", local user "test" and default faillog records in /var/log/faillog. * Note no system should have a user called "test" unless you have a) made it an unprivileged user and b) set a ridiculously strong password and c) restricted access to it in the most BOFH-stylee kind of way.

0. Check if you got /var/log/faillog: using pam_tally's "onerr=fail" will cause a DoS if the file doesn't exsist, so make sure you want that. Most likely you'll want "onerr=succeed" and let another module in the PAM stack deny or allow access to the service.
1. Check for user "test" if it's got a non-zero ".fail_max" in faillog: "faillog -u test" (or "pam_tally --user test"). Enter a maximum or 2: "faillog -u test -m 2" (and check it's set correctly).
2. Edit your /etc/pam.d/su stack:
Code:

#%PAM-1.0
auth      sufficient  /lib/security/$ISA/pam_rootok.so
auth      required    /lib/security/$ISA/pam_tally.so onerr=succeed
auth      required    /lib/security/$ISA/pam_stack.so service=system-auth
account    required    /lib/security/$ISA/pam_tally.so deny=3
account    required    /lib/security/$ISA/pam_stack.so service=system-auth
password  required    /lib/security/$ISA/pam_stack.so service=system-auth
session    required    /lib/security/$ISA/pam_stack.so service=system-auth

** The "deny=3" is only used for users that don't have ".fail_max" in faillog.
3. Now try to su to user "test" and give a vronk password. Repeat once more. Check with faillog: "faillog -u test" or "pam_tally --user test" and see the counter get incremented.
4. Now try to su to user "test" giving the correct password and see access being denied.
Please make it a standard procedure to first use the faillog / pam_tally tools and read the system logs to check for errors before reporting failures.


*** Cracklib is for password strength, not denying logins, so if you say "retry=3" you're giving 3 *chances* before returning. A user can rerun it w/o probs, no denial. And if you use "remember" make sure you have got a file "/etc/security/opasswd" for storing old passes (if the RPM didn't create this already).

HTH

legcard 06-25-2007 11:21 AM

Hi,
First, thank you for your response. I think that maybe I am mixing my "su" and my "login. Or I did not phrase my question correctly.

My goal is to LOCK users who are attempting to login (not "su") and enter 3 bad passwords. Sort of like windows lock-out for bad password attempts at login and it locks you out for 15 minutes. That is the mechanism I am trying to configure.

I had already created /var/log/faillog (though, based on your email this is for su attempts.)

I had already created /etc/security/opasswd (for remember=5)

We are still in the beginning stages of hardening this box so I login as root on this non-networked machine. One of my tasks down the road is to verify that "su" is working. I did do "faillog -u bob -m 2" that you suggested and could see the "2" when I did faillog -u bob. Unfortunately, when I logged in as bob and tried to "su" (to root), the counter in faillog did not increment. Odd.

So my focus for now is to lock users when they fumble their passwords 3 times. I tried "auth required pam_tally.so per_user deny=3 lock_time=180" (3 mins). /var/log/messages logged an authentication failure each time my user (bob) tried to login but reported "unknown option lock_time=180". No matter how many times (3 ,6, etc) I enter a bad password while trying to login to bob, it does not lock the account. I don't know where I would see "account locked". But if I enter the correct password after 6 or 8 incorrect ones, it lets me in. So if you are a good guesser, you can just keep trying. YIKES!

I would appreciate any help you can give me.

unSpawn 06-25-2007 12:28 PM

My goal is to LOCK users who are attempting to login (not "su") and enter 3 bad passwords.
My "su" was just my example, applying it is your risk :-]


One of my tasks down the road is to verify that "su" is working. I did do "faillog -u bob -m 2" that you suggested and could see the "2" when I did faillog -u bob. Unfortunately, when I logged in as bob and tried to "su" (to root), the counter in faillog did not increment. Odd.
No, it isn't. You're looking at the source user, you must look at the target user.


All times are GMT -5. The time now is 06:08 AM.