Einen neuen VPS absichern: die Checkliste

1. Alle Updates installieren

Cloud-Images sind oft Wochen alt. Bring alles auf den neuesten Stand, bevor du irgendetwas anderes installierst, und starte neu, wenn sich der Kernel oder zentrale Bibliotheken geändert haben.

sudo apt update && sudo apt full-upgrade -y
[ -f /var/run/reboot-required ] && echo "reboot needed"

sudo dnf upgrade --refresh -y
sudo dnf needs-restarting -r

In der RHEL-Familie sagt needs-restarting -r, ob ein Neustart nötig ist. Starte mit sudo reboot neu und melde dich wieder an.

2. Einen eigenen Benutzer mit sudo anlegen

Arbeite als namentlicher Benutzer mit sudo, nicht als root: Aktionen werden unter einem Namen protokolliert, und der root-Login lässt sich im nächsten Schritt abschalten.

sudo adduser deploy
sudo usermod -aG sudo deploy

sudo useradd -m deploy
sudo passwd deploy
sudo usermod -aG wheel deploy

Kopiere deinen SSH-Schlüssel zum Benutzer (ssh-copy-id deploy@SERVER_IP von deinem Rechner aus), melde dich aus einem zweiten Terminal als dieser Benutzer an und prüfe sudo -v. Stell dann sicher, dass nur root die Benutzer-ID 0 hat und kein Konto ein leeres Passwort: Der erste Befehl darf nur root ausgeben, der zweite gar nichts.

awk -F: '$3 == 0 {print $1}' /etc/passwd
sudo awk -F: '$2 == "" {print $1}' /etc/shadow

3. SSH absichern

Nur Schlüssel, kein root-Login, wenige Versuche pro Verbindung. Die vollständige Anleitung mit allen Prüfungen und dem Portwechsel steht unter So stoppst du SSH-Brute-Force-Angriffe. Die Kurzfassung, sobald dein Schlüssel-Login funktioniert:

sudo tee /etc/ssh/sshd_config.d/00-hardening.conf > /dev/null <<'EOF'
PubkeyAuthentication yes
PasswordAuthentication no
KbdInteractiveAuthentication no
PermitRootLogin no
MaxAuthTries 4
EOF
sudo sshd -t && echo "config OK"

sudo systemctl reload ssh

sudo systemctl reload sshd

4. Die Firewall einschalten

Alles Eingehende verbieten, dann nur öffnen, was der Server anbietet. Hier SSH auf 22 und ein Webserver auf 80 und 443; lass weg, was bei dir nicht läuft.

sudo apt install -y ufw
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow 22/tcp
sudo ufw allow 80,443/tcp
sudo ufw enable
sudo ufw status verbose

sudo dnf install -y firewalld
sudo systemctl enable --now firewalld
sudo firewall-cmd --permanent --add-service=ssh
sudo firewall-cmd --permanent --add-service=http --add-service=https
sudo firewall-cmd --reload
sudo firewall-cmd --list-all

• Unter RHEL 9 und seinen Rebuilds erlaubt die Standardzone auch cockpit: Entferne es mit sudo firewall-cmd --permanent --remove-service=cockpit, wenn du es nicht nutzt, und lade dann neu.
• Docker veröffentlicht Container-Ports mit eigenen iptables-Regeln, die ufw nicht sieht: Ein mit -p 8080:80 veröffentlichter Port ist offen, auch wenn ufw etwas anderes anzeigt. Veröffentliche auf 127.0.0.1:8080:80, wenn nur der lokale Proxy ihn braucht.
• Die meisten Provider haben zusätzlich eine Cloud-Firewall oder Security Group. Nutze sie als zweite Schicht mit denselben Regeln.

5. Automatische Sicherheitsupdates einschalten

Auf den meisten kompromittierten Servern läuft Software, für die es seit Wochen ein Update gab. Lass den Server Sicherheitsupdates selbst installieren.

