SSH-Härtung und Best Practices für Audits

Der wirkungsvollste einzelne Schritt zur Härtung von SSH besteht darin, PasswordAuthentication no in /etc/ssh/sshd_config zu setzen. Dadurch müssen sich alle Benutzer mit öffentlichen Schlüsseln authentifizieren; das beseitigt die Risiken schwacher oder wiederverwendeter Passwörter und von Brute-Force-Angriffen. Stellen Sie sicher, dass mindestens ein autorisierter Schlüssel installiert ist, bevor Sie die Passwortauthentifizierung deaktivieren, damit Sie sich nicht selbst aussperren.

Die Direktiven AllowUsers und AllowGroups beschränken den SSH-Zugriff auf benannte Benutzer bzw. Mitglieder bestimmter Gruppen. So erlaubt AllowGroups sshusers beispielsweise nur Mitgliedern der Gruppe sshusers den Zugriff. Dies sorgt für eine mehrschichtige Absicherung: Selbst wenn ein Angreifer einen Benutzernamen kennt und Zugangsdaten erlangt, wird der SSH-Zugriff verweigert, sofern das Konto nicht ausdrücklich zugelassen ist.

Das Ändern des SSH-Ports von 22 auf einen hohen Port ist eine Form der Verschleierung, keine Sicherheitsmaßnahme. Es reduziert jedoch die Zahl irrelevanter Logeinträge durch automatisierte Scanner, die Port 22 angreifen, erheblich. Dadurch lassen sich Protokolle leichter auf echte Bedrohungen analysieren. Halten Sie Firewallregeln stets als primäre Zugriffskontrolle aufrecht; die Verschleierung des Ports ist ausschließlich eine ergänzende Maßnahme.

Das Setzen von PermitRootLogin no verhindert die direkte Root-Authentifizierung über SSH. Angreifer, die root ins Visier nehmen, verfügen damit über einen garantiert gültigen Benutzernamen und bei Erfolg über uneingeschränkte Berechtigungen. Empfohlen wird PermitRootLogin prohibit-password; damit ist die Root-Anmeldung nur per Authentifizierung mit öffentlichem Schlüssel möglich. So wird Brute-Force gegen root per Passwort blockiert, während ein Notfallzugriff erhalten bleibt.

MaxAuthTries 3 begrenzt die Zahl der Authentifizierungsversuche pro Verbindung auf drei. Nach drei Fehlversuchen beendet der Server die Verbindung. Dadurch werden Brute-Force-Versuche verlangsamt. Zusammen mit dem exponentiellen Backoff von fail2ban oder SSHGuard, die IPs nach wiederholten Fehlversuchen vorübergehend sperren, werden Brute-Force-Angriffe praktisch undurchführbar.

LoginGraceTime gibt an, wie lange der Server auf eine erfolgreiche Authentifizierung wartet, bevor er die Verbindung trennt. Der Standardwert beträgt 120 Sekunden; eine Reduzierung auf 20 Sekunden verhindert langsame Brute-Force-Versuche und verringert die Ressourcenbindung durch nicht authentifizierte Verbindungen. ClientAliveInterval und ClientAliveCountMax steuern die Verbindungsprüfungen, um inaktive oder nicht mehr bestehende Sitzungen zu trennen.

Moderne SSH-Konfigurationen sollten die Algorithmen auf starke, zeitgemäße Optionen beschränken. Setzen Sie in sshd_config Ciphers auf chacha20-poly1305@openssh.com,aes256-gcm@openssh.com, MACs auf hmac-sha2-256-etm@openssh.com und KexAlgorithms auf curve25519-sha256. Dadurch werden veraltete Algorithmen wie arcfour, DES und auf MD5 basierende MACs ausgeschlossen, die möglicherweise aus Gründen der Abwärtskompatibilität verfügbar sind.

fail2ban überwacht Authentifizierungsprotokolle und sperrt IP-Adressen, die einen Schwellenwert fehlgeschlagener Anmeldeversuche überschreiten. Nach einer konfigurierbaren Anzahl von Fehlversuchen innerhalb eines Zeitfensters fügt fail2ban eine iptables-Regel hinzu, die weitere Pakete von dieser IP-Adresse verwirft. Diese automatisierte Reaktion macht Brute-Force-Angriffe ohne manuelles Eingreifen praktisch unmöglich.

Das Tool ssh-audit verbindet sich mit einem SSH-Server und bewertet dessen Konfiguration: Es prüft, welche Schlüsselaustauschalgorithmen, Hostschlüsseltypen, Chiffren und MACs angeboten werden, und kennzeichnet veraltete oder schwache Optionen. Wenn Sie ssh-audit vor und nach der Härtung gegen Ihre Server ausführen, erhalten Sie eine objektive Bewertung des Zustands vorher und nachher und erkennen Konfigurationslücken.

SSH-Authentifizierungsereignisse werden über syslog protokolliert. Unter Linux erfasst /var/log/auth.log (Debian) bzw. /var/log/secure (RHEL) jede erfolgreiche und fehlgeschlagene Anmeldung mit Zeitstempel, Benutzername, Quell-IP und dem verwendeten Fingerabdruck des Schlüssels. Wenn Sie diese Protokolle an ein zentrales SIEM senden, können ungewöhnliche Zugriffsmuster erkannt werden, etwa Anmeldungen aus unerwarteten Ländern oder zu ungewöhnlichen Uhrzeiten.

Eine gehärtete sshd_config kombiniert: PasswordAuthentication no, PermitRootLogin prohibit-password, MaxAuthTries 3, LoginGraceTime 20, AllowGroups sshusers, eingeschränkte Ciphers und MACs, X11Forwarding no sowie AllowTcpForwarding no (sofern kein Tunneling erforderlich ist). Jede Direktive beseitigt einen bestimmten Angriffsvektor; zusammen bilden sie eine mehrschichtige Absicherung von SSH.

Welche Einstellung in sshd_config ist am wirksamsten, um Brute-Force-Angriffe mit Passwörtern auf SSH zu verhindern?

Checkliste zur SSH-Härtung: Passwortauthentifizierung deaktivieren, den Zugriff auf AllowGroups/AllowUsers beschränken, die Root-Anmeldung deaktivieren oder auf die Schlüsselauthentifizierung beschränken, MaxAuthTries 3 setzen, LoginGraceTime reduzieren, die Algorithmen auf ausschließlich moderne Chiffren beschränken, fail2ban oder SSHGuard einsetzen, mit ssh-audit eine objektive Bewertung durchführen und Protokolle zur Erkennung von Anomalien zentralisieren.