Linux-Logmanipulation erkennen: auditd abschalten, Audit-Regeln entfernen und Logs leeren

Linux-Logmanipulation erkennen heißt, den Moment zu sehen, in dem ein Angreifer der Verteidigung die Augen schließt. Nach dem ersten Zugriff über eine Unix-Shell und spätestens vor dem Einrichten einer Persistenz über Cron und systemd oder die Shell-Konfiguration sorgt er dafür, dass davon möglichst wenig im Log steht. Dieser Beitrag aus der Serie "Angriff erkennen" zeigt aus Verteidigersicht, welche Wege es gibt, welche Spuren jeder davon noch hinterlässt und warum die wichtigste Erkennung nicht auf dem betroffenen Host läuft, sondern im SIEM. Er ist das Linux-Gegenstück zu Event-Log-Löschung und Audit-Logging abschalten unter Windows; die Telemetrie-Grundlagen stehen unter Linux-Sicherheitsmonitoring.

Was der Angreifer tut

Sechs Wege, die sich in Wirkung und Spur unterscheiden. Bewusst auf der Ebene des Prinzips, nicht als Anleitung:

• Audit-Regeln entfernen oder reduzieren. Mit auditctl werden alle Regeln gelöscht (-D), einzelne entfernt (-d) oder das Kernel-Auditing abgeschaltet (-e 0). auditd läuft weiter, protokolliert aber nichts mehr oder nur noch das, was dem Angreifer egal ist - die leiseste Variante, weil der Dienst scheinbar gesund bleibt.
• auditd stoppen oder deaktivieren. Über das service-Skript oder systemctl wird der Daemon beendet, deaktiviert oder maskiert. Der Kernel erzeugt Audit-Ereignisse zwar weiter, aber niemand schreibt sie mehr strukturiert weg.
• journald stoppen oder entwerten. journald lässt sich stoppen oder über journald.conf so einstellen, dass es nichts mehr speichert oder nur noch flüchtig im RAM hält. Damit verschwinden Dienst-, Anmelde- und sudo-Meldungen - und auf vielen Systemen auch die Ausgabe von Sysmon for Linux, die über den Syslog-Pfad läuft.
• Journal bereinigen. journalctl mit --vacuum-Parametern (nach Zeit, Größe oder Dateianzahl) entfernt archivierte Journal-Dateien - ein legitimes Wartungswerkzeug, das als Löschwerkzeug dient.
• Logdateien löschen oder leeren. Klassische Dateien unter /var/log (auth.log oder secure, syslog oder messages, wtmp, btmp, Webserver-Logs) werden entfernt, mit truncate oder einer Shell-Umleitung auf null gesetzt oder mit shred überschrieben.
• Konfiguration dauerhaft verändern. Dateien unter /etc/audit/ (auditd.conf, rules.d) oder /etc/systemd/journald.conf werden so geändert, dass auch nach dem nächsten Neustart weniger entsteht - weniger Regeln, kleineres Journal, keine Weiterleitung. Das ist die nachhaltigste und unauffälligste Variante.

Gemeinsam ist allen Wegen: Sie brauchen Root, sie hinterlassen bis zum Moment der Wirkung noch Spuren, und sie können das, was bereits das System verlassen hat, nicht mehr zurückholen. An diesen drei Punkten setzt die Erkennung an.

Das Detection-Paradoxon

Eine Regel, die auf dem Host "auditd wurde gestoppt" aus dem Audit-Log liest, hat ein Problem: Das Audit-Log endet genau dort. Dasselbe gilt für journald, das sein eigenes Stoppen höchstens noch als letzte Zeile festhält, und für Sysmon for Linux, dessen Ereignisse über den lokalen Syslog-Pfad laufen und mit journald oder rsyslog mit verstummen. Die lokale Quelle kann ihr Ende ankündigen, aber nicht bezeugen, was danach geschah. Daraus folgt die Architektur der Erkennung: Erstens den letzten Datensatz ernst nehmen - CONFIG_CHANGE und DAEMON_END im Audit-Log, die Stopp-Meldung der Unit im Journal, der auditctl- oder systemctl-Aufruf in der Prozess-Telemetrie. Zweitens eine Sensorik betreiben, die nicht an derselben Stelle hängt - eine EDR mit eigenem Transportweg oder Sysmon for Linux mit direkter Weiterleitung statt über Syslog. Drittens, und das ist der entscheidende Punkt, die Ereignisse so früh wie möglich vom Host wegschaffen und im SIEM das Ausbleiben selbst zur Erkennung machen: Ein Host, der bis 14:03 Uhr jede Minute Audit-Ereignisse geliefert hat und seitdem schweigt, während seine Syslog-Zeilen weiterkommen, hat nicht die Netzverbindung verloren - er hat sein Audit-System verloren.

