Proxmox absichern lassen: Security-Audit und Umsetzung prüfen den vereinbarten Scope. Erstgespräch vereinbaren.
Diese Checkliste führt in sechs Bereichen durch die Absicherung eines Proxmox-VE-Hosts oder -Clusters: Zugänge mit 2FA und SSH, Firewall, Rollen und API-Tokens, Updates, Weboberfläche und Linux-Unterbau. Jeder Bereich nennt Befehle und Konfiguration aus der Herstellerdokumentation und einen Sollzustand zur Abnahme. Stand: Oktober 2026. Änderungen zuerst in einer geeigneten Umgebung prüfen und immer über einen zweiten Zugang (Konsole, IPMI) absichern.
Inhalt
- 1. Zugänge: Web-GUI, SSH und 2FA
- 2. Netzwerk und Firewall
- 3. Rollen und API-Tokens
- 4. Updates und Schwachstellen
- 5. Zertifikate und Brute-Force-Schutz
- 6. Linux-Unterbau und Backup-Schutz
- Prüfliste zur Abnahme
- BSI und Security-Audit-Checkliste
- Abnahme und Betrieb
- Quellen
1. Zugänge: Web-GUI, SSH und 2FA
Begrenzen Sie Web-GUI und SSH auf VPN, Bastion oder freigegebene Quellnetze. Der Benutzer root@pam kann sich laut Dokumentation immer über Linux PAM anmelden und ist uneingeschränkter Administrator. Arbeiten Sie deshalb im Alltag mit benannten Konten und Rollen und sichern Sie root@pam mit starkem Passwort und 2FA.
Zwei-Faktor-Anmeldung: Proxmox VE unterstützt TOTP, WebAuthn (Hardware-Keys, TPM), Recovery Keys und YubiKey OTP. Die Einrichtung läuft in der Weboberfläche beim Benutzer unter „TFA“. Erzwingen können Sie sie je Authentifizierungs-Realm. Nach 8 fehlgeschlagenen TOTP-Versuchen wird der Zugang gesperrt, bei WebAuthn und Recovery Keys nach 100 Versuchen für eine Stunde. Verwahren Sie Recovery Keys getrennt und prüfen Sie auch alternative Realms und Notfallkonten.
SSH: Die PVE-2FA gilt nicht für den SSH-Dienst. Setzen Sie SSH auf Schlüsselanmeldung, in einer Datei unter /etc/ssh/sshd_config.d/:
PermitRootLogin prohibit-password
PasswordAuthentication no
KbdInteractiveAuthentication no
sshd -t && systemctl reload ssh # Syntax prüfen, dann neu laden
sshd -T | grep -E 'permitrootlogin|passwordauthentication|kbdinteractiveauthentication'
Ein vollständiges PermitRootLogin no ist in Clustern riskant, weil Knoten untereinander schlüsselbasierte Root-Verbindungen nutzen; prohibit-password verbietet nur das Passwort. Öffnen Sie vor dem Abschalten der Passwortanmeldung eine zweite Sitzung und prüfen Sie den Schlüsselzugang. Kontrollieren Sie auch Match-Blöcke in der OpenSSH-Konfiguration.
2. Netzwerk und Firewall
Dokumentieren Sie zuerst erlaubte Verbindungen für Management, Corosync, Storage, Migration und Gäste. Die Ports, die Proxmox VE nutzt:
| Dienst | Port | Zugriff erlauben für |
|---|---|---|
| Web-GUI und API | TCP 8006 | Verwaltungsnetz oder VPN |
| SSH | TCP 22 | Verwaltungsnetz oder VPN |
| VNC-Konsole | TCP 5900-5999 | Verwaltungsnetz |
| SPICE-Proxy | TCP 3128 | Verwaltungsnetz |
| Corosync | UDP 5405-5412 | Nur Cluster-Netz |
| Live-Migration | TCP 60000-60050 | Nur Cluster- oder Migrationsnetz |
| rpcbind (NFS) | UDP/TCP 111 | Nur NFS-Netz, falls genutzt |
Die Proxmox-Firewall arbeitet auf drei Ebenen: Datacenter (cluster.fw), Host und Gast. Bei aktivierter Datacenter-Firewall erlaubt sie nach Dokumentation standardmäßig Verkehr über Loopback, bestehende Verbindungen, Management-Zugriffe aus dem lokalen Netz (Web-GUI, SSH, VNC, SPICE), die Cluster-Kommunikation sowie bestimmte ICMP-Typen. Eigene Regeln für ein getrenntes Verwaltungsnetz legen Sie als IP-Set und Regel an, zum Beispiel in /etc/pve/firewall/cluster.fw:
[OPTIONS]
enable: 1
[IPSET management]
203.0.113.0/24
[RULES]
IN ACCEPT -source +management -p tcp -dport 8006,22
Vorgehen gegen das Aussperren: Regeln zuerst anlegen, die Firewall erst danach aktivieren, jede Ebene über einen zweiten Zugang prüfen und den Zustand kontrollieren:
pve-firewall status # Dienststatus und Konfigurationsprüfung
pve-firewall compile # die erzeugten Regeln ansehen
iptables-save | head -50 # aktive Regeln auf dem Host
Eine pauschale DROP-Regel kann Cluster oder Administration aussperren. Die nftables-Implementierung proxmox-firewall ist laut aktueller Dokumentation noch Tech Preview; ein Backend-Wechsel ist kein beiläufiger Härtungsschritt.
3. Rollen und API-Tokens
Vergeben Sie Rollen und Pfade nach Aufgabe. Vordefiniert sind unter anderem PVEAuditor (nur lesen), PVEVMUser (Gast nutzen, Konsole, Backup) und PVEVMAdmin (Gäste verwalten). Eigene Rollen legen Sie mit pveum role add an:
pveum user add monitoring@pve --comment "Nur-Lese-Zugriff"
pveum acl modify / --user monitoring@pve --role PVEAuditor
pveum user token add monitoring@pve readonly --privsep 1
API-Tokens erhalten eigene ACLs und bleiben auf Privilege Separation, dem Standard für neue Tokens. Ihre effektiven Rechte sind dann die Schnittmenge aus Benutzer- und Tokenrechten; ein Token ohne Privilege Separation übernimmt die vollen Rechte des Benutzers. Der Tokenwert wird nur einmal angezeigt. Prüfen Sie Berechtigungen mit einem Testkonto und dokumentieren Sie Rotation und Widerruf (Benutzerverwaltung).
4. Updates und Schwachstellen
Prüfen Sie unterstützte PVE-Version, Repository und offene Advisories. Reguläre Paketupdates erfolgen über die Weboberfläche oder auf der Kommandozeile; Backup, Wartungsfenster und Clusterzustand werden vorab geprüft:
pveversion -v # installierte Versionen der Pakete
apt update && apt full-upgrade
Major-Upgrades benötigen einen eigenen Ablauf, einschließlich der Ceph- und PBS-Abhängigkeiten (Upgrade von 8 auf 9). Für Produktivsysteme ist das Enterprise-Repository oder ein kommerzieller Betrieb ohne Subscription bewusst zu entscheiden. Proxmox-Dokumentation.
5. Zertifikate und Brute-Force-Schutz
Verwenden Sie ein geeignetes Zertifikat für den Administrationszugang. PVE unterstützt ACME einschließlich automatischer Erneuerung. Wählen Sie HTTP- oder DNS-Challenge passend zur Erreichbarkeit; öffnen Sie nicht allein dafür dauerhaft die Managementoberfläche. Der Ablauf auf der Kommandozeile (Domain und Adresse anpassen):
pvenode acme account register default [email protected]
pvenode config set --acme domains=pve.example.com
pvenode acme cert order
Gegen wiederholte Anmeldeversuche an der Weboberfläche beschreibt das Proxmox-Wiki eine Fail2ban-Anbindung. Der Filter liest die pvedaemon-Meldungen aus dem Journal, die Jail sperrt nach drei Fehlversuchen:
# /etc/fail2ban/filter.d/proxmox.conf
[Definition]
failregex = pvedaemon\[.*authentication failure; rhost=<HOST> user=.* msg=.*
journalmatch = _SYSTEMD_UNIT=pvedaemon.service
# /etc/fail2ban/jail.local
[proxmox]
enabled = true
port = https,http,8006
filter = proxmox
backend = systemd
maxretry = 3
findtime = 2d
bantime = 1h
Danach systemctl restart fail2ban; gesperrte Adressen gibt fail2ban-client unban <IP> frei. Fail2ban ergänzt die Einschränkung auf Verwaltungsnetz oder VPN, ersetzt sie aber nicht.
6. Linux-Unterbau und Backup-Schutz
Prüfen Sie, welche Dienste auf welchen Adressen lauschen, und deaktivieren Sie nicht benötigte:
ss -tlnp # lauschende TCP-Dienste mit Prozess
systemctl list-unit-files --state=enabled
Prüfen Sie außerdem Containerprivilegien (bevorzugt unprivilegierte Container) und AppArmor für die konkrete Umgebung (Container-Dokumentation). Kernel-Parameter werden nicht pauschal aus fremden Listen übernommen. Trennen Sie Backup-Zugänge und Schlüssel von der täglichen Administration. Prüfen Sie Offsite-Kopie, Aufbewahrung und Wiederherstellung. Ein erfolgreicher Backup-Job belegt keinen erfolgreichen Restore.
Prüfliste zur Abnahme
| Bereich | Prüfung | Sollzustand |
|---|---|---|
| 2FA | Anmeldung aller Administratoren | TOTP oder WebAuthn erzwungen, Recovery Keys getrennt verwahrt |
| SSH | sshd -T |
Keine Passwortanmeldung, Schlüsselzugang getestet |
| Firewall | pve-firewall status und Zugriff von außen |
Nur Verwaltungsnetz erreicht 8006 und 22 |
| Corosync | Portscan aus dem Nicht-Cluster-Netz | UDP 5405-5412 nicht erreichbar |
| Tokens | pveum user token list je Benutzer |
Privilege Separation, Rotation dokumentiert |
| Updates | pveversion -v |
Unterstützte Version, aktuelle Pakete |
| Zertifikat | Browser-Zugriff | Gültiges Zertifikat, Erneuerung automatisch |
| Dienste | ss -tlnp |
Nur benötigte Dienste lauschen |
| Backup | Restore-Protokoll | Wiederherstellung mit Schlüssel erfolgreich |
BSI und Security-Audit-Checkliste
Der BSI-Baustein SYS.1.5 Virtualisierung, Edition 2023 behandelt die Absicherung der Virtualisierungsinfrastruktur. Die folgende Zuordnung ist eine Arbeitshilfe, kein BSI-Nachweis und keine Zertifizierung:
| Prüffeld | Zu erhebender Nachweis |
|---|---|
| Zugänge und Rechte | Konten, Realms, MFA, Token-ACLs und Notfallzugang |
| Netztrennung | Netzplan, Regelwerk und erlaubte sowie abgewiesene Verbindungen |
| Pflege und Protokollierung | Paketstand, Änderungsprotokoll und Log-Zugriff |
| Wiederherstellung | Backup-Umfang, Schlüsselzugriff und Restore-Protokoll |
Erfassen Sie je Punkt Status, Beleg, Abweichung, Zuständigkeit und Folgemaßnahme. Fehlende Nachweise bleiben offen; eine installierte Schutzfunktion allein ist keine bestandene Prüfung.
Abnahme und Betrieb
Prüfen Sie erlaubte und gesperrte Zugriffe, MFA, Tokenrechte, Alarmierung und einen dokumentierten Wiederanlauf. Der Restore-Test prüft den vereinbarten Wiederherstellungsweg. Für laufende Pflege gibt es Managed Proxmox.
Security-Audit: Den Prüfumfang für Proxmox-Sicherheit und Härtung mit WZ-IT abstimmen. Vertiefung: PBS-Restore testen.
