SSH. Wir wissen es. Wir lieben es. Wir müssen es benutzen.
Ich werde Sie durch acht Schritte führen, um Ihnen zu helfen, den SSH-Dienst in Ihrem Netzwerk besser zu sichern. Ich denke, wir alle wissen die Bedeutung von SSH zu schätzen. Es ermöglicht uns, eine Verbindung zu und von Linux-Geräten, Unix-Servern, Netzwerkgeräten und manchmal sogar Windows-Boxen herzustellen. Ich werde nicht versuchen, Ihnen zu verkaufen, wie oft SSH verwendet wird oder wie wichtig es ist. Ich werde Ihnen eine solide Checkliste zur Verfügung stellen, mit der Sie sicherstellen können, dass SSH-Dienste in Ihrer Umgebung gesperrt sind.
1. Sichern Sie die Konfigurationsdatei
Sichern Sie zunächst die Konfigurationsdatei, bevor Sie größere Änderungen vornehmen. Dies ist ein allgemeiner Ratschlag, aber es ist ein echter. Es ist einfach, dauert nur einen Moment und schützt Sie im Falle eines Fehlers beim Bearbeiten der Datei. Und wer hat in Vim noch keinen Fehler gemacht?
# cp /etc/ssh/sshd_config ~/sshd_config_original Sehen Sie, das ist nicht so schlimm.
Herausforderung – Sichern Sie Konfigurationsdateien konsequent, bevor Sie größere Änderungen vornehmen?
2. Legen Sie eine Bannernachricht fest
Zugegeben, hier geht es genauso um gesetzliche Anforderungen wie um alles andere, aber auch diese Einstellung dauert nur einen Moment. Sie können auch in Bannernachrichten einige ziemlich gute Informationen bereitstellen. Zuerst schreiben wir die Bannernachricht in /etc/issue.net Datei mit Vim. Dann öffnen wir die sshd_config -Datei und weisen Sie sie an, den Inhalt von issue.net zu verwenden als Banner.
# vim /etc/issue.net
Warning! Authorized use only.
This server is the property of MyCompanyName.com [Das könnte Ihnen auch gefallen: SSH-Passwortautomatisierung in Linux mit sshpass ]
Natürlich möchten Sie sich etwas einfallen lassen, das für Ihre Organisation spezifisch ist. Entfernen Sie alle Informationen, die sich bereits in issue.net befinden Datei.
Weisen Sie als Nächstes SSH an, die Bannernachricht zu verwenden. Öffnen Sie die sshd_config Datei in Vim und finden Sie die Zeile, die Banner liest . Sie erinnern sich, dass Sie den Schrägstrich im Befehlsmodus von Vim verwenden können, um eine Datei mit Schlüsselwörtern zu durchsuchen, richtig? Beispiel:/banner
# vim /etc/ssh/sshd_config Suchen Sie die Zeile mit der Aufschrift # no default banner path , und kommentieren Sie dann die nächste Zeile aus (da steht Banner ).
# no default banner path
Banner /etc/issue.net Speichern Sie Ihre Änderungen in Vim mit :wq und starten Sie dann den SSH-Dienst neu:
# systemctl restart sshd Hinweis:Ich werde Sie ab diesem Zeitpunkt nicht daran erinnern, SSH neu zu starten. Jedes Mal, wenn Sie eine Änderung an der Konfigurationsdatei vornehmen, müssen Sie den Dienst neu starten.
Herausforderung – Ist die Bannernachricht auf allen SSH-Geräten in Ihrem Netzwerk konsistent?
3. Leere Passwörter verhindern
Das scheint ein Kinderspiel zu sein, aber leere Passwörter sind eindeutig eine schlechte Idee. Möglicherweise haben Sie andere Dienstprogramme wie Pluggable Authentication Modules (PAM), die Ihre regulären Passwörter regulieren, aber es ist auch eine gute Idee sicherzustellen, dass SSH auch verantwortungsvolle Sicherheitseinstellungen erzwingt.
Öffnen Sie die /etc/ssh/sshd_config Datei in Vim und suchen Sie dann die Zeile, die PermitEmptyPasswords liest . Entkommentieren Sie es und ersetzen Sie das yes Wert mit nein .
PermitEmptyPasswords no Das ist es.
4. Verhindern Sie, dass der Root-Benutzer das Netzwerk über SSH durchquert
Die Idee hier ist ziemlich einfach. Senden Sie anstelle von Root-Anmeldeinformationen standardmäßige Benutzeranmeldeinformationen über das Netzwerk. Sobald Sie Ihre SSH-Verbindung mit einem Standardbenutzerkonto hergestellt haben, verwenden Sie su oder sudo um Ihre Privilegien zu erhöhen.
Öffnen Sie die SSH-Konfigurationsdatei und kommentieren Sie dann PermitRootLogin aus Linie. Bearbeiten Sie die Einstellung von Ja auf nein .
PermitRootLogin no
Herausforderung – Ihre Organisation hat sudo angenommen , richtig?
5. Bestimmte Benutzerkonten auf die weiße Liste setzen
Wenn Sie bereits die Verwendung des Root-Benutzerkontos über SSH verhindern, warum gehen Sie nicht einen Schritt weiter und geben explizit an, welche Benutzer darf mit dem Server verbinden? Vielleicht haben Sie ein reguläres Nicht-Root-Administratorkonto, das Sie verwenden, oder eines, das bereits mit sudo konfiguriert ist Privilegien.
Fügen Sie in der SSH-Konfigurationsdatei die folgende Zeile hinzu (standardmäßig nicht enthalten):
AllowUsers user1 Ich würde es in die Nähe der PermitRootLogin-Nr stellen Einstellung.
Übrigens können Sie tatsächlich mit allen folgenden Einstellungen filtern:AllowUsers , Benutzer verweigern , Gruppen zulassen , Gruppen verweigern . Ich habe sie absichtlich in dieser Reihenfolge geschrieben – das ist die Reihenfolge, in der sie verarbeitet werden. Weitere Informationen finden Sie auf der Manpage für sshd_config .
Herausforderung - achten Sie genau darauf, wer autorisiert ist.
Hinweis:Sie können Verbindungen auch über iptables einschränken.
6. Kein Port 22 mehr
Eine weitere häufige Änderung besteht darin, SSH so zu konfigurieren, dass es auf einem anderen Port als dem standardmäßigen 22/tcp lauscht die wir alle auswendig gelernt haben. Es gibt bereits einen Eintrag in der sshd_config Datei.
Sie können die Standardporteinstellung auskommentieren und eine weitere Zeile hinzufügen, wie ich es unten getan habe:
#Run SSH on a non-standard port
#Port 22
Port 2222 Ich vermute, dass viele Leute 2222 als Ersatz-Portnummer verwenden, also sollten Sie vielleicht etwas Einzigartigeres verwenden.
Sie müssen daran denken, ab diesem Zeitpunkt die neue nicht standardmäßige Portnummer an Ihre SSH-Verbindungsversuche anzuhängen. Zum Beispiel:
# ssh -p 2222 [email protected] Frage:Haben Sie für alle Ihre SSH-Ziele dieselbe nicht standardmäßige Portnummer konfiguriert? Konsistenz wird Ihr Leben viel einfacher machen.
7. Die Zeit ist um!
Der nächste Tipp befasst sich mit dem Timeout von Verbindungen. Das ClientAliveInterval verwaltet inaktive SSH-Verbindungen. Der Server sendet eine Nachricht an den Client und erwartet eine Antwort. Das ClientAliveInterval ist der Zeitraum zwischen den Nachrichten. Der ClientAliveCountMax definiert, wie oft der Server dies tut, bevor er entscheidet, dass der Client nicht mehr wirklich da ist. An diesem Punkt wird die Verbindung getrennt.
Hier ist eine Beispielkonfiguration, die alle 60 Sekunden eine Überprüfung durchführt, und zwar dreimal:
ClientAliveInterval 60
ClientAliveCountMax 3 Bearbeiten Sie diese Werte so, dass sie für Ihre Umgebung sinnvoll sind.
Hinweis:Wenn Sie SSH zum Tunneln für andere Verbindungen verwenden, müssen Sie möglicherweise sicherstellen, dass das Intervall lang genug ist, um alle anderen Anwendungen, die es verwenden, ordnungsgemäß zu unterstützen.
Es gibt ein ServerAliveInterval Wert, den Sie auch clientseitig konfigurieren können. Dadurch können Clients Verbindungen zu nicht reagierenden SSH-Servern trennen.
8. Hier ist der Schlüssel
Eine der heutzutage am häufigsten verwendeten Sicherheitseinstellungen für SSH ist die schlüsselbasierte Authentifizierung. Im Laufe der Jahre, in denen ich Linux unterrichtet habe, ist diese Authentifizierungsmethode immer häufiger geworden. Tatsächlich würde ich kein Red Hat Admin Exam absolvieren, ohne mich in diesem Prozess sicher zu fühlen. Glücklicherweise ist es nicht schwierig.
Machen wir eine kurze Überprüfung. Die schlüsselbasierte Authentifizierung verwendet asymmetrische Kryptografie. Das bedeutet, dass es zwei Schlüssel gibt, die unterschiedlich, aber mathematisch miteinander verwandt sind. Einer ist privat und wird nie über das Netzwerk gesendet. Der andere ist öffentlich und kann über das Netzwerk übertragen werden. Da die Schlüssel verwandt sind, können sie verwendet werden, um Identitäten zu bestätigen – Identitäten wie SSH-Authentifizierungsversuche.
Sie müssen das Schlüsselpaar auf dem lokalen SSH-Clientcomputer generieren und dann den öffentlichen Schlüssel über das Netzwerk an den Ziel-SSH-Server übertragen. Mit anderen Worten, die Schlüssel identifizieren Sie auf Ihrer Administrator-Workstation. Sobald diese Konfiguration eingerichtet ist, werden Sie nicht mehr nach einem Passwort gefragt, wenn Sie eine SSH-Verbindung herstellen.
Der Vorgang erfordert nur wenige Schritte.
Generieren Sie zuerst das Schlüsselpaar:
# ssh-keygen
Die Schlüssel werden in Ihrem Home-Verzeichnis in einem versteckten Verzeichnis namens .ssh gespeichert , und die Standardschlüsselnamen sind id_rsa (privater Schlüssel) und id_rsa.pub (öffentlicher Schlüssel).
Senden Sie als Nächstes den öffentlichen Schlüssel von user1 über das Netzwerk an den SSH-Zielserver unter 10.1.0.42:
# ssh-copy-id [email protected] Testen Sie abschließend die Verbindung:
# ssh [email protected] Beachten Sie, dass Sie nicht nach einem Passwort gefragt werden.
Da Sie jetzt die schlüsselbasierte Authentifizierung angenommen haben, können Sie die sshd_config bearbeiten -Datei, um alle Anmeldungen basierend auf Passwörtern zu verhindern. Sobald Sie diese Einstellung konfiguriert haben, wird nur die schlüsselbasierte Authentifizierung akzeptiert.
Bearbeiten Sie diese beiden Zeilen in der Datei:
PasswordAuthentication no
PublicKeyAuthentication yes [ Möchten Sie mehr über Sicherheit erfahren? Schauen Sie sich die Checkliste für IT-Sicherheit und Compliance an. ]
Abschluss
Ich habe einige gängige, aber effektive SSH-Konfigurationen aufgelistet, die Ihnen dabei helfen, Ihre Umgebung besser zu sichern. Denken Sie daran, dass mit Sicherheit wahrscheinlich keine Einstellung Ihre Geräte schützt. Das Ziel sind Sicherheitsebenen, deren Kombination dazu beiträgt, Sicherheitsbedrohungen zu mindern. Ich empfehle dringend, dass Sie Ihre Schlüssel sorgfältig organisieren, wenn Sie die schlüsselbasierte Authentifizierung implementieren. Sie können auch eine zentralisierte /etc/ssh/sshd_config verwenden -Datei, um konsistente Sicherheitskonfigurationen auf Ihren SSH-Servern aufrechtzuerhalten. Vergessen Sie nicht, SSH jedes Mal neu zu starten, wenn Sie die Konfigurationsdatei ändern.