Welche Logquellen die Technik zeigt

• auditd - bis zum letzten Datensatz. Jede Regeländerung erzeugt einen CONFIG_CHANGE-Datensatz mit Operation (add_rule, remove_rule), Schlüssel und auid; das Abschalten per -e 0 erscheint als CONFIG_CHANGE mit audit_enabled=0, das Beenden des Daemons als DAEMON_END. Watches auf die eigene Konfiguration und die Werkzeuge (-w /etc/audit/ -p wa -k auditconfig, -w /sbin/auditctl -p x -k audittools, -w /sbin/auditd -p x -k audittools, -w /usr/sbin/augenrules -p x -k audittools) zeigen Änderungen und Aufrufe, ein Watch auf das Log-Verzeichnis (-w /var/log/ -p wa -k logtamper) jede Schreib-, Lösch- und Leerungsoperation samt exe und auid - der Watch auf /var/log ist laut, weil Dienste dort ständig schreiben, und braucht die Filterung auf untypische Schreiber. Wichtig: Wird auditd mit -e 2 gesperrt, lehnt der Kernel jede weitere Änderung bis zum Neustart ab und protokolliert den Versuch - das ist die einzige Einstellung, bei der auditd seine Manipulation nicht nur meldet, sondern verhindert. Auf systemd-Distributionen verweigert systemctl das direkte Stoppen von auditd (RefuseManualStop); der Angreifer braucht das service-Skript, was die Prozesssicht sichtbar macht. Ohne laufenden Daemon landen die Kernel-Audit-Meldungen je nach Konfiguration unstrukturiert im Kernel-Log (dmesg beziehungsweise Journal) - kein Ersatz, aber ein forensischer Rest.
• journald - Dienstereignisse und eigene Grenzen. systemd meldet das Stoppen, Deaktivieren und Maskieren von Units (Stopping, Stopped, Removed symlink) ins Journal, solange es läuft; Änderungen an journald.conf und das Ergebnis eines Vacuum (Deleted archived journal) stehen ebenfalls dort. Das Journal protokolliert damit die Manipulation seiner Nachbarn gut und seine eigene nur bis zur letzten Zeile. Forward Secure Sealing (journalctl --setup-keys, --verify) macht nachträgliche Änderungen an versiegelten Einträgen erkennbar, verhindert aber weder das Löschen ganzer Dateien noch das Stoppen des Dienstes - ein Integritäts-, kein Verfügbarkeitsschutz.
• Sysmon for Linux und EDR - die unabhängige Sicht. Event 1 zeigt auditctl, systemctl, service, journalctl, rm, truncate und shred mit Kommandozeile, Konto und Elternprozess, Event 11 neu angelegte oder überschriebene Dateien unter /var/log, Event 23 (FileDelete, sofern konfiguriert) gelöschte Logdateien. Sysmon for Linux arbeitet über eBPF und ist vom Audit-System unabhängig; es sieht das Stoppen von auditd also weiterhin. Seine Ausgabe geht aber standardmäßig über den Syslog-Pfad - wer journald oder rsyslog stoppt, nimmt auch Sysmon die lokale Stimme. Eine EDR mit eigenem Agenten und eigenem Transport zum Hersteller ist die robusteste zweite Sensorik, solange der Angreifer nicht auch sie stoppt - was dann wiederum deren Backend als Agent-Ausfall meldet.
• Remote Logging und SIEM - der Kontrollpunkt. Was den Host verlassen hat, bevor der Angreifer eingriff, ist gerettet: per rsyslog oder syslog-ng (TLS, bei RELP mit Warteschlange), per systemd-journal-upload an einen journal-remote, per audisp-remote aus dem Audit-Dispatcher oder über den Agenten des SIEM. Das SIEM hält außerdem die Information, die kein Host liefern kann: wann das letzte Ereignis kam. Eine Telemetrie-Ausfall-Erkennung pro Host und Quelle (Audit-Strom, Syslog-Strom, EDR-Heartbeat) macht aus dem Schweigen ein Signal - differenziert nach "alles weg" (Host offline, Netz) und "nur der Audit-Strom weg" (Manipulation). Die Grundlagen zur zentralen Aufbewahrung stehen unter Log-Management und Aufbewahrung.

