Prazis Images - stock.adobe.com
Technische Hardening-Maßnahmen für Proxmox VE 9 Hosts
Proxmox VE 9 benötigt für einen sicheren Betrieb gezielte Hardening-Schritte auf Host- und Managementebene. Der Text gibt Tipps für einige wichtige Schritte und zeigt die Umsetzung.
Proxmox VE 9 tritt als leistungsfähige Virtualisierungsplattform auf Basis von Debian auf und verbindet KVM, LXC, Cluster-Funktionen und integrierte Verwaltungsdienste in einem gemeinsamen Stack. Die Lösung wird vor allem dadurch bekannter, weil viele Unternehmen von VMware vSphere zu Proxmox migrieren. Diese Integration erhöht die Effizienz im Betrieb und erweitert zugleich die Angriffsfläche auf Hostebene. Sicherheitsmaßnahmen konzentrieren sich daher auf den Management-Layer, die Systemdienste des Hosts und die Kommunikationspfade zwischen Knoten, Storage und Backup-Infrastruktur. Ein belastbarer Hardening-Ansatz beginnt unmittelbar nach der Installation und begleitet den gesamten Lebenszyklus des Systems.
SSH-Zugriff technisch absichern
Der SSH-Dienst stellt einen primären Zugangspunkt dar und zieht automatisierte Angriffe an. Eine Härtung erfolgt über den Verzicht auf Root-Logins, den Einsatz von Schlüsselauthentisierung und eine restriktive Dienstkonfiguration. Die Datei /etc/ssh/sshd_config bildet die zentrale Steuerstelle. Eine Anpassung setzt die Parameter PermitRootLogin no und PasswordAuthentication no. Die Option PubkeyAuthentication yes bleibt aktiv. Nach der Änderung lädt ein Neustart des Dienstes die Konfiguration mit service ssh restart. Der Betrieb erfolgt anschließend über dedizierte Benutzerkonten mit sudo-Rechten, die Admins für Wartung und Diagnose nutzen. Ergänzend begrenzt eine Firewall den Zugriff auf den SSH-Port auf definierte Managementnetze. Ein zusätzlicher Schutzmechanismus blockiert automatisierte Anmeldeversuche über Fail2Ban.
Fail2Ban für Management-Dienste einsetzen
Fail2Ban analysiert Journald-Einträge und sperrt Quelladressen nach wiederholten Fehlversuchen. Proxmox VE 9 speichert Authentifizierungsereignisse im systemd-Journal, daher nutzt Fail2Ban das Backend systemd. Die Installation erfolgt mit apt update && apt install fail2ban -y. Die Datei /etc/fail2ban/jail.local definiert individuelle Regeln und überschreibt Standardwerte. Eine Jail für SSH aktiviert den Dienst mit einer niedrigen Fehlversuchsschwelle. Eine eigene Filterdefinition kann fehlgeschlagene Login-Versuche aus den Journal-Einträgen von pveproxy auswerten. Die zugehörige Filterdefinition liegt in /etc/fail2ban/filter.d/proxmox.conf und wertet Einträge aus pvedaemon und dem Authentifizierungsmodul aus. Nach der Konfiguration startet der Dienst mit systemctl restart fail2ban. Der Status zeigt aktive Jails über fail2ban-client status. Diese Maßnahme reduziert das Risiko durch Brute-Force-Versuche deutlich.
Proxmox-Firewall kontrolliert aktivieren
Die integrierte Firewall von Proxmox arbeitet zustandsbehaftet und trennt Regeln auf Datacenter- und Knotenebene. Eine Aktivierung ohne vorbereitete Regeln führt zum Verlust des Zugriffs auf das Management-Interface. Eine sichere Vorgehensweise beginnt mit expliziten Freigaben auf Knotenebene. Eine Regel erlaubt TCP-Verbindungen auf Zielport 8006 für die Weboberfläche.
Eine weitere Regel erlaubt den SSH-Port des Hosts. Erst nach dem Setzen dieser Regeln aktiviert die Option Firewall Yes unter Datacenter -> Firewall -> Options den Filter. Der Dienststatus lässt sich mit pve-firewall status prüfen. Weitere Regeln erlauben Clusterkommunikation über Corosync sowie Storage-Zugriffe für NFS oder iSCSI innerhalb dedizierter Netze. Die Firewall erzwingt danach ein restriktives Kommunikationsmodell und blockiert nicht freigegebene Dienste. Wenn ein Cluster verwendet wird, sollten die Cluster-Ports vor der Aktivierung überprüft werden, da sonst ein Split-Brain-Risiko entsteht.
TLS-Zertifikate für die Weboberfläche
Proxmox sichert die Weboberfläche ab Werk über HTTPS mit einem selbstsignierten Zertifikat. Für produktive Umgebungen ersetzt ein Zertifikat einer vertrauenswürdigen CA diese Voreinstellung. Die integrierte ACME-Funktionalität automatisiert den Bezug von Zertifikaten. Unter Datacenter -> ACME definieren Admins einen Account und einen Challenge-Plug-in-Typ. DNS-Challenges eignen sich für Systeme ohne direkte Internetanbindung. Nach der Einrichtung bindet der Knoten das Zertifikat unter System -> Certificates ein. Der Dienst pveproxy lädt das neue Zertifikat. Alternativ übernimmt ein Reverse Proxy die TLS-Terminierung und ergänzt Rate-Limiting oder WAF-Funktionen vor dem Cluster.
Zwei-Faktor-Authentisierung einsetzen
Proxmox integriert TOTP, WebAuthn und Hardware-Token direkt in die Benutzerverwaltung. Die Aktivierung erfolgt unter Datacenter -> Permissions -> Two-Factor. Admins aktivieren 2FA für das Konto root@pam und für alle administrativen Benutzer. Die Anmeldung erfordert danach einen zeitbasierten Code oder einen Sicherheitsschlüssel. Ein kompromittiertes Passwort allein erlaubt keinen Zugriff mehr auf das System.
Rollenbasierte Rechtevergabe umsetzen
Die Benutzerverwaltung von Proxmox trennt Rechte über Rollen, Gruppen und Pfade. Ein monolithischer Root-Zugriff erhöht das Risiko bei einem Sicherheitsvorfall. Eine strukturierte Rechtevergabe erstellt dedizierte Rollen für Backup-Operationen, VM-Verwaltung oder reine Lesezugriffe. Die Konfiguration erfolgt unter Datacenter -> Permissions. Ein kompromittiertes Konto kann danach nur Aktionen innerhalb seines Berechtigungsrahmens ausführen. Diese Begrenzung reduziert den Schaden bei Missbrauch erheblich.
Systemdienste und Protokolle reduzieren
Ein minimierter Host bietet weniger Angriffsfläche. Nicht genutzte Dienste deaktivieren sich dauerhaft über systemd. RPC-Dienste stoppen mit systemctl disable --now rpcbind.service rpcbind.socket. NFS-Komponenten lassen sich über die Einstellung NEED_STATD=no" in "/etc/default/nfs-common deaktivieren. Ein Neustart lädt die geänderte Konfiguration. IPv6 lässt sich deaktivieren, sofern es in der Umgebung nicht benötigt wird und keine Cluster- oder Storage-Komponenten darauf angewiesen sind. Die Datei /etc/sysctl.conf enthält dafür den Parameter net.ipv6.conf.all.disable_ipv6 = 1. Postfix beschränkt sich auf IPv4 durch inet_protocols = ipv4 in /etc/postfix/main.cf und aktiviert einen Neustart des Dienstes mit systemctl restart postfix.service.
Kernelparameter restriktiv setzen
Kernelparameter beeinflussen das Netzwerkverhalten des Hosts direkt. Restriktive sysctl-Parameter nach gängigen Härtungsempfehlungen (etwa des BSI) reduzieren Angriffsvektoren auf Protokollebene. Die Datei /etc/sysctl.conf nimmt Parameter für das Deaktivieren von IP-Forwarding, das Blockieren von Redirects, das Erzwingen von Reverse-Path-Filtering und das Aktivieren von SYN-Cookies auf. Die Aktivierung erfolgt mit sysctl -p. Diese Einstellungen unterbinden unerwünschte Paketflüsse und erschweren Spoofing-Angriffe.
Updates strukturiert durchführen
Regelmäßige Aktualisierungen schließen bekannte Schwachstellen. Proxmox unterscheidet Enterprise- und No-Subscription-Repositories. Admins aktivieren die passende Quelle unter Node -> Updates -> Repositories. Sicherheits-Updates für Debian lassen sich über unattended-upgrades automatisieren. Ein kontrollierter Ablauf testet Aktualisierungen auf einem separaten Knoten oder in einer verschachtelten Umgebung, bevor produktive Hosts folgen. Dieser Prozess reduziert das Risiko ungeplanter Ausfälle.
Storage- und Backup-Zugriffe absichern
Storage-Protokolle erfordern eine restriktive Netzsegmentierung. NFS-Exporte sollten ausschließlich IP-Adressen der Proxmox-Knoten erlauben. iSCSI-LUNs sollten Verbindungen nur aus dedizierten Storage-Netzen akzeptieren. Der Proxmox Backup Server sollte wiederum getrennte Netzpfade und ein eigenes Authentisierungskonzept nutzen.
Ein dediziertes Benutzerkonto mit stark eingeschränkten Rechten bietet sich für den Zugriff auf das Backup-Repository an, da sich der Funktionsumfang gezielt auf Sicherungsaufgaben begrenzen lässt. Der Zugriff über API-Token trennt Backup-Vorgänge von interaktiven Administrationskonten und reduziert die Auswirkungen eines kompromittierten Tokens. Clientseitige Verschlüsselung bietet zusätzlichen Schutz, indem Sicherungen selbst bei direktem Zugriff auf das Zielsystem keinen auswertbaren Inhalt preisgeben. Immutable Backups (unveränderlich) erhöhen die Widerstandsfähigkeit gegenüber nachträglichen Änderungen und sichern die Wiederherstellbarkeit auch dann, wenn administrative Fehler oder Schadsoftware auftreten.
Logging und Überwachung integrieren
Sicherheitsmaßnahmen behalten ihren Wert nur dann, wenn Ereignisse nachvollziehbar bleiben. Eine Weiterleitung der Proxmox-Logs an einen zentralen Syslog-Server verlagert die Auswertung aus dem einzelnen Knoten heraus und erleichtert Korrelationen über mehrere Systeme hinweg. Ergänzende Benachrichtigungen per E-Mail erhöhen die Reaktionsgeschwindigkeit bei relevanten Systemereignissen. Die Einbindung von Monitoring-Lösungen auf Basis von Prometheus, InfluxDB oder Grafana schafft eine dauerhafte Sicht auf Betriebsdaten und ermöglicht die Einordnung von Abweichungen im zeitlichen Verlauf. Wiederholte Anmeldefehler, unerwartete Neustarts oder fehlgeschlagene Jobs fallen dadurch frühzeitig auf und lassen sich technisch bewerten.
Management-Netze physisch trennen
Der Schutz der Umgebung endet nicht bei Softwareeinstellungen. Eine Trennung der Management-Schnittstellen von Proxmox, IPMI oder iDRAC in eigene VLANs verringert die Angriffsfläche, sobald ein Gastnetz oder eine virtuelle Maschine kompromittiert ist. Diese Segmentierung verhindert direkte Zugriffe auf die Verwaltungsoberflächen aus produktiven Netzen. Zugangsdaten für diese Schnittstellen bleiben sinnvollerweise unabhängig von regulären Administrationskonten, um Kettenreaktionen bei Zugangsdatenverlust zu vermeiden. Der Einsatz einer USV stabilisiert den Betrieb bei Stromunterbrechungen und erhält definierte Systemzustände auch unter physischen Störungen.
