Die erste Stunde auf einem neuen VPS: meine Härtungs-Checkliste

Wenn ein neuer VPS online geht, ob für einen Kunden oder für eines meiner eigenen Systeme, wird nichts deployt, bevor er dieselbe kurze Checkliste durchlaufen hat. Das dauert unter einer Stunde und schließt genau die Angriffsfläche, auf die automatisierte Scanner und Bots losgehen, sobald eine neue IP im Internet auftaucht, oft innerhalb von Minuten. Nichts davon ist exotisch, es ist das langweilige Grundzeug, das tatsächlich den Unterschied macht.

1. Sofort weg von Passwort-Login

Als Erstes nach dem initialen Root-Login lege ich einen Non-Root-Benutzer mit Sudo-Rechten an, kopiere meinen SSH-Public-Key dorthin und teste in einem zweiten Terminal, dass der Key-Login funktioniert, bevor irgendetwas anderes passiert.

adduser deploy
usermod -aG sudo deploy
rsync --archive --chown=deploy:deploy ~/.ssh /home/deploy

Sobald der Login funktioniert, bekommt /etc/ssh/sshd_config drei Änderungen:

PermitRootLogin no
PasswordAuthentication no
MaxAuthTries 3

systemctl restart sshd, und von diesem Moment an führt der einzige Weg in den Server über einen privaten Schlüssel, der nur auf meinem Rechner und beim Kunden existiert, niemals über ein Passwort, das man per Brute-Force erraten oder phishen könnte.

2. Firewall mit Default-Deny

UFW (oder CSF, je nach Stack) kommt als Nächstes dran, eingestellt auf "alles Eingehende standardmäßig blockieren" mit nur den Ports, die der Server wirklich braucht, explizit geöffnet:

ufw default deny incoming
ufw default allow outgoing
ufw allow 22/tcp
ufw allow 80/tcp
ufw allow 443/tcp
ufw enable

Alles andere, ein Datenbank-Port, ein Kontrollpanel, ein Admin-Interface, kommt nur dazu, wenn etwas Konkretes es braucht, und meistens beschränkt auf eine bestimmte Quell-IP oder einen VPN-Bereich statt offen für die ganze Welt. Genau dieser Schritt hätte den CyberPanel-Wurm, über den ich schon geschrieben habe, sofort gestoppt: Der verwundbare Admin-Port war von überall erreichbar, und die Firewall-Regel, die das behoben hätte, braucht etwa zehn Sekunden.

3. Fail2ban gegen das Hintergrundrauschen

Selbst mit reinem Key-Login füllen sich die Logs mit Login-Versuchen von Bots, die IP-Bereiche scannen. Fail2ban stoppt keinen gezielten Angriff, reduziert aber das Rauschen deutlich und sperrt IPs nach ein paar Fehlversuchen:

apt install fail2ban
systemctl enable --now fail2ban

Die Standard-sshd-Jail reicht zum Start. Läuft auf dem Server zusätzlich ein webbasierter Dienst wie Nginx oder ein WordPress-Login, kommen dafür eigene Jails dazu, wiederholte /wp-login.php-Zugriffe von derselben IP werden dann genauso schnell gesperrt wie SSH-Brute-Force.

4. Unbeaufsichtigte Sicherheitsupdates

Ein Server, der sich nicht selbst patcht, läuft irgendwann mit einer Kernel- oder OpenSSL-Version, in der eine bekannte Lücke nur darauf wartet, ausgenutzt zu werden. Unattended Upgrades übernehmen Sicherheitspatches automatisch, mit Neustarts in einem ruhigen Zeitfenster, falls ein Kernel-Update einen braucht:

apt install unattended-upgrades
dpkg-reconfigure --priority=low unattended-upgrades

Ich schaue ab und zu in /var/log/unattended-upgrades/, einfach um zu bestätigen, dass es wirklich läuft und nicht nur installiert ist.

Das ist die Grundlage

Nichts davon ist fortgeschritten, und genau das ist der Punkt: Das ist das Minimum, auf dem jeder Server stehen sollte, bevor irgendetwas Anwendungsspezifisches dazukommt. Die Server, bei denen ich Kompromittierungen gesehen habe, sind fast nie an einem Zero-Day gescheitert, sondern an einem Standardpasswort, einem offenen Admin-Port oder einem Kernel, der seit Monaten nicht gepatcht wurde. Eine Stunde hier investiert erspart einen deutlich schlimmeren Tag später.