sudo apt install -y unattended-upgrades
sudo tee /etc/apt/apt.conf.d/20auto-upgrades > /dev/null <<'EOF'
APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Unattended-Upgrade "1";
EOF
sudo unattended-upgrade --dry-run --debug 2>&1 | tail -n 20

Welche Updates installiert werden, steht in /etc/apt/apt.conf.d/50unattended-upgrades (unter Ubuntu die Sicherheitsupdates, unter Debian die Sicherheits- und Point-Release-Updates). Automatische Neustarts sind aus, solange du dort nicht Unattended-Upgrade::Automatic-Reboot "true"; setzt.

sudo dnf install -y dnf-automatic
sudo sed -i -e 's/^upgrade_type.*/upgrade_type = security/' \
  -e 's/^apply_updates.*/apply_updates = yes/' /etc/dnf/automatic.conf
sudo systemctl enable --now dnf-automatic.timer
systemctl list-timers dnf-automatic.timer

• CentOS Stream veröffentlicht keine Security Advisories, deshalb installiert upgrade_type = security dort nichts: Nimm upgrade_type = default.
• Fedora 41 und neuer nutzen dnf5: Installiere dnf5-plugin-automatic und setze dieselben Optionen in /etc/dnf/automatic.conf (siehe man dnf5-automatic).
• Keines der beiden Werkzeuge startet standardmäßig neu. Plane einen Neustart ein, wenn der Kernel aktualisiert wurde.

6. Backups einrichten, die den Server verlassen

Ein Backup auf demselben Server oder nur im selben Provider-Konto ist weg, wenn der Server oder das Konto weg ist. Bewahre mindestens eine Kopie woanders auf, verschlüsselt, und teste eine Wiederherstellung. Snapshots des Providers sind eine gute Ergänzung, kein Ersatz.

restic ist eine einfache Möglichkeit: verschlüsselt, dedupliziert, auf SFTP, S3 und andere Ziele. Es ist für Debian und Ubuntu paketiert und für die RHEL-Familie in EPEL. Ersetze BACKUP_HOST durch deinen Backup-Server; restic fragt nach einem Repository-Passwort, das du außerhalb dieses Servers aufbewahren musst.

sudo apt install -y restic

sudo dnf install -y epel-release
sudo dnf install -y restic

sudo restic -r sftp:backup@BACKUP_HOST:/srv/restic/$(hostname) init
sudo restic -r sftp:backup@BACKUP_HOST:/srv/restic/$(hostname) backup /etc /home /root /var/www
sudo restic -r sftp:backup@BACKUP_HOST:/srv/restic/$(hostname) snapshots

Exportiere Datenbanken vor dem Backup in eine Datei (mysqldump --single-transaction, pg_dump), statt ihre Datenverzeichnisse im laufenden Betrieb zu kopieren. Beweise dann, dass eine Wiederherstellung funktioniert:

sudo restic -r sftp:backup@BACKUP_HOST:/srv/restic/$(hostname) restore latest --target /tmp/restore-test --include /etc/hostname
cat /tmp/restore-test/etc/hostname

7. Monitoring und Alarme einrichten

Ohne dich anzumelden, musst du erfahren, wann der Server ausfällt, wann die Platte vollläuft und wann sich jemand anmeldet oder ihn angreift. Mindestens:

• Eine externe Uptime-Prüfung der Website oder des Dienstes, von außerhalb deines Providers.
• Einen Alarm bei knappem Speicherplatz und bei fehlgeschlagenen Diensten.
• Eine Aufzeichnung, wer sich angemeldet hat, und einen Alarm bei Angriffen und bei Änderungen an Systemdateien.

Bis ein Werkzeug das für dich übernimmt, zeigen diese Befehle die letzten Anmeldungen, die Fehler seit dem Start und den freien Speicherplatz:

last -n 20
sudo journalctl -p err -b --no-pager | tail -n 30
df -h /

8. Nicht benötigte Ports schließen