Das Muster im Log

Die einzelnen Kommandos sind nur der Anfang, denn jedes davon hat einen legitimen Zwilling: Logrotation löscht und legt neu an, Wartung stoppt Dienste, Speicherplatz-Bereinigung ruft vacuum, Konfigurationsmanagement schreibt nach /etc/audit/. Belastbar wird der Fall erst durch die Abfolge und den Kontext. Vier Muster tragen die Erkennung: Ein Logging-Dienst war aktiv und ist plötzlich gestoppt, ohne Paket-Upgrade und ohne Change Window. Ein Host, der sonst gleichmäßig Audit-Ereignisse liefert, verstummt in diesem einen Strom, während andere Ströme weiterlaufen. Audit-Regeln werden entfernt oder auf einen Rest reduziert, erkennbar am CONFIG_CHANGE-Datensatz und daran, dass der Regelbestand (auditctl -l) nicht mehr zur Baseline passt. Und Logdateien werden kurz nach verdächtiger Aktivität geleert - eine neue Shell aus einem Dienst, eine Rechteausweitung, ein neuer Cron-Eintrag, und zwanzig Minuten später ist auth.log leer. Der Schreiber entscheidet mit: logrotate aus einem Timer ist Normalbetrieb, eine interaktive Root-Shell mit einer Umleitung auf eine Logdatei ist es nicht. Je mehr dieser Glieder zusammenkommen, desto klarer der Fall; die Telemetrie-Lücke ist dabei das Glied, das der Angreifer nicht entfernen kann, weil es nicht auf seinem Host entsteht.

Fünf Sigma-Regeln und die Lücken-Erkennung

Die Regeln sind mit sigma-cli validiert und nutzen die Linux-Logquellen process_creation, file_event und file_delete. Sie decken das ab, was eine Prozess- oder Dateiquelle tatsächlich trägt: den auditctl-Eingriff, das Stoppen eines Logging-Dienstes, das Bereinigen und Leeren von Logs, das Löschen von Logdateien und die Konfigurationsänderung. Das wichtigste Signal - "von diesem Host kommt nichts mehr" - ist keine Sigma-Einzelregel und wird hier bewusst nicht in eine gepresst; es folgt als SIEM-Logik im Anschluss. Die Übersetzung ins SIEM steht unter Sigma-Regeln. sigma-cli-validiert heißt dabei: syntaktisch und gegen das verwendete ATT&CK-Dataset geprüft, nicht produktiv getestet. Image, CommandLine, ParentImage und TargetFilename sind die portable Sigma-Abstraktion, keine nativen auditd-Felder - Sysmon for Linux liefert sie direkt, bei auditd muss der Mapper sie aus exe, a0 bis aN, ppid und den PATH-Datensätzen aufbauen; ParentImage braucht dazu eine Prozessbaum-Anreicherung, und file_delete setzt eine Quelle voraus, die Löschungen überhaupt liefert (Sysmon for Linux Event 23, EDR oder ein auditd-Watch, dessen Datensätze auf diese Kategorie gemappt werden). Die Ausnahmen in den Regeln - Paketmanager, logrotate, journald, systemd-tmpfiles - greifen nur, wenn die Pipeline das schreibende oder löschende Programm (Image) im Dateiereignis und in Regel 3 den Elternprozess (ParentImage) im Prozessereignis mitliefert. Fehlt das Feld, fällt der Filter weg: Die Regel wird dann lauter, nicht blinder, und die Baseline muss im SIEM nachgezogen werden. Weitere Techniken dieser Taktik führt das Lexikon nach Taktik unter Defense Impairment.

1. Audit-Regeln per auditctl entfernt oder Auditing abgeschaltet (T1685.004). Der direkte Eingriff ins Audit-System, auf level: high - trägt nur mit einer vom Audit-System unabhängigen Prozessquelle oder dem letzten Datensatz davor.

