Root Server absichern (Ubuntu 14.04)

Einleitung

Gratulation! Wir haben einen Root Server gemietet und unsere Zugangsdaten per EMail erhalten. In der EMail steht in der Regel ein Satz drin, dass man die Zugangsdaten von dem (root) User ändern soll. Doch wie macht man das? Und ist damit der Server schon sicher? Was kann man noch alles machen um den Server zu sichern?

Diese Fragen sollen nachfolgend geklärt werden. Die notwendigen Schritte und Maßnahmen sind auch nicht sonderlich kompliziert.

Es gibt aber eine dringende Empfehlung (eigentlich zwei):

• Die Maßnahmen überhaupt durchzuführen (zumindest zum Teil).
• Nehmt Euch Zeit und macht es in Ruhe.

Für diesen Artikel gehe ich von einem installierten Ubuntu 14.04 aus. Die einzelnen Schritte sollten aber auch unter Debian und anderen darauf aufsetzenden Distributionen funktionieren.

Erste Maßnahmen

Zwei Tipps vorweg:

• Das Kapitel Zugang für root bei SSH verbieten können wir zusammen mit dem Kapitel Schotten dicht! durchführen. Dadurch können wir alle anderen Maßnahmen erst einmal gefahrlos ausprobieren. Zur Not können wir uns als root wieder anmelden und die Fehler beseitigen.
• Halten wir uns nicht an den ersten Tipp sollten wir undbedingt dieses hier befolgen: Wir werden uns mit SSH (von einem anderen Linux-System) oder per Putty (Windows) auf unserem Server anmelden. Diese Session sollten wir solange nicht beenden, solange wir die einzelnen Maßnahmen nicht mit einer weiteren Session getestet haben! Es besteht sonst die Gefahr, dass wir selber nicht mehr auf unseren Server kommen!

Kennwort ändern

Wir melden uns mit dem user root und dem uns mitgeteiltem Kennwort an unserem Server an (ssh oder putty) und ändern wir als erstes das Kennwort mit dem Befehl

passwd

Das neue Kennwort zweimal (identisch) eingeben. Empfehlung: Langes Kennwort mit Sonderzeichen, Buchstaben und Ziffern. Dieses gut merken oder in einem Kennwort-Tresor (Software) hinterlegen.

Das neue Kennwort testen wir, indem wir eine neue Session mit dem user root starten. Wenn die Anmeldung klappt können wir die erste Session schließen.

SSH Port ändern

Wenn der Server frisch installiert wurde läuft SSH auf einem Standardport (Port 22). Da das keine Geheimnis ist, werden potentielle Angriffe als erstes diesen Port testen. Um dieses Risiko auszuschalten, ändern wir einfach den Port. Im Prinzip kann man einen beliebigen Port nehmen, allerdings werden einige Ports im Standard für andere Dienste genutzt (z.B. Port 80 für http). Auf der sicheren Seite ist man, wenn man Ports im Bereich (grob) von 50000 und 65000 verwendet. Auch wenn ich hier im Beispiel einen konkreten Port verwende, sollte der natürlich auf Euren Servern ein anderer sein.

Um zu zeigen, dass SSH ohne Änderung tatsächlich auf Port 22 läuft, kann man den folgenden Befehl ausführen

netstat -tulpen | grep ":22"

Die Ausgabe sieht dann so aus wie nachfolgend dargestellt:

tcp   0  0 0.0.0.0:22  0.0.0.0:*  LISTEN  0  15703  1388/sshd

Die Ausgabe oben zeigt, dass da tatsächlich der Dienst für SSH auf Port 22 läuft.

Das ändern wir jetzt:

nano /etc/ssh/sshd_config

Es öffnet sich der Editor nano mit der sshd_config. Dort gehen wir in die Zeile Port 22 und ändern den Port von 22 auf einen anderen nur uns bekannten Port. Hier im Beispiel auf 55333. Ansonsten keine Änderungen vornehmen (kommt später noch)!

Die Datei speichern wir mit STRG-O und Eingabetaste (Return/Enter). Mit STRG-X verlassen wir nano.

Jetzt müssen wir dem SSH-Dienst noch mitteilen, dass wir die Konfiguration geändert haben:

service ssh restart

Debian:

/etc/init.d/ssh reload

