Trickkiste: SSH absichern – aber richtig!
SSH? Brauchichnich – hab' doch Telnet...
Diese Auffassung mag in einer gesicherten Umgebung (z. B. einem privaten
Netzwerk ohne direkten Zugang von außen) noch angehen, aber sowie eine
Verbindung über das Internet vonnöten ist, ist sie extrem gefährlich.
Das Problem ist, daß Telnet eine unsichere Verbindung aufbaut, die auf dem
kompletten Weg von Ihrem Rechner zu seinem Ziel jederzeit eingesehen werden
kann. Ein Problem ergibt sich immer dann, wenn ein Rechner auf der aktuellen
Route nicht ganz sauber tickt und z. B. den Datenverkehr mitschneidet.
Man möchte jetzt argumentieren, daß der Rechner nicht die passende
Netzwerkadresse hat und somit gar nicht der Empfänger sein kann – nur gibt
es eine Möglichkeit, eine Netzwerkkarte so einzurichten, daß sie auf
jedes Datenpaket reagiert, das sie erreicht, egal ob
sie als Empfänger eingetragen wurde oder nicht: Es ist der
Promiscuous Mode.
Zwar hat dieser Betriebsmodus sehr wohl seine Berechtigung (ohne ihn wären
verschiedene Netzwerkfunktionen schlichtweg nicht möglich), aber leider bietet
er auch Raum für Mißbrauch.
Sicherheitsrisiko Klartext
Wie der Name schon sagt: Ohne geeignete Maßnahmen ist der gesamte Datenstrom
von einem zu irgendeinem anderen Rechner von jedem auf dem Weg dorthin
befindlichen Rechner jederzeit einsehbar. Zwar werden diese nicht weiter auf
den Datenstrom reagieren, Probleme ergeben sich jedoch immer dann, wenn auf
irgendeiner der Zwischenstationen der Datenverkehr mitgeschnitten wird.
Dies kann sich zwar als harmlos entpuppen, weil hier möglicherweise jemand auf
der Suche nach Fehlern oder anderen Problemen ist, aber es könnte auch sein,
daß irgendwer nach sensiblen Daten (als Möglichkeiten seien hier einmal
Zugangskennungen, also Nutzername und Passwort, oder Kontoinformationen oder
andere nicht für die Öffentlichkeit bestimmte Daten genannt) sucht – und die
Intention dahinter ist alles andere als gut.
Um hier also keine böse Überraschung zu erleben, ist es erforderlich, daß der
Datenstrom unkenntlich gemacht wird. Denn wo niemand etwas Brauchbares erkennen
kann, da schnüffelt auch keiner.
Sicherheitsrisiko Verbindungsziel
Sie werden sich wahrscheinlich fragen, weshalb gerade
dies ein Problem sein soll. Schließlich gibt es ja
eine eindeutige Zuordnung zwischen IP-Adressen und Verbindungsziel...
Doch der Teufel steckt, wie so oft, im Detail.
Wie bereits erwähnt, gibt es eine Möglichkeit, Datenverkehr auf andere Rechner
umzuleiten (Promiscuous Mode der Netzwerkkarte), ganz zu schweigen von
Adreßspoofing.
Um hier also nicht vom Regen in die Traufe zu kommen, muß etwas her, das die
Authentizität eines Ziels bestätigt. Denn wenn man sich sicher sein kann, daß
man mit dem richtigen Ziel verbunden ist, dann braucht man sich auch keine
Sorgen zu machen, daß irgendetwas Seltsames passiert.
Weshalb soviel Aufhebens?
Das läßt sich ganz einfach sagen: Es geht um die Sicherheit im Internet. Denn
wenn man sicher über das Internet arbeiten will, dann muß man dafür Sorge
tragen, daß man erstens das Ziel zu fassen bekommt, das man erreichen möchte,
und zweitens niemand mitlesen kann, was auf der Verbindung stattfindet.
Denn nur so ist auf Dauer ein sicheres Arbeiten über das Internet
gewährleistet.
Und genau hier setzt SSH an. Auf diesem Wege öffnet man eine Verbindung, die
nicht nur die Authentifizierung des Nutzers erlaubt, sondern auch noch die
Authentizität des Ziels überprüft und dafür sorgt, daß der Datenstrom zwischen
Anwender und Zielrechner für allzu neugierige Augen verschlüsselt wird.
Verschlüsselt, aber...
SSH verfügt, wie bereits festgestellt, über mächtige Möglichkeiten, um für Sicherheit beim Arbeiten zu sorgen, aber dennoch bleibt noch ein Wermutstropfen: Die Authentifizierung eines Nutzers. Hierbei wird i. d. R. eine Kombination aus Nutzername und Passwort verwendet, allerdings versuchen etwaige Angreifer hier dann oftmals, das Passwort herauszufinden – leider in einigen Fällen von Erfolg gekrönt...
nach obenSicherheitsrisiko Passwort
Denn das Passwort stellt in allzu vielen Fällen ein Problem dar. Leider werden
hier Wörter verwendet, die man ganz einfach durch eine Wörterbuchattacke
herausfinden kann, wodurch ein Angreifer schnell Zugang zum System bekommt. In
anderen Fällen werden Passwörter gewählt, die man anderweitig sehr leicht
herausfinden kann (Name des Haustieres, Geburtsname, Name der Eltern, usw.).
Leider nützen die besten Sicherheitsvorkehrungen von SSH nichts, wenn die
Schnittstelle zum Nutzer, sprich die Authentifizierung, die Schwachstelle im
ganzen System ist. So ist dann nämlich wieder nichts gewonnen, und man hat den
Angreifer wieder ganz schnell auf dem Rechner.
Also muß eine andere Methode her, die für wesentlich mehr Sicherheit bei der
Authentifizierung sorgt, aber auch hier ist SSH uns behilflich.
Vorbereitungen
Um Wörterbuchangriffen und den meisten
Brute-force-Angriffen
zu begegnen, brauchen wir etwas, das nicht so ohne Weiteres zu fälschen ist.
Erzeugen Sie dazu ein RSA-Schlüsselpaar, das Sie als
Authentifizierungsinformation für SSH verwenden können.
Öffnen Sie dazu eine Shell und geben Sie folgenden Befehl ein:
ssh-keygen -t rsa -f id_rsa
Sie
können die Schlüssel aber auch gleich hier generieren.
Das Programm fragt Sie anschließend nach einer Passphrase, mit der der private
Schlüssel gesichert werden kann. Wenn keine fremde Person Zugang zu Ihrem
Rechner hat, dann können Sie hier einfach RETURN
drücken. Ansonsten geben Sie hier etwas ein (kann beliebig lang sein, aber Sie
sollten es sich immer noch merken können!) und bestätigen die Passphrase.
ssh-keygen wird jetzt das Schlüsselpaar
erzeugen. Auf diese Art und Weise erhalten Sie zwei Dateien:
id_rsa und id_rsa.pub.
Die Datei id_rsa ist Ihr geheimer Schlüssel, der
auf Ihrem Rechner verbleibt. Kopieren Sie diese Datei nach
~/.ssh.
Die andere Datei, id_rsa.pub, wandert dabei auf Ihren
entfernten Rechner. Führen Sie dazu folgendes Kommando aus:
scp id_rsa.pub root@<hostname>:/root/.ssh/authorized_keys
(ersetzen Sie <hostname> durch den tatsächlichen Namen Ihres
entfernten Rechners)
Bestätigen Sie mit dem root-Passwort des entfernten
Rechners, und er öffentliche Schlüssel wird übertragen.
Wenn Sie einen weiteren RSA-Schlüssel auf Ihrem Rechner importieren wollen, nachdem bereits welche installiert sind, dann dürfen Sie den neuen Schlüssel unter gar keinen Umständen einfach nur nach ~/.ssh/authorized_keys kopieren, da dies die alten Schlüssel überschreibt!
Kopieren Sie ihn stattdessen zunächst einmal nach /root und übertragen ihn dann manuell in die andere Datei!
Beachten Sie bitte, daß Sie in einer Zeile immer nur einen einzigen Schlüssel stehen haben, um Probleme zu vermeiden.
Jetzt haben Sie die notwendigen Vorbereitungen getroffen, um SSH noch sicherer
zu gestalten.
Sollten Sie die Authentifizierung mittels RSA-Schlüsseln bereits aktiviert
haben, so können Sie sich nicht mehr mittels Nutzername und Passwort
anmelden, sondern Sie müssen dann zwingend die
Passphrase des alten Schlüssels angeben, um Daten zu übertragen oder sich
anzumelden! Sonst verweigert SSH die Mitarbeit und wird den Anmeldeversuch
abweisen.
Die richtige Konfiguration
Nachdem Sie Ihre RSA-Schlüssel erzeugt und auf die richtigen Rechner verschoben
haben, müssen Sie SSH noch richtig konfigurieren. Dazu ist es sowohl auf Ihrem
lokalen als auch dem entfernten Rechner notwendig, die zugehörigen
Konfigurationsdateien anzupassen.
Schauen Sie sich also zunächst einmal die Konfigurationsdatei für den
SSH-Client auf Ihrem Rechner an:
- Öffnen Sie dazu zunächst eine Shell mit root-Rechten.
- Wechseln Sie in das Verzeichnis /etc/ssh.
- Laden Sie die Datei ssh_config in Ihren Editor.
- Suchen Sie nach den Zeilen, die den Begriff IdentityFile enthalten.
- Wenn noch nicht geschehen, aktivieren Sie die Zeile (Entfernen Sie dazu das #).
- Wenn Sie wünschen, dann können Sie zusätzlich die Zeile mit VisualHostKey auf yes. Auf diesem Wege zeigt SSH Ihnen den Schlüssel auf dem entfernten Rechner an, und Sie können im Bedarfsfalle feststellen, ob irgendetwas nicht stimmt.
- Speichern Sie die Datei anschließab.
Danach wird der SSH-Client bei seinem nächsten Aufruf die so angemeldete
Schlüsseldatei für eine Authentifizierung mittels RSA-Schlüsseln
berücksichtigen. Übrigens können Sie auf diesem Wege Ihrem Client mehrere
Schlüsseldateien bekannt machen, z. B. wenn Sie über mehr als einen entfernten
Rechner (z. B. irgendwelche Server) verfügen. Fügen Sie für jeden Schlüssel
einfach eine weitere Zeile mit IdentityFile hinzu.
Anschließend sind einige Anpassungen auf Ihrem entfernten Rechner vonnöten.
- Loggen Sie sich auf Ihrem entfernten System als root ein (anfangs verwenden Sie zur Authentifizierung das zugehörige Passwort).
- Wechseln Sie in das Verzeichnis /etc/ssh.
- Laden Sie die Datei sshd_config in Ihren Editor.
- Suchen Sie anschließend nach den in der nachstehenden Tabelle aufgeführten Zeilen und passen Sie sie wie angegeben an. Im Bedarfsfalle entfernen Sie das # am Anfang einer Zeile.
- Speichern Sie die Datei und verlassen Sie Ihren Editor.
- Führen Sie dann systemctl restart sshd.service aus.
Danach sind Sie gesetzt, und etwaige Angreifer haben es zukünftig deutlich schwerer, sich auf Ihrem entfernten Rechner einzschleichen.
Konfigurationspunkte für ein sicheres Arbeiten mit SSH | ||
---|---|---|
Parameter | Wert | Erläuterung |
Protocol | 2 | Legt die Version des verwendeten SSH-Protokolls fest. Protokollversion 2 (der Default) ist die deutlich sicherere Variante. |
PubkeyAuthentication | yes | Erlaubt die Authentifizierung mittels erzeugter Schlüsselpaare. Da diese Methode sicherer ist als die Authentifizierung mit Nutzername und Passwort, aktivieren Sie diese bitte. |
AuthorizedKeysFile | .ssh/authorized_keys | Gibt die Datei an, in denen die autorisierten Schlüssel für den Login
stehen. Für maximale Sicherheit belassen Sie diesen Wert einfach wie er ist,
zumal es etwaigen vorhandenen anderen Nutzern so erlaubt, ihre eigenen
Schlüssel zu installieren. WICHTIG: Wenn Sie diesen Pfad ändern, dann müssen Sie die Datei authorized_keys an den entsprechenden Ort verschieben und (wenn Sie zudem noch einen anderen Namen gewählt haben) ggf. passend umbenennen. Sonst sperren Sie sich auf diesem Wege sehr elegant selbst aus! |
HostbasedAuthentication | no | Wie PubkeyAuthentication, nur wird zusätzlich versucht die Datei ~/.ssh/rhosts respektive /etc/hosts.equiv abzufragen. Da Sie meist jedoch mit einer dynamischen (durch Ihren Provider bei jedem erneuten Verbindungsaufbau vergebenen) IP-Adresse operieren, werden Sie sich so wahrscheinlich selbst aussperren, von daher ist diese Option recht sinnfrei. |
PasswordAuthentication | no | Da Sie eine sichere Methode für das Login haben wollen, sind in Relation unsicherere Methoden schlichtweg zu deaktivieren. Setzen Sie diese Option daher auf no (Default wäre yes). |
ChallengeResponseAuthentication | no | Basiert meist ebenfalls auf einer Anmeldung mittels Nutzername und Passwort. Ist daher ebenso abzuschalten wie PasswordAuthentication. |
UsePAM | yes | Selbst wenn Sie die Login-Möglichkeiten mittels Passwort und Challenge-Response deaktiviert haben, kann das PAM-Modul noch hilfreiche Dienste leisten, indem es einige Überprüfungen bei einem Login-Versuch vornimmt. |
Legen Sie sich auf jeden Fall eine Sicherungskopie Ihres privaten Schlüssels an! Sollten Sie ihn jemals verlieren, so haben Sie keine Chance mehr, auf diesem Wege Verbindung zu Ihrem entfernten Rechner aufzunehmen!
Alternativ sollten auf jeden Fall über eine andere Login-Möglichkeit verfügen (z. B. Telnet in einem IPsec-Tunnel oder – wenn von Ihrem Hoster angeboten – eine Remote-Konsole), mit der Sie im Bedarfsfalle Zugang bekommen können!
nach oben
Angreifer – ausgesperrt!
Durch Anpassung der Konfiguration von SSH haben Sie auf jeden Fall schon mal
für mehr Sicherheit auf Ihrem Rechner gesorgt. In Kombination mit
einer Firewall können Sie etwaigen Angreifern das
Leben richtig schwer machen!
Dazu fügen Sie in der Datei /etc/rc.local einige
iptables-Befehle hinzu, die diesen einige zusätzliche
Steine in den Weg legen. Die notwendigen Änderungen habe ich
beim Thema Firewall
eingehend beschrieben.
Wer jetzt einen Brute-force-Angriff auf Ihren entfernten Rechner versucht, wird
sehr schnell feststellen, daß er sich unvermittelt ausgesperrt wiederfindet,
und wer es übertreibt, der muß noch länger warten, bis er überhaupt eine
Reaktion bekommt. Auf jeden Fall wird der SSH-Daemon vorübergehend nicht mehr
mit solchen ungültigen Verbindungsversuchen belastet.
Und sollten Sie wider Erwarten in Ihren eigenen Sicherheitsvorkehrungen
hängenbleiben, so ist das kein Grund zur Panik. Warten Sie einfach die zwei
Stunden Sperrzeit ab und versuchen Sie es dann erneut – oder schaffen Sie sich
eine Ausweichmöglichkeit, um sich einloggen zu können (z. B. per Telnet in
einem IPsec-Tunnel).