# Incident Response (IR): Handeln, wenn es brennt

TL;DR / Management Summary Ein Sicherheitsvorfall ist kein technisches Problem, sondern eine Stresssituation. Wer erst bei einem Hack anfängt, nach Tools zu suchen, hat bereits verloren. Incident Response (IR) ist der geplante Prozess zur Schadensbegrenzung. Ein Senior Admin folgt den SANS IR Phasen: Vom ersten Verdacht über die Isolierung (Containment) bis zur Wiederherstellung. Das Ziel ist es, den Angreifer auszubremsen, Beweise zu sichern und das System kontrolliert wieder in den Betrieb zu führen.

# 1. Einführung & Architektur

Die Phasen des Notfalls.

Incident Response ist ein Kreislauf. In der Enterprise-Welt nutzen wir das PICERL-Modell.

# Der IR-Lifecycle (Mermaid)

graph TD
    A[Phase 1: Preparation - Tools & Training] --> B[Phase 2: Identification - Detect Alert]
    B --> C[Phase 3: Containment - Isolate Host]
    C --> D[Phase 4: Eradication - Remove Malware]
    D --> E[Phase 5: Recovery - Restore from Backup]
    E --> F[Phase 6: Lessons Learned - Post Mortem]
    F --> A
    subgraph "Technical Action"
        C --> C1[Snapshot VM]
        C --> C2[Cut Network]
    end

# 2. Phase 2: Identifikation (Der Verdacht)

Ist es ein Fehlalarm?

Nutzen Sie Ihre Monitoring-Tools (Artikel 328, 341), um den Einbruch zu bestätigen.

• Indizien: Neue SUID-Dateien, unbekannte Netzwerkverbindungen zu C&C Servern, gelöschte Logs.

# 3. Phase 3: Containment (Eindämmung)

Den Schaden begrenzen.

Sobald der Vorfall bestätigt ist, muss der Angreifer gestoppt werden.

# Taktik A: Netzwerk-Isolierung

Blockieren Sie den Traffic am Switch oder Hypervisor (Proxmox Firewall). Vermeiden Sie das Ziehen des Netzwerkkabels, da dies bei flüchtigen Malware-Samples zum Verlust der Verbindung zum C&C-Server führt (was für die Analyse wichtig sein kann).

# Taktik B: Snapshot & Freeze

Wenn Sie in einer VM-Umgebung arbeiten:

1. Erstellen Sie einen Snapshot inklusive RAM-Inhalt.
2. Pausieren Sie die VM (qm suspend <vmid>). Dies sichert den aktuellen Zustand des Arbeitsspeichers für die Forensik (Artikel 359).

# 4. Day-2 Operations: Eradication & Recovery

Den Feind vertreiben.

Vertrauen Sie einem kompromittierten System niemals wieder.

• Eradication: Löschen Sie die kompromittierte Instanz komplett.
• Recovery: Bauen Sie den Server aus einem bekannten sauberen Backup (vor dem Einbruch) neu auf. Patchen Sie die Sicherheitslücke, bevor Sie den Server wieder ans Netz lassen!

# 5. Troubleshooting & “War Stories”

Wenn die Panik regiert.

# Story 1: “Der voreilige Reboot”

Symptom: Ein Admin bemerkt einen Einbruch und startet den Server sofort neu, um die Malware zu stoppen. Ursache: Panikreaktion. Ergebnis: Das Rootkit, das nur im RAM lebte, ist weg. Forensische Beweise im Arbeitsspeicher sind vernichtet. Der Angreifer kommt 10 Minuten später über die gleiche Lücke wieder rein. Lösung: Ruhe bewahren. Erst Snapshotten, dann isolieren, dann analysieren.

# Story 2: “Das infizierte Backup”

Symptom: Ein Server wird nach einem Hack aus einem Backup von letzter Nacht wiederhergestellt. Nach 2 Stunden wird er erneut gehackt. Ursache: Der Angreifer war bereits seit 2 Wochen im System. Alle Backups der letzten 14 Tage enthalten bereits die Hintertür (Backdoor). Lösung: Analysieren Sie die Timeline des Angriffs mit auditd und aide (Artikel 349). Nutzen Sie nur Backups, die nachweislich vor dem ersten Anzeichen des Einbruchs erstellt wurden.

# 6. Fazit & Empfehlung

• Vorbereitung: Erstellen Sie ein “First Responder Kit” (statisch gelinkte Binaries wie ls, ps, netstat auf einem schreibgeschützten USB-Stick).
• Kommunikation: Definieren Sie eine Meldekette. Wer muss informiert werden? (Management, Recht, Kunden).
• Wahl: Nutzen Sie Forensic Images, um das Originalsystem für Beweiszwecke unangetastet zu lassen.

# Anhang: Checkliste für den Ernstfall