Die erste Stunde auf einem neuen VPS: Meine Hardening-Checkliste

Wenn ein neuer VPS online geht, wird absolut nichts bereitgestellt, bevor er diese Checkliste durchlaufen hat. Es dauert keine Stunde und schließt sofort die Angriffsfläche, auf die automatisierte Scanner abzielen, sobald eine neue IP im Netz auftaucht. Nichts davon ist exotisch oder geheim. Es sind die langweiligen, grundlegenden Dinge, die wirklich zählen.

1. Passwort-Login sofort abschalten

Das Erste, was ich nach dem initialen Root-Login mache: einen Nicht-Root-Benutzer mit sudo-Rechten anlegen, meinen Public-SSH-Key kopieren und den schlüsselbasierten Login testen. Ich mache das in einem zweiten Terminalfenster, bevor ich irgendetwas anderes anfasse.

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

Sobald der Login funktioniert, passe ich in /etc/ssh/sshd_config drei Zeilen an:

PermitRootLogin no
PasswordAuthentication no
MaxAuthTries 3

Mit systemctl restart sshd wird die Änderung aktiv. Ab diesem Punkt kommt man nur noch mit einem Private Key auf den Server. Es gibt keine Passwörter mehr, die per Brute-Force erraten oder gephisht werden könnten.

2. Firewall auf "Default Deny"

Als Nächstes kommt UFW (oder CSF). Ich setze den Standard so, dass jeglicher eingehender Traffic blockiert wird. Geöffnet werden nur die Ports, die der Server tatsächlich braucht:

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

Datenbank-Ports, Control-Panels oder Admin-Interfaces werden nur freigegeben, wenn sie zwingend benötigt werden. Und wenn, dann schränke ich den Zugriff auf spezifische IP-Adressen oder ein VPN ein – solche Ports stehen niemals komplett offen im Netz. Eine einfache Firewall-Regel wie diese hätte den CyberPanel-Wurm, über den ich kürzlich geschrieben habe, sofort gestoppt. Dort war der anfällige Admin-Port für die ganze Welt erreichbar.

3. Fail2ban gegen das Rauschen

Selbst wenn SSH nur noch Keys akzeptiert, füllen sich die Logs schnell mit Login-Versuchen von Botnetzen. Fail2ban hält keinen zielgerichteten, hochentwickelten Angriff auf, aber es senkt das Grundrauschen enorm, indem es IPs nach ein paar Fehlversuchen sperrt:

apt install fail2ban
systemctl enable --now fail2ban

Der Standard-Jail für sshd reicht für den Anfang. Wenn der Server auch webbasierte Dienste wie Nginx oder eine WordPress-Login-Seite betreibt, füge ich dafür ebenfalls Jails hinzu. Wiederholte /wp-login.php-Anfragen von derselben IP werden genauso schnell geblockt wie SSH-Scans.

4. Automatische Sicherheitsupdates (Unattended Upgrades)

Ein Server, der sich nicht selbst patcht, wird irgendwann mit einem Kernel oder einer OpenSSL-Version laufen, für die es einen bekannten Exploit gibt. unattended-upgrades kümmert sich automatisch um diese Sicherheitspatches.

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

Ich werfe ab und zu einen Blick in /var/log/unattended-upgrades/, um sicherzugehen, dass es auch wirklich läuft und nicht nur nutzlos installiert ist.

Das absolute Minimum

Nichts davon ist extrem fortgeschritten. Und das ist auch der Sinn der Sache. Es ist die absolute Mindestanforderung, die jeder Server erfüllen muss, bevor man auch nur an Applikations-Code denkt. Die kompromittierten Server, die ich gesehen habe, sind fast nie an Zero-Days gescheitert; sie fielen Standardpasswörtern, offenen Admin-Ports oder monatelang nicht gepatchten Kerneln zum Opfer. Eine investierte Stunde hier spart einen katastrophalen Tag in der Zukunft.