Wir sehen:

ssh stop/waiting
ssh start/running, process xxxx

Kontrolle mit

netstat -tulpen | grep ":22"

Diesmal erhalten wir: Nichts. Prima.

Ein Versuch sich mit Port 22 anzumelden schlägt fehl (könnt ihr ausprobieren). Mit dem Port 55333 funktioniert es. Wir behalten wieder die neue Session bei und beenden die Erste.

Das System aktualisieren

Wenn unser Server frisch installiert wurde, sollte man dennoch sicherstellen, dass auch wirklich alles auf dem neuesten Stand ist. Das sollten wir auch regelmäßig kontrollieren (lassen) bzw. das lässt sich auch automatisieren.

Um unseren Server auf den neuesten Softwarestand zu bringen reicht der folgende Befehl aus:

apt-get update && apt-get -y upgrade

Die ganze Geschichte läuft jetzt eine Weile und produziert so Ausgaben wie:

Setting up python3-problem-report (2.14.1-0ubuntu3.9) ...
Setting up python3-apport (2.14.1-0ubuntu3.9) ...
Setting up apport (2.14.1-0ubuntu3.9) ...
apport start/running
Setting up policykit-1 (0.105-4ubuntu2.14.04.1) ...

Neuen Benutzer anlegen

Dringend zu empfehlen ist, einen neuen Benutzer anzulegen, über den man sich zukünftige an seinem Server anmeldet.

Auch wenn ich hier für das Beispiel den Benutzer admin genannt habe, sollte man tatsächlich einen anderen, nicht so leicht zu erratenden Benutzernamen wählen. Mit dem nachfolgendem Befehl wird nicht nur der Benutzer angelegt, sondern er bekommt auch gleich sein eigenes Home-Verzeichnis:

useradd -g users -d /home/admin -m -s /bin/bash admin

Jetzt noch das Kennwort für admin setzen:

passwd admin

Wieder zweimal ein sicheres(!) Kennwort eintippen und wir können versuchen uns mit dem neuen Benutzer anzumelden.

Wenn die Anmeldung erfolgreich war, wechseln wir zu root

su -

Mit dem geänderten Kennwort für root sollte das gelingen.

Das muss unbedingt probiert werden! Wenn das nicht klappt, sperren wir uns im nächsten Schritt selber aus!

Zugang für root bei SSH verbieten

Wenn wir im vorherigen Schritt alles richtig gemacht haben - und nur dann - gehen wir jetzt daran, den Zugang für root über SSH zu verbieten. Zu Sicherheit behalten wir die eine Session offen und testen das Ganze mit einer neuen Session. Erst wenn das funktioniert hat, können wir die erste Session wieder schliessen.

Wir ändern die Konfiguration von SSH mit:

nano /etc/ssh/sshd_config

Im Editor suchen wir die Zeile

PermitRootLogin yes

und ändern sie auf

PermitRootLogin no

Und um das Ganze noch mehr zu vernageln fügen wir noch ein paar Zeilen hinzu:

# Nur noch den user admin zulassen. 
AllowUsers admin
# root oder benutzer in der Gruppe root generell sperren
DenyUsers root
DenyGroups root

Das Ganze können wir am Anfang der Datei einfügen. Sollen sich später noch andere Benutzer per SSH anmelden dürfen, kann man den Eintrag AllowUser erweitern. Neue Benutzer werden mit Leerzeichen getrennt hinzugefügt. z.B.:

AllowUsers admin benutzer1 benutzer2 benutzer3

Wichtig: Auf keinen Fall nach den Benutzernamen ein Komma einfügen. Aussperrgefahr!

Mit STRG-O und STRG-X speichern wir und beenden den Editor. Jetzt fehlt noch:

service ssh restart

Debian:

/etc/init.d/ssh reload

Wir öffnen zu Kontrolle eine neue Session und versuchen uns mit root anzumelden. Mit korrektem Kennwort sollten wir die Meldung bekommen:

Access denied

Jetzt die Gegenkontrolle mit einer Anmeldung mit unserem neuen Benutzer admin und korrektem Kennwort sollte uns gelingen. Zur Sicherheit kontrollieren wir noch einmal, dass wir auch wirklich von da zu root wechseln können:

su -

