Americas

  • United States
sandra_henrystocker
Unix Dweeb

Monitoring failed login attempts on Linux

How-To
Nov 20, 20205 mins
Linux

Failed logins can be legitimate human error or attempts to hack your Linux system, but either way they might flag something that warrants attention.

A password login screen overlaid against an abstract background of data and network connections.
Credit: Vladimir Kazakov / Getty Images

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
         
sandra_henrystocker
Unix Dweeb

Sandra Henry-Stocker has been administering Unix systems for more than 30 years. She describes herself as "USL" (Unix as a second language) but remembers enough English to write books and buy groceries. She lives in the mountains in Virginia where, when not working with or writing about Unix, she's chasing the bears away from her bird feeders.

The opinions expressed in this blog are those of Sandra Henry-Stocker and do not necessarily represent those of IDG Communications, Inc., its parent, subsidiary or affiliated companies.