Gut geschützt ist halb „gerootet“

Gut geschützt ist halb „gerootet“

Root Server – der Inbegriff der Freiheit für Entwickler. Denn im Gegensatz zu einem Managed System könnt ihr als Nutzer alles so einstellen, wie ihr es gerne haben möchtet. Ein Root Server eignet sich also für alle, die gerne in die die Tiefe gehen und sich mit der Konfiguration eines Servers auskennen. Wer sich zu diesen Freiheits-Liebenden zählt, dem erfüllen sich mit einem Root Server alle Wünsche.

  1. Aber wo anfangen?
  2. Einen Benutzer anlegen
  3. Passwörter sind old-school
  4. SSH absichern
  5. Unbefugte Zugriffe erkennen und blocken
  6. Security! Security!

Doch geht mit großer Macht auch große Verantwortung einher – denn je mehr Konfigurationsfreiheit ihr habt, desto anfälliger ist euer System für Sicherheitslücken. Wir möchten euch daher in diesem Beitrag ein paar Tipps zur grundlegenden Absicherung eines Linux Root Servers geben.

Aber wo anfangen?

Grundsätzlich solltet ihr erstmal ein neues root-Passwort setzen, dies geht recht einfach und schnell. Das Passwort sollte komplex und vor allem lang sein. Ihr benötigt das Passwort nur, falls ihr nicht mehr per ssh auf den Server kommt oder euer sudo-Passwort verloren habt.
Wir arbeiten nur jetzt am Anfang mit dem root-Benutzer, da es leichtsinnig wäre, dies im produktiven Geschäft zu tun.
Ein neues root-Passwort erstellt ihr mit dem Befehl:

passwd

Nun lesen wir noch die Paketquellen neu ein und aktualisieren alte Pakete und installieren den ssh-Server:

apt-get update
apt-get upgrade
apt-get install openssh-server (falls noch nicht geschehen)

So haben wir erstmal unsere frische Linux Distribution auf einen neuen Stand gebracht und den SSH-Server mit Standard-Settings installiert.

Einen Benutzer anlegen

Als nächstes legt ihr euch einen Benutzer an.
Der Name des Benutzers sollte so gewählt werden, dass man ungefähr erkennen kann, wem dieser gehört, wie z. B. einer Gruppe (Entwickler-Team o-Ä.) oder einer einzelnen Person mit einer Kombination aus Vorname und Nachname. Grundsätzlich könnt ihr aber nehmen, was ihr gern möchtet.
Für die Beispiele in diesem Artikel wird eine Kombination aus meinem Vor- und Nachnamen verwendet.
Bei vielen Distributionen ist schon ein zusätzlicher Benutzer vorkonfiguriert, bei Ubuntu ist dies ebenfalls so.

useradd mschmidt
mkdir /home/mschmidt
mkdir /home/mschmidt/.ssh
chmod 700 /home/mschmidt/.ssh

chmod 700 bedeutet, dass die Rechte so gesetzt werden, dass der zurzeit ausgewählte Benutzer, in unserem Fall „root“, diese Datei lesen, schreiben und ausführen kann.

Alternativ:

adduser mschmidt

Mit beiden haben wir einen Benutzer hinzugefügt, ihm ein Verzeichnis gegeben und dort einen Ordner angelegt, welchen wir später für die ssh-Absicherung benötigen.
Behaltet in den folgenden Schritten bitte das Konsolen-Fenster mit dem root-Benutzer immer geöffnet, da wir oft zwischen Server und PC wechseln werden.

Passwörter sind old-school

Passwörter für den Verbindungsaufbau sind nicht gerade sicher, daher gehen wir auf eine public-key Methode über. Hierbei wird der öffentliche Schlüssel, den wir gleich erstellen, auf dem Server hinterlegt und als Authentifizierung genutzt.
Beginnen wir aber erstmal mit dem Anlegen des Schlüssels auf dem Computer, mit dem ihr den Verbindungsaufbau startet.
Hier gibt es je nach Betriebssystem Unterschiede, wir gehen hier auf Linux und Windows ein.
Unter Linux geht dies am schnellsten über die Befehlszeile.
Um einen Key zu erstellen, benutzen wir den Befehl:

ssh-keygen -t rsa

Mit -t wird die Verschlüsselungsmethode ausgewählt.