Nach Eingabe des Kennwortes von root sollten wir nun root sein. Wenn das alles geklappt hat, können wir nun die Sessions beenden. Wir können uns nun über unseren neuen Benutzer anmelden und von da aus zu root wechseln.

SSH über Keyfile

Bevor Ihr Euch mit diesem Kapitel versehentlich aussperrt, kann man eine kleine, temporäre Sicherheitsmaßnahme vornehmen. Legt einfach vorübergehend einen weiteren Benutzer an. Entweder um mit diesem die Schritte aus dem Kapitel zu testen oder um notfalls noch handlungsfähig zu sein.

Key erstellen unter Ubuntu

Auf einem anderen Ubuntu-Rechner als dem Server erstellen wir zunächst das Schlüsselpaar, bestehend aus dem öffentlichen und dem privaten Schlüssel.

ssh-keygen -b 4096

Wir werden nach dem gewünschten Dateinamen für das Schlüsselpaar gefragt. Wir nehmen den Vorschlag - in der Regel id_rsa - an. Danach werden wir nach einer optionalen aber dringend empfohlenen Passphrase (Kennwort für den Schlüssel) gefragt. Die Passphrase ist optional. Allerdings kann dann jeder, der den Schlüssel erlangen sollte, sich dieses Schlüssels bedienen und sich, das ist ja das Ziel, auch damit an dem Server anmelden. Deshalb auch hier: Sicheres Kennwort für den Schlüssel vergeben und gut merken oder in einem Kennworttresor (Software) speichern. Einen kurzen Moment später ist das Schlüsselpaar erstellt.

Key erstellen unter Windows

Unter Windows nehmen wir zur Schlüsselerstellung ein Programm, das im Programmpaket von putty enthalten ist: puttygen.exe Wenn wir dieses starten, vergewissern wir uns, dass als Parameter SSH-2 RSA ausgewählt ist und tragen in Number of bits in generated key 4096 ein. Ein click auf den Button Generate startet die Schlüsselerstellung. Wir werden dazu aufgefordert während dessen die Maus zufällig in dem Fenster zu bewegen. Wenn die Schlüsselerstellung fertig ist, haben wir auch hier zwei Eingabefelder für die Passphrase (Kennwort). In dem Feld Key comment können wir einen Kommentar zu dem Schlüssel hinterlegen. Der wird uns später beim login angezeigt. Nicht vergessen das Schlüsselpaar mit den Buttons Save public key und Save private key zu speichern.

Public key auf Server übertragen

Damit wir unseren neu erzeugten Schlüssel auf den Server übertragen können müssen wir ein paar Dinge prüfen und gegebenenfalls neu anlegen.

Mit dem folgenden Befehl prüfen wir, ob bei unserem Benutzer admin das Verzeichnis .ssh existiert:

ls -al /home/admin

Mir ist es bisher immer so gegangen, dass das Verzeichnis noch nicht existiert hat. Also ändern wir das jetzt:

cd /home/admin
mkdir .ssh
chown admin .ssh
chgrp users .ssh
chmod 700 .ssh

Anstelle den beiden Befehlen chown und chgrp können wir auch Folgendes eingeben:

chown admin:users .ssh

Der Reihenfolge nach: Mit cd wechseln wir in das Home-Verzeichnis unseres Benutzers admin. mkdir legt ein Verzeichnis an. Mit chown und chgrp ändern wir den Owner und die Group für dieses Verzeichnis. Zuletzt setzen wir noch die Zugriffsberechtigung für dieses Verzeichnis mit chmod.

Jetzt legen wir noch die folgende Datei an und setzen die Berechtigungen:

touch authorized_keys
chown admin authorized_keys
chgrp users authorized_keys

oder

chown admin:users authorized_keys

chmod 600 authorized_keys

Linux

Unter Linux ist übertragen wir den öffentlichen Schlüssel wie folgt auf unseren Server:

cat ~/.ssh/id_rsa.pub | ssh admin@<Server> 'cat >> .ssh/authorized_keys'

Windows

Falls wir puttygen schon geschlossen haben sollten ist das kein Problem. Einfach wieder starten und dann über den Button Load den vorher angelegten privaten Schlüssel wieder laden. Wir werden noch mal nach dem Kennwort für den Schlüssel gefragt, bevor er geladen wird. Hat das alles geklappt, sehen wir im oberen Teil der Anwendung die Bezeichnung Public key for pasting into OpenSSH authorized_keys file.

