Login
Newsletter
Werbung

So, 4. Oktober 2009, 00:00

SSH-Port absichern

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 »Script-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. Wir zeigen Ihnen ein paar Möglichkeiten, wie Sie Ihre Systeme ein wenig sicherer machen können.

Allgemeine Problematik

Wer einen eigenen Server unterhält, kennt die Situation zur Genüge. 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 zwei Mal 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 nennt. Auch hier ist der geneigte Administrator in der Pflicht, die Oma oder den Spieler-Roxxor vor ihrem 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 abarbeitet 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 stellen wir ihnen ein paar Möglichkeiten vor, wie sie den Dienst gegen potentielle Angreifer schützen.

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 sollten. 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 radikalste und 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
MaxAuthTries 3
AllowUsers root@*.mydomain user

In unserem Fall 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 nur noch auf die Domain mydomain beschränkt. Zugleich setzen wir die Zahl der Versuche auf 3 und eine Schonzeit von zwei Minuten. 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.

Limitieren wir also den Zugang auf den Server auf einen einzigen Anwender und setzen die Zahl der Versuche auf ein Minimum, steigern wir die Sicherheit des Systems massiv.

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 Sie Ihren Server mit dieser Methode absichern können, liefert Ihnen der Artikel »Den Server absichern« 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 Scripte von Botfarmen-Betreibern ist es allerdings perfekt.

Ändern sie dazu den Standardport von 22 auf einen Ihnen genehmen. Dazu müssen Sie lediglich den Parameter Port in der Datei /etc/ssh/sshd_config verändern. Für unsere Erklärung haben wir den Parameter auf den Port 12345 gesetzt. Versuchen Sie sich nun regulär auf Ihren Server einzulogen, wird es nicht mehr gelingen und Sie erhalten die Meldung, dass die Verbindung abgewiesen wurde. Erst ein Login auf dem Port 12345 bringt Sie zum Ziel:

ssh myserver -p 12345 -l user

Kommentare (Insgesamt: 0 )
Pro-Linux
Pro-Linux @Facebook
Neue Nachrichten
Werbung