alphaspirit - Fotolia

OpenSSH optimal für maximale Sicherheit konfigurieren

OpenSSH ist eine wichtige Komponente für die Remote-Administration. Tools wie Fail2Ban und die richtige Konfiguration machen den Server sicher.

Es ist eine Sicherheitslücke für OpenSSH aufgetaucht. Damit können Angreifer von außen prüfen, ob ein bestimmter Anwender das Recht hat, sich via SSH anmelden zu dürfen. Der Grund liegt an der im Code von OpenSSH hinterlegten Methode der Überprüfung des Passworts. Schickt ein Angreifer einen beliebigen Nutzer und ein langes Passwort an den Server, dann antwortet der Server schneller bei einem nicht existenten Anwender.

Der Code für die Überprüfung eines Passworts für nicht autorisierte oder nicht vorhandene Anwender basiert auf Blowfish. Reale Anwender werden mittels SHA256 / SHA512 überprüft. Eine Antwort für letzteres dauert bei langen Passwörtern (zehn KByte) länger.

Mithilfe eines Programms könnte ein Angreifer nun herausfinden, welche Anwender sich an einem System anmelden dürfen oder nicht. Da er auch noch das Passwort braucht, dauert so ein Angriff möglicherweise eine Weile.

Weiterhin haben mehr und mehr Heimanwender einen Rechner zu Hause, der als Server dient. Vielleicht betreiben Sie eine ownCloud, die zu administrativen Zwecken auch über OpenSSH und das Internet erreichbar ist. In so einem Fall ist die richtige Konfiguration von OpenSSH entscheidend.

Administratoren können es Angreifern aber schwer machen. Sicherheitslücken, wie die hier erwähnten, werden damit im Prinzip harmlos. Nachfolgend finden Sie einige Tipps, wie Sie einen Server mit OpenSSH richtig absichern.

Die absolut sicherste Methode wäre natürlich, OpenSSH erst gar nicht zu aktivieren oder zu erlauben. Das ist in der heutigen Zeit mit der Notwendigkeit für Remote-Administration aber nicht praktikabel. OpenSSH ist für Linux- und UNIX-Administratoren eine der wichtigsten Komponenten.

Als root darf man sich nicht anmelden

Es gilt als ungeschriebenes Gesetz, dass sich niemand via SSH als Superuser root anmelden darf. Root-Rechte auf einem Remote-Server erlangen Sie grundsätzlich über einen Zwischenanwender. Mit diesem melden Sie sich an und dieser hat dann das Recht, sich als root anzumelden. Für einen Angriff sind so zwei Passwörter zu knacken und ein Anwender richtig zu erraten. Das wird bei entsprechend langen Passwörtern schon komplex. Bei modernen Linux-Distributionen ist ein Verbot für das Anmelden des Anwenders root per Standard implementiert. Sie sollten das auf keinen Fall ändern.

Darf sich root auf einem Server nicht direkt via SSH anmelden, dann gilt er im Hinblick auf den Bug übrigens als nicht existierender Anwender. Allein dieser Fakt könnte einen potenziellen Angreifer schon abschrecken. Es gibt möglicherweise einfachere Ziele für die böswilligen Hacker.

Der kryptische Anwender

Handelt es sich um einen wichtigen Server, dann muss nicht nur das Passwort kryptisch sein. Es hindert Sie nichts daran, auch einen kryptischen Anwendernamen zu verwenden. User Peter mit Passwort Mausi!23 ist wesentlich einfacher zu knacken als ein 14-stelliger Nutzername aus dem Bereich /^[_.A-Za-z0-9][-\@_.A-Za-z0-9]*\$?$/ mit einem langen und sogenanntem sicheren Passwort.

Dass Sie sich so eine sichere Kombination schlechter merken können, ist klar. Es geht aber nicht um Bequemlichkeit, sondern um die Sicherheit des Servers, der von außen erreichbar ist. Es gibt sichere Passwort-Manager, in denen Sie solche Kombinationen aufbewahren können.

Dass Sie Passwörter dann und wann ändern sollten, ist bekannt. Das gilt übrigens auch für den Anwendernamen.

Schlüsselpaare (Public / Private Key) verwenden

Eine sehr sichere Methode ist der Einsatz sogenannter Schlüsselpaare. Das ist auch als Public / Private Key oder Public Key Authentication bekannt. Dann ist ein Login nur erlaubt, wenn der von außen kommende Rechner den richtigen Schlüssel besitzt.

Sie hinterlegen damit beim Server sozusagen, welche Rechner oder Computer, genauer genommen welche Schlüssel, als vertrauenswürdig eingestuft sind.

Diese Methode wird häufig auch für automatische Abläufe über eine verschlüsselte Verbindung verwendet. Public Key Authentication lässt sich so aufsetzen, dass ein Anmelden nur mit dem Schlüssel und ohne Passwort möglich ist. Unter Linux erstellen Sie ein Schlüsselpaar übrigens mit ssh-keygen.

Abbildung 1: Mit diesem Tool erstellen Sie unter Linux ein Schlüsselpaar.

Setzen Sie Windows auf Ihrer Workstation ein, dann können Sie für diese Methode putty nehmen. Damit lassen sich ebenfalls Schlüsselpaare erstellen.

Bei einem Linux-Server finden Sie die autorisierten Schlüssel normalerweise in der Datei ~/.ssh/authorized_keys. Stellen Sie außerdem sicher, dass die Datei mit den Rechten 600 abgesichert ist: chmod 600 ~/.ssh/authorized_keys

Das Problem bei dieser Methode ist, dass Sie sich dann nicht von jeder beliebigen Workstation am Server anmelden können. Das kann ein Problem sein, wenn Sie auf den Server müssen, aber Ihren autorisierten Rechner nicht griffbereit haben.

Fail2Ban ist Pflicht

Das Tool Fail2Ban finden Sie in der Regel in den Repositories moderner Linux-Distributionen. Die Software blockiert IP-Adressen, die eine gewisse Anzahl an gescheiterten Passworteingaben vorweisen. Dafür überprüft Fail2Ban die Log-Dateien des Systems. Die Software bringt dabei nicht nur Services für OpenSSH mit sich. Sie kann auch Apache, das Senden von E-Mails und so weiter überwachen.

Nach einer Installation konfigurieren Sie Fail2Ban, damit es Ihre Anforderungen erfüllt. Sie können zum Beispiel bestimmen, dass eine bestimmte IP-Adresse nach drei gescheiterten Anmeldeversuchen an SSH eine Stunde lang blockiert wird. Das macht einen Brute-Force-Angriff extrem langsam und eine Security-Lücke wie am Anfang erwähnt, ist im Prinzip komplett entschärft.

Abbildung 2: In diesem Beispiel werden IP-Adressen von Angreifern nach drei gescheiterten Versuchen eine Stunde lang geblockt. Damit wird ein Brute-Force-Angriff aufwendiger.

Den Port ändern

Ein kleiner aber feiner Taschenspielertrick ist es, den Port von SSH zu verlegen. Der Service muss nicht auf Port 22 laufen. Viele automatisierte Angriffe scheitern wohl schon, wenn der Port irgendwo über 50000 liegt.

Die Methode hilft aber wirklich nur gegen automatisierte Angriffe auf Port 22. Hacker können recht schnell herausfinden, welche Ports auf einem Server offen sind, der aus dem Internet erreichbar ist.

Folgen Sie SearchSecurity.de auch auf Twitter, Google+, Xing und Facebook!

Erfahren Sie mehr über Netzwerksicherheit

- GOOGLE-ANZEIGEN

ComputerWeekly.de

Close