Genau das machen wir jetzt auch. Wir markieren den gesamten Bereich, beginnend mit ssh-rsa, bis zum Ende. Es ist wichtig, dass wir wirklich alles in diesem Bereich markiert haben. Mit STRG-C übernehmen wir das in die Zwischenablage.

Ich gehe davon aus, dass wir noch eine Session zu unserem Server offen haben und noch root sind. Ansonsten: Session aufmachen mit unserem neuen Benutzer und zu root wechseln. Der nächste Schritt ginge zwar auch unter unserem Benutzer, aber spätestens beim Ändern der SSH-Konfiguration brauchen wir root-Rechte.

Im .ssh Verzeichnis unseres Benutzers admin öffnen wir die Datei authorized_keys:

nano authorized_keys

In der Zwischenablage von Windows haben wir noch unseren öffentlichen Schlüssel. Den fügen wir jetzt in die geöffnete Datei authorized_keys ein, indem wir einfach die rechte Maustaste drücken. Anmerkung: Sollte in der Datei schon ein Schlüssel eingetragen sein, müssen wir erst in eine neue, leere Zeile. Wichtig: Der eben eingefügte Schlüssel muss in einer Zeile stehen! Eventuelle Zeilenumbrüche müssen entfernt werden! Jetzt speichern wir mit STRG-O und verlassen den Editor mit STRG-X.

Jetzt wird es Zeit für einen ersten Test. Wir starten putty und richten uns eine neue Verbindung ein, die wir auch speichern können. In das Feld Host Name (or IP address) tragen wir die IP-Adresse unseres Servers ein. In das Feld Port kommt der geändertet Port (aus dem Beispiel wäre es 55333). Als Connection type wählen wir SSH aus. In dem Feld Saved Sessions können wir der Verbindung einen Namen geben unter dem auch gespeichert wird, d.h. der Name taucht dann in der Liste darunter auf. Jetzt fehlt noch die Sache mit dem Schlüssel. In der Baumstruktur Category klappen wir den Eintrag Connection und dann SSH auf und klicken mit der Maus auf Auth. Die ganzen Optionen lassen wir auf den vorgeschlagenen und wählen über den Button Browse unseren privaten Schlüssel aus. Danach klicken wir in der Baumstruktur Category wieder auf den ersten Eintrag Session und speichern per Button Save.

Per Button Open öffnen wir die neue Verbindung zu unserem Server. Bei der Frage login as: geben wir unseren Benutzernamen admin ein und sehen etwas in der Art:

Authenticating with public key "rsa-key-20150425"
Passphrase for key "rsa-key-20150425":

Nach Angabe es Kennwortes für den Schlüssel sind wir an unserem Server angemeldet.

Wir könnten uns im Moment allerdings immer noch mit dem Benutzerkennwort anmelden, wenn wir in Putty unseren Schlüssel nicht angeben. Diese Möglichkeit klemmen wir jetzt ab.

Schotten dicht!

Warnung: Nach diesem Schritt können wir uns auch nicht mehr per Kennwort als anmelden! Also unbedingt eine Session zum Server offen halten und mit einer neuen Verbindung/Session testen!

Wir öffnen die SSH-Konfiguration:

nano /etc/ssh/sshd_config

Wir ersetzen

PasswordAuthentication yes

in

PasswordAuthentication no

Jetzt noch

service ssh restart

Und ganz wichtig: Testen mit einer neuen Verbindung! Also wieder mit Putty die angelegte Verbindung aufrufen und nach Eingabe von Benutzername admin und Kennwort für den Schlüssel sollten wir erfolgreich am Server angemeldet sein. Zur Sicherheit testen wir noch den Wechsel zu root mit

su -

und geben das Kennwort für root ein. Erst wenn das alles geklappt hat, können wir die Verbindungen schließen. Nicht vergessen den privaten Schlüssel zu sichern! Wenn der verloren geht, kommt ihr nicht mehr auf den Server!

Haben wir alle Schritte bis hierher durchgeführt, ist unser Server schon ziemlich gut geschützt.

Weitere bzw. optionale Maßnamen

tbd