title: Audit-Regeln per auditctl entfernt oder Auditing abgeschaltet
id: fadf04fb-837d-49db-b0ff-1a18b3a880d0
status: experimental
description: |
  Erkennt auditctl beim Entfernen aller Audit-Regeln (-D), beim Entfernen einzelner
  Regeln (-d) oder beim Abschalten des Kernel-Auditings (-e 0). Damit verliert das
  Audit-System seine Sicht, bevor weitere Aktivitaet folgt (Disable or Modify Linux
  Audit System Log). Die Regel traegt nur mit einer Prozessquelle, die vom
  Audit-System unabhaengig ist (Sysmon for Linux, EDR), oder mit dem
  Audit-Datensatz, der noch vor der Aenderung entsteht - auditd selbst
  protokolliert den Aufruf nur, solange es laeuft. Das Neuladen von Regeln
  (auditctl -R, augenrules --load) ist kein Treffer.
references:
  - https://attack.mitre.org/techniques/T1685/004/
author: blue-team.net
date: 2026-10-09
tags:
  - attack.defense-impairment
  - attack.t1685.004
logsource:
  product: linux
  category: process_creation
detection:
  sel_img:
    Image|endswith: '/auditctl'
  sel_cmd:
    CommandLine|contains:
      - ' -D'
      - ' -d '
      - ' -e 0'
      - ' -e0'
  condition: sel_img and sel_cmd
falsepositives:
  - Konfigurationsmanagement und Admins, die Regelsaetze neu aufbauen (-D vor dem Laden) - bekannte Skripte, Konten und Wartungsfenster als Baseline ausnehmen
level: high

2. Logging-Dienst gestoppt oder deaktiviert (T1685, T1685.004). auditd, journald, rsyslog, syslog-ng oder Sysmon per systemctl oder service beendet, auf level: high.

title: Logging-Dienst per systemctl oder service gestoppt oder deaktiviert
id: 739fde1f-99b5-400c-94c9-925830dd4f32
status: experimental
description: |
  Erkennt das Stoppen, Deaktivieren oder Maskieren eines Logging- oder
  Telemetriedienstes (auditd, systemd-journald, rsyslog, syslog-ng, Sysmon for
  Linux) ueber systemctl oder das service-Skript. Damit verliert die Erkennung ihre
  lokale Quelle (Disable or Modify Tools; fuer auditd Disable or Modify Linux Audit
  System Log). Die Regel traegt nur, wenn die Prozessquelle den Aufruf noch sieht -
  eine vom gestoppten Dienst unabhaengige Sensorik oder der Datensatz unmittelbar
  vor dem Stopp. Das Ausbleiben weiterer Ereignisse danach ist das eigentliche
  Signal und gehoert in eine Telemetrie-Ausfall-Erkennung im SIEM.
references:
  - https://attack.mitre.org/techniques/T1685/
  - https://attack.mitre.org/techniques/T1685/004/
author: blue-team.net
date: 2026-10-09
tags:
  - attack.defense-impairment
  - attack.t1685
  - attack.t1685.004
logsource:
  product: linux
  category: process_creation
detection:
  sel_img:
    Image|endswith:
      - '/systemctl'
      - '/service'
  sel_action:
    CommandLine|contains:
      - 'stop'
      - 'disable'
      - 'mask'
      - 'kill'
  sel_unit:
    CommandLine|contains:
      - 'auditd'
      - 'systemd-journald'
      - 'rsyslog'
      - 'syslog-ng'
      - 'sysmon'
  condition: sel_img and sel_action and sel_unit
falsepositives:
  - Wartung, Paket-Upgrades und Neustarts der Logging-Dienste - Wartungsfenster, Paketmanager als Elternprozess und bekannte Admin-Konten als Baseline ausnehmen
level: high

3. Journal bereinigt oder Logdateien geleert (T1685.006). vacuum, rm, truncate, shred und die Shell-Umleitung auf /var/log, auf level: medium, weil Wartung dasselbe tut.

