Seminar Linux Incident Response – Analyse und Wiederanlauf

Bei einem kompromittierten Linux-System können sowohl lokale Werkzeuge als auch Protokolle verändert worden sein. Die Schulung entwickelt deshalb einen Untersuchungsweg, der die Vertrauenswürdigkeit der Analyseumgebung und unabhängige Gegenprüfungen berücksichtigt. Im Mittelpunkt stehen Serverdienste, administrative Zugänge und Hinweise auf fortbestehende Zugriffsmöglichkeiten.

Der Laborfall verbindet SSH-Anmeldungen, Prozessaktivitäten, Konfigurationsänderungen und Auffälligkeiten in einem Webdienst. Nach der Untersuchung wird ein ausgewählter Dienst aus einer sauberen Ausgangsbasis neu bereitgestellt. Produktive Bereinigung auf Verdacht wird von einer kontrollierten Wiederherstellung mit geprüften Konfigurationen und Daten unterschieden.

Schulungsziele

• Linux-Systeme mit dokumentierten und situationsgerechten Triage-Schritten untersuchen.
• Anmelde-, Prozess-, Dienst- und Netzwerkbefunde zeitlich miteinander verbinden.
• Persistenzhinweise und kompromittierte Zugänge im Kontext bewerten.
• Einen betroffenen Labordienst aus einer kontrollierten Basis wiederherstellen und abnehmen.

Zielgruppe

Linux- und Unix-Administratoren, Incident Responder, SOC-Analysten und technische Betriebsverantwortliche.

Voraussetzungen

Sichere Linux-Kommandozeilenkenntnisse, Erfahrung mit systemd, Dateirechten, SSH und Netzwerkdiensten. Incident-Response-Grundlagen werden vorausgesetzt.

Seminarinhalte

Die folgenden Themen bilden den fachlichen Aufbau der Schulung.

• Sichere Linux-Triage
• Anmeldungen und Protokollkorrelation
• Persistenz und Konfigurationsveränderungen
• Artefakte, Speicher und Untersuchungsumfang
• Neuaufbau und Dienstwiederherstellung
• Durchgängiger Linux-Vorfall

1. Sichere Linux-Triage

• Untersuchungszugang, Werkzeugherkunft und Auswirkungen von Live-Abfragen vor dem Einsatz bewerten.
• Prozesse, offene Dateien, Verbindungen und angemeldete Benutzer situationsgerecht erfassen.
• Lokale Beobachtungen mit zentralen Protokollen oder einer unabhängigen Sicherung gegenprüfen.

2. Anmeldungen und Protokollkorrelation

• SSH-, sudo-, systemd-journal- und vorhandene Audit-Ereignisse anhand des Laborfalls auswerten.
• Zeitabweichungen, Rotation, fehlende Protokolle und Unterschiede zwischen Distributionen berücksichtigen.
• Administrationshandlungen, automatisierte Abläufe und verdächtige Aktivitäten anhand mehrerer Hinweise unterscheiden.

3. Persistenz und Konfigurationsveränderungen

• System- und Benutzerdienste, Timer, Cron-Einträge und SSH-Schlüssel auf unerwartete Veränderungen untersuchen.
• Berechtigungen, Dienstkonten und ausführbare Dateien mit einer vertrauenswürdigen Ausgangsbasis vergleichen.
• Webdienst-Artefakte und Containerbezüge einordnen; eine Auffälligkeit in einem Container nicht automatisch auf den gesamten Host übertragen.

4. Artefakte, Speicher und Untersuchungsumfang

• Gezielte Artefaktsammlungen und vorbereitete Speicherabbilder zur Unterstützung der Untersuchung einsetzen.
• Passende Linux-Kernelsymbole und die Grenzen einer unvollständigen Speicheraufnahme bei Volatility 3 berücksichtigen.
• Eine Ereigniszeitlinie und eine Liste möglicherweise betroffener Systeme oder Zugänge aus den Befunden ableiten.

5. Neuaufbau und Dienstwiederherstellung

• Ein sauberes Zielsystem bereitstellen und geprüfte Konfigurationen sowie Daten selektiv übernehmen.
• SSH-Schlüssel, Dienstgeheimnisse und weitere betroffene Zugänge nach Befund koordiniert erneuern.
• Paketquellen, Dienstberechtigungen, Netzwerkzugänge und Monitoring vor einer Wiederaufnahme prüfen.

6. Durchgängiger Linux-Vorfall

• Einen vorbereiteten Servervorfall aus Triage-Daten und weiteren Spuren rekonstruieren.
• Eine begründete Eindämmung festlegen und einen ausgewählten Labordienst wiederaufbauen.
• Funktion, Zugriffsrechte und Beobachtung nach dem Wiederanlauf dokumentieren und die technische Übergabe erstellen.

Praktische Fallbearbeitung

1. Den Laborhost und zentrale Protokolle untersuchen und Veränderungen durch die Untersuchung dokumentieren.
2. Auffällige Anmeldungen mit Prozessen, Dienständerungen und Netzwerkverbindungen korrelieren.
3. Hinweise auf Persistenz überprüfen und den betroffenen Vertrauensbereich bestimmen.
4. Einen Dienst auf einer sauberen Linux-Instanz wiederherstellen und erforderliche Zugänge erneuern.
5. Berechtigungen, fachliche Funktion und Überwachung prüfen und offene Befunde an das Wiederanlaufteam übergeben.

Schulungsumgebung

Isolierte Linux-Server mit vorbereiteten Spuren, zentralen Protokollexporten und einem getrennten Wiederherstellungsziel. Die praktische Arbeit erfolgt überwiegend in der Kommandozeile; grafische Analyseoberflächen ergänzen die Befundübersicht. Aktive Ransomware wird nicht eingesetzt.

Passende Vertiefungen

Die weitere Auswahl richtet sich nach Aufgabenfeld und vorhandenen Kenntnissen.

• Netzwerkforensik und Threat Hunting für Incident Responder – 3 Tage
• Ransomware Recovery – Sicherer Wiederanlauf im Clean Room – 3 Tage
• Cyber Incident Response Intensiv – Forensik und Threat Hunting – 5 Tage