Die ersten 30 Minuten: VPS-Härtungs-Checkliste

Ein frischer VPS bekommt seinen ersten SSH-Scan innerhalb von Minuten nach der IP-Vergabe. Hier ist die exakte Sequenz, die ich auf jeder neuen Box ausführe — copy-paste-fertig für Debian 13, mit einer Checklisten-Tabelle am Ende.

Annahmen: ein frisches Debian-13-Image aus deinem VPSRento-Deploy, du bist als root per SSH angemeldet, und die Beispiel-IP ist 185.220.101.14 — ersetze sie durch deine. Gesamtzeit: etwa eine halbe Stunde. Führe die Schritte in Reihenfolge aus; Schritt 2 kann dich aussperren, wenn du es überstürzt.

1. Deinen sudo-Benutzer erstellen

Als root zu arbeiten ist, wie Tippfehler zu Incidents werden. Erstelle einen echten Benutzer, gib ihm sudo, und erledige alles von dort aus:

Copy# create the user (you'll set a password — still useful for sudo)
adduser ops

# grant sudo
usermod -aG sudo ops

Alles ab diesem Punkt läuft als ops , sofern nicht anders angegeben.

2. Nur SSH-Keys — keine Passwörter, kein Root-Login

Passwort-Authentifizierung ist das größte Einfallstor auf einer internet-exponierten Box. Bots hämmern den ganzen Tag mit Credential-Listen auf Port 22. Keys machen diese gesamte Angriffsklasse irrelevant. Auf deinem lokalen Rechner:

Copy# generate a keypair if you don't have one (ed25519, no passphrase tradeoff is yours)
ssh-keygen -t ed25519 -C "ops@atlas"

# push the public key to the server
ssh-copy-id [email protected]

Verifiziere, dass du dich mit dem Key in einem neuen Terminal — ssh [email protected] — bevor du die Konfiguration anfasst. Halte die bestehende Root-Sitzung als Notausgang offen. Bearbeite dann /etc/ssh/sshd_config:

Copy# /etc/ssh/sshd_config — the three lines that matter
PasswordAuthentication no
KbdInteractiveAuthentication no
PermitRootLogin prohibit-password

Copy# validate the config, then reload (Debian 13 uses ssh.service)
sshd -t && systemctl reload ssh

prohibit-password statt einer flachen no für Root absichtlich: Root kann sich weiterhin mit einem Key von deiner Workstation authentifizieren, was gelegentlich für die Provider-Konsolen-Wiederherstellung nützlich ist — aber kein Passwort wird je funktionieren, für niemanden, von überall. Bestätige mit sshd -T | grep -E 'passwordauthentication|permitrootlogin'.

3. Firewall: Standard-Deny, nur erlauben, was du betreibst

Debians ufw ist eine schlanke, solide Schicht über nftables. Die Policy ist die Sicherheit; die Regeln sind nur Ausnahmen davon:

Copyapt update && apt install -y ufw

ufw default deny incoming
ufw default allow outgoing

# SSH stays open — add this BEFORE enabling
ufw allow 22/tcp comment 'SSH'

# whatever your box actually serves, e.g.:
ufw allow 80/tcp comment 'HTTP'
ufw allow 443/tcp comment 'HTTPS'

ufw enable
ufw status verbose

Jeder Port, den du öffnest, sollte einen Namen und einen Grund haben. Wenn du nicht benennen kannst, wofür ein Port ist, bekommt er keine Regel.

4. fail2ban: die Bots ausbremsen

Mit deaktivierter Passwort-Auth ist Brute-Force bereits tot — aber fail2ban hält deine Logs lesbar und bannt die Scanner, die alles andere anstupsen:

Copyapt install -y fail2ban

Copy# /etc/fail2ban/jail.local
[sshd]
enabled  = true
port     = ssh
maxretry = 5
findtime = 10m
bantime  = 1h

Copysystemctl enable --now fail2ban

# watch it work
fail2ban-client status sshd

5. Automatische Sicherheitsupdates

Die ungepatchte CVE ist ein größeres Risiko als der Reboot. Debian unattended-upgrades installiert Sicherheitsupdates von selbst:

Copyapt install -y unattended-upgrades

# answer Yes to auto-install updates
dpkg-reconfigure -plow unattended-upgrades

Die Standardkonfiguration in /etc/apt/apt.conf.d/50unattended-upgrades zieht nur aus dem Security-Repository — was du auf einem Server willst: Sicherheitsfixes automatisch, alles andere, wenn du es wählst.

6. Abschalten, was du nicht betreibst

Jeder laufende Dienst ist Angriffsfläche, die du patchen musst. Sieh, was tatsächlich lauscht:

Copy# who is listening, on what, as which process
ss -tulpn

# everything enabled at boot
systemctl list-unit-files --state=enabled

# example: you don't run a print server — nobody does
systemctl disable --now cups

Die Regel: Wenn du nicht sagen kannst, was ein Listener tut, finde es heraus, bevor du ihn leben lässt. Auf einem minimalen VPSRento-Image sollte es kaum mehr als sshd und deine eigene Anwendung geben.

7. Optional, aber empfohlen: eine WireGuard-Verwaltungsebene

Die stärkste Form von SSH-Sicherheit ist SSH, das dem Internet gar nicht erst ausgesetzt ist. Betreiben Sie WireGuard auf dem Server, erlauben Sie SSH nur innerhalb des Tunnels, und Port 22 verschwindet von jedem Scanner der Welt:

Copyapt install -y wireguard

# /etc/wireguard/wg0.conf — minimal management tunnel
# [Interface] Address = 10.8.0.1/24, ListenPort = 51820

# open the tunnel, not the shell
ufw allow 51820/udp comment 'WireGuard'
ufw allow in on wg0 to any port 22 proto tcp comment 'SSH via WG'
ufw delete allow 22/tcp

systemctl enable --now wg-quick@wg0

Danach verbinden Sie sich per ssh [email protected] durch den Tunnel, und die öffentliche IP antwortet nur auf genau einen UDP-Port. Die vollständige WireGuard-Anleitung – Schlüssel, Peers, Client-Konfigurationen, QR-Codes fürs Handy – finden Sie im Begleit-Guide.

Die 10-Punkte-Checkliste

Gehen Sie diese Tabelle nach jedem neuen Deployment durch, und erneut nach jedem Dienst, den Sie hinzufügen:

Punkt 10 verdient einen Satz: erst härten, dann Snapshot, in dieser Reihenfolge – ein Snapshot einer sauberen, gehärteten Box ist Ihr Rollback für jeden künftigen Fehler. Tägliche Offsite-Snapshots sind ein $1.99/Monat -Add-on im Clientbereich. Dreißig Minuten Prävention, ein Klick Versicherung.