SSH-Härtungs-Checkliste für Linux-Server im Internet

Wie diese Liste zu benutzen ist

Härtungs-Checklisten scheitern meist aus einem Grund: Sie sind nach Thema geordnet statt nach Risiko, man arbeitet sie von oben ab und die Zeit ist irgendwo bei der Banner-Konfiguration aufgebraucht, ohne dass die Authentifizierung je drankam.

Diese ist geordnet. Abschnitt 1 entfernt den Weg, auf dem Linux-Server tatsächlich übernommen werden. Wenn Sie nur eine Stunde haben: Abschnitt 1, dann aufhören — er ist mehr wert als alles darunter zusammen.

Die Liste setzt einen Server voraus, der SSH von beliebigen Adressen annehmen muss. Muss Ihrer das nicht, schrumpft Abschnitt 3 auf eine einzige Firewall-Regel, und das ist eine gute Nachricht.

1. Authentifizierung

Übernahmen beginnen weit häufiger mit gültigen Zugangsdaten als mit einem ungepatchten Daemon. Dieser Abschnitt ist das ganze Spiel.

• Passwortauthentifizierung vollständig abschalten: PasswordAuthentication no. Das ist die wertvollste Zeile in diesem Dokument — ohne Passwort zu erraten können Rateangriffe überhaupt nicht gelingen.
• Ebenso KbdInteractiveAuthentication no setzen. Vergisst man es, bietet PAM weiterhin eine Passwortabfrage an, Passwörter funktionieren also weiter und Sie haben nichts geändert. Mit sshd -T prüfen, nicht durch Lesen der Datei.
• PermitRootLogin auf prohibit-password setzen, oder auf no, wenn root nie direkt verbindet. Root ist der erste Name auf jeder Angriffsliste.
• Private Schlüssel mit einer Passphrase schützen und von geteilten Maschinen fernhalten. Ein geleakter Schlüssel ist genauso schlimm wie ein geleaktes Passwort, und er leckt auf denselben Wegen: gestohlener Laptop, versehentlicher Commit, CI-Runner-Umgebung.
• Schlüssel rotieren, wenn jemand geht, und ~/.ssh/authorized_keys auf jedem Konto prüfen. Alte Schlüssel sammeln sich lautlos an, und niemand entfernt sie je.
• AllowUsers oder AllowGroups als explizite Liste setzen. Selbst bei Keys-only verhindert das, dass ein neu angelegtes Dienstkonto versehentlich aus der Ferne erreichbar wird.

2. Erreichbares reduzieren

Die zweite Frage nach „wer darf sich anmelden" lautet „was lauscht sonst noch". Jeder offene Port ist ein Dienst, den gerade jemand testet.

• Inventarisieren, was wirklich lauscht: ss -tlnp auf dem Host, dann von einem anderen Netz prüfen, welche davon antworten. Die beiden Listen sind selten gleich.
• Dienste an localhost binden, wo sie nicht remote sein müssen — besonders Datenbanken. Ein PostgreSQL oder Redis auf 0.0.0.0 ist ein weit größeres Problem, als SSH je war.
• Eine Default-Deny-Firewall betreiben: nftables oder das Frontend der Distribution, das nur zulässt, was Sie benannt haben.
• SSH-Quelladressen einschränken, wenn möglich. Ist die legitime Menge klein und stabil, ist das die billigste echte Maßnahme — und sie hört auf zu funktionieren, sobald jemand verreist.
• Einen Wechsel weg von Port 22 zur Rauschunterdrückung erwägen, im Bewusstsein, dass es Rauschunterdrückung ist und kein Schutz.

3. Automatisches Sperren fehlgeschlagener Anmeldungen

Keys-only entfernt das Risiko eines erfolgreichen Ratens. Es entfernt nicht den Verkehr, und um den geht es hier.

Bots kennen Ihre Konfiguration nicht. Sie verbinden sich weiter, bieten Passwörter an und werden abgewiesen — jeder Versuch kostet eine TCP-Verbindung, einen sshd-Fork, eine Protokollzeile und ein Stück CPU. Sich selbst überlassen, schluckt ein exponierter Server tausende am Tag, und das Protokoll rotiert schnell genug, um die Ereignisse zu verlieren, die Sie gebraucht hätten.

