VPS Server absichern: Praxis-Anleitung 2026

Einen VPS Server absichern ist das Erste, was du nach der Bestellung tun solltest — noch bevor du Software installierst oder eine Domain aufschaltest. Ob du einen Hetzner Cloud Server, ein Netcup-VPS oder eine IONOS-Instanz verwendest: Innerhalb von Minuten nach der Bereitstellung erscheinen die ersten automatisierten Anmeldeversuche in deinen Logs. Brute-Force-Bots scannen kontinuierlich neue IP-Adressen und testen Standardpasswörter. In dieser Anleitung erfährst du Schritt für Schritt, wie du deinen VPS innerhalb der ersten Stunde von einem offenen Ziel in einen gehärteten Produktionsserver verwandelst — mit konkreten Befehlen für Ubuntu 22.04+ und Debian 12+.

Warum die erste Stunde entscheidend ist

Bei meinem letzten Hetzner-Server habe ich die /var/log/auth.log nach 30 Minuten geprüft: über 200 fehlgeschlagene SSH-Anmeldeversuche, alle von verschiedenen IP-Adressen, alle auf Port 22 mit Passwörtern wie root/root oder admin/password. Das sind keine gezielten Angriffe — das sind automatisierte Scanner, die ständig laufen. Und sie finden jeden neuen Server.

Die meisten kompromittierten Server werden in den ersten 24 Stunden übernommen. Der Grund: Die Standardkonfiguration von Ubuntu und Debian erlaubt SSH-Passwortanmeldungen, hat keine Firewall aktiviert und keine automatischen Updates eingerichtet. Diese Anleitung schliesst genau diese Lücken — in der richtigen Reihenfolge, damit du dich nicht aussperrst.

System aktualisieren und Grundpakete installieren

Verbinde dich per SSH mit den Zugangsdaten deines Anbieters. Bei Hetzner findest du diese in der Cloud Console, bei Netcup im SCP (ServerControlPanel), bei IONOS im Cloud Panel. Der erste Befehl schliesst bekannte Sicherheitslücken im Basissystem:

sudo apt update && sudo apt upgrade -y
sudo apt install -y ufw fail2ban unattended-upgrades curl

Welche Pakete brauche ich auf einem frischen VPS?

Diese vier Pakete bilden die Sicherheitsgrundlage: ufw ist die Firewall, fail2ban schützt gegen Brute-Force-Angriffe, unattended-upgrades installiert Sicherheitspatches automatisch, und curl brauchst du später zum Testen von Verbindungen. Auf den meisten Server-Images sind einige davon bereits vorinstalliert — apt install überspringt dann einfach diese Pakete.

Entferne ausserdem Pakete, die auf einem Headless-Server nichts verloren haben:

sudo apt purge -y telnet rsh-client
sudo apt autoremove -y

Benutzer einrichten und Root-Zugang sperren

Warum sollte ich nicht als Root auf meinem Server arbeiten?

Jeder Befehl als Root wird ohne Rückfrage ausgeführt — ein Tippfehler kann das System zerstören. Mit einem benannten Benutzer und sudo gibt es eine zusätzliche Bestätigungsebene, und jede Aktion ist einer realen Person zugeordnet. Das ist nicht nur gute Praxis, sondern auch relevant für die DSGVO: Wenn du personenbezogene Daten verarbeitest, musst du nachweisen können, wer auf das System zugegriffen hat.

adduser deploy
usermod -aG sudo deploy

Teste in einem zweiten Terminal, dass deploy sich einloggen und sudo-Befehle ausführen kann. Erst wenn das funktioniert, geh zum nächsten Schritt. Ich habe mir selbst schon den Zugang gesperrt, weil ich diesen Test übersprungen habe — das passiert dir nur einmal.

SSH-Zugang härten — Schlüssel statt Passwörter

SSH ist der Hauptangriffsvektor auf jedem Linux-Server. Die Standardkonfiguration erlaubt Passwortanmeldungen, die sich trivial automatisiert durchprobieren lassen. Der Wechsel auf Schlüsselauthentifizierung eliminiert diese gesamte Angriffsklasse.

Wie erstelle ich einen SSH-Schlüssel und kopiere ihn auf den Server?

Auf deinem lokalen Rechner (nicht auf dem Server) erstellst du einen Ed25519-Schlüssel. Ed25519 ist der aktuelle Standard: schnell, sicher, kurze Schlüssel:

ssh-keygen -t ed25519 -C "deploy@mein-projekt" -f ~/.ssh/id_ed25519_vps -N ""

Kopiere den öffentlichen Schlüssel auf den Server. Ersetze die IP-Adresse mit der deines VPS:

ssh-copy-id -i ~/.ssh/id_ed25519_vps.pub [email protected]

Öffne ein neues Terminal und teste den Schlüssel-Login als deploy. Nur wenn dieser Test erfolgreich ist, änderst du die SSH-Konfiguration.

Wie sieht eine sichere sshd_config aus?

