SSH oder Secure SHell ersetzte Telnet irgendwann in den 1990er Jahren als bevorzugtes Fernzugriffsprotokoll, und das aus gutem Grund. SSH ermöglicht Administratoren – oder Benutzern – den Zugriff auf eine Remote-Shell über einen sicheren Tunnel, indem sie ihren SSH-Client mit einem SSH-Server verbinden. SSH kann auch Dateiübertragungen handhaben, die FTP ersetzen sollten, obwohl es eine überraschende Anzahl von Situationen gibt, die immer noch auf das gute alte Klartext-FTP angewiesen sind.
Wieso den? Ähm.
Aus den oben genannten Gründen werden moderne Linux-Systeme über SSH verwaltet. Die meisten erfahrenen Systemadministratoren lieben den direkten Zugriff und die Leistung, die sie erhalten, wenn sie sich relativ einfach und sicher mit der Shell ihres Systems verbinden. In diesem Artikel werde ich speziell auf den OpenSSH-Server-Daemon sshd eingehen . Wir behandeln einige der Sicherheitsprobleme, auf die Sie stoßen können, und wie Sie sie mindern oder vollständig lösen können.
Warum wir SSH brauchen
Wie ich bereits erwähnt habe, ist SSH ein mächtiges Werkzeug. Über eine SSH-Sitzung können Sie ein virtuelles Terminal direkt mit Ihrem Zielsystem verbinden. In den falschen Händen kann diese Fähigkeit problematisch sein, also warum lassen wir diese Macht zugänglich? Nun, die Leistungsfähigkeit von SSH beinhaltet ein empfindliches Gleichgewicht. Innerhalb von Minuten kann ein Administrator eine sichere Sitzung für seinen Server öffnen, um auf einen Vorfall zu reagieren. Die Einfachheit ist elegant.
SSH ist auch der Kern von Automatisierungstools wie Ansible. Ansible kann über SSH Änderungen an einem System vornehmen, ohne dass ein Agent erforderlich ist. Alle Änderungen werden stattdessen über SSH und Python durchgeführt.
SSH kann, wie bereits erwähnt, auch für sichere Dateiübertragungen verwendet werden. Beispiel:rsync Tunnel durch SSH für eine sichere Datensynchronisierung. SSH kann auch verwendet werden, um durch ein System zu tunneln, um zu einem anderen zu gelangen, was großartig für die Fehlersuche, aber auch großartig für einen Angreifer ist.
Wenn Sie die vorangegangenen Absätze nicht überzeugt haben, sage ich es noch einmal:SSH ist ein mächtiges Werkzeug, und wie jedes mächtige Werkzeug kann es missbraucht werden. Wenn ein Angreifer eine sichere Shell in Ihr System bringen kann, ist das Spiel vorbei. Und Angreifer wissen das, also suchen sie ständig nach Systemen mit SSH, die für die Welt offen sind, damit sie angreifen können.
SSH sperren
Der häufigste Angriff gegen SSH ist Brute Force. Auf meinen Systemen ist mir persönlich noch nie ein Brute-Force-Angriff gegen SSH gelungen. Bevor ich jedoch anfing, einfache Sperrregeln zu befolgen, kann ich Ihnen sagen, dass sie es auf jeden Fall versucht haben.
Eine schnelle Suche auf Shodan – einer Suchmaschine, die auf mit dem Internet verbundene Geräte abzielt – zeigt 20.984.090 Systeme mit weltweit offenem SSH. Müssen sie so eingerichtet werden? Ich kann Ihnen fast garantieren, dass jedes einzelne dieser Systeme mehrere SSH-Brute-Force-Angriffe pro Sekunde erhält. Während ich diesen Artikel schrieb, startete ich ein Droplet auf Digital Ocean, ließ SSH für die Welt offen und verfolgte /var/log/secure . Innerhalb von etwa 20 Minuten sah ich die erste SSH-Sonde. Innerhalb einer Stunde begann die Flut von Brute-Force-Angriffen.
Jun 23 01:35:33 centos-s-1vcpu-1gb-sgp1-01 sshd[10926]: Did not
receive identification string from 81.22.45.137 port 61000
Jun 23 01:37:47 centos-s-1vcpu-1gb-sgp1-01 sshd[10928]: Invalid
user fake from 104.248.132.25 port 36050
Jun 23 01:37:47 centos-s-1vcpu-1gb-sgp1-01 sshd[10928]:
input_userauth_request: invalid user fake [preauth]
Jun 23 01:37:47 centos-s-1vcpu-1gb-sgp1-01 sshd[10928]: Received
disconnect from 104.248.132.25 port 36050:11: Bye Bye [preauth]
Kurz gesagt, ein schlechtes Passwort auf einem standardmäßigen sshd Die Installation könnte alles sein, was zwischen den Bösewichten und Ihrem System steht. Während die Standardkonfiguration für OpenSSH anständig sicher ist, kann sie gehärtet werden. Zum Glück habe ich Vorschläge.
Beschränken Sie den Zugriff auf Port 22
Überprüfen Sie zunächst, ob der Standard-SSH-Port (Port 22) für die Welt offen ist. Sie können dies tun, indem Sie Nmap ausführen, das Ihr Netzwerk gemäß Ihren Spezifikationen prüft:
Starting Nmap 7.70 ( https://nmap.org ) at 2019-06-22 20:56 EDT
Nmap scan report for 167.71.200.117
Host is up (0.26s latency).
Not shown: 995 closed ports
PORT STATE SERVICE
22/tcp open ssh Das Eingrenzen, wer auf Port 22 zugreifen kann, ist die grundlegendste Maßnahme, die Sie ergreifen können, um Ihr System zu sichern. Mir ist klar, dass diese Taktik möglicherweise nicht für jedes Szenario funktioniert. Vielleicht betreiben Sie ein öffentlich genutztes System, oder vielleicht ist der CIO viel unterwegs und greift von vielen verschiedenen Orten aus auf Systeme zu (wir werden gleich über VPNs sprechen). Mein Punkt ist, dass Sie möglicherweise einen triftigen Grund haben, warum SSH unbedingt für die breite Öffentlichkeit zugänglich sein muss. Denken Sie sehr schwer, diese Konfiguration zu vermeiden. Ich habe es getan, aber hauptsächlich aus Faulheit. Normalerweise gibt es einen besseren Weg.
Wenn Sie einen Cloud-Anbieter verwenden, konfigurieren Sie eine Sicherheitsgruppe, um nur SSH-Datenverkehr von dem Netzwerk zu akzeptieren, in dem Sie arbeiten. Diese Aufgabe sollte einfach sein, wenn Sie von einer Unternehmensumgebung aus auf diesen Anbieter zugreifen. Sie haben wahrscheinlich Ihren eigenen IP-Adressbereich, was bedeutet, dass Sie ihn auf die weiße Liste setzen und alles andere blockieren können. Wenn Sie jedoch von zu Hause aus auf den Cloud-Anbieter zugreifen, müssen Sie möglicherweise einige Tricks anwenden, um den dynamisch zugewiesenen IP-Block Ihres ISP auf die Whitelist zu setzen. Wenn Sie eine Sicherheitsgruppe verwenden, sollten Sie den IP-Adressbereich bei Bedarf über das Self-Service-Portal Ihres Cloud-Anbieters ändern können.
Wenn Sie ein System hosten, das sich nicht hinter einer Firewall befindet, verwenden Sie die hostbasierte Firewall, um Port 22 von überall außer Ihrem IP-Adressbereich zu blockieren, indem Sie die gleichen Methoden verwenden, die ich gerade beschrieben habe. Das Problem dabei ist natürlich, dass es Ihnen schwerer fällt, die erforderlichen Änderungen vorzunehmen, wenn Sie gesperrt werden, weil sich Ihre IP-Adresse geändert hat.
Und vergessen Sie nicht, dass eine Unternehmensumgebung Vorteile hat. Wenn sich Ihr Server in einem Unternehmensnetzwerk befindet, besteht eine gute Chance, dass es eine Netzwerk-Firewall gibt, mit der Sie den SSH-Zugriff sperren können, also nutzen Sie diese Tatsache zu Ihrem Vorteil. Defense-in-Depth Leute, das ist eine Sache!
VPN für Fernzugriff erforderlich
Ok, reden wir also über diesen reisenden CIO, der unbedingt braucht Zugriff auf ssh von einem Hotelzimmer aus. Die Lösung scheint für diejenigen von uns, die um den Block herum gewesen sind, offensichtlich zu sein, aber wenn Sie erwägen, den SSH-Zugang für die ganze Welt zu öffnen, müssen Sie vielleicht Folgendes hören:Mit einem VPN oder Virtual Private Network können Sie einen verschlüsselten Tunnel aufbauen von einem Endpunkt – wie dem Laptop Ihres CIO in diesem Hotel in Maui – zurück zu Ihrem Unternehmensnetzwerk in Seattle. Diese Verbindung ist auf eigene Weise geschützt und verschlüsselt.
Ihre Dutzende von Servern, die für die Welt nicht zugänglich sind, könnten jedoch über diesen einzigen Punkt zugänglich werden. Ja, diese Vorgehensweise verschiebt das Angriffsziel auf das VPN, aber das bedeutet, dass es eine weitere Hürde für die Bösewichte gibt, die es zu überwinden gilt.
Root-Zugriff verweigern
Jetzt kommen wir zum eigentlichen sshd Aufbau. Der OpenSSH-Daemon hat eine Option namens PermitRootLogin . Standardmäßig ist diese Option auf Yes eingestellt , da bei der Installation einiger Systeme zunächst nur root vorhanden ist. In diesem Fall benötigen Sie das Root-Konto, um auf das System zuzugreifen und die Erstkonfiguration durchzuführen.
Ich empfehle, während des Installationsvorgangs oder als Teil Ihres Golden Image einen Benutzer hinzuzufügen und Root-Logins von Anfang an zu deaktivieren. Es gibt keinen Grund, sich als Root anzumelden, und es gibt sicherlich keinen Grund, sich als Root über SSH anzumelden. Ändern Sie also die Konfigurationszeile in:
PermitRootLogin no Schlüsselbasierte Authentifizierung implementieren
Ursprünglich habe ich die schlüsselbasierte Authentifizierung aus praktischen Gründen verwendet. Ich habe einen privaten Schlüssel generiert und den öffentlichen Schlüssel zu meinen authorized_keys hinzugefügt Datei auf den von mir verwalteten Servern und konnte mich dann ohne Passwort sicher mit meinen Systemen verbinden. Dies sparte Zeit und ermöglichte die Automatisierung. GEWINNEN! Erst später fand ich heraus, dass die schlüsselbasierte SSH-Authentifizierung genutzt werden kann, um Passwort-Brute-Force-Versuche zu eliminieren.
Um einen Schlüssel zu generieren, führen Sie ssh-keygen aus auf einem Mac oder einer Linux-Box. Vielleicht können Sie Windows-Leute dies jetzt nativ tun, aber auf Windows-Computern habe ich immer PuTTYGen verwendet (und dann den Schlüssel mit dem PuTTY-Client verwendet). Sie werden nach einem Schlüsseltyp und einer Länge gefragt. Ich habe in letzter Zeit 4096-Bit-RSA-Schlüssel erstellt. Je mehr Bits, desto schwieriger ist der Schlüssel zu knacken. Warum also nicht?
[gangrif@meliodas ~]$ ssh-keygen -b 4096
Generating public/private rsa key pair.
Enter file in which to save the key (/home/gangrif/.ssh/id_rsa): ./test-key
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in ./test-key.
Your public key has been saved in ./test-key.pub.
The key fingerprint is:
SHA256:xfHOf4t3V3CCkJ+3FbEnQusAjBwOjBXfOa9WdGXBMqc [email protected]
The key's randomart image is:
+---[RSA 4096]----+
| ++o.+. ....+o.|
| . .+o..+o+o+o..|
| o + =o=B..o|
| = *E.+.+|
| S o +. * |
| o .. .|
| o . o|
| . .o+|
| ...o|
+----[SHA256]-----+
Am Ende erhalten Sie eine neue Datei namens test-key (in diesem Fall) und test-key.pub . Der Schlüssel in test-key ist mein privater Schlüssel und test-key.pub enthält den öffentlichen Schlüssel. Schützen Sie den privaten Schlüssel mit Ihrem Leben. Sie können den öffentlichen Schlüssel jedoch überall herumliegen lassen, da er ohne den privaten Schlüssel nutzlos ist.
[gangrif@meliodas ~]$ cat test-key.pub
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQDAQxmjoHO6i4Kkq8vp49KtqAsMcw+ptgvd+PGjxVYkDPGdzRZpJhq0c3BDstFs86ENlojs61zZaP3MihLR0BlDdIyM3jh9TmVvmOPiylhu4X9QliAca/ODxyVp76OpTKm+QcgBi/7i/JNiJdEgcSy8izB0Oil7LZjIhS6wCs3mQFVbkPXPfe1lmHQIcuMDOKO0RuyecY/lrKodcr/YbEE4GsM/P11QdDPZ78lq83G3H5vqLqMrxVKkLw7Z4//+PZPFFxi/N1EBwBp/uPEo4MfD1IwSmnKromRlkYTdOYlbiCNosdvEobtMARySdqjv7RDn0Iwb3JxioUW6jQdAXfl8d01LvX/0Yb1tq5hF44ahwvI6TyoB4z3DRs+3cFiMPWQR7LK8/qQOvHk5I2NMBAV9KuSN2ML0d7xeB8tglw38PYjhZsXl/t2rAWT4n8PU0o6+Hrrli+WEfvk8QWpLesmBBmzG0sLjH0mXBU/xN4UBLLJNlrsUQ/TzEsdknntMhh7leOzechlU3PiTNuUitweT9NqLJwCP+CHbeSJn2M5qzb090CPnCGpnr2GOfm2dL+RfHQi2R1Cf04nBDq3WuhAPJY5SoEw2llfSgA2GlOdhcY9N9Bl9rLUBPgQ6ttBd7qZJ6E3BkiPlHnU+kSSpYr8Gkw1oDGbtd2UUjExZqvz4rQ== [email protected]
Kopieren Sie auf Computern, zu denen Sie eine Verbindung herstellen möchten, ohne ein Kennwort zu verwenden, den öffentlichen Schlüssel in .ssh/authorized_keys (oder lassen Sie es den Benutzer tun, je nach Situation). Jetzt sage ich ohne Passwort, aber Sie müssen den privaten Schlüssel trotzdem mit dem Passwort entsperren, das Sie während der Generierung festgelegt haben. Sie haben ein Passwort festgelegt, richtig?
Sie können diesen Schlüssel auch per Fernzugriff auf einen Server kopieren, indem Sie ssh-copy-id verwenden .
Kennwortbasierte Authentifizierung deaktivieren
Erinnern Sie sich, als ich sagte, dass Ihnen die schlüsselbasierte Authentifizierung die Möglichkeit eröffnet, SSH-Brute-Force-Versuche vollständig zu unterbinden? Nun, hier ist wie. Mit Ihren privaten und öffentlichen Schlüsseln fordert SSH Sie nicht mehr zur Eingabe eines Passworts auf, richtig? Warum also diesen Weg als Angriffsvektor offen lassen?
Auf jedem Linux-Server, den ich betreibe, füge ich meinen öffentlichen Schlüssel als Teil unserer Basisinstallation hinzu und schalte die SSH-Passwortauthentifizierung aus, bevor das System überhaupt das Netzwerk erreicht. Dies ist eine Einstellung direkt in sshd Konfigurationsdatei von . Auch hier erlaubt die Standardeinstellung eine Kennwortauthentifizierung, da diese Funktion für die Konfiguration funktionieren muss. Sobald Sie Ihre Schlüssel an Ort und Stelle haben, schalten Sie sie jedoch aus.
PasswordAuthentication no Herzlichen Glückwunsch, Sie sind jetzt immun gegen Passwort-Brute-Force-Angriffe.
SSH-Benutzergefängnis, mit chroot
Die chroot – normalerweise ausgesprochen „chi-root“ oder „ch-root“ – command ist ein nettes Werkzeug. Damit können Sie das Root-Verzeichnis ändern, das von einem Prozess und seinen Kindern gesehen wird, daher der Name. Es eignet sich hervorragend zur Fehlerbehebung bei einem System, bei dem Sie auf die Festplatte zugreifen können, aber nicht booten. Sie mounten einfach seine Festplatte und chrooten nach /mnt/whatever.
Dies ist auch ein nettes Sicherheitstool für so etwas wie einen Shell-Server. Sie können einen Benutzer bei der Anmeldung chrooten, sodass er den Rest des Dateisystems buchstäblich nicht sehen kann. Ich mache das nicht oft, aber es ist ein sehr praktikables Gefängnis für Benutzer. Ich habe hier eine anscheinend anständige Beschreibung gefunden.
Rotation
Es lohnt sich, über die Rotation von Passwörtern und SSH-Schlüsseln nachzudenken. Ich werde versuchen, die guten und schlechten hier zu skizzieren.
Passwortrichtlinie und -rotation
Ich werde die Passwortrichtlinie mit der Passwortrotation in einen Topf werfen, weil sie verwandt sind. Passwortrichtlinien, die Komplexität erzwingen, sind eine großartige Möglichkeit, Ihre Benutzer dazu zu bringen, ein „starkes“ Passwort zu wählen. Dies hat jedoch einige Vorbehalte, insbesondere wenn es mit einem willkürlichen (d. h. zeitgesteuerten) Kennwortablauf gekoppelt ist. Ich könnte einen ganzen Artikel darüber schreiben, wie ich zu Passwortrichtlinien und -rotation stehe, aber ich werde versuchen, es hier kurz zu halten.
Letztes Jahr hat NIST bei seinen Passwort-Richtlinien eine Art Kehrtwende vollzogen und einige ihrer Vorschläge geändert, die in den meisten unserer Köpfe während der meisten unserer Karrieren verwurzelt waren. Die Infosec-Community (in der ich mich versuche) schlägt seit Jahren vor, dass zufällige Passwörter mit 8 Zeichen oder eine Mindestlänge von 8 Zeichen mit strengen Komplexitätsregeln mehr zur HARM-Passworthygiene beitragen, als ihr zu helfen. Kombinieren Sie strenge Komplexitätsregeln mit einer Richtlinie für die Kennwortrotation von 3 bis 6 Monaten, und Sie bereiten Ihre Benutzer auf Frustration vor. Diese Frustration führt zur Wiederverwendung von Passwörtern und anderen schlechten Angewohnheiten. Denken Sie also gut darüber nach, ob Sie dies Ihren Benutzern aufzwingen wollen. Die neuen Empfehlungen laufen nur dann ab, wenn ein Verstoß oder eine Kompromittierung vermutet wird, und eine Richtlinie, die Ihre Benutzer zu starken Passphrasen anstelle von Passwörtern führt. „Das ist mein p@ssw0rd 2019.“ ist viel schwieriger zu erraten und zu knacken als „W1nt3r2019“. Was übrigens sowohl für Passwortsetzer als auch für Red Teamer eine häufige Anlaufstelle ist. Denken Sie jedoch daran, dass Sie dieses Problem möglicherweise nicht haben, wenn Sie intelligente Administratoren bitten, ihre Passwörter zu rotieren (weil sie verstehen, WARUM sie es tun und wie wichtig es ist). Aber für Ihre Benutzer im Allgemeinen gehören willkürliche Ablaufzeiten und komplexe „Passwörter“ der Vergangenheit an.
Rotation privater SSH-Schlüssel
Wie bei jedem Identifikator, der generiert werden kann, kann es sinnvoll sein, Ihren privaten Schlüssel regelmäßig zu rotieren. Ihr privater Schlüssel ist nicht ganz so leicht zu stehlen oder zu erraten wie ein Passwort, aber es ist möglich, dass jemand Ihren Schlüssel ohne Ihr Wissen gestohlen hat. Dies gerät in das Gebiet „Wie paranoid möchten Sie sein?“. Das Ändern des Passworts auf Ihrem privaten Schlüssel ist jedoch nicht gut genug. Dieses Passwort entsperrt diesen Schlüssel, wenn ich heute Ihren Schlüssel durchziehe und Sie Ihr Passwort morgen ändern, hat die Kopie Ihres Schlüssels, die ich habe, immer noch Ihr altes Passwort. Wenn Sie dies richtig machen wollen, müssen Sie einen ganz neuen Schlüssel generieren. Jetzt ist ein guter Zeitpunkt, um die Schlüssellänge zu verlängern, wenn sich der Standard erhöht hat, seit Sie zuletzt einen Schlüssel generiert haben. Vielleicht generieren Sie jedes Mal einen neuen Schlüssel, wenn Ihr Arbeitgeber Ihnen einen neuen Laptop ausstellt, vielleicht tun Sie es einmal im Jahr an Ihrem Arbeitsjubiläum. Ich habe jedoch keine Lösung gefunden, die dies für Sie erledigt.
Denken Sie daran, dass die Generierung eines neuen Schlüssels bedeutet, dass alle öffentlichen Schlüssel, die Sie auf der Welt haben, jetzt ungültig sind. Oder zumindest sind sie mit Ihrem neuen Schlüssel nicht gültig. Sie müssen wahrscheinlich Ihren alten Schlüssel verwenden, um Ihren neuen öffentlichen Schlüssel zu platzieren.
MFA
Multi-Faktor-Authentifizierung wird zur Norm. Einige Leute haben versucht zu behaupten, dass SSH-Schlüssel eine Form von MFA sind, sie sind es irgendwie nicht. Vor allem, wenn Sie die Passwortauthentifizierung deaktiviert haben. Sie können jedoch mfa wie TOTP oder YubiKey in die PAM-Konfiguration Ihres Systems integrieren. Zentrale Authentifizierungslösungen wie FreeIPA machen dies einfach.
Schlussfolgerung
Da haben Sie es also, ich hoffe, Sie nehmen diese Informationen und wenden sie auf Ihre Systeme an, um Ihre Sicherheit zu verbessern. Seien Sie nicht eines dieser 21 Millionen Systeme mit SSH, die für die Welt offen sind. Es gibt einfach keinen Grund dafür.
Danke fürs Lesen!
Dieser Artikel wurde ursprünglich auf Underground.org veröffentlicht. Wiederveröffentlicht mit Genehmigung.