Ein eigener vServer (VPS, Virtual Private Server) ist günstig, schnell bestellt und in Minuten startklar. Genau das ist auch die Gefahr: Viele Server hängen kaum gehärtet im Netz und werden binnen Minuten von automatisierten Bots auf bekannte Schwachstellen abgeklopft. Wer einen frisch gemieteten VPS einfach mit Root-Passwort laufen lässt, lädt Angreifer förmlich ein. Dieser Artikel führt dich durch die wichtigsten Härtungsschritte, die du direkt nach dem Setup erledigen solltest.
Warum die ersten Minuten entscheidend sind
Sobald dein Server eine öffentliche IP-Adresse hat, scannen automatisierte Bots ihn rund um die Uhr. Sie probieren Standard-Logins durch, suchen nach offenen Diensten und testen bekannte Sicherheitslücken. Ein Server mit aktiviertem Root-Login per Passwort und einem schwachen Kennwort kann innerhalb von Stunden kompromittiert sein. Die gute Nachricht: Mit einer Handvoll grundlegender Maßnahmen schließt du die mit Abstand häufigsten Einfallstore.
Schritt 1: System aktualisieren
Das Erste nach dem ersten Login ist immer ein vollständiges Update. Auf Debian- oder Ubuntu-Systemen erledigst du das mit apt update && apt upgrade. Veraltete Pakete enthalten oft bekannte und längst gepatchte Sicherheitslücken – ein aktuelles System ist die Grundvoraussetzung für alles Weitere.
Schritt 2: Einen unprivilegierten Benutzer anlegen
Arbeite niemals dauerhaft als root. Lege stattdessen einen normalen Benutzer an und gib ihm über die sudo-Gruppe gezielt Administratorrechte. Der Vorteil: Angreifer müssen erst den Benutzernamen erraten, und versehentliche Fehler richten als normaler Nutzer weniger Schaden an. Nach dem Anlegen des neuen Nutzers testest du den Login, bevor du im nächsten Schritt den direkten Root-Zugang sperrst.
Schritt 3: SSH mit Schlüsseln statt Passwörtern
Das ist die wichtigste einzelne Maßnahme. SSH-Schlüssel sind praktisch unmöglich zu erraten, im Gegensatz zu Passwörtern. So gehst du vor:
- Erzeuge auf deinem lokalen Rechner ein Schlüsselpaar (z. B. ein Ed25519-Schlüssel).
- Kopiere den öffentlichen Schlüssel auf den Server, etwa mit
ssh-copy-id. - Teste den schlüsselbasierten Login.
- Deaktiviere danach in der
/etc/ssh/sshd_configsowohlPasswordAuthenticationals auchPermitRootLogin.
Wenn du den privaten Schlüssel mit einer Passphrase schützt, brauchst du dir kein einziges Server-Passwort mehr zu merken. Solltest du dennoch irgendwo ein starkes Passwort benötigen – etwa für ein Web-Panel oder eine Datenbank – erzeugst du es am besten mit unserem Passwort-Generator.
Optional, aber empfehlenswert: Verlege SSH auf einen anderen Port als 22. Das stoppt zwar keine gezielten Angriffe, reduziert aber den Lärm der automatisierten Massenscans in deinen Logs erheblich.
Schritt 4: Eine Firewall einrichten
Standardmäßig sind oft mehr Ports offen, als du brauchst. Eine Firewall nach dem Prinzip „alles verbieten, nur das Nötige erlauben" ist Pflicht. Unter Ubuntu ist UFW (Uncomplicated Firewall) der einfachste Einstieg. Die Grundregeln sind schnell gesetzt:
- Eingehenden Verkehr standardmäßig blockieren, ausgehenden erlauben.
- Nur die wirklich benötigten Ports öffnen – typischerweise SSH (dein gewählter Port), HTTP (80) und HTTPS (443).
- Erst die SSH-Regel setzen, dann die Firewall aktivieren – sonst sperrst du dich selbst aus.
Jeder offene Port ist eine potenzielle Angriffsfläche. Prüfe regelmäßig mit ss -tulpn, welche Dienste tatsächlich nach außen lauschen.
Schritt 5: Brute-Force-Angriffe mit Fail2ban abwehren
Fail2ban überwacht deine Logdateien und sperrt automatisch IP-Adressen, die zu viele fehlgeschlagene Login-Versuche produzieren. Selbst bei deaktiviertem Passwort-Login reduziert das den Bot-Traffic spürbar und schützt zusätzlich andere Dienste wie Webserver oder Mailserver. Die Standardkonfiguration ist für die meisten Fälle bereits sinnvoll; du kannst Sperrzeiten und Schwellenwerte nach Bedarf anpassen.
Schritt 6: Automatische Sicherheitsupdates
Updates sind nur dann wirksam, wenn sie auch eingespielt werden. Auf Debian und Ubuntu sorgt das Paket unattended-upgrades dafür, dass zumindest sicherheitsrelevante Aktualisierungen automatisch installiert werden. So bleibst du auch dann geschützt, wenn du den Server mal eine Weile nicht aktiv betreust. Bei kritischen Diensten solltest du dennoch regelmäßig manuell nach dem Stand sehen.
Schritt 7: Dienste minimal halten
Jeder laufende Dienst ist eine potenzielle Schwachstelle. Deinstalliere oder deaktiviere alles, was du nicht brauchst. Ein Webserver-VPS braucht keinen Datenbankserver, der nach außen lauscht, und keine ungenutzten Standarddienste. Datenbanken und interne Dienste solltest du grundsätzlich nur an localhost binden, nicht an die öffentliche IP.
Wenn du mehrere Anwendungen betreibst, ist es eine gute Praxis, sie in Docker-Containern zu kapseln. So bleiben Abhängigkeiten getrennt, und eine kompromittierte Anwendung erreicht nicht automatisch den Rest des Systems. Den Einstieg liefert unser Artikel zu Docker Compose.
Schritt 8: HTTPS und Reverse Proxy
Sobald Webdienste laufen, gehört Verschlüsselung dazu. Ein Reverse Proxy wie Nginx oder Caddy nimmt alle eingehenden Anfragen entgegen, kümmert sich um kostenlose Let's-Encrypt-Zertifikate und leitet intern an deine Dienste weiter. So ist nur ein einziger, gut konfigurierter Einstiegspunkt nach außen offen, und deine Anwendungen bleiben dahinter geschützt. Die Grundlagen erklärt der Artikel zu Nginx als Reverse Proxy.
Schritt 9: Backups und Monitoring
Sicherheit endet nicht beim Abwehren von Angriffen. Wenn doch etwas schiefgeht – ein gehackter Dienst, eine versehentliche Löschung, ein Festplattenfehler beim Provider – rettet dich nur ein funktionierendes Backup. Richte automatische, verschlüsselte Sicherungen ein, idealerweise auf einen externen Speicher. Und teste die Wiederherstellung mindestens einmal: Ein Backup, das du nie zurückgespielt hast, ist nur eine Hoffnung.
Ergänzend hält dich ein einfaches Monitoring auf dem Laufenden. Mit Uptime Kuma bekommst du sofort eine Benachrichtigung, wenn ein Dienst ausfällt – oft bevor deine Nutzer es überhaupt merken.
Die häufigsten Fehler, die du vermeiden solltest
- Root-Login per Passwort offen lassen: Der absolute Klassiker und das größte vermeidbare Risiko.
- Schwache oder wiederverwendete Passwörter: Jeder Dienst braucht ein eigenes, starkes Kennwort.
- Alles als root betreiben: Trenne Rechte konsequent.
- Updates aufschieben: Bekannte Lücken werden aktiv massenhaft ausgenutzt.
- Datenbanken öffentlich erreichbar machen: Interne Dienste gehören hinter die Firewall, nicht ins offene Netz.
Häufige Fragen
Reicht es, nur den SSH-Port zu ändern?
Nein. Ein anderer Port reduziert nur das Hintergrundrauschen automatisierter Scans, bietet aber kaum echten Schutz. Die wirklich wirksamen Maßnahmen sind schlüsselbasiertes SSH, eine Firewall und das Deaktivieren von Passwort- und Root-Login.
Brauche ich Fail2ban, wenn ich nur SSH-Keys nutze?
Es ist trotzdem sinnvoll. Fail2ban schützt nicht nur SSH, sondern auch andere Dienste wie Web- oder Mailserver vor Brute-Force-Versuchen und reduziert die Last durch dauerhafte Bot-Angriffe auf deinen Server.
Wie oft sollte ich meinen vServer warten?
Mit automatischen Sicherheitsupdates läuft die Basis selbstständig. Plane trotzdem etwa monatlich einen Blick auf Logs, freien Speicherplatz, laufende Dienste und die Backup-Integrität ein. Bei öffentlich erreichbaren, kritischen Diensten eher häufiger.
Lohnt sich ein vServer überhaupt gegenüber Shared Hosting?
Ein VPS gibt dir volle Kontrolle und die Möglichkeit, beliebige Software zu betreiben – ideal für eigene Projekte, Self-Hosting und zum Lernen. Dafür trägst du selbst die Verantwortung für Sicherheit und Wartung. Wer nur eine einfache Website hosten will und sich nicht um den Unterbau kümmern möchte, ist mit Managed Hosting oft besser bedient.