Liste auf, was lauscht. Eine Adresse 0.0.0.0 oder [::] bedeutet alle Schnittstellen, also das Internet, sofern die Firewall es nicht aufhält.

sudo ss -tulpn

• Stoppe und deaktiviere die Dienste, die du nicht nutzt.
• Datenbanken und Caches, die nur derselbe Server nutzt, lauschen auf localhost: bind-address = 127.0.0.1 für MySQL und MariaDB, listen_addresses = 'localhost' für PostgreSQL, bind 127.0.0.1 -::1 für Redis.
• Stell die Docker-API (2375, 2376) oder Redis ohne Passwort nie ins Internet: Beides sind gängige Einfallstore für Krypto-Miner.

sudo systemctl disable --now SERVICE_NAME

Prüfe dann von außen, von einem anderen Rechner mit installiertem nmap. Antworten dürfen nur die Ports, die du in Schritt 4 geöffnet hast.

nmap -Pn SERVER_IP

9. Die Uhr synchron halten

Logs verschiedener Server passen nur zusammen, wenn ihre Uhren übereinstimmen, und TLS, Zwei-Faktor-Codes und die Zeitleiste eines Vorfalls hängen alle von der Uhrzeit ab. Prüfe sie:

timedatectl

Du willst System clock synchronized: yes sehen. Wenn nicht:

sudo apt install -y systemd-timesyncd
sudo timedatectl set-ntp true

sudo dnf install -y chrony
sudo systemctl enable --now chronyd
chronyc tracking

10. Logs lange genug aufbewahren

Wenn etwas passiert, lautet die erste Frage, was vorher passiert ist. Mach das System-Journal dauerhaft, mit einer Größengrenze und einer Aufbewahrungsdauer deiner Wahl:

sudo mkdir -p /etc/systemd/journald.conf.d
sudo tee /etc/systemd/journald.conf.d/retention.conf > /dev/null <<'EOF'
[Journal]
Storage=persistent
SystemMaxUse=1G
MaxRetentionSec=1year
EOF
sudo systemctl restart systemd-journald
journalctl --disk-usage

• Richte die Grenze nach der Platte: 1 GB reicht für einen kleinen Server völlig.
• Wie lange du Logs aufbewahren musst, hängt von deinen Verträgen und Pflichten ab (zum Beispiel den Meldepflichten bei Vorfällen nach NIS2). Leg es fest, schreib es auf und stell es hier ein.
• Logs, die nur auf dem Server liegen, kann jeder löschen, der eingebrochen ist. Schick zusätzlich eine Kopie an einen anderen Rechner oder einen Log-Dienst.
• Dateien in /var/log (Webserver, auth.log unter Debian und Ubuntu) rotiert logrotate: Der Wert rotate in /etc/logrotate.d/ legt fest, wie viele alte Dateien erhalten bleiben.

Fragen

Reicht die Firewall des Providers, oder brauche ich zusätzlich ufw oder firewalld?

Nutze beide, wenn du kannst. Die Firewall des Providers hält Verkehr auf, bevor er den Server erreicht; die auf dem Server schützt ihn weiter, wenn die Cloud-Regeln versehentlich geändert werden oder der Server umzieht.

Sind automatische Updates auf einem Produktivserver sicher?

Sicherheitsupdates für die stabilen Releases dieser Distributionen sind klein und getestet und deutlich weniger riskant, als bekannte Lücken offen zu lassen. Lass automatische Neustarts aus und plane sie, und halte ein getestetes Backup bereit.

Wie lange sollte ich Logs aufbewahren?

Eine allgemeingültige Zahl gibt es nicht. Es hängt von deinen Verträgen und von Regeln wie NIS2 für die Unternehmen ab, die darunter fallen. Leg einen Zeitraum fest, bewahre eine Kopie außerhalb des Servers auf und sorg dafür, dass der Server mindestens genug behält, um die letzten Wochen nachzuvollziehen.