Bearbeite /etc/ssh/sshd_config mit sudo nano /etc/ssh/sshd_config:

# /etc/ssh/sshd_config
PermitRootLogin no
PubkeyAuthentication yes
PasswordAuthentication no
PermitEmptyPasswords no
MaxAuthTries 3
ClientAliveInterval 300
ClientAliveCountMax 2
X11Forwarding no
AllowTcpForwarding no
AllowUsers deploy

PermitRootLogin no sperrt den Root-Zugang komplett — alle Aktionen laufen über den benannten Benutzer mit sudo. AllowUsers deploy lehnt Verbindungen für jeden anderen Benutzernamen ab, noch bevor die Authentifizierung beginnt. MaxAuthTries 3 begrenzt die Anmeldeversuche pro Verbindung.

Prüfen und anwenden:

sudo sshd -t && sudo systemctl restart sshd

sshd -t prüft die Konfiguration auf Syntaxfehler. Wenn der Test fehlschlägt, behebe das Problem bevor du neu startest. Ein Neustart mit fehlerhafter Konfiguration kann deine Verbindung kappen. Auf manchen Ubuntu-Versionen heisst der Dienst ssh statt sshd — prüfe mit systemctl status ssh.

Firewall mit UFW einrichten

Eine Firewall blockiert alles, was du nicht ausdrücklich erlaubst. UFW (Uncomplicated Firewall) ist das Standard-Firewall-Tool auf Ubuntu und Debian.

Welche Ports muss ich für einen Webserver freigeben?

Für einen typischen Webserver brauchst du genau drei Ports: 22 (SSH), 80 (HTTP) und 443 (HTTPS). Alles andere bleibt geschlossen:

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw limit 22/tcp comment 'SSH mit Rate-Limiting'
sudo ufw allow 80/tcp comment 'HTTP'
sudo ufw allow 443/tcp comment 'HTTPS'
sudo ufw --force enable
sudo ufw status verbose

default deny incoming schliesst jeden Port, der nicht explizit geöffnet ist. limit 22/tcp erlaubt SSH-Verbindungen, blockiert aber IP-Adressen, die mehr als 6 Verbindungsversuche innerhalb von 30 Sekunden starten. Das comment-Flag dokumentiert den Zweck jeder Regel — unbezahlbar, wenn du den Server Monate später wieder anschaust.

Wichtig: Aktiviere UFW erst, nachdem du SSH erlaubt hast. Wenn du ufw enable ohne SSH-Regel ausführst, sperrst du dich sofort aus.

Fail2Ban gegen Brute-Force-Angriffe

Brauche ich Fail2Ban, wenn ich SSH-Schlüssel verwende?

Streng genommen ist Schlüssel-basiertes SSH immun gegen Passwort-Brute-Force. Aber Fail2Ban bietet trotzdem Mehrwert: Es sperrt IP-Adressen, die wiederholt fehlschlagen, reduziert Log-Rauschen, spart CPU-Zyklen und schützt gegen mögliche Zero-Day-Schwachstellen in OpenSSH. Auf Servern, die zusätzlich Webdienste mit Login-Formularen betreiben, ist Fail2Ban unverzichtbar.

Erstelle /etc/fail2ban/jail.local (bearbeite nie jail.conf direkt — sie wird bei Updates überschrieben):

# /etc/fail2ban/jail.local
[DEFAULT]
bantime = 3600
findtime = 600
maxretry = 3
banaction = ufw
bantime.increment = true
bantime.factor = 2
bantime.maxtime = 604800

[sshd]
enabled = true
port = ssh
filter = sshd
logpath = /var/log/auth.log

Diese Konfiguration sperrt eine IP-Adresse für eine Stunde nach drei Fehlversuchen innerhalb von 10 Minuten. Mit bantime.increment = true verdoppelt sich die Sperrzeit bei Wiederholungstätern: 1 Stunde, 2 Stunden, 4 Stunden — bis maximal 7 Tage. banaction = ufw sorgt dafür, dass Fail2Ban UFW-Befehle für die Sperrung nutzt, statt iptables direkt zu manipulieren.

sudo systemctl restart fail2ban
sudo fail2ban-client status sshd

Der status-Befehl zeigt aktuell gesperrte IP-Adressen und die Gesamtzahl der Sperrungen. Auf meinen öffentlich erreichbaren Servern sehe ich typischerweise 20–50 Sperrungen pro Tag — alles automatisierte Scanner, die nicht über den dritten Versuch hinauskommen.

Automatische Sicherheitsupdates aktivieren

Kann ich automatische Updates auf einem Produktivserver aktivieren?

Ja — solange du dich auf Sicherheitsupdates beschränkst. Das Paket unattended-upgrades installiert standardmässig nur Patches aus dem -security-Repository. Das bedeutet: Sicherheitsfixes kommen automatisch, Feature-Änderungen oder neue Hauptversionen nicht.

sudo dpkg-reconfigure -plow unattended-upgrades

