Dieser Beitrag ist erschienen in freiesMagazin (Link) 11/2009 / Lizenz: GNU Free Documentation License (GNU FDL) (Link) / Autor: Mirko Lindner .
Wenn Sie diesen Artikel weiterverwenden möchten, beachten Sie bitte die Lizenzbedingungen. Vielen Dank.
SSH-Port absichern
von Mirko Lindner
In Zeiten, in denen Heimanwender eine dauerhafte Verbindung ins Internet und unerfahrene Spieler einen Linux-Server unterhalten, werden zunehmend auch private Systeme ein lohnendes Ziel feindlicher Angriffe. Nicht nur sogenannte „Skript-Kiddies“, sondern auch professionelle Anbieter von Bot-Farmen grasen systematisch die Adressbereiche ab und starten in regelmäßigen Abständen Angriffe auf Heimserver. Der wohl am häufigsten angegriffene Port ist dabei der SSH-Port. Dieser Artikel zeigt ein paar Möglichkeiten, wie man seine Systeme ein wenig sicherer machen kann.
Redaktioneller Hinweis: Der Artikel „SSH-Port absichern“ erschien erstmals bei Pro-Linux [1] und wird mit freundlicher Genehmigung des Autors unter der GNU Free Documentation License veröffentlicht [2].
Allgemeine Problematik
Das Netz scheint von bösen Buben und Crackern voll zu sein, denn auch nicht publik gemachte Server geraten zunehmend in die Schusslinie von zwielichtigen Gestalten. Die Vorgehensweise ist dabei fast immer dieselbe: Skriptgesteuert wird nach lohnenden Zielen gesucht. Um den Aufwand relativ klein zu halten, denn Zeit ist bekanntlich Geld, werden dabei nur bestimmte Ports abgefragt. Eines dieser lohnenden Ziele ist dabei der SSH-Port (22), der regelmäßig Opfer von Brute-Force oder Wörterbuch-Attacken wird.
Wer nun glaubt, dass sein Server außerhalb des Fokusses der Angreifer liege, weil seine IP-Adresse nicht öffentlich gemacht wurde, der irrt mitunter gewaltig. Gelegentliche Tests ergeben, dass auch neue Systeme in relativ kleinen Netzen bisweilen bis zu zweimal täglich Opfer von Angriffen werden. Die wohl bekanntesten Angriffe waren dabei Listen-Attacken, in denen beispielsweise versucht wird, das Passwort des Nutzers Root mittels vorgefertigter Listen zu erraten. Wer unkonventionelle Passwörter benutzt, fühlt sich wahrscheinlich sicherer, doch alleine schon der Angriff kann die ohnehin meistens limitierten Ressourcen des Heimservers massiv schmälern.
Ein weiteres Risiko stellt im Allgemeinen auch der Anwender dar, der oftmals seine Telefonnummer aus einem Telefonbuch streichen lässt, bei der Vergabe der Passwörter mitunter aber den kreativen Tod stirbt und grundsätzlich als Passwort seinen Vornamen nimmt. Auch hier ist der Administrator in der Pflicht, den Anwender vor seinem eigenen Untergang zu bewahren.
Der Angriff
Um effektiv gegen potentielle Angreifer vorgehen zu können, muss man sich zuallererst im Klaren sein, wie die meisten Angriffe strukturiert sind. Dazu reicht es, die Log-Dateien auszuwerten, um zu erkennen, dass die überwiegende Mehrzahl der Angriffe auf zwei Arten erfolgt. Zum einen wird versucht, mittels einer Liste das Passwort der ohnehin schon bekannten Benutzer zu erraten. Einer dieser Nutzer ist Root. Das Skript arbeitet dazu eine bereits vorgefertigte Liste ab und probiert schlicht alle Passwörter aus. Eine zweite Möglichkeit ist, dass das Skript eine Liste von häufig benutzten Anwendernamen abarbeitet und ebenfalls mittels einer Liste das Passwort zu erraten versucht.
Sicherlich gibt es auch kompliziertere Methoden wie SSH Session Hijacking oder die Ausnutzung von Sicherheitsproblemen in ssh, wie Beispielsweise des SSH CRC-32 Compensation Attack Detector-Fehlers. Die meisten Attacken benötigen allerdings einen direkten Zugriff auf den Server und oftmals eine Portion Glück, weshalb sie faktisch von den mittlerweile täglich stattfindenden Angriffen auf private Server so gut wie nie durchgeführt werden. Das Gros der Angriffe stellen immer noch Listenangriffe dar.
Der ssh-Daemon
Bereits von Hause aus kann der ssh-Daemon so abgesichert werden, dass ein Einbruch weitgehend ausgeschlossen wird. Hier werden ein paar Möglichkeiten vorgestellt, wie man den Dienst gegen potentielle Angreifer schützen kann.
Keine Macht den Doofen
In den meisten Fällen ist es nicht notwendig, dass alle Anwender auf einen Server auch mittels ssh zugreifen können. Am wenigsten besteht dabei die Notwendigkeit, dass Root sich direkt einloggen kann, bietet doch Linux mittels sudo und su die Möglichkeit, im laufenden Betrieb den Anwender zu wechseln. Bedenkt man ebenfalls, dass die Hälfte der Listenangriffe gegen Root durchgeführt werden, grenzt es fast schon an Fahrlässigkeit, Root auch einen Zugriff auf den Server mittels ssh zu erlauben.
Um Root den Zugriff auf den Server zu verwehren, bietet der Daemon mehrere Möglichkeiten. Die effektivste ist dabei, den Parameter PermitRootLogin in der Datei /etc/ssh/sshd_config auf no zu setzen. Damit wird grundsätzlich dem Anwender Root ein Zugriff mittels ssh verwehrt. Will man sich allerdings von einem lokalen Netzwerk weiter als Root auf den Server einloggen, bedarf es einer anderen Strategie.
Eine feinere Einteilung der Rechte ermöglicht die Option AllowUsers mit dem folgenden Eintrag:
LoginGraceTime 600 |
In Beispielfall würde das allen Anwendern grundsätzlich den Zugang auf den Server mittels ssh verwehren. Einzig die Anwender root und user sind noch in der Lage, den Server zu betreten. Während sich user allerdings von jedem System aus einloggen kann, ist root auf die Domain mydomain beschränkt. Zugleich wird die Zahl der Versuche auf 3 und eine Schonzeit von zehn Minuten gesetzt. Gelingt es einem Anwender nicht, sich mit höchstens drei Versuchen einzuloggen, wird die Verbindung abgebaut. LoginGraceTime gibt an, nach wie vielen Sekunden die Verbindung vom Server getrennt wird, falls sich der Benutzer nicht korrekt einloggen konnte.
Durch die Limitierung des Zugang auf den Server auf einen Benutzer und die Beschränkung auf maximal drei Fehlversuche konnte die Sicherheit des Systems massiv gesteigert werden.
Ein Schlüssel zum Glück
Eine weitere Möglichkeit, das System gegen Angriffe von außen zu schützen, stellt die Umstellung des Authentifizierungsverfahrens dar. SSH bietet grundsätzlich die Möglichkeit, sich mittels verschiedener Verfahren zu authentifizieren. Das gängigste dabei ist die Passwort-Authentifizierung, die mit dem Parameter PasswordAuthentication gesteuert wird. Schaltet man diese und weitere auf dem Passwort beruhenden Optionen aus, so kann sich kein Anwender mehr auf den Server mit dem regulären Passwort einloggen. Doch was tun, um trotzdem Zugriff auf den Server zu haben? Die Antwort darauf liefert das schlüsselbasierte Verfahren.
In diesem Fall wird auf dem Server ein Schlüsselpaar generiert und dem ssh-Daemon bekannt gegeben. Während der Serverschlüssel, wie der Name bereits suggeriert, auf dem Server verbleibt, erhält jeder berechtigte Anwender einen öffentlichen Schlüssel, der einen Zugriff auf den Server erlaubt. Ein Angriff mittels Wörterbuchlisten ist damit ausgeschlossen. Eine Anleitung, wie man seinen Server mit dieser Methode absichern kann, liefert der Artikel „Den Server absichern“ [3] auf Pro-Linux von Mario Schröder.
Portsalat
Eine ebenso simple wie effektive Möglichkeit, Server gegen automatisierte Angriffe zu schützen, stellt die Umstellung der Ports dar. Das Verfahren hilft zwar nur bedingt gegen dedizierte Angriffe auf einen Server, denn ein Angreifer wird mit hoher Wahrscheinlichkeit auch einen Portscan durchführen, für simple Skripte von Botfarmen-Betreibern ist es allerdings perfekt.
Dazu ändert man den Standardport von 22 auf einen anderen. Dazu muss man lediglich den Parameter Port in der Datei /etc/ssh/sshd_config verändern. Für diesen Artikel wurde der Parameter auf den Port 12345 gesetzt. Versucht man sich nun regulär auf seinem Server einzulogen, wird es nicht mehr gelingen und man erhält die Meldung, dass die Verbindung abgewiesen wurde. Erst ein Login auf dem Port 12345 bringt einen zum Ziel:
$ ssh myserver -p 12345 -l user |
Sperren statt blocken
Die obigen Möglichkeiten stellen nur einen Teil der Funktionen dar, die ssh bietet, um Angreifer abzuwehren. Kombiniert mit den Systemtools wie beispielsweise der pam_abl [4], die in der Lage ist, Blacklists von falschen Logins zu erstellen, ergeben sich mächtige Kaskaden von Programmen, die jeden Angreifer in Schach halten.
Eine Steigerung stellt allerdings nicht nur das Blocken, sondern auch das Aussperren von Angreifern dar. Es ist grundsätzlich davon auszugehen, dass jemand, der beispielsweise zehnmal ein falsches Passwort über SSH eingegeben hat, nichts Gutes im Schilde führt. Was liegt also näher, ihm nicht nur ein Login zu verwehren, sondern ihn gleich komplett für eine bestimmte Zeit zu sperren?
Auch hier bietet Linux eine Reihe von Werkzeugen, die einem die Arbeit erleichtern werden. In diesem Artikel werden zwei der bekanntesten Vertreter vorgestellt, die das Aussperren von Anwendern direkt in einer Firewall übernehmen.
Hinweis: Man sollte grundsätzlich alle Änderungen und Tests auf einem lokalen Server durchführen. Nichts ist schlimmer, als sich von einem Root-Server durch eine falsche Konfiguration auszusperren!
fail2ban
fail2ban [5] kann IP-Adressen aufgrund einer bestimmten Anzahl fehlgeschlagener Loginversuche für eine einstellbare Zeit blockieren. Technisch gesehen überprüft die Applikation zuvor festgelegte Log-Dateien nach missglückten Loginversuchen und erstellt beim Erreichen einer zuvor festgelegten Anzahl von Fehlern eine Regel in der Firewall. Dabei kommt die Anwendung nicht nur mit SSH, sondern auch mit einer Vielzahl von weiteren Applikationen klar. Die Filterregelfunktionalität ermöglicht darüber hinaus die Erstellung von neuen, an die Erfordernisse des Anwenders angepassten Regeln. Für SSH bietet fail2ban bereits schon vorkonfigurierte Regeln an, die lediglich eine kleinere Anpassung erfordern.
Die eigentliche Konfiguration der Filterregel wird in der Datei /etc/fail2ban/jail.conf umgesetzt. Der für das Absichern von SSH interessante Abschnitt dieser Datei findet sich unter dem Eintrag ssh-iptables.
Mit enabled = true aktiviert man die eigentliche Überprüfung. Die unter action eingetragene Aktion legt fest, um welchen Port und um welches Protokoll es sich handelt. Ferner wird hier die Adresse eingetragen, an die eventuelle Sperrungen per E-Mail versendet werden sollen. Ein wichtiger Eintrag ist der logpath, der aussagt, welche Datei überprüft werden soll. Je nach Distribution kann sich der Eintrag ändern. Mit maxretry legt man fest, nach wie vielen fehlgeschlagenen Loginversuchen der Zugang gesperrt werden soll.
Ist der Abschnitt ssh-iptables angepasst worden, kann der fail2ban-Daemon auch schon gestartet werden. Je nach Distribution mit dem Kommando /etc/init.d/fail2ban start. Mit dem Befehl fail2ban-client status ssh-iptables kann man die Funktionalität testen:
# fail2ban-client status ssh-iptables |
Alternativ kann man sich sich die geblockten Adressen auch direkt in den Firewall-Regeln mit dem Befehl
# iptables -L fail2ban-SSH |
anschauen.
Wie man dann erkennen kann, führen fehlerhafte Logins direkt zu einer Sperrung in der Firewall. Je nach eingetragener Zeit bleibt die Sperrung so lange bestehen, bis sie entweder vom Administrator aufgehoben wurde oder eine bestimmte Karenzzeit verstrichen ist.
fail2ban ist nicht das einzige Werkzeug seiner Art. So bieten beispielsweise auch DenyHosts [6] und BlockHosts [7] eine ähnliche Funktionalität. Auch zahlreiche freie Intrusion-Detection-Systeme, wie beispielsweise OSSEC, bedienen sich der Möglichkeit, bei einem Angriff Systeme durch Filterregeln auszusperren.
knockd
Eine andere Strategie der Eindringlingsabwehr verfolgt knockd [8] mit Portknocking. Portknocking stellt ein Verfahren dar, um einzelne Serverdienste oder einen kompletten Server abzusichern. Wie bereits der Name suggeriert, muss der Anwender zuvor an den Server „anklopfen“, damit er Zugang zu einem vorher festgelegten Serverdienst erhält. Die Kommunikation auf dem gewünschten Port wird dabei zunächst von einer Firewall vollständig geblockt. Sendet der Anwender ein Klopfzeichen in Form von mehreren SYN-Paketen mit einem zuvor vereinbartem Inhalt, „öffnet“ knockd den entsprechenden Port für den Anwender. Der Vorteil des Verfahrens ist, dass ein Angreifer ohne die Kenntnis der zuvor vereinbarten Abfolge der Zeichen von außen auch mit einem Port-Scanner nicht erkennen kann, ob ein bestimmter Serverdienst eingeschaltet wurde.
Die Konfigurationsdatei /etc/knockd.conf beherbergt alle relevanten Informationen, die für einen reibungslosen Betrieb von knockd notwendig sind.
Die wichtigste Einstellung der Datei stellt die Option sequence dar. Diese legt die Ports fest, an denen angeklopft werden muss, um hereingelassen zu werden. seq_timeout legt dagegen fest, wie lange knockd wartet, bis die Sequenz übertragen wurde, während command das Kommando festlegt, das einen Port sperrt bzw. entsperrt. Durch den Parameter tcpflags kann man festlegen, auf welche Pakete knockd reagiert.
Sind alle Optionen eingestellt, kann man knockd entweder über init oder direkt mittels knockd --debug -verbose starten. In diesem Fall wird man direkt auf der Konsole die Resultate zu Gesicht bekommen. Angeklopft wird nun mit dem Kommando knock serverip 1234 2345 3456.
Abschließendes
Dieser Artikel konnte nur einen kleinen Teil der Möglichkeiten aufzeigen, die einem zur Absicherung eines Systems zur Verfügung stehen. Man sollte immer im Hinterkopf behalten, dass ein Server ein lohnendes Ziel für Angreifer darstellt. Es lohnt sich deshalb, die gängigsten Strategien anzuschauen. Allein schon die Änderung des Standardports senkt die Zahl der erfolgten Angriffe massiv. Schaltet man dann nur noch dienotwendigen Benutzer für einen SSH-Zugriff frei, senkt man das Einbruchsrisiko weiter. Trotz allem sollte man allerdings beachten, dass kein System oder Server hundertprozentig sicher ist.
Links
Autoreninformation:
Mirko Lindner ist seit 1998 aktiv in die Entwicklung des Kernels eingebunden und verantwortlich für diverse Treiber und Subsysteme. Daneben ist er einer der Betreiber von Pro-Linux.de.
| < Zurück | Weiter > |
|---|