title: Journal bereinigt oder Logdateien unter /var/log geleert
id: 39efeba3-097e-48ec-af56-85735ac2636e
status: experimental
description: |
  Erkennt journalctl mit --vacuum-Parametern sowie rm, truncate oder shred mit
  einem Ziel unter /var/log, dazu eine Shell-Kommandozeile, die per Umleitung in
  eine Datei unter /var/log schreibt. Das sind die ueblichen Wege, lokale Spuren zu
  entfernen (Clear Linux or Mac System Logs). Dieselben Befehle nutzen
  Logrotation, Wartung und Speicherplatz-Bereinigung legitim, deshalb traegt der
  Treffer erst mit Konto, Elternprozess (interaktive Shell statt logrotate oder
  Timer) und zeitlicher Naehe zu verdaechtiger Aktivitaet Gewicht. Die Umleitung
  erscheint nur, wenn die Shell mit der Kommandozeile gestartet wird (bash -c);
  interaktiv getippt bleibt sie fuer die Prozessquelle unsichtbar - dafuer braucht
  es den auditd-Watch auf /var/log. Die Ausnahme fuer logrotate und systemd-tmpfiles
  setzt voraus, dass die Quelle den Elternprozess (ParentImage) liefert; ohne dieses
  Feld faellt der Filter weg und die Regel meldet auch die Rotation.
references:
  - https://attack.mitre.org/techniques/T1685/006/
author: blue-team.net
date: 2026-10-09
tags:
  - attack.defense-impairment
  - attack.t1685.006
logsource:
  product: linux
  category: process_creation
detection:
  sel_vacuum:
    Image|endswith: '/journalctl'
    CommandLine|contains: '--vacuum'
  sel_tools:
    Image|endswith:
      - '/rm'
      - '/truncate'
      - '/shred'
    CommandLine|contains: '/var/log/'
  sel_redirect:
    Image|endswith:
      - '/bash'
      - '/sh'
      - '/dash'
      - '/zsh'
    CommandLine|contains:
      - '> /var/log/'
      - '>/var/log/'
  filter_rotate:
    ParentImage|endswith:
      - '/logrotate'
      - '/systemd-tmpfiles'
  condition: (sel_vacuum or sel_tools or sel_redirect) and not filter_rotate
falsepositives:
  - Logrotation, Speicherplatz-Bereinigung und Wartungsskripte - bekannte Skripte, Timer und Konten als Baseline ausnehmen
  - Admins, die bei der Fehlersuche Logdateien leeren - mit Change Window abgleichen
level: medium

4. Logdatei außerhalb der Logrotation gelöscht (T1685.006). Die Dateisicht für Löschungen ohne sichtbare Kommandozeile, auf level: medium; braucht Sysmon Event 23, eine EDR oder einen auditd-Watch mit Mapping auf file_delete.

title: Logdatei unter /var/log ausserhalb der Logrotation geloescht
id: 2ca665e9-1809-4c1b-9efb-f7a3759622d0
status: experimental
description: |
  Erkennt das Loeschen einer Datei unter /var/log (inklusive Journal-Dateien) durch
  einen anderen Prozess als die Dienste, die Logs regulaer rotieren und bereinigen
  (logrotate, systemd-journald, systemd-tmpfiles, rsyslog, journalctl). Die
  Dateisicht faengt auch Loeschungen, die ohne sichtbare Kommandozeile laufen, etwa
  aus einem Skript oder einem kompilierten Werkzeug (Clear Linux or Mac System
  Logs). Setzt eine Quelle voraus, die Datei-Loeschungen liefert - Sysmon for Linux
  Event 23, eine EDR oder ein auditd-Watch mit Loeschrecht (-p wa), gemappt auf die
  Sigma-Kategorie file_delete. Die Ausnahmen fuer Rotation und Paketmanager greifen
  nur, wenn das Ereignis das loeschende Programm (Image) nennt. Das Loeschen allein
  ist ein Pruefsignal; Konto, Zeitpunkt und vorangehende Aktivitaet entscheiden.
references:
  - https://attack.mitre.org/techniques/T1685/006/
author: blue-team.net
date: 2026-10-09
tags:
  - attack.defense-impairment
  - attack.t1685.006
logsource:
  product: linux
  category: file_delete
detection:
  sel_path:
    TargetFilename|startswith: '/var/log/'
  filter_rotation:
    Image|endswith:
      - '/logrotate'
      - '/systemd-journald'
      - '/systemd-tmpfiles'
      - '/journalctl'
      - '/rsyslogd'
      - '/syslog-ng'
  filter_pkg:
    Image|endswith:
      - '/dpkg'
      - '/rpm'
      - '/apt'
      - '/apt-get'
      - '/dnf'
      - '/yum'
  condition: sel_path and not filter_rotation and not filter_pkg
