Monitoring & Intrusion Detection: Angriffe erkennen

Monitoring & Intrusion Detection: Angriffe erkennen

Die meisten sichern ihren Server ab und hoffen, dass nichts passiert. Aber was passiert, wenn trotz SSH-Härtung und Firewall jemand reinkommt? Würdest du es überhaupt bemerken?

In diesem Artikel zeige ich dir fünf Maßnahmen für Monitoring und Incident Response — von automatischen Updates über Audit-Logging bis zum Notfallplan. Jede einzelne erhöht deine Chance, Angriffe zu erkennen bevor es zu spät ist.

DarkWolfCave.de

ℹ️ Hinweis: Die hier gezeigten Konfigurationen sind Empfehlungen aus meiner eigenen Praxis — keine Garantie für vollständige Sicherheit. Jedes Setup ist anders. Teste Änderungen immer zuerst in einer Testumgebung und passe sie an deine Infrastruktur an. Monitoring und Incident Response lassen sich auf viele Arten umsetzen — dieser Artikel zeigt fünf davon.

Warum Monitoring genauso wichtig ist wie Prävention

Du kannst deinen SSH-Server absichern, eine Firewall aufsetzen und Angreifer mit Endlessh aufhalten. Das ist alles wichtig und richtig. Aber Prävention allein reicht nicht.

Kein System ist zu 100% sicher. Zero-Day-Exploits, Fehlkonfigurationen oder ein kompromittierter SSH-Key — es gibt immer ein Restrisiko. Die Frage ist nicht ob, sondern wann etwas passiert. Und wenn es passiert, willst du es sofort wissen.

Die Maßnahmen in diesem Artikel bilden die zweite Verteidigungslinie: Erkennung und Reaktion. Sie greifen genau dann, wenn die Prävention versagt hat.

Automatische Sicherheitsupdates einrichten

Einer der häufigsten Angriffsvektoren bei Linux-Servern sind ungepatchte Schwachstellen. Laut dem Verizon Data Breach Investigations Report 2025 ist Vulnerability Exploitation mit 20% der Breaches nur noch knapp hinter Credential Abuse — Tendenz steigend mit einem 34% Anstieg gegenüber dem Vorjahr. Das bedeutet: Viele Einbrüche hätten durch ein simples Update verhindert werden können.

unattended-upgrades installieren und konfigurieren

# Installation
sudo apt install unattended-upgrades

# Interaktive Konfiguration
sudo dpkg-reconfigure -plow unattended-upgrades

Bei der interaktiven Abfrage wählst du Ja — damit werden Sicherheitsupdates automatisch installiert. Für die Feinabstimmung bearbeitest du die Konfigurationsdatei:

# /etc/apt/apt.conf.d/50unattended-upgrades
Unattended-Upgrade::Allowed-Origins {
    "${distro_id}:${distro_codename}-security";
    "${distro_id}ESMApps:${distro_codename}-apps-security";
};

// Automatischer Neustart wenn nötig (z.B. Kernel-Updates)
Unattended-Upgrade::Automatic-Reboot "true";
Unattended-Upgrade::Automatic-Reboot-Time "03:00";

// E-Mail-Benachrichtigung bei Problemen
Unattended-Upgrade::Mail "admin@deine-domain.de";
Unattended-Upgrade::MailReport "on-change";

// Ungenutzte Abhängigkeiten entfernen
Unattended-Upgrade::Remove-Unused-Kernel-Packages "true";
Unattended-Upgrade::Remove-Unused-Dependencies "true";

Funktionstest

# Trockenlauf — zeigt was installiert würde, ohne es zu tun
sudo unattended-upgrades --dry-run --debug

# Status prüfen
sudo systemctl status unattended-upgrades

⚠️ Wichtig: Automatische Reboots (Automatic-Reboot "true") sind bei Servern mit Docker-Containern oder Datenbanken kritisch. Stelle sicher, dass deine Dienste nach einem Reboot automatisch starten (restart: unless-stopped bei Docker, systemctl enable bei Systemd-Services).