Wähle «Ja», wenn gefragt wird. Die Konfiguration liegt in /etc/apt/apt.conf.d/50unattended-upgrades. Wichtige Einstellungen:

# /etc/apt/apt.conf.d/50unattended-upgrades
Unattended-Upgrade::Automatic-Reboot "false";
Unattended-Upgrade::Remove-Unused-Dependencies "true";
Unattended-Upgrade::Mail "[email protected]";

Ich lasse Automatic-Reboot auf "false" — Kernel-Updates, die einen Neustart erfordern, plane ich in ein Wartungsfenster. Mail sendet eine Zusammenfassung der installierten Updates, damit du informiert bleibst, ohne dich täglich einloggen zu müssen.

Besonderheiten bei deutschen Hosting-Anbietern

Die grundsätzlichen Schritte sind bei jedem Anbieter gleich, aber einige Eigenheiten solltest du kennen:

Hetzner Cloud

Hetzner bietet beim Erstellen eines Servers die Option, direkt einen SSH-Schlüssel zu hinterlegen. Nutze das — der Server startet dann ohne Passwort-Authentifizierung. In der Cloud Console kannst du im Notfall über die Konsole auf den Server zugreifen, auch wenn SSH gesperrt ist. Hetzner-Server haben standardmässig keine Firewall aktiviert; die Hetzner Cloud Firewall ist eine zusätzliche Option auf Netzwerkebene, ersetzt aber nicht UFW auf dem Server selbst.

Netcup

Netcup-VPS werden über das SCP (ServerControlPanel) verwaltet. Die VNC-Konsole im SCP ist dein Rettungsanker, wenn du dich ausgesperrt hast. Netcup-Server kommen oft mit einer älteren Ubuntu-Version — prüfe mit lsb_release -a, ob du auf einer unterstützten Version läufst, und führe bei Bedarf ein Upgrade durch.

IONOS

IONOS Cloud Server verwenden ein eigenes Panel. Beachte, dass IONOS je nach Tarif bereits eine Netzwerk-Firewall vorkonfiguriert haben kann. Prüfe im Panel, welche Ports auf Netzwerkebene offen sind, und richte UFW zusätzlich auf dem Server selbst ein — eine doppelte Absicherung ist hier sinnvoll.

DSGVO-Relevanz der Server-Absicherung

Wenn dein Server personenbezogene Daten verarbeitet — und das tut fast jede Webanwendung mit Kontaktformular, Benutzerkonten oder Analytics — schreibt die DSGVO (Art. 32) «geeignete technische Massnahmen» zum Schutz dieser Daten vor. Ein ungesicherter Server ist ein Verstoss.

Konkret relevant sind:

• Verschlüsselung: SSH mit Schlüsseln + HTTPS für Webdienste
• Zugriffskontrolle: Benannte Benutzer mit sudo, keine Shared Accounts
• Protokollierung: auth.log und Fail2Ban dokumentieren Zugriffsversuche
• Aktualisierung: Automatische Sicherheitsupdates zeigen, dass du aktiv Schwachstellen schliesst

Diese Massnahmen sind nicht nur gute Praxis, sondern im Ernstfall deine Dokumentation gegenüber der Datenschutzbehörde.

Zusammenfassung — Deine VPS-Sicherheits-Checkliste

Arbeite diese Liste bei jedem neuen Server von oben nach unten ab:

• apt update && apt upgrade -y — System patchen
• Sicherheitspakete installieren: ufw, fail2ban, unattended-upgrades
• Unnötige Pakete entfernen (telnet, rsh)
• Admin-Benutzer mit sudo anlegen, in zweitem Terminal testen
• SSH-Schlüssel erstellen und auf den Server kopieren
• /etc/ssh/sshd_config härten: Root sperren, Passwörter deaktivieren
• Konfiguration testen mit sshd -t, dann SSH neu starten
• UFW aktivieren: Default Deny, SSH/HTTP/HTTPS erlauben
• Fail2Ban mit progressiven Sperrzeiten einrichten
• Automatische Sicherheitsupdates aktivieren
• Anbieterspezifische Firewall-Einstellungen prüfen

Nächste Schritte — vom abgesicherten VPS zur Produktionsumgebung

Mit SSH-Schlüsseln, UFW, Fail2Ban und automatischen Updates hat dein VPS eine solide Sicherheitsbasis. Die nächsten Schritte hängen von deinem Stack ab: Richte einen Reverse Proxy mit SSL ein (Nginx + Let’s Encrypt), setze deine Anwendung mit Docker Compose auf, oder vertiefe die Absicherung mit Kernel-Härtung und Audit-Logging.

Für eine vertiefte Absicherung auf Kernel-Ebene, SUID-Auditing und CIS-Benchmark-Alignment empfehle ich den englischsprachigen Artikel zur Linux Server Hardening Checklist. Für den vollständigen Aufbau einer deutschsprachigen Website mit internationalem SEO findest du unsere Erfahrungen im Artikel Internationale Website, deutsches SEO.