falsepositives:
  - Eigene Rotations- und Bereinigungsskripte, Paketdeinstallationen und Anwendungen, die ihre Logs selbst rotieren (Webserver, Datenbanken) - bekannte Prozesse als Baseline ausnehmen
level: medium

5. Konfiguration von auditd oder journald geändert (T1685.004, T1685). Die nachhaltige Variante, auf level: high, weil diese Dateien sich außerhalb von Paketen und Konfigurationsmanagement nicht ändern.

title: Konfiguration von auditd oder journald geaendert
id: 74312fbb-026f-4c4b-b675-30670a620021
status: experimental
description: |
  Erkennt Schreibzugriffe auf die Konfiguration des Audit-Systems (/etc/audit/,
  inklusive rules.d und auditd.conf) und von journald (/etc/systemd/journald.conf
  und journald.conf.d/) durch einen anderen Prozess als den Paketmanager. Eine
  geaenderte Konfiguration reduziert das Logging dauerhaft, auch ueber Neustarts
  hinweg - etwa durch entfernte Regeln, ein kleineres Journal oder abgeschaltete
  Speicherung (Disable or Modify Linux Audit System Log, Disable or Modify Tools).
  Diese Dateien aendern sich ausserhalb von Paketinstallationen und
  Konfigurationsmanagement praktisch nie. Der auditd-Watch auf /etc/audit/ sieht
  die Aenderung nur, solange auditd laeuft und die Regel noch geladen ist. Die
  Paketmanager-Ausnahme greift nur, wenn das Dateiereignis das schreibende Programm
  (Image) nennt - Sysmon for Linux Event 11 tut das, bei auditd liefert es das Feld
  exe des SYSCALL-Datensatzes.
references:
  - https://attack.mitre.org/techniques/T1685/004/
  - https://attack.mitre.org/techniques/T1685/
author: blue-team.net
date: 2026-10-09
tags:
  - attack.defense-impairment
  - attack.t1685.004
  - attack.t1685
logsource:
  product: linux
  category: file_event
detection:
  sel_path:
    TargetFilename|startswith:
      - '/etc/audit/'
      - '/etc/systemd/journald.conf'
  filter_pkg:
    Image|endswith:
      - '/dpkg'
      - '/rpm'
      - '/apt'
      - '/apt-get'
      - '/dnf'
      - '/yum'
      - '/zypper'
  condition: sel_path and not filter_pkg
falsepositives:
  - Konfigurationsmanagement (Ansible, Puppet, Chef) und geplante Aenderungen am Regelsatz - Wartungsfenster und bekannte Prozesse als Baseline ausnehmen
  - augenrules beim Zusammenfuehren der rules.d-Dateien im Rahmen einer geplanten Aenderung
level: high

Die Lücken-Erkennung im SIEM (keine Sigma-Regel). Pro Host und pro Quelle den Zeitstempel des letzten Ereignisses führen und alarmieren, wenn ein Strom länger als sein übliches Intervall schweigt - für Audit-Ereignisse auf einem aktiven Server sind das Minuten, nicht Stunden. Drei Ausprägungen trennen die Fälle: Alle Ströme eines Hosts enden gleichzeitig (Host aus, Netz weg, Agent gestoppt - ein Betriebsfall, der trotzdem geprüft gehört), nur der Audit-Strom endet, während Syslog und EDR-Heartbeat weiterlaufen (Audit-System manipuliert), oder der Audit-Strom läuft weiter, enthält aber nur noch die Hälfte der gewohnten Schlüssel (Regeln reduziert). Die Baseline dafür liefert das SIEM selbst: Ereignisse pro Host, Quelle und Schlüssel über die letzten Wochen. Jede verbreitete Plattform hat dafür einen Mechanismus (Heartbeat- und Data-Health-Regeln, "host not reporting"-Suchen, Agenten-Status) - die Regel ist trivial, die Pflege der Erwartungswerte ist die Arbeit.

Härtung

