Triage and Containment of SSH Brute Force Attacks from Linux Logs
Practical techniques for parsing /var/log/auth.log, aggregating attacking subnets, and verifying whether key-only policies prevented breach.
1. Structure of Linux Authentication Logs
On Debian and Ubuntu systems, authentication activity is captured in /var/log/auth.log (or accessed via journalctl -u ssh.service). On RHEL and CentOS, it is stored in /var/log/secure.
Each entry records the timestamp, hostname, daemon name, PID, status (Failed/Accepted), target username, source IP, and source port.
2. Rapid Command-Line Parsing for Triage
When alerted to high connection failure rates, an analyst should immediately isolate the attacking IP addresses and the usernames targeted.
grep "Failed password" /var/log/auth.log | awk '{print $(NF-3)}' | sort | uniq -c | sort -nr | head -n 103. How to Prove No Breach Occurred
Management and stakeholders need to know: did they get in? To answer this definitively, search for successful logons from the attacking IP addresses.
grep "Accepted" /var/log/auth.log | grep -E "198.51.100.42|198.51.100.89"4. Hardening Strategies Beyond Password Disabling
Disabling password authentication (PasswordAuthentication no) in /etc/ssh/sshd_config is step one. To reduce log noise and scanning overhead, place SSH behind an IP allowlist, a WireGuard VPN tunnel, or change the default listening port.