VPS absichern: Die ersten 10 Minuten

Die ersten 10 Minuten entscheiden, wie sicher Ihr Server ist

Ein brandneuer VPS ist nicht sicher. Sobald er über eine öffentliche IP-Adresse erreichbar ist, versuchen Scanner, sich anzumelden. Das Standard-Image bietet dafür eine große Angriffsfläche: root ist häufig erreichbar, Passwörter sind oft zulässig, eine Firewall fehlt und Sicherheitsupdates werden nicht regelmäßig installiert. Die gute Nachricht: Das lässt sich mit etwa zehn Minuten und einigen Befehlen beheben. Diesen Ablauf arbeite ich auf jedem neuen Server ab, bevor ich dort etwas bereitstelle.

Arbeiten Sie die Schritte in der angegebenen Reihenfolge durch, da sie aufeinander aufbauen. Jeder Schritt hat eine eigene Anleitung, auf die im jeweiligen Abschnitt verwiesen wird. Diese Seite ist der schnelle Ablauf, der die einzelnen Anleitungen miteinander verbindet.

Minute 1: Alles aktualisieren

Melden Sie sich mit den Zugangsdaten Ihres Providers als root an und bringen Sie das System vollständig auf den neuesten Stand, bevor Sie etwas anderes tun:

apt update && apt upgrade -y

Ein System ohne eingespielte Sicherheitsupdates ist das einfachste Ziel. Deshalb steht dieser Schritt an erster Stelle. Richten Sie nach Abschluss automatische Sicherheitsupdates ein. So bleibt das System aktuell, ohne dass Sie daran denken müssen.

Minute 2: Einen normalen Benutzer mit sudo erstellen

Arbeiten Sie nicht weiter als root. Erstellen Sie einen Benutzer für sich selbst und geben Sie ihm sudo-Berechtigungen:

adduser matt
usermod -aG sudo matt

Melden Sie sich ab jetzt als dieser Benutzer an und verwenden Sie sudo für administrative Aufgaben. Wenn Sie dauerhaft als root arbeiten, hat jeder Fehler und jeder erfolgreiche Angriff uneingeschränkte Berechtigungen. Genau das soll die Ausführung als unprivilegierter Benutzer verhindern.

Minute 4: SSH-Schlüssel einrichten

Passwörter können erraten werden, Schlüssel nicht. Erstellen Sie auf Ihrem eigenen Laptop einen Schlüssel, falls noch keiner vorhanden ist:

ssh-keygen -t ed25519

Kopieren Sie anschließend den öffentlichen Schlüssel auf den Server:

ssh-copy-id matt@YOUR_SERVER

Für ssh-copy-id muss die Anmeldung per Passwort für den neuen Benutzer aktiviert sein. Falls sie bereits deaktiviert ist, kopieren Sie ~/.ssh/authorized_keys von root nach /home/matt/.ssh/authorized_keys (im Besitz von matt). Alternativ können Sie Ihren öffentlichen Schlüssel manuell in diese Datei einfügen.

Das zugrunde liegende Modell mit einem Schlüssel pro Gerät, die Berechtigungen, die eine Schlüsselanmeldung verhindern, und das Sperren eines verlorenen Schlüssels werden in Grundlagen der SSH-Schlüsselverwaltung behandelt.

Melden Sie sich als matt ab und mit dem Schlüssel wieder an. Bestätigen Sie, dass die Anmeldung funktioniert, bevor Sie mit dem nächsten Schritt fortfahren. Wenn Sie SSH absichern, bevor Sie sich mit einem Schlüssel anmelden können, sperren Sie sich leicht selbst aus. Wenn bei dieser Anmeldung Permission denied (publickey) ausgegeben wird, beheben Sie das Problem jetzt, statt wieder auf das Passwort zurückzugreifen. Diese eine Meldung kann fünf verschiedene Fehler bedeuten. Die Ausgabe von ssh -v zeigt, welcher davon tatsächlich vorliegt.

Minute 6: Root-Login und Passwörter deaktivieren