• Früh und verlässlich weiterleiten. rsyslog oder syslog-ng mit TLS und Warteschlange, audisp-remote für den Audit-Strom, systemd-journal-upload für das Journal, Sysmon for Linux nicht nur in die lokale Syslog-Datei, sondern direkt in den Weiterleitungspfad. Was in Sekunden beim Sammler ist, kann lokal gelöscht werden, ohne verloren zu sein.
• Zentral manipulationsgeschützt speichern. Auf dem Sammler und im SIEM gehören die Daten in einen Speicher, den die Absender-Hosts nicht ändern können - getrennte Zugangsdaten nur zum Schreiben, Aufbewahrung nach Richtlinie, bei Objektspeichern eine Sperre gegen Löschen innerhalb der Frist. Append-only-Attribute auf den lokalen Logdateien (chattr +a) erschweren das Leeren, sind aber für Root per chattr aufhebbar und stören die Logrotation - sie sind ein Stolperdraht, kein Schutz.
• Audit-Konfiguration sperren. -e 2 als letzte Regel macht den Regelsatz bis zum Neustart unveränderlich, und ein Neustart ist auf einem Server selbst ein Ereignis. Schreibrechte auf /etc/audit/ und /etc/systemd/journald.conf eng halten, Änderungen nur über Konfigurationsmanagement ausrollen und per FIM überwachen.
• Servicezustand und Telemetrie überwachen. Den Zustand von auditd, journald und dem Weiterleitungsagenten vom Monitoring prüfen lassen und im SIEM die Lücken-Erkennung pro Host und Quelle betreiben - das ist die Kontrolle, die der Angreifer vom Host aus nicht abschalten kann.
• Zweite, unabhängige Sensorik. Eine EDR mit eigenem Transportweg sieht das Stoppen der nativen Quellen weiter und meldet ihr eigenes Verstummen als Agent-Ausfall. Auf Systemen ohne EDR übernimmt Sysmon for Linux mit direkter Weiterleitung diese Rolle teilweise.

Der Test

Der Test soll den Blindspot zeigen, nicht nur eine Regel auslösen. Er läuft auf einer isolierten Lab-VM mit auditd (inklusive der Watches oben), Sysmon for Linux und einer funktionierenden Weiterleitung an ein Test-SIEM - und ohne -e 2, damit sich alles ohne Neustart zurücksetzen lässt:

1. Baseline. Mit auditctl -l den Regelbestand festhalten, eine überwachte Testdatei anfassen und prüfen, dass das Audit-Ereignis lokal (ausearch) und im SIEM ankommt. Den Zeitstempel des letzten Audit-Ereignisses im SIEM notieren.
2. Kontrollierter Eingriff. Mit auditctl -e 0 das Auditing abschalten. Erwartung lokal: ein CONFIG_CHANGE-Datensatz mit audit_enabled=0 als letzter Eintrag, dazu Sysmon Event 1 für den auditctl-Aufruf, Regel 1 greift. Dann die überwachte Testdatei erneut anfassen.
3. Der Blindspot. ausearch zeigt für den zweiten Zugriff nichts mehr - das ist der Punkt, den der Test demonstrieren soll. Prüfen, ob Sysmon for Linux (eBPF, unabhängig) den Zugriff trotzdem als Prozess- oder Dateiereignis sieht und ob er über die Weiterleitung im SIEM ankommt.
4. Die Lücke im SIEM. Nach dem Ausfall-Intervall muss die Lücken-Erkennung melden, dass der Audit-Strom dieses Hosts endet, während Syslog- und Sysmon-Ereignisse weiterkommen. Prüfen, dass die vor Schritt 2 gesendeten Ereignisse im SIEM unverändert vorhanden sind.
5. Zweiter Fall, Journal. Auf einer Kopie des Systems journalctl --vacuum-time=1s ausführen und prüfen, dass Regel 3 greift, das Journal die Bereinigung als letzte Meldung festhält und die zuvor per journal-upload oder Syslog weitergeleiteten Einträge im SIEM erhalten bleiben.
6. Wiederherstellung. auditctl -e 1, Regeln mit augenrules --load neu laden, auditctl -l gegen die Baseline aus Schritt 1 vergleichen, die Lücken-Erkennung muss den Host wieder als gesund führen. Breiter wird der Test mit den Linux-Fällen zu T1685 aus Atomic Red Team, die unter den älteren IDs T1562.012 und T1070.002 geführt sein können.

Fehlalarme und Tuning

