Ein VPS ist schnell gebucht, in wenigen Minuten installiert und oft günstiger als ein klassisches Webhosting-Paket. Gleichzeitig bekommst du damit die Verantwortung für ein öffentlich erreichbares Linux-System. Bots scannen dauerhaft nach offenen SSH-Zugängen, schwachen Passwörtern, alten WordPress-Versionen und falsch konfigurierten Diensten. Die gute Nachricht: Für einen Einsteiger-Server brauchst du kein Security-Team, sondern einen klaren Ablauf. Dieser Guide zeigt, wie du deinen VPS 2026 absichern kannst, ohne dich in Spezialthemen zu verlieren.
Die Beispiele orientieren sich an Debian und Ubuntu, funktionieren aber sinngemäß auch auf vielen anderen Distributionen. Ziel ist eine robuste Baseline: sichere Anmeldung, minimale Angriffsfläche, automatische Sicherheitsupdates, Schutz vor Brute-Force-Versuchen, sinnvolle Benutzerrechte und ein Backup-Konzept. Arbeite die Schritte am besten direkt nach der Serverinstallation ab, bevor du Webserver, Datenbank oder Anwendungen produktiv freigibst.
1. Vor dem ersten Login: Zugangsdaten und Rettungsweg prüfen
Notiere dir zuerst, wie du im Notfall wieder auf den Server kommst. Viele Provider bieten eine Web-Konsole, einen Rescue-Modus oder Snapshots an. Diese Funktionen sind wichtig, falls du dich mit einer Firewall-Regel oder einer fehlerhaften SSH-Konfiguration aussperrst. Prüfe außerdem, ob dein Server eine feste IPv4-Adresse, IPv6 und eine Hostname-Konfiguration besitzt. Ein sauber gesetzter Hostname hilft später bei Logs, Monitoring und Zertifikaten.
Nach dem ersten Login als root solltest du das System aktualisieren. Unter Debian oder Ubuntu reicht zunächst apt update && apt upgrade. Starte danach neu, wenn Kernel- oder systemnahe Pakete aktualisiert wurden. Erst wenn das Basissystem aktuell ist, legst du Benutzer, Firewall und Dienste an. So vermeidest du, dass du eine veraltete Standardinstallation absicherst, die schon beim Start bekannte Lücken enthält.
2. Eigenen Admin-Benutzer anlegen
Dauerhaft als root zu arbeiten ist bequem, aber riskant. Lege einen normalen Benutzer an und gib ihm nur bei Bedarf Administratorrechte über sudo. Beispiel: adduser adminname und anschließend usermod -aG sudo adminname. Melde dich in einem zweiten Terminalfenster mit diesem Benutzer an und teste sudo whoami. Erst wenn das klappt, solltest du den direkten Root-Login abschalten.
Nutze für den Admin-Benutzer ein langes, einzigartiges Passwort, selbst wenn du später nur noch SSH-Schlüssel zulässt. Ein Passwortmanager ist hier Pflicht. Wer Server beruflich oder für Kunden betreibt, sollte zusätzlich dokumentieren, wer Zugriff hat und wann Schlüssel ausgetauscht werden. Sicherheit ist nicht nur Technik, sondern auch ein nachvollziehbarer Prozess.
3. SSH härten: Schlüssel statt Passwort
SSH ist der wichtigste Zugang zu deinem VPS und deshalb das Hauptziel automatisierter Angriffe. Erstelle lokal ein modernes Schlüsselpaar, zum Beispiel mit ssh-keygen -t ed25519 -a 100. Kopiere den öffentlichen Schlüssel mit ssh-copy-id adminname@deine-server-ip auf den Server. Danach testest du den Login in einer neuen Sitzung. Wichtig: Schließe dein bestehendes Root-Fenster erst, wenn der neue Login wirklich funktioniert.
Öffne anschließend /etc/ssh/sshd_config oder eine passende Datei unter /etc/ssh/sshd_config.d/. Für Einsteiger sind diese Einstellungen besonders relevant: PermitRootLogin no, PasswordAuthentication no, PubkeyAuthentication yes und optional MaxAuthTries 3. Ein anderer Port als 22 reduziert Lograuschen, ist aber kein Ersatz für echte Sicherheit. Wenn du den Port änderst, passe vorher die Firewall an. Danach prüfst du die Konfiguration mit sshd -t und lädst den Dienst neu.
4. Firewall mit UFW: Nur erlauben, was wirklich gebraucht wird
Eine Firewall ist die Türliste deines Servers. Für viele Einsteiger ist UFW die einfachste Wahl, weil sie iptables oder nftables verständlich kapselt. Installiere UFW, erlaube zuerst deinen SSH-Zugang und aktiviere die Firewall erst danach. Bei Standard-SSH wäre das ufw allow OpenSSH. Wenn du einen eigenen Port nutzt, erlaubst du ihn explizit, zum Beispiel ufw allow 2222/tcp. Anschließend aktivierst du mit ufw enable und kontrollierst mit ufw status verbose.
Für einen typischen Webserver öffnest du später nur 80/tcp und 443/tcp. Datenbanken wie MySQL, PostgreSQL oder Redis sollten nicht öffentlich erreichbar sein, außer du hast einen sehr guten Grund und zusätzliche Schutzmaßnahmen wie VPN, private Netzwerke oder IP-Whitelisting. Die beste Firewall-Regel ist oft die, die einen Dienst gar nicht erst nach außen sichtbar macht.
5. Fail2ban gegen Brute-Force und Log-Spam
Fail2ban liest Logdateien und sperrt IP-Adressen, die wiederholt verdächtige Muster auslösen. Das ist besonders nützlich für SSH, kann aber auch Webserver, Maildienste oder Anwendungen schützen. Installiere Fail2ban und erstelle eine lokale Konfigurationsdatei, statt die Standarddateien direkt zu bearbeiten. Für SSH reichen zu Beginn Werte wie enabled = true, maxretry = 5, findtime = 10m und bantime = 1h. Danach startest du den Dienst neu und prüfst mit fail2ban-client status sshd, ob die Jail aktiv ist.
Fail2ban ersetzt keine starken Passwörter und keine SSH-Schlüssel. Es ist ein zusätzlicher Schutz, der automatisierte Angriffe bremst und Logdateien übersichtlicher macht. Achte darauf, deine eigene IP nicht versehentlich zu sperren. Wer häufig von wechselnden Netzen arbeitet, sollte die Ban-Zeiten moderat halten oder einen zweiten Zugang über die Provider-Konsole bereithalten.
6. Automatische Sicherheitsupdates aktivieren
Viele Server werden nicht durch spektakuläre Zero-Days kompromittiert, sondern durch bekannte Schwachstellen, die längst gepatcht sind. Automatische Sicherheitsupdates schließen diese Lücke. Unter Ubuntu und Debian ist unattended-upgrades der Standardweg. Aktiviere Sicherheitsupdates, konfiguriere automatische Bereinigung alter Pakete und überlege, ob Reboots automatisch erfolgen dürfen. Für kleine private Server kann ein geplanter Reboot nachts sinnvoll sein; für geschäftskritische Systeme solltest du Wartungsfenster definieren.
Wichtig ist die Kontrolle: Automatisierung bedeutet nicht blindes Vertrauen. Prüfe regelmäßig /var/log/unattended-upgrades/, beobachte fehlgeschlagene Updates und abonniere Sicherheitsmeldungen deiner Distribution. Wenn du Docker nutzt, denke auch an Container-Images. Ein aktueller Host hilft wenig, wenn eine Anwendung in einem zwei Jahre alten Image läuft.
7. Dienste minimieren und Ports überprüfen
Jeder laufende Dienst ist potenziell eine Angriffsfläche. Prüfe nach der Grundinstallation mit Werkzeugen wie ss -tulpn, welche Ports lauschen. Alles, was du nicht brauchst, wird deaktiviert oder deinstalliert. Typische Kandidaten sind ungenutzte Maildienste, alte Test-Webserver oder Datenbankdienste, die versehentlich auf allen Interfaces lauschen. Dokumentiere kurz, welcher Dienst welchen Port nutzt und warum er öffentlich erreichbar sein muss.
Wenn du mehrere Projekte betreibst, trenne sie möglichst sauber. Eigene Linux-Benutzer, getrennte Verzeichnisse, systemd-Services und restriktive Dateirechte verhindern, dass ein Fehler in einer Anwendung sofort den ganzen Server betrifft. Für Webprojekte gilt: Schreibrechte nur dort, wo sie wirklich erforderlich sind, Upload-Verzeichnisse nicht ausführbar machen und sensible Konfigurationsdateien niemals im Webroot ablegen.
8. Backups und Snapshots: Sicherheit endet nicht bei der Firewall
Ein abgesicherter VPS kann trotzdem ausfallen: Fehlkonfiguration, defekte Updates, gelöschte Daten oder ein kompromittiertes CMS. Deshalb gehören Backups zur Sicherheitsstrategie. Die 3-2-1-Regel ist ein guter Start: drei Kopien, zwei unterschiedliche Speichermedien oder Orte, eine Kopie extern. Provider-Snapshots sind praktisch, aber sie ersetzen keine unabhängigen Backups. Wenn dein Anbieterkonto kompromittiert wird, können Snapshots ebenfalls gelöscht werden.
Für Einsteiger sind BorgBackup, Restic oder einfache verschlüsselte rsync-Backups beliebt. Entscheidend ist nicht das Tool, sondern der getestete Restore. Plane regelmäßig eine Wiederherstellung auf einem Testsystem. Nur so weißt du, ob Datenbank-Dumps, Konfigurationsdateien, SSH-Schlüssel, Webroot und Cronjobs vollständig gesichert sind. Ein Backup, das nie zurückgespielt wurde, ist nur eine Hoffnung.
9. Monitoring, Logs und einfache Alarmierung
Du musst nicht sofort eine große Observability-Plattform betreiben. Schon einfache Checks helfen: Erreichbarkeit per Ping oder HTTP, Speicherplatz, CPU-Last, RAM, ablaufende TLS-Zertifikate und fehlgeschlagene Dienste. Tools wie Netdata, Uptime Kuma oder ein externer Uptime-Monitor reichen für viele kleine VPS-Projekte. Wichtig ist, dass du eine Nachricht bekommst, bevor die Festplatte voll ist oder ein Dienst tagelang nicht läuft.
Logs sind deine Blackbox. Lerne die wichtigsten Orte kennen: /var/log/auth.log oder journalctl -u ssh für SSH, Webserver-Logs für HTTP-Fehler und journalctl -p warning für systemweite Warnungen. Prüfe Logs nicht nur nach einem Vorfall, sondern routinemäßig. Auffällige Login-Versuche, häufige 404-Scans oder wiederkehrende Dienstabstürze zeigen früh, wo du nachhärten solltest.
10. Updates für Anwendungen, CMS und Container
Viele VPS werden nicht über SSH angegriffen, sondern über Anwendungen. WordPress, Nextcloud, Adminer, phpMyAdmin, alte Node-Abhängigkeiten oder verwaiste Docker-Container sind häufige Einfallstore. Halte Anwendungen aktuell, entferne ungenutzte Plugins und setze starke Admin-Passwörter plus Zwei-Faktor-Authentifizierung ein. Öffentliche Admin-Oberflächen sollten, wenn möglich, zusätzlich per VPN, Basic Auth oder IP-Regel geschützt werden.
Bei Docker solltest du nicht nur docker compose pull ausführen, sondern Release Notes lesen und Volumes sichern. Automatische Container-Updates können bequem sein, bergen aber das Risiko inkompatibler Versionen. Für kleine Projekte ist ein wöchentlicher Patch-Termin oft der beste Kompromiss: Backups prüfen, Images aktualisieren, Container neu starten, Logs ansehen.
Praktische Checkliste für deinen sicheren VPS
- System direkt nach Installation aktualisiert und neu gestartet
- Eigener sudo-Benutzer angelegt, Root-Login deaktiviert
- SSH-Schlüssel aktiv, Passwort-Login ausgeschaltet
- UFW-Firewall aktiv, nur SSH, HTTP und HTTPS geöffnet
- Fail2ban für SSH eingerichtet und getestet
- Automatische Sicherheitsupdates aktiviert
- Unnötige Dienste deaktiviert und offene Ports kontrolliert
- Externe, verschlüsselte Backups eingerichtet und Restore getestet
- Monitoring für Uptime, Speicherplatz und Zertifikate aktiv
- Anwendungen, CMS, Plugins und Container regelmäßig gepatcht
Fazit: Ein sicherer VPS entsteht durch Routine
VPS-Sicherheit ist kein einmaliger Haken auf einer To-do-Liste. Die Grundabsicherung aus SSH-Schlüsseln, Firewall, Fail2ban und automatischen Updates bringt dich sehr weit, aber dauerhaft sicher bleibt dein Server nur durch Routine. Plane feste Wartungszeiten, lies Logs, teste Backups und entferne alles, was du nicht mehr brauchst. Je kleiner und verständlicher dein Setup ist, desto einfacher bleibt die Absicherung.
Für Einsteiger lohnt es sich, mit einem einzelnen Server bewusst simpel zu starten. Wenn dein Projekt wächst, kannst du später VPN-Zugänge, zentrale Logs, Konfigurationsmanagement, Geheimnisverwaltung und Härtungsprofile ergänzen. Die wichtigste Entscheidung triffst du aber heute: Lass deinen VPS nicht im Auslieferungszustand online, sondern gib ihm eine sichere Basis.