Overview

Hardening reduces the chance of a compromise; logging and auditing tell you when one happened anyway. No control is perfect, and the difference between a minor incident and a catastrophe is often how quickly you notice and how much you can reconstruct afterward. A host with no usable logs is a host where an attacker operates in the dark and you have nothing to investigate. This group is about making sure the machine keeps an honest, queryable record of what it did and who did it.

The three pages here climb a ladder of intent. System logs record what services and the kernel report on their own. The audit subsystem records what you explicitly ask it to watch, at the syscall level, with tamper resistance. Intrusion detection turns those records (plus filesystem baselines) into alerts about compromise. Together they answer the three questions that follow any incident: what happened, when, and is the attacker still here.

The three layers of visibility

Each layer sees a different slice of the system, and they are complementary rather than redundant.

Layer	Records	Answers	Covered in
System logs	Service, auth, and kernel messages	What did the system report?	System Logs
Audit subsystem	Chosen syscalls and file access	Who touched this file or ran this command?	Auditd
Intrusion detection	Deviations from a known-good baseline	Has something changed that should not have?	Intrusion Detection

System logs are always on and cheap; they are your first stop for almost any question. The audit subsystem is deliberate and detailed; you point it at the handful of things that matter (privilege changes, access to /etc/shadow, execution of certain binaries) and it records them with attribution. Intrusion detection compares reality against a baseline and flags drift, catching the file an attacker replaced or the rootkit they installed.

Why attribution and integrity matter

Two properties separate security logging from ordinary application logging. The first is attribution: a log line is useful in an investigation only if it ties an action to a user, a process, and a time. The audit subsystem exists largely to provide this. The second is integrity: an attacker who reaches root will try to erase their tracks, so logs that live only on the compromised host are only as trustworthy as the host. This is why forwarding logs off the box (covered in System Logs) and tamper-evident file baselines (covered in Intrusion Detection) are not optional extras but the core of the discipline.

Trying it on the lab VM

Generate a little activity so the later pages have something real to query, then confirm the log stack is present.

sudo journalctl --disk-usage
systemctl is-active auditd 2>/dev/null || echo "auditd not yet installed"

Expected output:

Archived and active journals take up 48.0M in the file system.
auditd not yet installed

The journal is already collecting; auditd is installed on the Auditd page. This confirms the baseline: one layer on by default, the others to be added.

A note on cost and noise

Visibility is not free, and the failure mode of logging is not too little data but too much of the wrong kind. Verbose audit rules can generate thousands of events per second and fill a disk; a file integrity baseline that flags every legitimate update becomes noise you learn to ignore. The discipline is to collect what you will actually use in an investigation and tune out the rest. Each page in this group makes a specific tradeoff: system logs are cheap and broad, the audit subsystem is targeted and detailed, and intrusion detection compares against a baseline you must keep current. Deciding what matters before an incident is what keeps the signal readable during one.

Practical Guidance

1. Treat the three layers as complementary: reach for system logs first, add auditd for attribution on sensitive actions, and use baselining to catch silent change.
2. Make logs persistent and get a copy off the host early, since an attacker with root can rewrite anything stored locally.
3. Decide what “normal” looks like before an incident by baselining a clean host, so deviations are meaningful later.
4. Prioritize attribution: a log that cannot tie an action to a user, process, and time is far less useful in an investigation.
5. Generate known activity on the lab VM (log in, edit a sensitive file) so you can confirm each layer actually records it before you rely on it.
6. Review what you collect periodically, since logs you never read and rules that never fire give a false sense of coverage.