• Logrotation. logrotate aus Cron oder Timer benennt um, legt neu an, komprimiert und löscht alte Dateien, journald rotiert und bereinigt nach seinen Grenzwerten. Diese Prozesse sind in den Regeln 3 und 4 ausgenommen; eigene Rotationsskripte gehören nachgetragen. Das Muster ist erkennbar: Rotation läuft zu festen Zeiten, mit festem Elternprozess, und trifft alle Dateien gleich - nicht eine einzelne auth.log um 03:17 Uhr.
• Wartung und Upgrades. Paket-Upgrades von auditd, systemd oder rsyslog starten die Dienste neu und schreiben Konfigurationsdateien. Der Paketmanager als Eltern- oder Schreibprozess und das Wartungsfenster sind die Baseline; ein Stopp ohne nachfolgenden Start ist auch im Wartungsfenster prüfwürdig.
• Admin-Fehlersuche und Disk-Space-Bereinigung. Ein Admin, der ein volles /var/log aufräumt oder ein Journal bereinigt, löst Regel 3 aus. Konto, Ticket und Change Window entscheiden; ein Alarm, der mit einem Change zusammenfällt, wird dokumentiert, nicht unterdrückt.
• Geplante Änderungen am Regelsatz. Konfigurationsmanagement baut Regelsätze oft mit -D neu auf und schreibt nach rules.d. Deren Prozesse und Läufe gehören in die Baseline der Regeln 1 und 5 - und die anschließende Prüfung, dass der Regelbestand danach wieder vollständig ist, in den Prozess.
• Golden Images und Provisionierung. Beim Bauen von Images und beim ersten Boot werden Logs geleert und Konfigurationen gesetzt. Diese Hosts in dieser Phase ausnehmen, danach nicht mehr.
• Kontext schlägt Kommando. Wer, wann, auf welchem Host, mit welchem Elternprozess, mit welchem Change und mit welcher Aktivität unmittelbar davor - erst diese Fragen machen aus einem rm auf /var/log einen Vorfall oder einen Arbeitstag.

Analysten-Checkliste

• Wann kam das letzte reguläre Ereignis vom Host, und aus welcher Quelle? Ist nur eine Quelle ausgefallen (Audit-Strom) oder sämtliche Telemetrie (Host offline, Agent gestoppt)?
• Wurde auditd oder journald gestoppt, deaktiviert oder maskiert? Was sagen DAEMON_END, die Unit-Meldungen im Journal und die Prozess-Telemetrie?
• Welche Konfiguration wurde geändert - Regeln (CONFIG_CHANGE, auditctl -l gegen Baseline), auditd.conf, journald.conf? Wer hat die Änderung ausgeführt (auid, Konto, Elternprozess, Sitzung)?
• Gab es unmittelbar davor verdächtige Aktivität - eine Shell aus einem Dienst, eine Rechteausweitung, eine neue Persistenz, eine ausgehende Verbindung?
• Sind remote Ereignisse vorhanden, die lokal fehlen? Der Vergleich von SIEM und Host zeigt, was gelöscht wurde und ab wann.
• Ist es ein geplanter Change (Ticket, Wartungsfenster, Konfigurationsmanagement-Lauf), und passt die Änderung zu dem, was geplant war?
• Läuft EDR- oder Sysmon-Telemetrie weiter? Wenn ja, was zeigt sie für den Zeitraum nach dem Ausfall; wenn nein, wurde auch sie gestoppt?

Fazit

Logmanipulation unter Linux ist der Angriff auf die Erkennung selbst, und sie lässt sich nicht mit derselben Quelle erkennen, die gerade abgeschaltet wird. Was bleibt, ist dreierlei: der letzte lokale Datensatz, den auditd und journald noch schreiben, bevor sie verstummen; eine zweite Sensorik, die an einer anderen Stelle hängt; und das SIEM, das die bereits weitergeleiteten Ereignisse behält und das Schweigen eines Hosts als Signal versteht. Die fünf Regeln liefern die Prozess- und Dateisicht auf die Kommandos, die Lücken-Erkennung liefert den Rest - und sie ist der Teil, den der Angreifer vom Host aus nicht erreichen kann. Die wirksamste Härtung ist deshalb keine Regel, sondern die frühe Weiterleitung in einen Speicher, den der Host nicht ändern darf, plus ein gesperrter Audit-Regelsatz. Der Zugang davor läuft meist über eine Unix-Shell, die Persistenz danach über Cron und systemd oder die Shell-Konfiguration; die Windows-Seite steht unter Event-Log-Löschung und Audit-Logging abschalten. Weitere Techniken dieser Taktik führt das Lexikon nach Taktik unter Defense Impairment.