# Log Analysis Security: Einbrüche und Anomalien erkennen

TL;DR / Management Summary Wer seine Logs nicht auf Security-Muster prüft, bemerkt einen Einbruch oft erst, wenn es zu spät ist. Ein Senior Admin sucht aktiv nach IOCs (Indicators of Compromise): Ungewöhnliche Sudo-Aufrufe, massenhafte 404-Fehler (Scans) oder Logins zu unüblichen Zeiten. In diesem Modul lernen wir, wie wir diese Nadeln im Heuhaufen mittels Logwatch und fortgeschrittenem Shell-Grep finden, um Angriffe im Keim zu ersticken.

# 1. Einführung & Architektur

Vom Rauschen zum Signal.

Sicherheitsrelevante Logs sind meist über verschiedene Dateien verteilt. Wir müssen diese Daten korrelieren.

# Die Security-Sicht (Mermaid)

graph TD
    A[Sources: access.log / secure / audit.log] --> B{Analyzer}
    B -->|Search| C[Brute Force Patterns: 'Failed password']
    B -->|Search| D[Web Attacks: '../', 'SELECT', '<script>']
    B -->|Search| E[PrivEsc: 'USER_AUTH' via auditd]
    C/D/E --> F[Alerting: Admin Notification]
    G[Tool: Logwatch] --> B

# 2. Logwatch: Der tägliche Security-Report

Automatisierte Zusammenfassung.

Logwatch scannt Ihre Logs und sendet Ihnen eine kompakte E-Mail mit den wichtigsten Ereignissen.

# Einrichtung

sudo apt install logwatch # Debian
sudo dnf install logwatch # RHEL

# Manueller Test (Security Fokus)

sudo logwatch --detail high --service sshd --range today

Dies zeigt Ihnen sofort, welche IPs heute versucht haben, sich per SSH einzuloggen.

# 3. Mustererkennung mit der Shell

Handarbeit für Profis.

# 1. Web-Attacken (SQLi / Path Traversal)

Suchen Sie in den Nginx/Apache Logs nach typischen Mustern:

grep -E "UNION|SELECT|--|'|etc/passwd|../" /var/log/nginx/access.log

# 2. Sudo-Missbrauch

Wer hat versucht, Sudo ohne Berechtigung zu nutzen?

grep "NOT in sudoers" /var/log/secure # RHEL
grep "NOT in sudoers" /var/log/auth.log # Debian

# 4. Day-2 Operations: Echtzeit-Analyse mit MultiTail

Mehrere Quellen gleichzeitig im Blick.

Wenn Sie einen Angriff vermuten, müssen Sie verschiedene Logs gleichzeitig sehen.

# Zeigt SSH-Log und Nginx-Log farblich getrennt in einem Fenster
sudo multitail -i /var/log/secure -i /var/log/nginx/access.log

# 5. Troubleshooting & “War Stories”

Wenn der Angreifer schlau ist.

# Story 1: “Der Log-Overflow Angriff”

Symptom: Der Admin will das Log analysieren, aber das File hat eine Größe von 50GB und die Shell stürzt beim Öffnen ab. Ursache: Ein Angreifer flutet den Server mit absichtlichen Fehlern, um die Analyse-Tools lahmzulegen oder die Spuren des eigentlichen Einbruchs im Datenmüll zu verstecken. Lösung: Nutzen Sie tail -c (nach Größe) oder grep auf den Anfang des Files, um den Zeitpunkt des Angriffsbeginns zu finden. Nutzen Sie ELK (Artikel 045), das auch mit Terabytes an Daten umgehen kann.

# Story 2: “Das verschwiegene Script”

Symptom: Der Server wurde übernommen, aber in den Logs steht absolut nichts. Ursache: Der Angreifer hat ein Skript genutzt, das direkt den Systemaufruf syslog(2) umgeht oder die Log-Dienste gestoppt hat. Lösung: Nutzen Sie Auditd (Artikel 337). Audit-Events werden auf Kernel-Ebene generiert und lassen sich deutlich schwerer unterdrücken als Applikations-Logs.

# 6. Fazit & Empfehlung

• Routine: Lesen Sie den täglichen Logwatch-Bericht beim ersten Kaffee.
• Wahl: Nutzen Sie GoAccess für eine schnelle visuelle Analyse von Web-Traffic direkt im Terminal.
• Sicherheit: Sichern Sie Ihre Log-Verzeichnisse (chmod 700). Wer Logs lesen kann, erfährt viel über die Struktur Ihrer Applikationen.

# Anhang: Cheatsheet für Security-Admins