Ubuntu-Server sichern

Eine Anleitung, wie ein Server oder eine VPS Server-Instanz mit "Ubuntu Server" eingerichtet wird, um gegen automatisierte Hacking-Versuche weitgehend immun zu sein.

Im Text genutzte Beispielnamen sind:

Bevor es losgeht, muss das System auf den neuesten Stand gebracht werden. Dazu über SSH auf dem Server anmelden, über das voreingestellte root-Konto und die Server-IP.

ich@pc:~$ ssh root@xx.xx.xx.xx

root@server:~# apt-key update
root@server:~# apt-get update
root@server:~# apt-get dist-upgrade

Nun sind alle Schlüssen und Software-Pakete aktualisiert.

SSH Zugange nur über Public Key und normales Benutzerkonto

Ein neuer gemieteter Server hat oft nur ein einziges Benutzerkonto, dass mit "root"-Rechten ausgestattet ist, und ein Login mit Passwort über SSH ermöglicht.

Der erste Schritt für ein sicheres System ist, neben dem "root"-Konto ein weiteres Benutzerkonto anzulegen und kein SSH über das "root"-Konto zu erlauben. Ein "root"-Konto sollte nur genutzt werden, wenn es wirklich notwendig ist.

Zunächst muss dazu ein Schlüsselpaar auf dem lokalen PC erstellt werden (also nicht auf dem Server!). Dies ist jedoch nur notwendig, wenn nicht bereits ein Schlüssel in der Datei ~/.ssh/id_rsa.pub vorhanden ist.

ich@pc:~# ssh-keygen

Jetzt als "root" auf dem Server anmelden und einen neuen Benutzer anlegen. Nennen wir ihn "benutzer".

ich@pc:~$ ssh root@xx.xx.xx.xx

root@server:~# useradd benutzer
root@server:~# passwd benutzer
root@server:~# mkdir -p /home/benutzer
root@server:~# cp -R /etc/skel /home/benutzer
root@server:~# chown -R cst:cst /home/benutzer
root@server:~# chsh -s /bin/bash benutzer
root@server:~# usermod -a -G sudo benutzer

Nun den Inhalt der Datei ~/.ssh/id_rsa.pub (das ist der "öffentliche Schlüssel") vom lokalen PC auf den Server kopieren in die Datei ~/.ssh/authorized_keys.

ich@pc:~# cat ~/.ssh/id_rsa.pub

root@server:~# su benutzer

benutzer@server:~$ mkdir -p ~/.ssh
benutzer@server:~$ vim ~/.ssh/authorized_keys

Tip: Der Befehl ssh-copy-id automatisiert diesen Vorgang.

Der Schlüssel des lokalen PCs wird nun vom Server als "autorisiert" erkannt, und der Benutzer "benutzer" kann sich ohne Passwort über SSH anmelden. Bei Bedarf kann dann mit sudo su zum "root"-Konto gewechselt werden, denn oben hatten wir dem Benutzer "sudoer"-Rechte gegeben. Mal ausprobieren:

ich@pc:~$ ssh benutzer@xx.xx.xx.xx

benutzer@server:~$ sudo su
sudo password for benutzer:

root@server:~# whoami
root

Wenn alles funktioniert sollte nun noch der Zugang über Passwort-Anmeldung geschlossen werden und dem Benutzer "root" eine direkte Anmeldung verweigert werden. Dazu die folgende Datei mit einem Texteditor (zum Beispiel vim oder nano) öffnen und die Zeilen PasswordAuthentication und PermitRootLogin jeweils auf no setzen. Danach den SSH demon neu starten.

root@server:~# vim /etc/ssh/sshd_config

PasswordAuthentication no
PermitRootLogin no

root@server:~# service ssh restart

In einer zweiten Shell die Konfiguration testen:

ich@pc:~$ ssh root@xx.xx.xx.xx
Permission denied (publickey).
ich@pc:~$ ssh benutzer@xx.xx.xx.xx

benutzer@server:~$

Server mit IPTables-Firewall und fail2ban absichern