Einstellung	Empfehlung	Warum
Security-Updates	Automatisch	Kritisch, kein Risiko
Stable-Updates	Manuell	Können Kompatibilitätsprobleme verursachen
Reboot	Automatisch (nachts)	Kernel-Updates erfordern Reboot
E-Mail-Benachrichtigung	Aktivieren	Du willst wissen was passiert

Audit-Logging mit auditd

Normale Logfiles wie syslog oder auth.log zeichnen nur vordefinierte Ereignisse auf. Wenn du wirklich wissen willst, wer wann was auf deinem System gemacht hat, brauchst du auditd. Das Linux Audit Framework arbeitet auf Kernel-Ebene und ist damit deutlich granularer und manipulationssicherer als normale Logs.

Installation und erste Regeln

# Installation
sudo apt install auditd audispd-plugins

# Dienst aktivieren und starten
sudo systemctl enable auditd
sudo systemctl start auditd

Jetzt definierst du Überwachungsregeln. Die wichtigsten für einen Server:

# SSH-Konfiguration überwachen — Alarm bei jeder Änderung
sudo auditctl -w /etc/ssh/sshd_config -p wa -k ssh_config

# Passwort-Dateien überwachen
sudo auditctl -w /etc/passwd -p wa -k passwd_changes
sudo auditctl -w /etc/shadow -p wa -k shadow_changes

# Cron-Jobs überwachen (beliebter Persistence-Mechanismus)
sudo auditctl -w /etc/crontab -p wa -k cron_changes
sudo auditctl -w /var/spool/cron/ -p wa -k cron_user_changes

# Sudo-Nutzung protokollieren
sudo auditctl -w /usr/bin/sudo -p x -k sudo_usage

Parameter-Erklärung

Parameter	Bedeutung
-w /pfad	Watch — diese Datei/Verzeichnis überwachen
-p wa	Permissions — write und attribute-Änderungen
-p x	Permissions — execute (Ausführung)
-k name	Key — Suchbegriff für die Filterung in Logs

Regeln permanent machen

Die auditctl-Regeln gehen bei einem Reboot verloren. Für permanente Regeln legst du eine Datei an:

# /etc/audit/rules.d/server-hardening.rules
-w /etc/ssh/sshd_config -p wa -k ssh_config
-w /etc/passwd -p wa -k passwd_changes
-w /etc/shadow -p wa -k shadow_changes
-w /etc/crontab -p wa -k cron_changes
-w /var/spool/cron/ -p wa -k cron_user_changes
-w /usr/bin/sudo -p x -k sudo_usage
-w /etc/audit/ -p wa -k audit_config

# Regeln neu laden
sudo augenrules --load

# Status prüfen
sudo auditctl -l

Logs auswerten

Die Audit-Logs findest du unter /var/log/audit/audit.log. Zum Durchsuchen nutzt du ausearch:

# Alle SSH-Config-Änderungen der letzten 24 Stunden
sudo ausearch -k ssh_config -ts today

# Alle sudo-Nutzungen eines bestimmten Users
sudo ausearch -k sudo_usage -ua 1000

# Zusammenfassung der letzten Ereignisse
sudo aureport --summary

💡 Tipp: Für forensische Analysen ist auditd sehr nützlich. Wenn du einen Einbruch vermutest, liefern die Audit-Logs die Timeline: Welcher User hat wann welche Datei geändert, welche Befehle wurden ausgeführt, welche Konfigurationen manipuliert. Ohne diese Daten ist eine Post-Mortem-Analyse praktisch unmöglich.

Security-Audit mit Lynis

Lynis ist ein Open-Source-Tool das über 300 Sicherheitsprüfungen auf deinem System durchführt. Es prüft Kernel-Parameter, Dateiberechtigungen, Netzwerk-Konfiguration, installierte Software und vieles mehr. Am Ende bekommst du einen Hardening Index — eine Zahl von 0 bis 100 die dir zeigt, wie gut dein System gehärtet ist.