Da Ihr Schlüssel jetzt funktioniert, schließen Sie die beiden Zugangsmöglichkeiten, auf die sich Scanner stützen. Verwenden Sie eine Drop-in-Datei, damit Paketaktualisierungen sie nicht überschreiben. Nennen Sie sie 00-, damit sie vor allen anderen Dateien in diesem Verzeichnis einsortiert wird. Ubuntu-Cloud-Images liefern 60-cloudimg-settings.conf standardmäßig mit PasswordAuthentication no aus. Wenn Ihr Anbieter jedoch in cloud-init ssh_pwauth setzt, schreibt cloud-init 50-cloud-init.conf. Diese Datei wird absichtlich vor der Datei des Images einsortiert und kann Passwörter wieder aktivieren. sshd verwendet den ersten Wert, den es liest. Eine später einsortierte Datei würde daher unbemerkt wirkungslos bleiben:

sudo nano /etc/ssh/sshd_config.d/00-hardening.conf

PasswordAuthentication no
KbdInteractiveAuthentication no
PermitRootLogin no

Laden Sie SSH anschließend neu:

sudo systemctl restart ssh

Prüfen Sie danach die Einstellungen, die sshd tatsächlich verwendet. So kann eine wirkungslose Drop-in-Datei Sie nicht täuschen:

sudo sshd -T | grep -Ei 'passwordauthentication|permitrootlogin'

Wenn Passwörter deaktiviert sind und der Root-Login nicht mehr möglich ist, kann der ständige Brute-Force-Netzwerkverkehr gegen Ihren Server keinen Erfolg haben. Die vollständige Anleitung einschließlich einer optionalen Portänderung finden Sie unter SSH auf einem VPS härten.

Minute 8: Firewall aktivieren

Blockieren Sie standardmäßig den gesamten eingehenden Datenverkehr. Erlauben Sie anschließend nur die benötigten Verbindungen. Erlauben Sie SSH, bevor Sie die Firewall aktivieren. Andernfalls trennen Sie Ihre eigene Verbindung:

sudo ufw default deny incoming
sudo ufw allow 22/tcp
sudo ufw enable

Fügen Sie allow-Regeln für jeden tatsächlich betriebenen Dienst hinzu, beispielsweise 80/tcp und 443/tcp für eine Website. Wenn nach dieser Änderung keine neue SSH-Sitzung mehr aufgebaut werden kann, lesen Sie die Fehlermeldung, bevor Sie etwas ändern. Eine Ablehnung bedeutet, dass sshd geantwortet hat. Ein Timeout bedeutet in der Regel, dass die Firewall das Paket verworfen hat. Prüfen Sie, ob IPv4 und IPv6 abgedeckt sind. Eine Firewall, die nur IPv4 filtert, lässt die IPv6-Seite weit offen. Die vollständige Anleitung finden Sie unter Firewalls 101 auf einem VPS. Diese ufw-Befehle setzen Ubuntu oder Debian voraus. Auf einem Rocky- oder AlmaLinux-System ist das Ziel mit standardmäßig blockiertem eingehendem Datenverkehr identisch. Dort wird jedoch firewalld verwendet. Arbeiten Sie stattdessen die firewalld-Variante dieses Schritts durch.

Minute 10: Verlangsamen Sie Scanner mit Fail2ban

Fügen Sie abschließend Fail2ban hinzu, um Adressen zu sperren, die wiederholt auf Ihre Ports zugreifen:

sudo apt install -y fail2ban

Unter Ubuntu 24.04 schützt die Standardinstallation SSH bereits ab dem ersten Boot. Da ohnehin bereits Schlüssel erforderlich sind, dient dies als zusätzliche Absicherung. Sie reduziert die Anzahl der Logeinträge und blockiert wiederholte Angreifer, ersetzt aber nicht Ihre zentrale Schutzmaßnahme.

Ihre Checkliste

Das ist das Runbook. Verwenden Sie den folgenden Generator, um jede Prüfung abzuhaken und eine personalisierte Checkliste mit dem exakten Befehl für jeden Schritt zu erstellen. Sie können diese Checkliste beim Server aufbewahren:

