Mein Weg zum Self-Hosting: Teil 2 - Server absichern
Im letzten Artikel habe ich den VPS Lite Server von Infomaniak eingerichtet und mich über SSH eingeloggt. Der Server läuft, aber ein frischer Server ist wie eine offene Haustür, jeder kann versuchen einzutreten. In diesem zweiten Teil zeige ich Schritt für Schritt, wie ich das System absichere.
Updates
Das erste was ich nach dem Login mache, ist sicherstellen, dass alle Pakete aktuell sind:
sudo apt update
sudo apt upgrade
apt update aktualisiert die Liste der verfügbaren Pakete und apt upgrade installiert die neuesten Versionen.
Wichtig sind die Meldungen im Terminal zu berücksichtigen wie in diesem Beispiel:
Diagnostics:
The currently running kernel version is not the expected kernel version
6.8.0-124-generic.
Restarting the system to load the new kernel will not be handled automatically,
so you should consider rebooting.
Wenn ein solches Kernel-Update dabei ist (also eine Aktualisierung des zentralen Herzstücks des Betriebssystems), muss der Server einmal neu gestartet werden:
sudo reboot
Automatische Sicherheitsupdates
Damit ich wichtige Updates nicht immer manuell machen muss, richte ich automatische Sicherheitsupdates ein:
sudo apt install unattended-upgrades
sudo dpkg-reconfigure --priority=low unattended-upgrades
dpkg-reconfigure öffnet die Konfiguration von unattended-upgrades neu.
Mit --priority=low werden alle Konfigurationsfragen angezeigt, auch die einfachen, so kann ich jeden Schritt explizit bestätigen. Bei der Frage wähle ich Yes, danach werden Sicherheitsupdates automatisch im Hintergrund installiert.
Passwort-Login deaktivieren
Standardmässig ist SSH-Login mit Passwort aktiviert. Das bedeutet, Bots können ständig versuchen sich mit verschiedenen Passwörtern einzuloggen.
Um zu sehen, wie viele fehlgeschlagene Versuche es bereits gab, kann man die Log-Dateien des Servers prüfen. Auf Ubuntu gibt es dafür zwei Möglichkeiten:
# Variante 1
sudo grep "Failed password" /var/log/auth.log | wc -l
# Variante 2
sudo journalctl -u ssh --no-pager | grep "Failed password" | wc -l
Da ich bereits einen SSH-Key eingerichtet habe, deaktiviere ich den Passwort-Login komplett um solche Versuche in Zukunft zu verhindern:
sudo nano /etc/ssh/sshd_config
Mit diesem Befehl wird die Konfigurationsdatei sshd_config im gewählten Texteditor (nano) geöffnet, damit ich sie bearbeiten kann. In der Datei sind viele Zeilen mit # auskommentiert, das bedeutet sie werden ignoriert und der Standardwert ist aktiv. Um eine Einstellung zu ändern, muss man das # entfernen und den Wert anpassen.
Ich suche also im File nach der Zeile PasswordAuthentication , entferne das # und setze es auf no, das würde dann so aussehen:
PasswordAuthentication no
Dann nur noch speichern und bestätigen (Ctrl+X → Y → Enter auf Mac).
Da die Änderungen an der Konfigurationsdatei erst wirksam werden, wenn der Dienst neu gestartet wird, mache ich das gleich:
sudo systemctl restart ssh
Firewall (UFW)
Als nächsten Schritt richte ich eine Firewall ein. UFW (Uncomplicated Firewall) ist ein Tool auf Ubuntu um den Netzwerkverkehr zu kontrollieren, also welche Verbindungen erlaubt sind und welche blockiert werden.
Ohne Firewall sind alle Ports des Servers offen und erreichbar. Mit UFW kann man explizit festlegen, dass nur SSH rein darf, alles andere wird blockiert:
sudo ufw allow ssh
sudo ufw enable
Wichtig: unbedingt zuerst sudo ufw allow ssh ausführen, ansonsten würde man sich selbst aussperren 😉
Mit diesem Befehl kann noch geprüft werden ob UFW korrekt läuft:
sudo ufw status
Fail2ban
Selbst wenn Passwörter verboten sind, hämmern Bots weiterhin gegen meine digitale Server-Tür. Das Programm "Fail2ban" überwacht Log-Dateien auf fehlerhafte Anmeldeversuche und blockiert die IP-Adressen der Angreifer.
Mit diesem Befehl wird es installiert:
sudo apt install fail2ban
Mit diesem Befehl kann geprüft werden, ob Fail2ban aktiviert wurde (mit q kann man die Ansicht wieder beenden):
sudo systemctl status fail2ban
Falls es noch nicht aktiviert ist, dann wie folgt aktivieren:
sudo systemctl start fail2ban
sudo systemctl enable fail2ban
Standardmässig schützt Fail2ban den SSH-Zugang auf Port 22 sofort nach der Installation mit Grundeinstellungen. Für den optimalen Schutz sollte man jedoch noch weitere Anpassungen vornehmen:
Eine eigene Konfigurationsdatei anlegen
Die wichtigsten Werte anpassen
SSH-Schutz explizit aktivieren
Die Hauptkonfigurationsdatei /etc/fail2ban/jail.conf wird bei Updates überschrieben, deshalb sollte man diese nie verändern, sondern eine eigene Datei jail.local erstellen. Diese hat dann Vorrang und bleibt bei Updates erhalten.
Zuerst kopiere ich die originale Konfigurationsdatei, damit ich meine eigene Datei nicht von Null auf abfüllen muss:
sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local
Jetzt öffne ich die Datei und ändere die wichtigsten Werte:
sudo nano /etc/fail2ban/jail.local
ignoreip
ignoreip = 127.0.0.1/8 ::1 MEINE_IP
ignoreip ist standardmässig auskommentiert, ich entferne das # und füge hinten meine IP Adresse hinzu, das schützt mich davor, mich jemals selbst versehentlich auszusperren. Falls man seine IP nicht weiss, findet man diese ganz einfach indem man in einem separaten Terminal den Befehl curl ifconfig.me eingibt.
bantime
bantime = 1d
Da moderne Angreifer-Bots geduldig sind, warten sie kurz und machen danach unendlich lange weiter. Eine Sperre von einem Tag bricht den Angriff sofort ab und reduziert zudem die Anzahl Firewall-Operationen, da jede Sperre und Entsperrung die Firewall-Regeln neu schreibt.
findtime
findtime = 10m
Das Zeitfenster in dem fehlgeschlagene Versuche gezählt werden. 10 Minuten ist ein guter Mittelwert, kurz genug um echte Angriffe zu erkennen, lang genug um versehentliche Tippfehler nicht zu bestrafen.
maxretry
maxretry = 3
Ein legitimer Benutzer vertippt sich vielleicht ein- oder zweimal, wenn es mehr als drei sind, dann deutet das auf einen Angreifer hin.
sshd
Die letzte Anpassung muss ich im sshd-Bereich der Datei vornehmen. Ich füge gleich oberhalb der Zeile port = ssh die Zeile enable = true hinzu. Der fertige Block sieht dann so aus:
enable = true
port = ssh
logpath = %(sshd_log)s
backend = %(sshd_backend)s
Anschliessend speichern und bestätigen (Ctrl+X → Y → Enter auf Mac) und Fail2ban neu starten:
sudo systemctl restart fail2ban
Mit diesem letzten Befehl kann ich noch prüfen, ob Fail2ban korrekt läuft und SSH überwacht:
sudo fail2ban-client status sshd
Root-Login deaktivieren
Der Benutzer root existiert auf jedem Linux-System und hat uneingeschränkte Rechte auf dem gesamten System. Angreifer kennen diesen Namen daher bereits und versuchen sich oft direkt als root einzuloggen.
Infomaniak blockiert zwar aus Sicherheitsgründen den direkten Login als root-Benutzer standardmässig von Anfang an, trotzdem deaktiviere ich in der SSH-Konfigurationsdatei des Servers die Option exlipzit:
sudo nano /etc/ssh/sshd_config
Von:
#PermitRootLogin prohibit-password
Zu:
PermitRootLogin no
Jetzt SSH neu starten damit die Änderung wirksam wird:
sudo systemctl restart ssh
Wie geht's weiter?
Der Server ist jetzt grundlegend abgesichert, noch nicht perfekt, es gibt weitere Massnahmen wie den SSH-Port zu ändern, aber das werde ich zu einem späteren Zeitpunkt noch behandeln.
Im nächsten Teil installiere ich Docker, was mir ermöglichen wird, Anwendungen in isolierten Containern zu betreiben.
