Sicherheit ist natürlich wichtig, wenn auch bisweilen lästig. Im Folgenden beschreibe ich einige Basis-Absicherungen, die ich bei neuen Servern immer zuerst vornehme. Damit sind sie keine uneinnehmbaren Festungen, aber doch auf einem relevanten Niveau geschützt. Wenn es einmal ein Hacker schafft, in Systeme im lokalen Netzwerk einzudringen, dann sollte er wenigstens nicht ungestört überall herumstöbern können.
Bei der Basisinstallation einer VM mit Ubuntu Server wird bereits ein Hauptuser eingerichtet, der mittels sudo Tätigkeiten mit root-Rechten durchführen kann. Bei manchen anderen Betriebssystemen und insbesondere bei der Basisinstallation eines LXC (auch mit Ubuntu) wird nur ein User root angelegt. Aus Sicherheitsgründen sollte kein Remote-SSH-Login mit Root-Kennung durchgeführt werden. Darum muss ggf. zunächst ein neuer User angelegt werden:
adduser --shell /bin/bash hanswurst
In dem sich anschließenden Dialog werden zunächst ein Passwort und dann weitere Daten abgefragt. Welche Daten man hier eingibt, ist egal. Nur das Passwort sollte man sich merken. Damit man mit dem neuen Account auch administrative Aufgaben ausführen kann, muss man den User der Gruppe sudo hinzufügen und ggf. ist zuerst das Tool sudo zu installieren:
apt install sudo
usermod -aG sudo hanswurst
So wird der User hanswurst der Gruppe sudo hinzugefügt, ohne die anderen Gruppenzugehörigkeiten des User zu ändern.
Zumindest ufw, die uncomplicated firewall sollte auf jedem Server installiert und eingerichtet werden. Soweit sie noch nicht installiert ist, kann dies mit
sudo apt install ufw
nachgeholt werden. Alle nicht benötigten Ports sollten geschlossen werden. Dazu gibt man zunächst ein:
sudo ufw default deny
So werden alle Ports (tcp und udp) geschlossen, die nicht explizit geöffnet werden. Dann öffnet man mit
sudo ufw allow [port-nr.]
jeden Port, den man braucht. Das sind im Zweifel die Ports 80 und 443 für Webserver, wenn man sie auf dem Server betreibt, 22 für SSH-Zugriff und spezielle Ports für Samba, VPN-Verbindungen und andere spezielle Anwendungen auf dem Server. Anschließend werden die Einstellungen mit dem Befehl
sudo ufw enable
scharf geschaltet. Die hierauf erscheinende Sicherheitsabfrage macht durchaus Sinn, weil man sich ggf. selbst ausschließt. Wenn nach Aktivierung der Firewall die Verbindung nicht getrennt wurde, dann hat man sich nicht selbst ausgeschlossen. Ansonsten müsste man das mit dem Consolen-Zugriff über die Proxmox Web GUI fixen.
Der SSH-Zugang mit Benutzername und Kennwort, insbesondere über eine WAN-Verbindung, ist nicht sehr sicher. Sicherer und nebenbei komfortabler ist der Zugriff per SSH-Key. Dazu muss man zunächst auf dem Client, mit dem man auf den Server zugreifen möchte, und auf dem es den gleichen User, den man für den Serverzugriff nutzen möchte, auch geben muss, einen SSH-Key generieren. Ich beschreibe hier ausschließlich, wie das an einem Linux-Client gemacht wird. Wer Windoof nutzt, ist selbst schuld ;-)
An dem Client (nicht auf dem Server) wird auf der Konsole der Befehl
ssh-keygen -t rsa
abgesetzt. So wird ein Schlüsselpaar aus öffentlichem und privatem Schlüssel erzeugt. Für die Authentifizierung am Server wird nur der öffentliche Schlüssel benötigt. Die nachfolgende Frage nach einem Passwort bezieht sich auf ein Passwort, mit dem explizit der Schlüssel gesichert werden soll. Aus Sicherheitsgründen sollte man hier natürlich ein Passwort vergeben. Man kann die Abfrage auch leer mit Enter bestätigen, dann wird der Schlüssel nicht mit einem Passwort geschützt.
Wenn man in dem Dialog, der nach og. Befehl erscheint, alle anderen Angaben einfach mit Enter bestätigt (was man beiläufig erwähnt tun sollte), dann befindet sich der öffentliche Schlüssel unter ~/.ssh/id_rsa.pub. Man kann ihn sich mit
cat ~/.ssh/id_rsa.pub
anzeigen lassen, um ihn zu markieren und in die Zwischenablage zu befördern. Für Copy&Paste nutzt man in einer Linux-Konsole übrigens Shift+Strg+c bzw. Shift+Strg+v. Dann kann man ihn auf dem Server in die Datei ~/.ssh/authorized_keys pasten. Wenn also auf einem Linux-Client der User hanswurst den Schlüssel erzeugt und unter dem gleichlautenden Account-Namen in die vorgenannte Datei pasted, dann ist der öffentliche Schlüssel dieses Users für den SSH-Zugang auf dem Server verfügbar. Bei nächster Anmeldung wird dann kein Passwort mehr für den Login abgefragt. Wenn man den Schlüssel passwortgeschützt hat (s.o.), dann wird natürlich das Passwort für den Schlüssel abgefragt. Bevor man weitere Schritte zur Absicherung unternimmt, sollte man das einmal durch ab- und wieder anmelden testen.
Wenn man sicher ist, dass der Zugang mittels SSH-Key funktioniert, dann kann man den Zugang per Account und Passwort auf dem Server deaktivieren. Dazu bearbeitet man die Datei /etc/ssh/sshd_config:
sudo nano /etc/ssh/sshd_config
Sollte der Editor nano noch nicht installiert sein, so holt man das mit
sudo apt install nano
zunächst nach. In dieser Datei sucht man nach dem Parameter "PasswordAuthentication", den man ggf. zunächst auskommentiert und dann mit dem Wert "no" ändert:
PasswordAuthentication no
In manchen Ubuntu-Installationen ist dieser Parameter in der Datei /etc/ssh/sshd_config.d/50-cloud-init.conf definiert, in manchen Installationen sogar in mehreren Dateien unter dem Pfad /etc/ssh. Ggf. muss man danach suchen und ihn sicherheitshalber mehrfach ändern. Ich habe auf drei verschiedenen Ubuntu-Servern der gleichen Version drei unterschiedliche Situationen vorgefunden.
Nun kann man noch die erlaubten Useraccounts und die IP-Adressen, von denen aus damit zugegriffen werden kann, vorgeben:
AllowUsers hanswurst@10.10.10.11 hanswurst@11.11.11.10
Aber Vorsicht: Wenn man an seinem Client die IP-Adressen per DHCP bezieht, dann können sie sich ändern und man kann sich aussperren. Nun kann man diese Einstellungen mit
sudo systemctl restart sshd (oder ssh statt sshd)
aktvieren und danach nie wieder auf seinen Server zugreifen ;-) Nee, Quatsch. Wenn alles richtig ist, dann kann man mit seinem Account und ohne Passworteingabe per ssh auf den Server zugreifen.
Oftmals liest man den Tipp, die Sicherheit zu erhöhen, indem man den Port für den SSH-Zugriff von 22 auf einen willkürlichen anderen ändert. Das kann man ebenfalls in der Datei /etc/ssh/sshd_config ändern. Dort steht auskommentiert
# Port 22
Das kann man einkommentieren (oder wie immer man das nennt, wenn man die Raute davor löscht) und einen beliebigen Port eintragen. Nach Neustart des SSH-Dienstes mit
sudo systemctl restart sshd
lauscht der SSH-Dienst auf dem anderen Port. Der Zugriff per ssh muss dann natürlich unter Angabe des Ports durchgeführt werden; beispielsweise:
ssh -l hanswurst 192.168.47.11 - p 4711
Aber Vorsicht: Wenn der entsprechende Port auf der Firewall nicht freigeschaltet ist, dann schließt man sich so vom Remotezugriff aus. Eine signifikante Steigerung der Sicherheit erreicht man so meiner Ansicht nach allerdings nicht, weil Hacker ohne jede Mühe in Erfahrung bringen können, auf welchem Port der SSH-Dienst lauscht.
Server, die Dienste im Internet anbieten, wie z.B. Webserver, sollten weiter gehend mit Tools gegen Distributed Denial of Servcies, Intrusion Detection, Intrusion Prevention usw. geschützt werden. Das ist hier nicht Gegenstand meiner Überlegungen.