Monitoring failed login attempts on Linux

Repeated failed login attempts on a Linux server can indicate that someone is trying to break into an account or might only mean that someone forgot their password or is mistyping it. In this post, we look at how you can check for failed login attempts and check your system’s settings to see when accounts will be locked to deal with the problem.

One of the first things you need to know is how to check if logins are failing. The command below looks for indications of failed logins in the /var/log/auth.log file used on Ubuntu and related systems. When someone tries logging in with a wrong or misspelled password, failed logins will show up as in the lines below:

$ sudo grep "Failed password" /var/log/auth.log | head -3
Nov 17 15:08:39 localhost sshd[621893]: Failed password for nemo from 192.168.0.7 port 8132 ssh2
Nov 17 15:09:13 localhost sshd[621893]: Failed password for nemo from 192.168.0.7 port 8132 ssh2

You could summarize instances of failed logins by account with a command like this:

$ sudo grep "Failed password" /var/log/auth.log | grep -v COMMAND | awk '{print $9}' | sort | uniq -c
     22 nemo
      1 shs
      2 times:

That command summarizes failed logins by username (ninth column in the grep output). It avoids looking at lines containing the word “COMMAND” to skip over inquiries that contain the “Failed passwords” phrase (e.g., someone running the command that was run above). The “times:” string suggests that there were more repeated attempts than the number reported. These come from lines containing “message repeated 5 times:”  that may be added to the log file when a password is entered incorrectly a number of times in quick succession.

Another thing you might want to check is where the failed login attempts are coming from. For that, change the field that you’re focusing on from  the ninth to the eleventh as in this example:

$ sudo grep "Failed password" /var/log/auth.log | grep -v COMMAND | awk '{print $11}' | sort | uniq -c
     23 192.168.0.7

It might be especially suspicious, for example, if you’re seeing failed logins for multiple users from a single system.

In RHEL, Centos and related systems, you’ll find the messages related to failed logins in the /var/log/secure file. You can use basically the same query as shown above to get a count. Just change the file name as shown here:

$ sudo grep "Failed password" /var/log/secure | awk '{print $9}' | sort | uniq -c
      6 nemo

Check settings in the /etc/pam.d/password-auth and /etc/pam.d/system-auth files. Adding lines like these will  enforce your settings.

Checking faillog

You might check out the faillog command, but this command looks at the /var/log/faillog file which does not seem to be used on many systems these days. If you use the faillog -a command and get output like that shown below listing 12/31/69 as in the time columns, it’s clear this file is not in use.

$ faillog -a
Login       Failures Maximum Latest                   On

root            0        0   12/31/69 19:00:00 -0500
daemon          0        0   12/31/69 19:00:00 -0500
bin             0        0   12/31/69 19:00:00 -0500
sys             0        0   12/31/69 19:00:00 -0500

The dates and times shown refer back to the beginning of Unix (01/01/70)–probably corrected for the local time zone. If you run the commands shown below, you can verify that the file is not empty, but contains no real data:

$ ls -l /var/log/faillog
-rw-r--r-- 1 root root 32576 Nov 12 12:12 /var/log/faillog
$ od -bc /var/log/faillog
0000000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000
                                       
*
0077500

If the faillog file is actually in use, you should see recent activity and no references to 1969.

How to respond

Failed logins can happen for many reasons. It may be that one of your users tried to log in with their caps-lock key on and didn’t notice. Maybe they recently changed their password and forgot that they did so and were trying the old one. Maybe they’re trying the password they use on a different system. If one particular account frequently shows up when you run your queries, you might look into it. However, an occasional failed login attempt is fairly common.

Checking your settings

To see how your system is set up to deal with failed logins, check out the /etc/pam.d/common-auth file. It’s used on systems with the Linux Pluggable Authentication Modules (PAM). Two settings in this file control how many failed login attempts will be tolerated before an account is temporarily locked and how long the account will be locked.

A line like this one will have PAM locking an account after six failed login attempts. The lockout will last for five minutes (300 seconds).

auth  required   pam_tally2.so deny=6 unlock_time=300

Wrap-Up

Occasional failed logins are to be expected, but it’s still a good idea to be familiar with how your system is configured and run a query from time to time to get a handle on how much of this kind of activity is taking place. One good way to do this is to run the query as a cron job and email the output to yourself.