How do I use the faillog program to track failed login attempts?
by The editorial team
Faillog is a small Linux utility that reports on the number of failed login attempts for a specific user. This utility requires modifying pam settings to work. Below are the steps to set up the faillog utility:
- Open the /etc/pam.d/system-auth file for editing.
- Add the following lines:
auth required pam_tally.so no_magic_root account required pam_tally.so deny=2 no_magic_root
- Save the file and exit.
- Test the configuration by attempting to login as a normal user, but using a wrong password.
- Verify the failed count increments by running the command:
faillog -u
contributed by Jeremy West
February 20th, 2007 at 8:31 am
This can cause a problem on RHEL-4 with xlock, xscreensaver, and other non-root level tools. The reason is that only root has access to the /var/log/faillog file.. so that xscreensaver cannot write to it when you try to unlock your screen.
The solution is to customize your non-root-level pam files from the system-auth ones. I tend to have 2 files:
/etc/pam.d/system-auth-root
/etc/pam.d/system-auth-nonroot
then I do a
sed -ie ‘s/system-auth$/system-auth-nonroot/’ /etc/pam.d/kscreensaver
I then copy the system-auth-root to /etc/pam.d/system-auth (this makes sure that I have a valid copy in the case that authconfig is run and the /etc/pam.d/system-auth is overwritten.)
or similar change command. This allows faillog to only be tried on things that faillog can write to.
In areas that you need to have a written security policy, the reasoning to use for such an exception is that a person who has console access to the system has enough physical access to bypass a faillog lockout, or you use a script to log xscreensaver etc attempts seperately.
February 21st, 2007 at 8:23 am
system-auth works unless you use ssh exclusively for access to a system. You then need to modify the sshd file under pam. I have found that if both files are modified you get double the login failures. I have telnet disabled so I only modify sshd.
auth required pam_tally.so onerr=fail no_magic_root
account required pam_tally.so deny=3 no_magic_root reset per_user
The plus side to using sshd is that authconfig does not overwrite your modifications.
February 28th, 2007 at 11:07 am
I use RedHat EL4, and the first few lines of the file are:
#%PAM-1.0
# This file is auto-generated.
# User changes will be destroyed the next time authconfig is run.
So that would mean that the changes are not permanent, or did I get this wrong?
February 28th, 2007 at 12:54 pm
Martin: Only if you use the authconfig tool (it’s under System Settings|Authentication in the GUI). We remove authconfig in our environment to make sure that doesn’t happen
May 25th, 2007 at 7:47 am
Re: How do I use the faillog program to track failed login attempts?
I have entered the lines as suggested in my /etc/pam.d/system-auth file but, it doesn’t seem to work. When I check the faillog file it will show 4 failures, max 0. I then changed the max to 2 (faillog -m2), reset my (faillog -r), which reset my failures. Then tried again and now I get failures 4, max 2. But then I can still log in as that user without unloacking the accounr. Any help would be greatly appreciated.
November 1st, 2007 at 9:28 am
This is another example of Red Hat trying to do things the Microsoft way and making life miserable for sysadmins. If everyone is so worried about “authconfig” overwriting the changes in configuration files, why doesn’t someone write the authconfig tool the right way, and instead of having it blindly overwriting the files in /etc/pam.d, have it read in the configuration from the /etc/pam.d files and present those as the default to the user when they call the tool. That way any changes will be preserved. This is unfortunately the way RedHat handles the vast majority of their config files, and I strongly disagree with the policy.