SSHGuard auf Debian und Ubuntu – Installation, Konfiguration und Praxis

SSHGuard erkennt typische Brute-Force-Angriffe anhand von Logmeldungen und übergibt erkannte Angreifer an ein Firewall-Backend. Dieser Guide erklärt Installation, journald, nftables/iptables, Whitelist, Schwellenwerte, IPv6, Diagnose und das Zusammenspiel mit SSH-Hardening.

Was SSHGuard macht

SSHGuard ist eine Erkennungs- und Reaktionsschicht, kein Ersatz für Firewall, sichere Authentisierung oder Updates. Es beobachtet Logs, erkennt typische Angriffsmuster und veranlasst eine Sperre über das konfigurierte Backend.

Installation auf Debian

Das Paket heißt `sshguard`. Nach der Installation sollte man die tatsächlich installierte Konfiguration prüfen, weil Backend und Logquelle von Distribution und Version abhängen können.

sudo apt update
sudo apt install sshguard
sudo systemctl enable --now sshguard
systemctl status sshguard

Installation auf Ubuntu

Auch Ubuntu stellt `sshguard` bereit. Nach der Installation sind `systemctl status sshguard` und die Journalmeldungen die ersten Prüfstellen.

Input, Parser und Blocking

SSHGuard braucht eine Logquelle, passende Parser und ein Blockierungs-Backend. Ein laufender Dienst allein beweist nicht, dass alle drei Komponenten funktionieren.

journald oder Logdatei?

Moderne Debian-/Ubuntu-Systeme verwenden häufig systemd-journald. Prüfe deshalb, wo SSH-Fehler tatsächlich landen: `journalctl -u ssh` beziehungsweise eine Suche nach `sshd` liefert schnell Hinweise.

journalctl -u ssh
journalctl | grep -Ei 'sshd|ssh'

Firewall-Backend

Je nach System kann nftables, iptables oder ein anderes Backend beteiligt sein. Vermeide mehrere konkurrierende Blockierungsmechanismen ohne klare Zuständigkeit.

nft list ruleset
iptables -S

Konfiguration

Schwellenwerte, Blockdauer, Whitelist und Serviceauswahl sollten bewusst gesetzt werden. Die lokale Beispielkonfiguration und die Manpage der installierten Version sind die zuverlässigste Referenz.

Whitelist und Rettungsweg

Eine falsche Sperre der eigenen Administrationsquelle kann den Zugang verlieren lassen. Vor Änderungen sollte ein zweiter SSH-Kanal, eine VM-Konsole oder Out-of-Band-Management verfügbar sein.

Schwellenwerte

Zu aggressive Einstellungen sperren legitime Benutzer; zu großzügige Einstellungen lassen automatisierte Angriffe länger laufen. Werte sollten anhand echter Logs und der eigenen Umgebung gewählt werden.

SSH zusätzlich härten

SSHGuard ersetzt keine SSH-Härtung. Bevorzuge Schlüssel, deaktiviere direkten Root-Login, begrenze administrative Benutzer und halte OpenSSH aktuell.

Sicher testen

Erst prüfen, ob SSHGuard Ereignisse erkennt, dann ob das Firewall-Backend tatsächlich sperrt. Teste aus einem kontrollierten Netz und halte einen zweiten Zugang offen.

Diagnose

Nützliche Befehle sind `systemctl status sshguard`, `journalctl -u sshguard`, `journalctl -u ssh` und je nach Firewall `nft list ruleset` beziehungsweise `iptables -S`.

systemctl status sshguard
journalctl -u sshguard --no-pager
journalctl -u ssh --no-pager
nft list ruleset

SSHGuard oder Fail2ban?

Beide Werkzeuge verfolgen ein ähnliches Ziel. Für denselben Dienst sollten sie nicht unkontrolliert parallel sperren. Für kleine Server ist eine bewusst gewählte primäre Lösung meist übersichtlicher.

IPv4 und IPv6

Wenn SSH über IPv6 erreichbar ist, muss auch die Blockierungsstrategie IPv6 berücksichtigen. `ss -lntp` und `ss -lntp6` helfen bei der Kontrolle.

ss -lntp | grep ':22'
ss -lntp6 | grep ':22'

Monitoring

Überwache nicht nur SSH, sondern auch SSHGuard selbst. Externes Monitoring prüft Erreichbarkeit; lokale Logs zeigen, ob die Erkennung arbeitet.

Praxis-Baseline

SSHGuard sollte als eine Schicht neben SSH-Key-Login, Firewall, Updates, Logging und Monitoring eingesetzt werden. Nach jeder Änderung: prüfen, reloaden, Logs kontrollieren, Test durchführen.

Fazit

SSHGuard ist klein und fokussiert. Richtig angeschlossen reduziert es die Wirkung automatisierter Brute-Force-Angriffe deutlich, ohne den Administrator von grundlegenden Sicherheitsmaßnahmen zu entbinden.