Installation und erster Scan

# Installation über Paketmanager
sudo apt install lynis

# Oder: Neueste Version direkt von CISOfy (git installieren: sudo apt install git)
cd /opt && sudo git clone https://github.com/CISOfy/lynis
sudo /opt/lynis/lynis audit system

# System-Audit starten
sudo lynis audit system

Der Scan dauert typischerweise 2-5 Minuten. Lynis prüft dabei unter anderem:

• Boot-Loader und Kernel-Konfiguration
• Benutzer und Gruppen (verwaiste Accounts, schwache Passwort-Policies)
• SSH-Konfiguration (Algorithmen, Root-Login, Key-Authentifizierung)
• Firewall-Regeln und Netzwerk-Stack
• Dateisystem-Berechtigungen und SUID-Binaries
• Malware-Scanner und Integritätsprüfung
• Docker-Konfiguration (falls installiert)

Ergebnisse interpretieren

Am Ende des Scans siehst du den Hardening Index:

Hardening index : 67 [#############       ]
Tests performed : 312

Score	Bewertung	Handlungsbedarf
< 60	Schwach	Dringend nachbessern
60-70	Basis	Standard-Härtung fehlt teilweise
70-80	Gut	Gute Grundkonfiguration
> 80	Sehr gut	Gut gehärtetes System
> 90	Sehr gut+	Konsequent gehärtet

Die konkreten Empfehlungen stehen in der Ausgabe unter Suggestions. Du findest sie auch in der Logdatei:

# Alle Empfehlungen anzeigen
sudo grep "suggestion" /var/log/lynis.log

# Details zu einer bestimmten Empfehlung
sudo lynis show details FIRE-4513

💡 Tipp: Führe Lynis regelmäßig aus — idealerweise per Cronjob einmal pro Woche. So erkennst du wenn der Hardening Index nach einem Update oder einer Konfigurationsänderung plötzlich sinkt. Ein Lynis-Scan nach jeder größeren Änderung sollte zur Routine gehören.

Automatisierter Scan per Cronjob

Für den E-Mail-Versand brauchst du mailutils:

sudo apt install mailutils

# /etc/cron.weekly/lynis-audit
#!/bin/bash
/usr/sbin/lynis audit system --cronjob --quiet \
  | mail -s "Lynis Report $(hostname)" admin@deine-domain.de

sudo chmod +x /etc/cron.weekly/lynis-audit

Intrusion Detection mit AIDE

AIDE (Advanced Intrusion Detection Environment) ist ein File Integrity Monitoring Tool. Es erstellt einen Snapshot deines Dateisystems — eine Datenbank mit Prüfsummen aller wichtigen Dateien. Bei späteren Prüfungen vergleicht AIDE den aktuellen Zustand mit diesem Snapshot und meldet jede Abweichung.

Das ist besonders wertvoll, weil viele Angriffe Dateien manipulieren: Backdoors in Binaries, veränderte Konfigurationen, zusätzliche SSH-Keys in authorized_keys oder manipulierte Cronjobs. AIDE erkennt all das.

Installation und Initialisierung

# Installation
sudo apt install aide aide-common

# Datenbank initialisieren (kann einige Minuten dauern)
sudo aideinit

# Generierte Datenbank als Referenz aktivieren
sudo cp /var/lib/aide/aide.db.new /var/lib/aide/aide.db

Die Initialisierung scannt dein gesamtes System und erstellt die Referenz-Datenbank. Das ist dein bekannter guter Zustand — jede spätere Änderung wird dagegen verglichen.

AIDE-Konfiguration anpassen

Die Standardkonfiguration ist bereits brauchbar, aber du kannst sie verfeinern:

# /etc/aide/aide.conf.d/99_custom_rules

# Kritische Systemdateien besonders überwachen
/etc/ssh p+i+u+g+s+sha256
/etc/passwd p+i+u+g+s+sha256
/etc/shadow p+i+u+g+s+sha256
/etc/crontab p+i+u+g+s+sha256

# Log-Verzeichnisse ausschließen (ändern sich ständig)
!/var/log
!/var/cache
!/tmp

Attribut	Bedeutung
p	Permissions (Berechtigungen)
i	Inode-Nummer
u	User (Besitzer)
g	Group (Gruppe)
s	Size (Dateigröße)
sha256	SHA-256-Prüfsumme

Integritätsprüfung durchführen

# Manuell prüfen
sudo aide --check

Die Ausgabe zeigt dir drei Kategorien:

• Added — Neue Dateien die nicht in der Referenz-Datenbank sind
• Removed — Dateien die verschwunden sind
• Changed — Dateien deren Attribute oder Inhalt sich geändert haben

Automatische tägliche Prüfung

# /etc/cron.daily/aide-check
#!/bin/bash
REPORT=$(sudo aide --check 2>&1)
if echo "$REPORT" | grep -qE "Added|Removed|Changed"; then
    echo "$REPORT" | mail -s "AIDE Alert: Änderungen auf $(hostname)" admin@deine-domain.de
fi

sudo chmod +x /etc/cron.daily/aide-check

⚠️ Wichtig: Nach jeder geplanten Änderung (Updates, neue Software, Konfigurationsänderungen) musst du die AIDE-Datenbank aktualisieren. Sonst bekommst du bei jeder Prüfung Fehlalarme:

# Nach geplanten Änderungen: Datenbank neu generieren
sudo aide --update
sudo cp /var/lib/aide/aide.db.new /var/lib/aide/aide.db

Incident Response Plan: Wenn der Ernstfall eintritt

Alle bisherigen Maßnahmen helfen dir, Angriffe zu erkennen. Aber was machst du, wenn du tatsächlich einen Einbruch feststellst? In diesem Moment zählt jede Minute — und ohne Plan triffst du unter Stress die falschen Entscheidungen.

Ein Incident Response Plan orientiert sich klassisch an den vier Phasen aus NIST SP 800-61 Rev. 2 (seit April 2025 durch Rev. 3 abgelöst, die sich am NIST CSF 2.0 orientiert). Die bewährte Phasenstruktur bleibt aber der praktischste Leitfaden:

Die Phasen der Incident Response

Detection → Containment → Eradication → Recovery → Lessons Learned

Phase 1: Detection (Erkennung)

Hier greifen deine Monitoring-Tools. Die Frage ist: Woran erkennst du einen Einbruch?

• AIDE meldet veränderte Systemdateien
• auditd zeigt ungewöhnliche Zugriffe auf kritische Dateien
• Lynis zeigt plötzlich einen niedrigeren Hardening Index
• Unbekannte Prozesse, offene Ports oder ausgehende Verbindungen
• Unerklärte CPU-Last (Cryptominer sind häufig)

# Schnellcheck: Unbekannte Prozesse finden
ps auxf | grep -v "^\[" | sort -k3 -rn | head -20

# Offene Netzwerkverbindungen prüfen
ss -tulnp

# Kürzlich geänderte Dateien in /etc
find /etc -mtime -1 -type f

Phase 2: Containment (Eindämmung)

Das Ziel: Den Schaden begrenzen, ohne Beweise zu vernichten.

• Server vom Netzwerk isolieren (aber nicht herunterfahren — RAM-Inhalte gehen verloren)
• Firewall-Regeln verschärfen: Nur deine IP zulassen
• Kompromittierte Accounts sperren
• Bei Cloud-Servern: Snapshot erstellen für spätere Forensik

# Sofortmaßnahme: Alle eingehenden Verbindungen außer deiner IP blockieren
sudo iptables -I INPUT -s DEINE_IP -j ACCEPT
sudo iptables -A INPUT -j DROP

⚠️ Wichtig: Fahre einen kompromittierten Server niemals sofort herunter. Im RAM können sich Malware-Prozesse befinden, die nach einem Reboot verschwinden. Für die forensische Analyse sind diese flüchtigen Daten oft entscheidend.

Phase 3: Eradication (Bereinigung)

• Malware und Backdoors entfernen
• Kompromittierte SSH-Keys widerrufen
• Passwörter aller betroffenen Accounts ändern
• Audit-Logs sichern und analysieren (auditd!)

Phase 4: Recovery (Wiederherstellung)

• System aus einem bekannt sicheren Backup wiederherstellen
• Patches und Updates einspielen
• AIDE-Datenbank neu initialisieren
• Monitoring verstärken (engmaschigere Prüfintervalle)

Phase 5: Lessons Learned

• Was ist passiert und wie?
• Wie wurde der Angriff erkannt?
• Was hat funktioniert, was nicht?
• Welche Maßnahmen verhindern eine Wiederholung?

Checkliste für deinen Notfallplan

Vorbereitung	Status
Kontaktliste (wer wird informiert?)	[ ]
Backup-Strategie dokumentiert	[ ]
Forensik-Tools vorbereitet	[ ]
AIDE-Referenz-Datenbank aktuell	[ ]
auditd-Regeln aktiv	[ ]
Tabletop Exercise durchgeführt	[ ]

💡 Tipp: Führe mindestens einmal im Jahr eine Tabletop Exercise durch. Das ist eine Simulation am Schreibtisch: “Was würden wir tun, wenn morgen um 3 Uhr nachts der Server kompromittiert wird?” Dabei deckst du Lücken im Plan auf, bevor der Ernstfall eintritt. Selbst für Homelabs ist das eine wertvolle Übung — dabei fallen oft Lücken auf, die man vorher nicht auf dem Schirm hatte.

Alle Maßnahmen im Überblick

Hier die fünf Maßnahmen zusammengefasst — von einfach bis fortgeschritten:

Maßnahme	Aufwand	Wirkung	Priorität
Automatische Updates	5 Minuten	Schließt einen der Top-Angriffsvektoren	Kritisch
auditd Logging	15 Minuten	Forensische Analyse möglich	Hoch
Lynis Audit	10 Minuten	Schwachstellen systematisch finden	Hoch
AIDE Intrusion Detection	20 Minuten	Dateimanipulation erkennen	Hoch
Incident Response Plan	1-2 Stunden	Richtig reagieren im Ernstfall	Mittel

---

Server-Sicherheit endet nicht bei Prävention. Die Kombination aus automatischen Updates, Audit-Logging, regelmäßigen Security-Scans und File Integrity Monitoring gibt dir die Werkzeuge, um Angriffe zu erkennen — und mit einem Incident Response Plan weißt du, was dann zu tun ist.

Fang mit den automatischen Updates an — das kostet fünf Minuten und eliminiert den häufigsten Angriffsvektor. Dann richte auditd und AIDE ein, führe deinen ersten Lynis-Scan durch und notiere dir einen einfachen Notfallplan.

Und wenn du die Grundlagen noch brauchst: In meiner SSH-Komplettanleitung findest du die Basis-Härtung, mit Endlessh beobachtest du Angreifer live, und in meinem Artikel zur Netzwerk-Sicherheit und Firewall geht es um die dritte Verteidigungslinie. Zusammen bilden diese Artikel eine Security-Strategie für jeden Linux-Server.

Die komplette Artikelserie

Diese sechs Artikel bilden zusammen einen Leitfaden für Linux-Server-Sicherheit:

1. SSH-Server absichern — Die Eingangstür härten
2. Netzwerk-Sicherheit & Firewall — Den Perimeter schützen
3. Linux-Server härten — Die Angriffsfläche minimieren
4. Monitoring & Intrusion Detection (dieser Artikel) — Angriffe erkennen
5. Endlessh SSH Tarpit — Bots aufhalten und beobachten
6. Backup & Defense-in-Depth — Das Sicherheitsnetz und die Gesamtstrategie