Arbeiten Sie die Liste bei jedem neuen Server einmal durch. Danach wird der Ablauf zur Routine. Zehn Minuten jetzt ersparen Ihnen den sehr schlechten Nachmittag, der auf einen kompromittierten Server folgt.

Sobald die grundlegenden Maßnahmen umgesetzt sind, halten automatische Sicherheitsupdates unter Ubuntu den Server aktuell, ohne dass Sie sich erneut anmelden müssen. Jeder Dienst, den Sie anschließend hinzufügen, benötigt eine eigene Prüfung, und die Schwachstellen verlagern sich: Bei einem selbst gehosteten Passwort-Tresor speichert der Server niemals Klartextdaten. Die tatsächlichen Risiken von Vaultwarden sind daher das Admin-Token und die Backup-Datei.

FAQ

Was sollte ich auf einem neuen VPS zuerst tun?

Aktualisieren Sie das System mit apt update && apt upgrade -y, erstellen Sie anschließend einen normalen Benutzer mit sudo-Rechten und beenden Sie die Arbeit als root. Richten Sie danach SSH-Keys ein, deaktivieren Sie den root-Login sowie die Passwort-Authentifizierung, aktivieren Sie eine Firewall mit der Standardrichtlinie deny und installieren Sie Fail2ban. Wenn Sie diese Schritte in dieser Reihenfolge ausführen, ist jeder Schritt sicher, ohne dass Sie sich selbst aussperren.

Wie vermeide ich es, mich bei der SSH-Härtung selbst auszusperren?

Richten Sie den SSH-Key-Login ein und testen Sie ihn, bevor Sie Passwörter oder den root-Zugang deaktivieren. Melden Sie sich ab und mit dem Key wieder an, um die Funktion zu bestätigen; erst danach schalten Sie PasswordAuthentication und PermitRootLogin ab. Wenn Sie die Firewall aktivieren, erlauben Sie Port 22, bevor Sie ufw enable ausführen. Sollten Sie sich dennoch aussperren, ermöglicht Ihnen die Web-Konsole Ihres Anbieters den Zugriff ohne SSH.

Benötige ich all das wirklich auf einem kleinen Server?

Ja, denn den Scannern ist die Größe Ihres Servers egal. Sie probieren jede öffentliche IP auf die gleiche Weise aus. Das gesamte Runbook dauert etwa zehn Minuten und beseitigt die einfachen Angriffswege: kein root-Login, kein Erraten von Passwörtern, keine ungewollten offenen Dienste und automatische Patches für bekannte Sicherheitslücken.

Was ist der wichtigste Einzelschritt?

SSH ausschließlich mit Keys und deaktiviertem root-Login. Die meisten Angriffe auf einen neuen VPS sind automatisierte Passwort-Versuche gegen den root-Account; durch das Deaktivieren beider Optionen wird diese gesamte Angriffskategorie unmöglich. Die Firewall und Fail2ban begrenzen anschließend die Angriffsfläche und verlangsamen verbleibende Versuche.

Wie bestätige ich, dass der Server tatsächlich abgesichert ist?

Überprüfen Sie manuell drei Punkte, bevor Sie dem System vertrauen. Führen Sie sudo ss -tlnp aus und bestätigen Sie, dass nur die von Ihnen beabsichtigten Ports auf einer öffentlichen Adresse lauschen und kein 0.0.0.0- oder [::]-Dienst läuft, den Sie vergessen haben. Führen Sie sudo ufw status verbose aus und bestätigen Sie, dass die Standardrichtlinie für eingehenden Datenverkehr deny lautet und sowohl die IPv4-Regeln als auch die (v6)-Regeln vorhanden sind. Öffnen Sie zudem immer eine zweite SSH-Sitzung, bevor Sie die erste schließen, damit ein Fehler in der SSH-Konfiguration Sie nicht vom Server aussperrt. Wenn alle drei Punkte korrekt sind, sind die Grundlagen erfüllt.