Zum Inhalt springen

Hardening/Linux/Audit und Logging

Aus Foxwiki

Hardening/Linux/Audit und Logging – Auditierung und Journalierung bilden die Basis für Erkennung, Analyse und Nachweis sicherheitsrelevanter Ereignisse.

Beschreibung

Audit und Logging liefern belastbare Informationen über

  • Sicherheitsereignisse
  • Authentifizierungsfehler
  • Policy-Verstöße
  • privilegierte Aktionen
  • Betriebsereignisse mit Sicherheitsbezug
  • Dienstabstürze
  • Konfigurationsänderungen
  • Ressourcenengpässe

Ziele

  • Nachvollziehbarkeit sicherheitsrelevanter Aktionen (Accountability)
  • Schnelle Erkennung von Angriffen und Fehlkonfigurationen (Detection)
  • Forensische Auswertung und Beweisfähigkeit (Forensics/Evidence)
  • Minimierung von Logverlust

Log-Quellen

Quelle Ereignisse Sicherheitsnutzen
systemd-journald Unit-Start/Stop, Kernel-Meldungen, Auth- und Dienstlogs Basis-Telemetrie, schnelle Analyse
Auth (sshd/PAM) Login-Erfolge/-Fehler, MFA-Status, Sperren Brute-Force/Account-Missbrauch
Privilegien (sudo) Privilege Escalation, Kommandonutzung Missbrauch administrativer Rechte
MAC (AppArmor/SELinux) Denials/AVC, Policy-Verstöße Policy-Fehler, Exploit-Indikatoren
Firewall Drops, ungewöhnliche Flows Scans, Exfiltration-Indikatoren
Applikationen Fehler, Admin-Aktionen, Zugriffsmuster Angriffs-/Fehlverhalten in Anwendungen

Logging-Architektur

Lokal
  • journald als zentrale Sammelstelle auf dem Host
  • Optional Syslog-Daemon (z.B. rsyslog) zur Weiterleitung/Kompatibilität
Zentral
  • Remote-Loghost oder SIEM zur manipulationsärmeren Aufbewahrung
  • Transport geschützt (TLS, mTLS oder abgesicherte Tunnel)
  • Zugriffstrennung: Host-Administration != Log-Administration

systemd-journald

Abfrage/Analyse
journalctl -b

journalctl -u ssh --since "today"

journalctl -p warning..alert --since "24 hours ago"
Persistente Speicherung und Limits