fail2ban ist die Standardantwort und ein vernünftiger Anfang. Richtig konfigurieren — bantime -1, ignoreip mit den eigenen Adressen, und Monitoring auf die Sperrzahl statt auf den Dienstzustand, denn sein Fehlerfall ist Stille. Seine strukturellen Grenzen sind Einzeladress-Sperren gegen bereichsrotierende Botnetze, Zustand, der einen Neuaufbau nicht übersteht, und kein geteiltes Wissen zwischen Ihren Servern.

SSH Protector ist dieselbe Aufgabe als verwalteter Agent: Subnetzsperren, dauerhaft und beim Booten wiederhergestellt, der echte SSH-Port aus sshds Konfiguration, Ihre Adresse bei der Installation auf der Whitelist, geteilte Reputation über alle geschützten Server und eine Konsole, die beantwortet, ob es noch läuft.

4. sshd-Konfigurationsdetails

Lohnend, einzeln geringfügig, zusammen eine kleinere Angriffsfläche. Nach jeder Änderung sshd -t laufen lassen und reloaden statt neu starten.

• MaxAuthTries 3 — weniger Zugangsdatenversuche pro Verbindung, ein Bot braucht also mehr Verbindungen für dieselbe Zahl an Rateversuchen.
• MaxSessions und MaxStartups herabsetzen — begrenzt, wie viele nicht authentifizierte Verbindungen gleichzeitig offen sein können, und genau das verbraucht eine Flut.
• LoginGraceTime 30 — eine nicht authentifizierte Verbindung sollte nicht zwei Minuten offen stehen.
• X11Forwarding no und AllowAgentForwarding no, sofern nichts sie wirklich braucht. Agent-Forwarding erlaubt einem kompromittierten Ziel insbesondere, Ihren Schlüssel zu benutzen.
• Nur moderne Algorithmen: Legacy-Chiffren, MACs und Schlüsselaustauschverfahren entfernen. Aktuelle Distributionen setzen vernünftige Standards, prüfen Sie also, bevor Sie ein Härtungs-Snippet von vor zehn Jahren kopieren — mehrere populäre brechen inzwischen mehr, als sie reparieren.

5. Protokollierung und Erkennung

Sie können nicht untersuchen, was Sie nicht aufgezeichnet haben, und die Standardkonfiguration behält weniger, als Sie erwarten.

• Bestätigen, dass sshds LogLevel mindestens INFO ist. Auf QUIET zeichnet es keine Authentifizierungsfehler auf.
• Die Aufbewahrung in journald erhöhen oder Logs vom Host wegschicken. Das lokale Journal einer kompromittierten Maschine ist Beweismaterial, das ein Angreifer bearbeiten kann; eine Kopie anderswo nicht.
• Auf das Bedeutsame alarmieren statt auf Volumen: eine erfolgreiche Anmeldung von unbekannter Adresse, eine Accepted-password-Zeile auf einem Keys-only-Server, ein neuer sudoers-Eintrag, ein neuer authorized_keys-Eintrag.
• Erfolgreiche Anmeldungen gelegentlich und bewusst durchsehen. Fehlschläge sind Rauschen; ein Erfolg, den Sie nicht erklären können, ist die ganze Sache.

6. Patches und Wiederherstellung

Die letzten beiden, und die Reihenfolge zwischen ihnen zählt weniger als dass es beide gibt.

Halten Sie sshd und den Kernel aktuell — aktivieren Sie unbeaufsichtigte Sicherheitsupdates, wenn Ihr Änderungsprozess das erlaubt. OpenSSH hatte Schwachstellen vor der Authentifizierung und wird weitere haben, und das Fenster zwischen Veröffentlichung und Massenausnutzung bemisst sich inzwischen in Tagen.

Dann Backups, mit einer Eigenschaft, die mehr zählt als alle anderen: mindestens eine Kopie, die der Server selbst weder erreichen noch löschen kann. Ransomware-Betreiber suchen das Backup-Ziel, bevor sie irgendetwas verschlüsseln, und ein Mount, auf den der kompromittierte Host schreiben kann, ist kein Backup, sondern eine zweite Kopie, die auf ihre Zerstörung wartet. Und stellen Sie eines wieder her — ein nie zurückgespieltes Backup ist eine Hypothese, kein Plan.