IPTables ist eine in Linux integrierte Firewall die Verbindungsanfragen sehr effizient blockieren kann. Das Programm fail2ban benutzt diese Firewall, um offensichtliche Einbruchsversuche automatisch zu blockieren. Und dass kommt auf einem normalen Server mehrmals täglich vor. Es ist also dringend geraten, fail2ban zu nutzen. Glücklicherweise ist die Einrichtung von fail2ban recht einfach.

root@server:~# apt-get install fail2ban

Die Konfigurationsdatei sollte zunächst kopiert und die Kopie dann mit einem Texteditor wie folgt angepasst werden.

root@server:~# cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local
root@server:~# vim /etc/fail2ban/jail.local

[DEFAULT]
ignoreip = 127.0.0.1/8
bantime  = 3600
findtime = 600
maxretry = 3
destemail = ich@example.com
sendername = Fail2Ban
mta = sendmail
action = $(action_mwl)s

[ssh]
enabled = true

Eine kurze Beschreibung der Einstellungen: maxretry ist die Anzahl der gescheiterten Login-Versuche, nach denen eine Benutzer-IP gesperrt wird. Die Länge der Sperre wird mit bantime in Sekunden festgelegt. Mit der Einstellung action kann festgelegt werden, wie fail2ban vorgehen soll, wenn ein Einbruchsversuch festgestellt wird. Mögliche Werte sind:

In den unteren zwei Zeilen wird fail2ban für SSH-Verbindungen aktiviert, wodurch fail2ban beginnt die Log-Dateien des SSH-Demon auf verdächtige Einträge hin zu überwachen.

Es können jedoch auch andere Serverdienste durch fail2ban überwacht werden. So lässt sich, zum Beispiel, auch das Wordpress-Login durch fail2ban überwachen. Es ist auch möglich, mittels IPTables bestimmte Ports des Servers permanent zu blockieren.

Eine Liste der aktuellen IPTable-Einstellungen kann eingesehen werden mit

root@server:~# iptables -L

System aktuell halten mit Unattended Upgrades

Der Server ist nun weitgehend abgesichert, wären da nicht bisher unbekannte Sicherheitslücken. Um bei Sicherheitsupdates immer auf dem neuesten Stand zu bleiben, sollte das Aktualisieren des Systems automatisiert werden. Dazu eignet die Software "Unattended Upgrades".

Während der Installation von "Unattended Upgrades" werden einige Fragen gestellt. Außerdem wird der "Update Notifier" installiert, um den Server bei Bedarf automatisch neu zu starten.

root@server:~# apt-get install unattended-upgrades update-notifier-common
root@server:~# dpkg-reconfigure --priority=low unattended-upgrades

Nach der Installation sollten ggf. noch einige Werte in zwei Konfigurationsdateien angepasst werden. (Das Semikolon am Zeilenende nicht vergessen!)

root@server:~# vim /etc/apt/apt.conf.d/20auto-upgrades

Unattended-Upgrade::Automatic-Reboot "true";

und

root@server:~# vim /etc/apt/apt.conf.d/50unattended-upgrades

Unattended-Upgrade::Mail "ich@example.com";

Nun wird man über Upgrades und eventuell nötige Neustarts des Systems per Email informiert.

Der Server ist nun gut gesichert: SSH-Anmeldung nur über Public Key und ohne Benutzer-Passwort; Nutzung von SSH nur durch reguläre Benutzer und nicht durch den "root"-User; außerdem wird IPTables automatisch durch fail2ban ergänzt, wenn von einer bestimmten IP ein Einbruchsversuch über SSH ausgeht. Und das System durch "Unattended Upgrades" aktuell gehalten.

Mit dieser Konfiguration habe ich noch keinen erfolgreichen Einbruchsversuch erlebt. Wer sein System jedoch noch weiter absichern möchte, kann dazu unter Stichworten wie "harden Linux server" mehr Infos ergoogeln. Diese Konfiguration ist jedoch in der Regel ausreichend für einen sicheren Ubuntu-Webserver.