Konfiguration in /etc/systemd/journald.conf oder Drop-In unter /etc/systemd/journald.conf.d/*.conf. 

[Journal]
Storage=persistent
Compress=yes
SystemMaxUse=500M
SystemKeepFree=1G
MaxRetentionSec=30days
RateLimitIntervalSec=30s
RateLimitBurst=1000
Hinweis
  • Storage=persistent verhindert Logverlust nach Reboot
  • Retention und Limits abhängig von Host-Rolle, Datenaufkommen und Speicherstrategie wählen
Zugriffskontrolle
  • Lesezugriff restriktiv vergeben (z.B. Gruppe systemd-journal nur für berechtigte Rollen)

Legacy Logfiles und Rotation

  • Applikations- und Legacy-Logs liegen häufig unter /var/log
  • Rotation und Aufbewahrung über logrotate oder Applikationsmechanismen sicherstellen
  • Log-Inhalte auf Secrets prüfen (Tokens, Passwörter, private Schlüssel) und Logging-Levels entsprechend konfigurieren

Zentrale Log-Sammlung

Ziel
  • Weiterleitung der relevanten Streams an einen zentralen Empfänger
  • Normalisierung, Parsing und Korrelation
  • Alarmierung auf Indikatoren

Auditing

Auditierung ergänzt Logging um Kernel-nahe, schwerer zu umgehende Ereignisse, z.B. Dateiänderungen, privilegierte Syscalls

Installation
sudo apt install auditd audispd-plugins

systemctl enable --now auditd

sudo auditctl -s
Regelverwaltung

Regeln unter /etc/audit/rules.d/*.rules pflegen und laden. 

sudo augenrules --load

sudo systemctl restart auditd
Beispiel-Regeln

Datei-Watches für kritische Konfigurationen: 

-w /etc/passwd -p wa -k identity
-w /etc/group -p wa -k identity
-w /etc/shadow -p wa -k identity
-w /etc/sudoers -p wa -k privilege
-w /etc/sudoers.d/ -p wa -k privilege
-w /etc/ssh/sshd_config -p wa -k ssh
-w /etc/systemd/system/ -p wa -k systemd
-w /etc/audit/ -p wa -k audit

Zeitmanipulation und Kernel-Module (Syscalls): 

-a always,exit -F arch=b64 -S adjtimex -S settimeofday -S clock_settime -k time-change
-a always,exit -F arch=b64 -S init_module -S delete_module -k kernel-modules
-S init_module -S finit_module -S delete_module
Hinweis
  • Syscall-Regeln verursachen je nach Workload hohes Event-Volumen. Einsatz auf Server-Rollen und Signalwirkung abstimmen
Auswertung
sudo ausearch -k identity --start today

sudo ausearch -k privilege --start today

sudo aureport -x --summary

Alarmierung

Indikatoren
  • Viele SSH-Fehlschläge in kurzer Zeit (Brute-Force, Credential Stuffing)
  • sudo-Nutzung außerhalb erwarteter Zeitfenster oder durch atypische Accounts
  • MAC-Denials-Spikes (AppArmor/SELinux), insbesondere bei Netzwerkdiensten
  • Unerwartete Service-Restarts oder Crashes sicherheitskritischer Komponenten
  • Änderungen an /etc/sudoers, sshd_config, systemd-Units, Audit-Regeln
  • Firewall-Drops mit Scan-Mustern oder ungewöhnlichen Zielnetzen
Ziel
  • Wenige, hochwertige Alarme statt hoher Menge niedrigwertiger Meldungen

Integrität und Manipulationsschutz

  • Lokale Logs gelten als potenziell manipulierbar. Beweisfähigkeit erfordert zentrale Sammlung und Zugriffstrennung
  • Loghost so betreiben, dass Write-Only für Sender möglich ist (kein Rückkanal zur Manipulation)
  • Aufbewahrung und Backups für Logs und Audit-Daten definieren (Retention nach Risiko/Compliance)

Security-Assessment-Tools

Werkzeuge dieser Klasse prüfen Konfigurationen und Hardening-Status. Sie ersetzen kein Logging/Auditing, liefern jedoch Baselines und Abweichungen.

Lynis

Zweck
  • Systematischer Hardening-Check (Kernel, Dienste, Dateisystem, Auth, Logging, Netzwerk)
Ergebnisse
  • Berichte typischerweise unter /var/log/lynis.log und /var/log/lynis-report.dat
  • Findings als Input für Hardening-Backlog verwenden (priorisieren nach Risiko/Angriffsfläche)

Lynis

Weitere Werkzeuge

Werkzeugklasse Zweck Nutzung
OpenSCAP/SCAP Compliance-/Baseline-Checks Policy-Validierung gegen Profile
osquery Abfragen über Systemzustand (SQL-ähnlich) Inventarisierung, Detektion, Baselines
AIDE/FIM File Integrity Monitoring Änderungen an kritischen Dateien erkennen
HIDS (Wazuh/OSSEC) Korrelation aus Logs + FIM + Regeln Zentrale Detektion/Alerting
Rootkit-Checker (rkhunter/chkrootkit) Indikatorenprüfung Ergänzend, Ergebnisbewertung erforderlich
Abgerufen von „https://wiki.foxtom.de/index.php?title=Hardening/Linux/Audit_und_Logging&oldid=159311“