Follow auditd writes to /var/log/audit/audit.log, readable only by root. The quickest export of a time window in the original format is:
sudo ausearch --raw -ts yesterday > web-03_audit.log
If /var/log/audit doesn’t exist, auditd isn’t installed. That’s the default on Debian and Ubuntu. The kernel’s audit events then go to the journal, where journalctl _TRANSPORT=audit finds them.
auditd is Linux’s answer to “who ran what, and touched which file”: process execution, file access, permission changes and account changes, down to the syscall. Prime Core has 1350 detection rules for auditd data, mapped to 440 MITRE ATT&CK techniques. Among them: malicious shell use (T1059.004), planted SSH keys (T1098.004) and permission changes on sensitive files (T1222.002).
Before you start
Is it running, and what is it recording?
systemctl is-active auditd
sudo auditctl -l
Red Hat-family systems install auditd by default; Debian and Ubuntu need the auditd package. If auditctl -l prints No rules, you still get a baseline of logins, authentication and SELinux denials. You won’t get command execution or file-access records, though, because nobody asked for them.
Root only. /var/log/audit is locked down tightly, so plan on sudo.
Rotation is auditd’s own. auditd rotates its log itself, based on max_log_file and num_logs in /etc/audit/auditd.conf, into audit.log.1, audit.log.2, and so on. Older history sits in those files.
The format takes getting used to. One event is often several lines (SYSCALL, EXECVE, CWD, PATH, PROCTITLE) sharing the same msg=audit(<epoch>:<serial>) stamp. Values with spaces are hex-encoded. That’s normal.
Step 1: Export with ausearch
ausearch filters by time, record type or rule key, and –raw keeps the original format:
# a day, raw
sudo ausearch --raw -ts yesterday -te today > web-03_audit.log
The keywords today, yesterday, this-week and recent (last ten minutes) save you from date formats. Explicit dates follow your locale, 10/19/2026 00:00:00 in en_US, which is where most “no matches” surprises come from.
For an upload, keep –raw: the original records carry more than the interpreted view.
If you’d rather just take everything, concatenate the files oldest-first:
sudo cat $(ls -tr /var/log/audit/audit.log*) > web-03_audit_all.log
Step 2 (no auditd): Get audit events from the journal
Without auditd, the kernel’s audit records still reach journald:
sudo journalctl _TRANSPORT=audit --since yesterday -o json --no-pager > web-03_audit.jsonl
With no rules loaded, expect mostly logins and SELinux or AppArmor messages, but it’s better than nothing.
Upload, sanitize and review in LogTotal
[PROOF: confirm LogTotal parses raw auditd format. If it doesn’t yet, publish this guide with the journal JSON route only, or hold it until support lands.]
- Upload. Open logtotal.com and drop in the file.
- Sanitize. [PROOF: what gets masked in auditd records: usernames, hostnames, IPs, paths]. Look it over before you continue.
- Review.
When it goes wrong
| Symptom | Likely cause | Fix |
|---|---|---|
| /var/log/audit doesn’t exist | auditd isn’t installed | Use the journal route (Step 2) |
| Permission denied | Not root | sudo |
| Logins only, no commands | No exec rules loaded | Expected; add rules for the future |
| <no matches> from ausearch | Date format doesn’t match your locale | Use today, yesterday, this-week |
| “backlog limit exceeded” in kernel messages | The kernel dropped audit events under load | Treat the log as having gaps; raise backlog_limit |
FAQ
Should I turn auditd on now?
Yes, for next time. Rules decide everything, so start from a known rule set rather than writing your own from scratch. The audit package ships sample rules, and well-maintained community sets exist.
auditd or the journal: which is the real record?
With auditd running, /var/log/audit/audit.log is the complete one. The journal may hold a partial copy, depending on configuration.
