Linux Security Logs Complete Guide

Understanding Linux Security Logging

Linux powers the vast majority of cloud infrastructure, web servers, containers, and IoT devices worldwide. Securing these systems requires deep visibility into authentication events, process execution, privilege escalation, and system changes. Linux's logging infrastructure is powerful but fragmented — understanding its components is the first step toward building a robust security monitoring pipeline.

The Linux Logging Ecosystem

syslog / rsyslog

The traditional syslog protocol (RFC 5424) defines a standard for log message transport. rsyslog is the most common implementation on modern distributions, offering high performance, TCP/TLS support, and output to databases or remote collectors. It reads messages from the kernel, daemons, and user-space applications, writing them to files in /var/log/ by default.

systemd-journald

journald is the logging subsystem for systems running systemd (the majority of modern Linux distros). It collects binary journal data enriched with metadata (PID, UID, boot ID, priority, kernel facility). Unlike rsyslog, its structured format enables field-level filtering. Use journalctl to query:

# Show all SSH authentication failures
journalctl _SYSTEMD_UNIT=sshd.service PRIORITY=3

# Show kernel messages for the current boot
journalctl -k -b -0

Many deployments run both journald and rsyslog in parallel — journald for local querying and structured data, rsyslog for centralized forwarding.

auth.log vs. secure vs. messages

Log file locations vary by distribution. Here is a quick reference:

• /var/log/auth.log (Debian/Ubuntu) — Authentication events: SSH logins, sudo, PAM module activity, useradd/del changes
• /var/log/secure (RHEL/CentOS/Fedora) — Same role as auth.log but with a different name. Also logs xinetd, tcpwrappers, and su attempts
• /var/log/messages (RHEL, sometimes Debian) — General system messages: kernel activity, service starts/stops, hardware changes
• /var/log/syslog (Debian/Ubuntu) — The all-purpose log for most daemon and kernel messages not in auth.log

Key Authentication Events

SSH Authentication

SSH logins generate detailed logs. A successful login looks like:

Mar 15 08:22:13 web-01 sshd[12345]: Accepted publickey for ubuntu from 203.0.113.50 port 51234 ssh2: RSA SHA256:abc123...
Mar 15 08:22:13 web-01 sshd[12345]: pam_unix(sshd:session): session opened for user ubuntu by (uid=0)

Monitor for:

• Failed password messages with high frequency — a brute-force indicator. Example: Failed password for root from 10.0.0.99 port 44567 ssh2
• Accepted messages for unexpected source IPs or non-standard user accounts
• Invalid user messages indicating scanning or username enumeration
• Connection closed by authenticating user — often indicates a dropped connection mid-attack

Sudo Usage

Every sudo invocation is logged. The PAM session module writes entries like:

Mar 15 09:45:01 web-01 sudo:   ubuntu : TTY=pts/0 ; PWD=/home/ubuntu ; USER=root ; COMMAND=/bin/bash

• Monitor TTY-less sudo (Cron, scripts) — often indicates automated privilege escalation
• Track sudo failures (incorrect password attempt) — a user may be trying to brute-force their own sudo or another user guessed their password
• Look for sudo -u (run as another user) — may indicate lateral movement or privilege abuse

User and Group Management

Commands like useradd, usermod, groupadd, and passwd generate logs in auth.log or secure:

Mar 15 10:00:00 web-01 useradd[23456]: new user: name=backup, UID=1002, GID=1002, home=/home/backup, shell=/bin/bash

• Alert on any new user creation that is not tied to a change management ticket
• Monitor usermod -aG sudo or usermod -aG root — unauthorized privilege group additions

auditd: Deep System Auditing

auditd (Linux Audit Daemon) provides granular, pre-configured monitoring of system calls, file access, and security events. It is the closest Linux equivalent to Windows Security Event Logging.

Audit rules can target specific syscalls, file paths, or executables:

# Monitor /etc/passwd for changes
-w /etc/passwd -p wa -k passwd_changes

# Monitor /etc/shadow reads
-w /etc/shadow -p rwa -k shadow_access

# Track all execution of /bin/bash
-a always,exit -S execve -F path=/bin/bash -k shell_execution

# Monitor privilege escalation via su/sudo
-w /usr/bin/su -p x -k priv_esc

Audit logs are written to /var/log/audit/audit.log by default. Each event is a key-value record containing the syscall, UID, success/failure, timestamp, and a type field (e.g., SYSCALL, PATH, CWD, PROCTITLE).

Common Detection Scenarios

Brute-Force Attack

Correlate auth.log with network flow data. A single source IP generating 50+ Failed password events in under 60 seconds is a brute force. Shieldlix triggers on threshold-based rules and can automatically block the source IP via firewall integration.

Privilege Escalation

Chain of events to detect: (1) user logs in via SSH, (2) user runs sudo -i within seconds, (3) user executes useradd -G sudo attacker. Each step is logged; correlating all three indicates a likely compromise.

Persistence via Cron

Monitor cron log (/var/log/cron on RHEL, journald unit crond.service on modern systems) for new entries added by non-root users. Attackers commonly use crontab -e or write to /etc/cron.d/ after privilege escalation.

Centralizing Linux Logs with Shieldlix

Shieldlix Security Monitoring provides a lightweight agent that collects logs from multiple Linux sources — rsyslog forwarding, journald export, auditd events, and custom text logs — into a single correlated stream. Built-in parsing normalizes auth events, sudo usage, auditd rules, and syslog messages into structured fields, enabling search, alerting, and dashboarding across your entire Linux fleet. Stop ssh-ing into individual servers to check logs — centralize with Shieldlix.