Ihr werdet unter anderem auch nach einer Passphrase gefragt, diese schützt den private key.
Solange ihr die Standardeinstellungen in der nachfolgenden Abfrage belässt, wird der Key unter dem home-Verzeichnis des zurzeit angemeldeten Benutzers hinterlegt, im Beispiel wäre das /home/mschmidt/.ssh/ .
Hier werden nun zwei Dateien angelegt, einmal eine id_rsa – dies ist der private key, der auf dem PC bleibt – und eine id_rsa.pub, dies ist der public key, der zum Server kommt. Wir benötigen den zweiten.
Die id_rsa.pub öffnet ihr mit einem Texteditor eurer Wahl und kopiert euch den Inhalt in die Zwischenablage, denn diesen Inhalt benötigt ihr später.

Mit dem SSH Client PuTTY könnt ihr auch unter Windows ein SSH-Keypaar erstellen.
Hierfür startet ihr die puttygen.exe und wählt im Parameter-Abschnitt SSH-2-RSA und klickt auf Generate. Anschließend bewegt ihr die Maus zufällig durch den zur Verfügung gestellten Screen, ihr könnt auch einen Kommentar hinzufügen, wenn ihr mehrere Schlüsselpaare benutzen wollt.
Anschließend gebt ihr noch eine Passphrase ein und bestätigt diese. Nun drückt ihr auf Save private key und auf save public key. Es sollte sich ein Fenster öffnen, in dem ihr nun den Speicherpfad auswählen könnt. Wie vorhin schon erwähnt, benötigt ihr den public key, dessen Inhalt ihr euch in die Zwischenablage kopieren müsst.
Nun wechseln wir wieder auf unseren Server und benutzen einen Editor, um die authorized_keys Datei anzulegen:

vim /home/mschmidt/.ssh/authorized_keys

Dort fügt ihr den Inhalt aus eurem vorhin erzeugten public key hinzu. Bei mehreren verbindenden Computern sollte hier auch von jedem Computer ein key enthalten sein.
Anschließend werden noch die Rechte angepasst:

chmod 400 /home/mschmidt/.ssh/authorized_keys
chown mschmidt:mschmidt /home/mschmidt -R

Wenn alles soweit geklappt hat, könnt ihr nun ein weiteres Terminal öffnen (das noch vorhandene „root-Terminal“ aber bitte nicht schließen) und baut eine neue Verbindung zum Server auf; diesmal aber mit dem neuen Benutzer (im Beispiel mschmidt). War das alles erfolgreich, wechselt bitte wieder auf das „root-Terminal“ und setzt das sudo-Passwort für den neuen Benutzer:

passwd mschmidt

Setzt ein komplexes Passwort, welches ihr entweder an einem sicheren Ort verwahrt, oder ein komplexes sowie einprägsames Passwort, welches ihr den Personen, die Zugriff haben sollen, mitteilt.

SSH absichern

Nun müssen wir noch unseren SSH-Zugang absichern. Hierzu öffnet ihr mit einem Editor eurer Wahl die sshd_config:

vim /etc/ssh/sshd_config

Nun fügt ihr folgende Zeilen hinzu:

