Lab: Linux log analysis for failed logins

Aim and what you need

The aim is to answer three questions from raw logs: who tried to log in and failed, from where, and how often. These are the same questions a SOC (security operations centre) analyst asks during a suspected brute-force attack, and the pipeline skills carry over to any text log.

• Two virtual machines on a host-only or internal network: a Linux target (Ubuntu Server 24.04 or Debian 12) with OpenSSH server, and a client VM or your host computer.
• Example addresses: target 192.168.56.20, client 192.168.56.30.
• An account with sudo rights on the target. About 40 minutes.

Tip: only generate login attempts against machines you own. Repeated logins against someone else's server can break the law even if you never get in.

Steps

1. On the target, make sure SSH is running and note which log source your distribution uses (Figure 2).
2. From the client, try to log in several times with a wrong password, using both a real user and a made-up one such as testuser. Press Ctrl+C after each failure.
3. On the target, read the raw events first, then filter and count them with the commands below.
4. Save the summary to a file so you can compare it with later runs.

sudo systemctl status ssh
ssh [email protected]
ssh <your-user>@192.168.56.20

sudo journalctl -u ssh --since "1 hour ago"
sudo journalctl -u ssh --since today | grep "Failed password"
sudo grep "Failed password" /var/log/auth.log
sudo grep "Invalid user" /var/log/auth.log
sudo grep "Failed password" /var/log/auth.log | awk '{print $(NF-3)}' | sort | uniq -c | sort -nr
sudo grep "Failed password" /var/log/auth.log | awk '{for(i=1;i<=NF;i++) if($i=="for") print $(i+1)}' | sort | uniq -c | sort -nr
sudo lastb -n 20
last -n 20
sudo grep "Accepted" /var/log/auth.log
sudo grep "Failed password" /var/log/auth.log | awk '{print $(NF-3)}' | sort | uniq -c | sort -nr > ~/failed-summary.txt

The awk '{print $(NF-3)}' trick works because every failed-password line ends with from IP port N ssh2, so the address is always the fourth field from the end. The second awk prints the word after "for", which is the user name; for unknown users this prints "invalid", which is itself a useful signal.

How to verify

You have succeeded when your summary shows the client address 192.168.56.30 with the same number of failures you generated, and the user list includes both the real user and testuser. Check that lastb agrees. Then look for the line that matters most in a real incident: an Accepted login from an address that also has many failures. A few failures followed by a success from the same address can mean a guessed password, so in a real investigation you would escalate it.

Troubleshooting and clean-up

• No /var/log/auth.log: Debian 12 and some minimal images do not install rsyslog. Use journalctl, or install rsyslog.
• Unit not found: the service is called ssh on Debian and Ubuntu but sshd on RHEL, Rocky and Fedora, where the file is /var/log/secure.
• Nothing logged: check that key-only authentication is not refusing passwords before they are tried; look for "Connection closed" lines instead.
• Too much noise on a cloud VM: internet-facing SSH receives constant guessing from bots. That is a good reason to allow SSH only from your own address.

Clean up by deleting testuser if you created it and keeping your summary file as evidence for your portfolio. Next steps: install fail2ban to block repeat offenders automatically, or forward the same logs to the Wazuh SIEM lab so that alerts appear without manual searching.