Auditd & Journald: A Logging Baseline

Logs are only useful if they survive a reboot, survive a full disk, and survive an attacker. A default Linux install fails at least one of these. This baseline makes journald persistent and bounded, deploys the kernel audit framework to watch security-sensitive files, and ships everything off-host so it cannot be quietly erased. It is the foundation the rest of the series builds on.

Make journald persistent and bounded

On many distributions the journal lives in /run and evaporates on reboot. Make it persistent and cap its size so it never fills the disk. Edit /etc/systemd/journald.conf:

[Journal]
Storage=persistent
Compress=yes
SystemMaxUse=2G
SystemKeepFree=1G
MaxRetentionSec=1month
ForwardToSyslog=yes

Storage=persistent writes to /var/log/journal, SystemMaxUse is the hard ceiling, and ForwardToSyslog=yes lets rsyslog pick events up for forwarding. Apply and inspect:

sudo mkdir -p /var/log/journal
sudo systemctl restart systemd-journald
journalctl --disk-usage
journalctl -p err -b      # all errors since the current boot

Install and configure auditd

The kernel audit subsystem records syscalls and file access that journald alone does not. Install and enable the daemon:

sudo apt install auditd audispd-plugins   # Debian/Ubuntu
sudo systemctl enable --now auditd

Set sane retention in /etc/audit/auditd.conf so audit data is never silently dropped:

max_log_file = 50
num_logs = 10
max_log_file_action = keep_logs
space_left = 500
space_left_action = email
admin_space_left_action = halt

max_log_file_action = keep_logs stops auditd from rotating over old evidence, and the space_left actions warn an admin before the partition is exhausted.

Watch the files that matter

Audit rules live in /etc/audit/rules.d/audit.rules. Watch identity files, escalation paths, and the clock — the things an attacker touches. Create /etc/audit/rules.d/hardening.rules:

## Identity and authentication
-w /etc/passwd -p wa -k identity
-w /etc/shadow -p wa -k identity
-w /etc/group -p wa -k identity
-w /etc/sudoers -p wa -k privesc
-w /etc/sudoers.d/ -p wa -k privesc

## Remote access configuration
-w /etc/ssh/sshd_config -p wa -k sshd

## Privilege escalation
-a always,exit -F arch=b64 -S execve -F euid=0 -F auid>=1000 -F auid!=4294967295 -k privesc

## Time changes
-a always,exit -F arch=b64 -S adjtimex,settimeofday,clock_settime -k time-change
-w /etc/localtime -p wa -k time-change

## Lock the configuration until reboot
-e 2

Load the rules and confirm they are active:

sudo augenrules --load
sudo auditctl -l

The trailing -e 2 enables immutable mode. Keep it last, since no rules can be added once it is set. Query collected events by their key:

sudo ausearch -k identity --start today
sudo ausearch -k privesc -i
sudo aureport --auth --summary

Ship logs off-host

The audit log is itself a target: an attacker with root can edit or delete /var/log/audit/audit.log. Defeat this by forwarding events to a separate collector in real time. With ForwardToSyslog=yes already set, point rsyslog at a remote host in /etc/rsyslog.d/90-remote.conf:

*.* @@logcollector.internal:6514   # @@ = TCP; use TLS in production

sudo systemctl restart rsyslog

Now even if local logs are wiped, the collector retains the evidence. This pairs naturally with file-integrity and host monitoring covered in intrusion detection, and the audit trail feeds the reporting expected by compliance benchmarks.

Verify

journalctl --disk-usage                 # journal is bounded and persistent
sudo auditctl -s | grep enabled         # expect "enabled 2" (immutable)
sudo auditctl -l | wc -l                # rules loaded
sudo ausearch -k privesc -i | tail      # escalation events recorded
logger "audit-baseline test" && journalctl -n1 | grep test   # forwarding path works

If enabled reports 2, the journal is persistent, and your keys return events, the baseline holds. From here, tighten what auditd reports on with mandatory access control denials and correlate audit identities with accounts and privileges hygiene.