PermitRootLogin no
PasswordAuthentication no
AllowUsers mschmidt@(unsere-ip) mschmidt@(unsere-ip2-wenn-gewünscht)
(Wenn man den unteren Wert setzt, kann es bei Dynamischen-IP's zu Einschränkungen kommen!)

Nun muss der SSH-Dienst neu gestartet werden:

service ssh restart

Ab jetzt kommt ihr nur noch von den eingetragenen PCs auf den Server.

Nun ändern wir noch den Standardport vom SSH-Dienst – dies könnt ihr machen, es ist aber kein Muss.
Der Standardport von SSH ist 22, dies ändert ihr auf einen anderen freien Port. Hier darf kein Systemport gewählt werden (0-1023), da diese meist von anderen Systemdiensten genutzt werden.
Am besten nehmt ihr einen Port aus den oberen Bereichen (über 40000-65535), so geht ihr Konflikten weitestgehend aus dem Weg.
Um das Ganze zu ändern, bearbeitet ihr wieder die sshd_config mit einem Editor:

vim /etc/ssh/sshd_config

In der Datei müsst ihr die folgende Zeile finden:

Port 22;

Dort müsst ihr dann anstatt 22 euren ausgesuchten Port eintragen.
Das Ganze wird abgespeichert und der SSH-Dienst wie oben noch einmal neugestartet.
Zum Verbinden müsst ihr nun folgendes eingeben:
<code>ssh -p PORT_NUMMER BENUTZER@SERVER-IP</code>

Unbefugte Zugriffe erkennen und blocken

Um z. B. Brute-Force-Angriffe zu blockieren oder anderen unerwünschten Zugang zu verhindern, könnt ihr mit iptables einige Regeln aufstellen.
Um die Regeln aufzustellen, könnt ihr z. B. folgende Befehle eingeben:

iptables -N block_ssh
iptables -A INPUT -p tcp --dport 22 -s BERECHTIGTE_IP -j ACCEPT
iptables -A INPUT -p tcp --dport 22 -m state --state NEW -j block_ssh
iptables -A block_ssh -m recent --set --name SSH
iptables -A block_ssh -m recent --update --seconds SEKUNDEN --hitcount ZUGRIFFSZAHL --name SSH -j DROP
/etc/init.d/iptables save
/etc/init.d/iptables restart

Wurden diese Befehle ausgeführt, könnt ihr euch per SSH nur mit der berechtigten IP mit dem Server verbinden, ebenfalls wird in der angegebenen Zeit in Sekunden nur die angegebene Zugriffszahl zugelassen, danach wird blockiert.

Als Alternative solltet ihr euch auf jeden Fall noch das fail2ban (http://www.fail2ban.org/wiki/index.php/Main_Page) Paket installieren.
Fail2ban scannt die Serverlogs (z. B. das Apache-Error-Log) nach Auffälligkeiten und legt damit Firewall-Regeln fest, die einzelne oder mehrere IPs nicht mehr durchlassen. Auffälligkeiten wären z. B. wiederholte und falsche Passwort-Eingaben. Auffällige IPs werden dann für eine gewisse Zeit geblockt. Da fail2ban selber schon Regeln aufstellt, könnt ihr euch auch die unteren Zeilen im iptables Beispiel sparen.

Security! Security!

Wir haben mit diesen Grundlagen den Server nun innerhalb kurzer Zeit schon mal gegen einen Großteil von Angriffen abgesichert. Jedoch können je nach eingesetzter Software noch mehr Maßnahmen notwendig sein. Achtet aber hierbei immer auf ein ausgewogenes Verhältnis zwischen Sicherheit und Administrierbarkeit.

Kommentare

  1. Patrick Oberdorf am

    @Daniel: Mit „Ausgewogenes Verhältnis zwischen Administrierbarkeit und Sicherheit“ ist eher gemeint, dass man nicht erst über eine 10m hohe Mauer klettern muss, dann durch ein Mienenfeld und abschließend noch über heiße Lava laufen muss, bevor man mit dem Schlüssel sein Auto aufschließen kann.
    Aber ich vermute du wolltest eh nur trollen, zumindest lässt deine absolute negative Haltung gegen den Artikel darauf schließen. Immerhin war der Artikel bestimmt nicht als umfassendes Handbuch gedacht, sondern eher als grobe Richtlinie oder als ein paar Tipps. Jemand der Ahnung von der Materie hat, weiß sowieso, dass man sich Informationen aus verschiedenen Quellen besorgen muss und nicht alles auf einem Silbertablett serviert bekommt.

    Antworten
  2. Daniel am

    Leider viel zu oberflächlich und teilweise unfreiwillig komisch. apt-get funktioniert nur auf Debian/ubuntu. Und wenn ich den ssh-server noch installieren muss, wie komme ich dann überhaupt in ein Terminal, um den Befehl einzugeben? Wenn mein „Root“ Server nicht gerade im Keller steht, wohl nur über eine grafische Oberfläche. Und da sollte der User dann besser auch bleiben, wenn er solche Anleitungen notwendig hat.

    Der Tiel ist weitgehend sinnfrei, die Verantwortung aus sudo geklaut und „gut“ geschützt sieht besser aus als Standardeinstellungen und fail2ban.

    Ausgewogenes Verhältnis zwischen Administrierbarkeit (gibt es das Wort eigentlich?) und Sicherheit? NEIN, Sicherheit! Ich lasse doch auch nicht mein Auto offen, um nicht den Schlüssel „administrieren“ zu müssen ….

    Antworten
  3. Emin am

    Eine Ergänzung für verschlüsselte Home-Verzeichnisse wäre cool. So wie es jetzt da steht, funktioniert es anscheinend mit verschlüsselte Home-Verzeichnisse nicht. Dafür muss man die Datei authorized_keys ins /etc/ssh/User/ schieben.

    Antworten
  4. hpvd am

    super Beitrag!
    bitte mehr davon :-)

    Antworten

Kommentar hinzufügen

    Hilfe & Kontakt

    Support-Hotline
    +49 (0) 800/440-3000

    E-Mail
    support@mittwald.de