Incident Response mit journald

Aufgaben

1. 1. Fehlgeschlagene Logins finden

   Schritt 1: Wer hat angegriffen? Fehlgeschlagene SSH-Logins verraten die IP-Adressen eines Brute-Force-Angriffs. Du filterst sie aus dem Journal und sicherst die Angreifer-IPs.

   Lege den Arbeitsordner an und extrahiere die Quell-IPs der gescheiterten Logins:

   mkdir -p /home/student/incident
   journalctl -u ssh | grep -i "failed password" | grep -oE '([0-9]{1,3}\.){3}[0-9]{1,3}' | sort -u > /home/student/incident/suspicious-ips.txt

   grep -oE zieht nur die IP-Adressen heraus, sort -u macht sie eindeutig.

   Kontrolle: /home/student/incident/suspicious-ips.txt ist nicht leer.

2. 2. Verdächtigen Cronjob identifizieren

   Schritt 2: Persistenz finden. Angreifer nutzen Cronjobs, um sich dauerhaft einzunisten — ein Eintrag, der regelmäßig z. B. eine Reverse-Shell startet, überlebt jeden Neustart. Du findest ihn, indem du alle Crontab-Speicherorte prüfst.

   Durchsuche die Cron-Verzeichnisse und kopiere die verdächtige Zeile in eine Datei:

   sudo grep -rE "bash|curl|wget|nc|/tmp/" /etc/crontab /etc/cron.d/ /var/spool/cron/ 2>/dev/null

   Trage die gefundene bösartige Zeile ein (nano /home/student/incident/malicious-cron.txt).

   Kontrolle: /home/student/incident/malicious-cron.txt ist nicht leer.

3. 3. Angriffs-Timeline rekonstruieren

   Schritt 3: Timeline rekonstruieren. Eine chronologische Timeline zeigt Eintrittspunkt, Aktionen des Angreifers und Auswirkung in der richtigen Reihenfolge — ohne sie kann niemand den Vorfall nachvollziehen. Nutze die Zeitstempel aus dem Journal.

   Schreibe pro Zeile Zeitstempel + Ereignis (mindestens 3 Zeilen) nach timeline.txt, z. B.:

   2026-05-28 02:14  Erster erfolgreicher SSH-Login von Angreifer-IP
   2026-05-28 02:17  Boesartiger Cronjob in /etc/cron.d/ angelegt
   2026-05-28 02:19  Unbekannter Dienst 'rogue-agent' gestartet

   Hilfreich zum Recherchieren: journalctl --since "today" | less.

   Kontrolle: /home/student/incident/timeline.txt enthält mindestens 3 Zeilen.

4. 4. Kompromittierten Service isolieren

   Schritt 4: Containment. Solange der kompromittierte Dienst läuft, kann der Angreifer aktiv bleiben. Du musst ihn stoppen (sofortiger Schaden gestoppt) und deaktivieren (startet nach Reboot nicht wieder — die Persistenz ist weg).

   Stoppe und deaktiviere den bösartigen Dienst rogue-agent:

   sudo systemctl stop rogue-agent
   sudo systemctl disable rogue-agent

   Kontrolle: systemctl is-active rogue-agent meldet inactive und systemctl is-enabled rogue-agent meldet disabled.

5. 5. Incident-Report verfassen

   Schritt 5: Incident-Report. Ein guter Bericht beginnt mit einer Zusammenfassung (Entscheider lesen oft nur die) und endet mit Empfehlungen (damit derselbe Angriff nicht wieder funktioniert). So schließt sich der Kreis: Lessons Learned.

   Schreibe einen strukturierten Bericht (nano /home/student/incident/report.md), der mindestens diese Abschnitte enthält:

   # Incident-Report
   
   ## Zusammenfassung
   Kurz: Was ist passiert, wann, welche Auswirkung.
   
   ## Timeline
   (Verweis auf timeline.txt)
   
   ## Betroffene Systeme
   ...
   
   ## Empfehlungen
   - Passwoerter zuruecksetzen
   - Public-Key-Auth erzwingen, Passwort-Login abschalten
   - Monitoring/fail2ban einrichten

   Kontrolle: /home/student/incident/report.md enthält eine Überschrift „Zusammenfassung" (oder „Summary") und „Empfehlungen" (oder „Recommendations").