In diesem Beitrag geht es um das Härten der SSH-Konfiguration
Einführung
SSH ist zum Standardwerkzeug für die Fernverwaltung von UNIX-basierten Systemen geworden. Der SSH-Daemon (sshd ) ist standardmäßig auf fast allen wichtigen Systemen installiert. Zusätzlich sshd bietet uns auch viele Konfigurationsoptionen.
Hinweis :Dieser Artikel ist eine Fortsetzung meines vorherigen Themas über Lynis. Obwohl ich versucht habe, dies für sich lesbar zu machen. Vielleicht möchten Sie den vorherigen lesen, um etwas Kontext zu bekommen.
Die Standardeinstellungen von openssh (die vom OpenBSD-Projekt entwickelte SSH-Version) folgt der „secure by default“-Philosophie, sodass die meisten Konfigurationen für sich genommen sicher sind. Bei der Durchführung des Lynis-Audit-Scans habe ich jedoch einige Vorschläge zu den Konfigurationen erhalten. Gehen wir also die Vorschläge durch, um unseren SSH-Daemon weiter zu härten. Ich werde auch kommentieren, ob das Deaktivieren/Aktivieren einiger von ihnen die Sicherheit verbessert.
SSH-Konfiguration härten
Die Vorschläge umfassen die Änderung unseres sshd Aufbau. Als Standardpfad für sshd config ist /etc/ssh/sshd_config , dort sollten wir suchen.
TCP und Agentenweiterleitung
Wie auf dem Screenshot zu sehen ist, lynis empfiehlt, AllowTCPForwarding und AllowAgentForwarding auf no zu setzen. Es ist ein guter Rat, nur das zu verwenden, was erforderlich ist, daher sollten wir diese Option deaktivieren, wenn wir sie nicht verwenden. Das Deaktivieren wird jedoch die Sicherheit nicht verbessern, wenn ein Benutzer Shell-Zugriff hat, in welchem Fall er seine eigenen Weiterleitungen einrichten kann (wie in sshd_config(5) gezeigt wird). Handbuchseite).
ClientAliveCountMax
ClientAliveCountMax und ClientAliveInterval sind zwei verwandte Optionen. Die maximale Anzahl, multipliziert mit dem Client-Alive-Intervall in Sekunden, bestimmt, wann eine Verbindung nicht mehr reagiert. Ich sehe nicht, wie sich dies auf die Sicherheit auswirken würde. Vielleicht muss ich noch mehr recherchieren. Trotzdem sollte es nicht schaden, den Wert zu verringern.
Komprimierung
SSH ermöglicht es uns, Daten zu komprimieren, die nach der Authentifizierung über diese Option gesendet werden. Bei langsamen Modems kann die Komprimierung die Verbindungsgeschwindigkeit verbessern. Auf den meisten modernen Systemen sollte dies jedoch keine Auswirkungen haben. Darüber hinaus kann es uns auch in BREACH-Angriffe einführen, wie in diesem GitHub-Kommentar ausgeführt. Nehmen wir also lynis' Vorschlag.
LogLevel
sshd protokolliert Nachrichten in journald standardmäßig auf den meisten GNU/Linux-Distributionen. Diese Option steuert die Detailebene, die protokolliert werden soll. lynis empfiehlt, dies von INFO auf VERBOSE zu setzen, was bei der Fehlerbehebung usw. hilfreich sein kann. Die Handbuchseite von sshd_config(5) weist jedoch darauf hin, dass die Einstellung auf eine höhere Ebene (z. B. DEBUG) die Privatsphäre seiner Benutzer verletzen kann. Ich sehe also wirklich keine Verbesserung der Sicherheit durch das Optimieren dieser Einstellung.
MaxAuthTries
Dieser Wert bestimmt, wie viele Authentifizierungsversuche pro Verbindung zugelassen werden. Wenn außerdem die Verbindungsversuchsfehler die Hälfte dieses Werts erreichen, dann sshd beginnt mit der Protokollierung der Fehler. Daher ist es sinnvoll, diesen Wert zu verringern.
MaxSessions
Der Wert dieser Option gibt an, wie viele Shell-Sessions pro Verbindung zugelassen werden sollen. Ich glaube nicht, dass man ssh braucht mehrfach auf einen einzigen Server. Außerdem gibt es noch tmux Dadurch können wir das gewünschte Multiplexing durchführen, ohne mehrere Sitzungen zu öffnen. Es macht also Sinn, diesen Vorschlag anzunehmen.
Port
Meine Interpretation dieses Vorschlags ist, dass wir sshd setzen sollten Listening Port auf einen anderen Wert. Dies wird sich als nützlich erweisen, um sich gegen die meisten Botnets zu verteidigen, die das Internet auf der Suche nach verwundbaren Computern an Standardports durchsuchen. Jeder, der sich mit den Grundlagen der Netzwerkzuordnung auskennt (Tools wie nmap ) wissen, dass dies nicht hilft. Lassen Sie uns ihn dennoch auf einen nicht standardmäßigen Wert setzen.
TCPKeepAlive
Das Setzen dieser Option auf YES hilft dem Server zu erkennen, wenn eine Verbindung unterbrochen wurde. Auf diese Weise hängen Sitzungen nicht auf unbestimmte Zeit auf dem Server. Daher denke ich, dass es besser ist, diese Option nicht zu deaktivieren.
X11Weiterleitung
Obwohl die meisten ssh Sitzungen sollen nur textbasiert sein. openssh bietet jedoch auch die Funktion, GUI-Anwendungen auf dem Server zu öffnen, die auf dem Client angezeigt werden. Das funktioniert so, dass der X-Server einen Kanal zurück zum Client öffnet. Das Problem dabei ist, dass X11 nie im Hinblick auf Sicherheit entwickelt wurde. Es wird davon ausgegangen, dass alle Programme vertrauenswürdig sind, da sie von uns ausgeführt wurden. Aber wie diese Antwort zeigt, kann der Server mit X11Forwarding den Client steuern und somit Shell-Befehle auf dem Client ausführen. Also schalten wir diese Funktion besser aus, wenn wir sie nicht brauchen.
Schlussfolgerung
Sicherheit ist wie immer ein sehr kompliziertes Thema. Wir können nicht immer wissen, wann ein System sicher ist. Außerdem ist der Anschein von Sicherheit noch schlimmer als keine Sicherheit.
In diesem Artikel bin ich die verschiedenen Konfigurationen durchgegangen, einschließlich der sehr kleinen Details, die dazu beitragen könnten, die Sicherheit unseres SSH-Servers zu verbessern. Aber härten Sie Ihr System wie immer gemäß Ihrem Bedrohungsmodell.
Sie wissen also, wie man die SSH-Konfiguration härtet