Proxmox Firewall einrichten – Grundlagen und Best Practices

Proxmox VE bringt bereits eine integrierte Firewall mit.

Damit lassen sich nicht nur einzelne virtuelle Maschinen absichern, sondern auch:

• Proxmox Hosts
• Container
• komplette Cluster
• virtuelle Netzwerke

zentral verwalten.

Gerade bei öffentlich erreichbaren Proxmox-Systemen sollte die Firewall nicht erst nachträglich berücksichtigt werden.

Ein falsch abgesicherter Hypervisor kann besonders kritisch sein, denn auf einem einzigen Proxmox Host laufen möglicherweise:

• Domain Controller
• Terminalserver
• Webserver
• Datenbanken
• NAS-Systeme
• Managementsysteme
• Firewalls
• Kundensysteme

Wird der Hypervisor kompromittiert, können damit mehrere virtuelle Systeme gleichzeitig betroffen sein.

In dieser Anleitung erklären wir deshalb, wie die Proxmox Firewall funktioniert, wie Regeln aufgebaut werden und welche Best Practices sich für produktive Umgebungen empfehlen.

Hat Proxmox eine eigene Firewall?

Ja.

Proxmox VE besitzt eine integrierte Firewall, die direkt über die Weboberfläche administriert werden kann.

Sie lässt sich unter anderem auf folgenden Ebenen konfigurieren:

Datacenter

↓

Node

↓

VM / Container

Dadurch können sowohl globale als auch individuelle Regeln erstellt werden.

Zusätzlich unterstützt Proxmox unter anderem:

• Security Groups
• IP Sets
• Aliases
• Firewall-Makros
• Logging
• IPv4
• IPv6

Proxmox speichert die Firewallkonfiguration clusterweit beziehungsweise ressourcenspezifisch im Proxmox Cluster File System unter /etc/pve. Dazu gehören globale Regeln sowie Regeln für Hosts, VMs und Container.

Proxmox Firewall oder pfSense?

Eine häufige Frage lautet:

Wenn Proxmox bereits eine Firewall besitzt, brauche ich überhaupt noch pfSense oder OPNsense?

Beide Lösungen erfüllen unterschiedliche Aufgaben.

Proxmox Firewall

Die integrierte Firewall eignet sich besonders zum Schutz von:

• Proxmox Hosts
• VMs
• Containern
• einzelnen Netzwerkinterfaces

Sie arbeitet sehr nah an der Virtualisierungsplattform.

pfSense oder OPNsense

Eine virtuelle oder physische Firewall wie pfSense oder OPNsense übernimmt dagegen häufig das zentrale Routing zwischen:

• Internet
• VLANs
• Servernetzen
• VPN
• Standorten

Ein typischer Aufbau lautet deshalb:

Internet

↓

pfSense / OPNsense

↓

Server-Netzwerke

↓

Proxmox

↓

Proxmox Firewall

↓

VM

Beide Firewalls können also gleichzeitig sinnvoll sein.

Die externe Firewall schützt das gesamte Netzwerk.

Die Proxmox Firewall bietet eine zusätzliche Sicherheitsschicht direkt am Hypervisor beziehungsweise an der VM.

Wie ist die Proxmox Firewall aufgebaut?

Eines der wichtigsten Konzepte ist die hierarchische Struktur.

Regeln können auf unterschiedlichen Ebenen erstellt werden.

Datacenter Firewall

Die Datacenter-Ebene gilt clusterweit.

Hier eignen sich insbesondere Regeln beziehungsweise Objekte, die für mehrere Nodes oder VMs verwendet werden sollen.

Beispielsweise:

• Management-Netze
• Administrator-IP-Adressen
• globale Security Groups
• IP Sets
• Aliases

Node Firewall

Die Node Firewall schützt den jeweiligen Proxmox Host.

Darüber sollte beispielsweise geregelt werden, wer Zugriff erhält auf:

• Proxmox Webinterface
• SSH
• Clusterkommunikation
• andere Hostdienste

VM- und Container-Firewall

Für jede virtuelle Maschine beziehungsweise jeden Container können eigene Regeln definiert werden.

Beispielsweise:

Webserver

TCP 443 erlauben

TCP 80 erlauben

alles andere eingehend blockieren

Proxmox dokumentiert diese unterschiedlichen Konfigurationsebenen ausdrücklich für clusterweite, hostspezifische sowie VM-/Container-Regeln.

Proxmox Firewall aktivieren

Eine Besonderheit der Proxmox Firewall:

Sie muss an den richtigen Stellen aktiviert werden.

Es reicht nicht zwingend aus, einfach eine Firewallregel zu erstellen.

Schritt 1: Datacenter Firewall aktivieren

Navigieren Sie zu:

Datacenter

→ Firewall

→ Options

Dort kann die Firewall grundsätzlich aktiviert werden.

Schritt 2: Node Firewall prüfen

Anschließend:

Node

→ Firewall

→ Options

Hier können weitere Optionen für den jeweiligen Host festgelegt werden.

Schritt 3: Firewall am VM-Netzwerkinterface aktivieren

Bei virtuellen Maschinen und Containern muss zusätzlich geprüft werden, ob die Firewall für das entsprechende virtuelle Netzwerkinterface aktiviert wurde.

Bei einer VM beispielsweise:

VM

→ Hardware

→ Network Device

→ Firewall

Die Option muss aktiviert sein.

Auch bei LXC-Containern besitzt das virtuelle Interface eine eigene firewall-Option. Proxmox dokumentiert diese direkt als Bestandteil der Container-Netzwerkkonfiguration.

Vorsicht: Nicht aus Proxmox aussperren

Das ist der wichtigste Hinweis dieser gesamten Anleitung.

Bevor die Standardregel auf DROP gesetzt wird, sollte sichergestellt werden, dass der eigene Administrationszugriff ausdrücklich erlaubt ist.

Beispielsweise:

Management-Netz

192.168.10.0/24

↓

Proxmox TCP 8006

ALLOW

und gegebenenfalls:

TCP 22

ALLOW

Erst danach sollte eine restriktivere Default Policy aktiviert werden.

Wer zuerst:

Input Policy = DROP

setzt und anschließend erst die Erlaubnisregeln erstellen möchte, kann den eigenen Zugriff verlieren.

Besonders kritisch ist das bei einem Remote-Server im Rechenzentrum.

Dort sollte idealerweise zusätzlicher Zugang vorhanden sein über:

• IPMI
• iDRAC
• iLO
• KVM-over-IP
• Remote Console

Damit lässt sich ein falsch konfigurierter Host weiterhin erreichen.

Welche Ports verwendet Proxmox?

Für die Administration eines normalen Proxmox Hosts sind insbesondere folgende Dienste relevant.

TCP 8006

Proxmox Webinterface und API.

Beispiel:

https://proxmox.example.de:8006

TCP 22

SSH.

SSH sollte allerdings nur für:

• Administratoren
• Managementnetzwerke
• VPN-Netze

zugänglich sein.

Es besteht normalerweise kein Grund, SSH weltweit öffentlich erreichbar zu machen.

Proxmox Webinterface aus dem Internet erreichbar?

Wenn möglich, sollte das Proxmox Webinterface nicht direkt für das gesamte Internet geöffnet werden.

Besser sind beispielsweise:

Variante 1

Management-VLAN

Variante 2

VPN

Variante 3

feste Administrator-IP-Adressen

Variante 4

Bastion Host beziehungsweise Jump Host

Ein Administrator verbindet sich beispielsweise:

Notebook

↓

VPN

↓

Management VLAN

↓

Proxmox

Damit ist TCP 8006 nicht für beliebige Internetadressen erreichbar.

Management-VLAN für Proxmox

Für professionelle Umgebungen empfiehlt sich ein eigenes Managementnetz.

Beispielsweise:

VLAN 10

Clients

VLAN 20

Server

VLAN 30

Backup

VLAN 40

Management

Der Proxmox Host erhält seine Management-IP ausschließlich im Management-VLAN.

Beispielsweise:

172.20.40.10

Zugriff auf dieses Netz erhalten nur:

• Administratoren
• Monitoring
• Backup
• ausgewählte Infrastruktur

Normale Benutzer benötigen keinen Zugriff auf das Proxmox Webinterface.

Default Allow oder Default Deny?

Eine zentrale Designentscheidung lautet:

Was passiert mit Netzwerkverkehr, für den keine Regel existiert?

Grundsätzlich gibt es zwei Ansätze.

Default Allow

Alles ist erlaubt, sofern es nicht ausdrücklich blockiert wurde.

Default Deny

Alles wird blockiert, sofern es nicht ausdrücklich erlaubt wurde.

Für Serverumgebungen ist Default Deny meist der bessere Ansatz.

Beispielsweise:

INPUT Policy

DROP

und anschließend:

TCP 443 → ALLOW

TCP 22 aus Managementnetz → ALLOW

Monitoring-IP → ALLOW

Dadurch werden nur tatsächlich benötigte Dienste freigeschaltet.

Proxmox unterstützt für eingehenden und ausgehenden Traffic entsprechende DROP- beziehungsweise REJECT-Policies auf Datacenter- sowie VM-/Container-Ebene.

DROP oder REJECT?

Auch das sorgt häufig für Verwirrung.

DROP

Pakete werden verworfen.

Der Absender erhält keine direkte Antwort.

REJECT

Die Verbindung wird abgelehnt und der Absender erhält eine entsprechende Antwort.

Für eingehenden unerwünschten Verkehr wird häufig DROP verwendet.

REJECT kann beispielsweise intern sinnvoll sein, wenn ein Client schnell erkennen soll, dass eine Verbindung nicht zulässig ist.

IN und OUT Regeln

Proxmox unterscheidet zwischen eingehendem und ausgehendem Netzwerkverkehr.

IN

Verkehr, der zur geschützten Ressource kommt.

Beispielsweise:

Internet

→ Webserver

OUT

Verkehr, der die Ressource verlässt.

Beispielsweise:

Webserver

→ Internet

Viele einfache Serverkonfigurationen konzentrieren sich zunächst auf die IN-Richtung.

In besonders abgesicherten Umgebungen kann jedoch auch ausgehender Traffic eingeschränkt werden.

Beispiel: Webserver absichern

Angenommen, eine VM betreibt einen Webserver.

IP-Adresse:

10.20.10.20

Benötigt werden:

• HTTP
• HTTPS
• SSH ausschließlich aus Managementnetz

Dann könnten Regeln konzeptionell so aussehen:

Regel 1

IN

ALLOW

TCP 80

Regel 2

IN

ALLOW

TCP 443

Regel 3

IN

ALLOW

Source:

10.20.40.0/24

TCP 22

Default

IN Policy:

DROP

Damit kann das Internet auf:

• HTTP
• HTTPS

zugreifen.

SSH funktioniert dagegen nur aus dem Managementnetz.

Beispiel: Windows Terminalserver

Ein Terminalserver benötigt normalerweise nicht automatisch öffentliche Erreichbarkeit über TCP 3389.

Ein besseres Konzept wäre beispielsweise:

Internet

↓

VPN / Remote Desktop Gateway

↓

Terminalserver

Die Proxmox Firewall könnte dann beispielsweise erlauben:

Managementnetz

→ RDP

oder:

RDS Gateway

→ RDP

aber:

Internet

→ RDP

blockieren.

TCP 3389 sollte nicht unnötig direkt ins Internet veröffentlicht werden.

Beispiel: Datenbankserver

Ein Datenbankserver benötigt häufig überhaupt keinen Internetzugriff von außen.

Beispielsweise:

Webserver

10.20.10.20

Datenbank

10.20.20.20

Die Firewall könnte erlauben:

10.20.10.20

→

10.20.20.20

TCP 3306

oder beispielsweise TCP 5432.

Alle anderen Verbindungen zur Datenbank werden blockiert.

Damit reduziert sich die Angriffsfläche erheblich.

Was sind Proxmox Security Groups?

Security Groups gehören zu den praktischsten Funktionen der Proxmox Firewall.

Statt identische Regeln bei jeder VM einzeln anzulegen, können mehrere Regeln zu einer Gruppe zusammengefasst werden.

Beispielsweise:

Security Group: Webserver

enthält:

• HTTP 80
• HTTPS 443
• Monitoring
• SSH aus Managementnetz

Diese Security Group kann anschließend mehreren VMs zugewiesen werden.

Proxmox unterstützt Security Groups ausdrücklich als wiederverwendbare Gruppen von Firewallregeln.

Beispiel für Security Groups

Ein Unternehmen besitzt 20 Linux-Webserver.

Ohne Security Group müsste auf jedem Server definiert werden:

HTTP erlauben

HTTPS erlauben

SSH aus Adminnetz erlauben

Monitoring erlauben

Mit Security Groups wird einmal definiert:

SG-Webserver

und anschließend allen 20 VMs zugewiesen.

Ändert sich später die Monitoring-IP, muss nicht jede VM einzeln angepasst werden.

Sinnvolle Security Groups

Beispiele für wiederverwendbare Gruppen:

SG-Webserver

• HTTP
• HTTPS
• Monitoring

SG-Windows-Server

• RDP aus Managementnetz
• Monitoring
• Backup

SG-Linux-Server

• SSH aus Managementnetz
• Monitoring
• Backup

SG-Domain-Controller

• benötigte AD-Dienste
• DNS
• Management

SG-Management

• SSH
• RDP
• Monitoring

Damit lassen sich Firewallregeln deutlich übersichtlicher verwalten.

Was sind IP Sets?

IP Sets bündeln mehrere:

• IP-Adressen
• Subnetze

zu einer logischen Gruppe.

Beispielsweise:

IP Set: Admin_Networks

enthält:

192.168.10.0/24

172.16.50.0/24

10.100.0.0/24

Anstatt jede dieser Adressen in jeder Firewallregel einzeln einzutragen, kann anschließend das gesamte IP Set verwendet werden.

Proxmox bietet IP Sets genau für solche wiederverwendbaren IP- und Netzwerklisten an.

Typische IP Sets

Management

Enthält sämtliche Administratornetze.

Monitoring

Enthält Monitoringserver.

Backup

Enthält Backupserver.

Trusted

Enthält vertrauenswürdige interne Systeme.

Blocklist

Enthält gesperrte IP-Adressen beziehungsweise Netzwerke.

Dadurch werden Regeln wesentlich leichter verständlich.

Was sind Aliases?

Aliases geben IP-Adressen verständliche Namen.

Statt:

10.20.30.14

kann beispielsweise verwendet werden:

Backup_Server

oder:

Monitoring_Server

Proxmox unterstützt dafür eigene IP Aliases.

Das verbessert besonders bei größeren Umgebungen die Lesbarkeit.

Vergleichen Sie:

Source: 10.20.30.14

mit:

Source: Monitoring_Server

Die zweite Variante ist später deutlich leichter zu verstehen.

Regeln sinnvoll benennen und kommentieren

Eine Firewall wächst mit der Zeit.

Was heute offensichtlich erscheint, ist in zwei Jahren möglicherweise nicht mehr nachvollziehbar.

Deshalb sollte jede besondere Freigabe dokumentiert werden.

Beispielsweise:

Allow Backup Server to Windows VM

ist besser als:

Rule 14

Idealerweise sollte erkennbar sein:

• Warum existiert die Regel?
• Wer benötigt sie?
• Welche Anwendung verwendet sie?

Nicht mehr benötigte Regeln können später einfacher entfernt werden.

Proxmox Firewall und VLANs

Die Proxmox Firewall ersetzt nicht automatisch ein gutes Netzwerkdesign.

Beispielsweise:

VLAN 10 – Management

VLAN 20 – Server

VLAN 30 – Backup

VLAN 40 – Kundenserver

Die VLAN-Trennung findet zunächst auf Netzwerkebene statt.

Die Firewall kontrolliert anschließend, welche Kommunikation zwischen beziehungsweise zu den jeweiligen Systemen zulässig ist.

Eine gute Infrastruktur kombiniert deshalb:

VLAN-Segmentierung

zentrale Firewall

Proxmox Firewall

VLANs allein sind keine Firewall

Ein häufiges Missverständnis:

Wir haben VLANs, also sind die Server voneinander getrennt.

Nicht zwangsläufig.

Wenn der Router beziehungsweise die Firewall sämtlichen Inter-VLAN-Verkehr erlaubt, können die Systeme weiterhin miteinander kommunizieren.

VLANs schaffen zunächst getrennte Broadcast Domains.

Die eigentliche Zugriffskontrolle erfolgt durch Firewallregeln.

Proxmox Bridge und Firewall

Proxmox arbeitet häufig mit Linux Bridges.

Beispielsweise:

vmbr0

Eine VM wird mit ihrem virtuellen Netzwerkinterface an diese Bridge angebunden.

Vereinfacht:

physische NIC

↓

vmbr0

↓

virtuelle NIC

↓

VM

Wird die Proxmox Firewall für das virtuelle Interface aktiviert, kann Netzwerkverkehr bereits auf Hypervisor-Ebene kontrolliert werden.

Firewall pro Netzwerkinterface

Eine VM kann mehrere Netzwerkinterfaces besitzen.

Beispielsweise:

net0

Produktionsnetz

net1

Backupnetz

net2

Managementnetz

Die Firewall kann entsprechend der jeweiligen Interfacekonfiguration eingesetzt werden.

Das ist besonders hilfreich bei Servern mit mehreren Netzwerkanbindungen.

Proxmox Firewall bei LXC-Containern

Die integrierte Firewall kann nicht nur für virtuelle Maschinen, sondern auch für LXC-Container verwendet werden.

Beim Netzwerkinterface eines Containers kann die Firewall ebenfalls aktiviert werden.

Proxmox integriert Container ausdrücklich in dasselbe Firewall- und Netzwerkmodell wie virtuelle Maschinen.

Dadurch können beispielsweise Webcontainer mit sehr restriktiven Regeln betrieben werden.

Firewall auf Host und VM gleichzeitig?

Ja.

Das kann sogar sinnvoll sein.

Beispielsweise:

Host Firewall

schützt:

• Proxmox Webinterface
• SSH
• Clusterkommunikation

VM Firewall

schützt:

• Webserver
• Datenbank
• Terminalserver

Die Regeln erfüllen unterschiedliche Aufgaben.

Proxmox Firewall und Gastbetriebssystem-Firewall

Auch innerhalb der VM sollte die lokale Firewall normalerweise aktiviert bleiben.

Beispielsweise:

Proxmox Firewall

Windows Defender Firewall

oder:

Proxmox Firewall

nftables/firewalld im Linux-Gast

Das entspricht dem Prinzip:

Defense in Depth

Fällt eine Sicherheitsschicht aus oder wird falsch konfiguriert, existiert noch eine weitere.

Windows Firewall nicht deaktivieren

Bei Windows Servern wird die Windows Defender Firewall leider teilweise komplett deaktiviert, sobald Netzwerkprobleme auftreten.

Das ist keine gute Dauerlösung.

Besser:

1. benötigte Ports identifizieren
2. gezielt freigeben
3. Firewall aktiviert lassen

Auch wenn bereits die Proxmox Firewall vorgeschaltet ist.

Ausgehenden Traffic begrenzen?

Für viele Systeme lautet die OUT Policy zunächst:

ACCEPT

Das ist administrativ einfacher.

Für besonders sensible Server kann auch ausgehender Traffic eingeschränkt werden.

Beispielsweise ein Datenbankserver benötigt vielleicht:

• DNS
• NTP
• Updates
• Backup

aber keinen beliebigen Zugriff auf das gesamte Internet.

Eine kompromittierte VM könnte dann weniger einfach externe Command-and-Control-Systeme erreichen.

Allerdings erhöht eine restriktive Egress-Firewall den Administrationsaufwand erheblich.

Wann Egress Filtering sinnvoll ist

Besonders interessant für:

• Datenbankserver
• Managementsysteme
• Backupserver
• kritische Infrastruktur
• besonders sensible Kundensysteme

Für jeden beliebigen Arbeitsplatzserver sämtliche ausgehenden Ziele einzeln freizuschalten, kann dagegen unverhältnismäßig komplex werden.

ICMP blockieren?

ICMP wird häufig pauschal blockiert.

Das ist nicht immer sinnvoll.

ICMP wird unter anderem benötigt beziehungsweise verwendet für:

• Ping
• Fehlerdiagnose
• Path MTU Discovery
• Netzwerkfunktionen

Gerade bei IPv6 spielt ICMPv6 eine noch wichtigere Rolle.

Ein vollständiges Blockieren kann deshalb Netzwerkprobleme verursachen.

Besser ist eine bewusst geplante ICMP-Konfiguration.

IPv6 nicht vergessen

Eine sehr häufige Sicherheitslücke entsteht dadurch, dass Administratoren ausschließlich IPv4-Regeln betrachten.

Das System besitzt jedoch zusätzlich eine öffentliche IPv6-Adresse.

Dann kann ein Dienst über IPv6 erreichbar sein, obwohl man davon ausgeht, ihn über IPv4 ausreichend geschützt zu haben.

Deshalb gilt:

IPv4 und IPv6 gemeinsam planen.

Wer IPv6 nicht verwendet, sollte es bewusst konfigurieren beziehungsweise kontrollieren und nicht einfach ignorieren.

Proxmox berücksichtigt IPv6 ausdrücklich in seinem Firewallmodell.

Firewall Logging

Proxmox kann Firewallereignisse protokollieren.

Das ist besonders wichtig bei der Fehlersuche.

Beispielsweise:

VM kann DNS nicht erreichen

oder:

Backupserver erreicht VM nicht

Im Firewalllog lässt sich prüfen, ob Pakete geblockt wurden.

Proxmox unterstützt Logging sowohl für Standard- als auch benutzerdefinierte Firewallregeln.

Nicht jede Regel vollständig loggen

Logging ist hilfreich.

Aber:

Eine stark frequentierte DROP-Regel kann enorme Mengen an Logs erzeugen.

Beispielsweise ein öffentlich erreichbarer Host erhält möglicherweise permanent:

• Portscans
• Bots
• Verbindungsversuche

Wer jedes verworfene Paket protokolliert, produziert unnötig große Logmengen.

Logging sollte deshalb gezielt eingesetzt werden.

Beispiel einer sinnvollen Proxmox Firewall-Struktur

Angenommen, ein Unternehmen betreibt:

• 3 Proxmox Hosts
• 20 VMs
• Management VLAN
• Server VLAN
• Backup VLAN

Eine mögliche Struktur wäre:

Datacenter

IP Sets

Management_Networks

Monitoring_Servers

Backup_Servers

Security Groups

SG_Linux_Server

SG_Windows_Server

SG_Webserver

Node

Erlauben:

• TCP 8006 aus Management
• TCP 22 aus Management
• Monitoring
• erforderliche Clusterkommunikation

Default:

DROP

Webserver VM

Security Group:

SG_Webserver

Erlauben:

• HTTP
• HTTPS
• SSH aus Management

Datenbank VM

Erlauben:

• Datenbankport ausschließlich vom Application Server
• SSH aus Management
• Monitoring

Default:

DROP

Dadurch entsteht ein strukturiertes und skalierbares Regelwerk.

Clusterkommunikation nicht versehentlich blockieren

In einem Proxmox Cluster kommunizieren die Nodes miteinander.

Diese Kommunikation darf durch eine zu restriktive Host-Firewall nicht beschädigt werden.

Besonders betroffen sein können:

• Corosync
• Migration
• Storage
• Clusterkommunikation

Deshalb sollte bei Clusterhosts nicht einfach dieselbe Firewallregel verwendet werden wie bei einem einzelnen Standalone-Server.

Netzwerk- und Clusterdesign müssen gemeinsam betrachtet werden.

Management, Cluster und Storage trennen

Bei größeren Proxmox-Umgebungen können unterschiedliche Netzwerke sinnvoll sein.

Beispielsweise:

Management

Webinterface und SSH

Corosync

Clusterkommunikation

Migration

Live Migration

Storage

Ceph / NFS / iSCSI

VM Networks

Produktive VMs

Diese Netze müssen nicht zwingend auf jeweils eigenen physischen Interfaces liegen, sollten aber logisch und sicherheitstechnisch bewusst geplant werden.

Ceph und Firewall

Bei Proxmox-Clustern mit Ceph entsteht erheblicher interner Netzwerkverkehr.

Eine unüberlegte Firewallregel kann:

• Storagezugriffe blockieren
• Clusterprobleme erzeugen
• Performance beeinflussen

Deshalb sollten Ceph-Kommunikationspfade gezielt berücksichtigt werden.

Eine Firewall ist kein Ersatz für ein sauberes Ceph-Netzwerkdesign.

Proxmox Backup Server freigeben

Ein Backupserver benötigt Zugriff auf die entsprechenden Proxmox-Komponenten beziehungsweise Backupdienste.

Statt das gesamte Backupnetz pauschal freizugeben, können einzelne:

• IP-Adressen
• Server
• Dienste

gezielt zugelassen werden.

Ein eigenes IP Set:

Backup_Servers

erleichtert die Verwaltung.

Fail-Safe bei Remote-Konfiguration

Wenn ein entfernter Proxmox Host abgesichert wird, empfehle ich folgende Reihenfolge:

1. Aktuelle Verbindung prüfen

Woher greife ich auf den Host zu?

2. Management-IP beziehungsweise Netzwerk als IP Set anlegen

Beispielsweise:

Admin_Network

3. Webinterface erlauben

TCP 8006

4. SSH erlauben

TCP 22

5. Regeln testen

Neue Sitzung öffnen.

6. Erst danach Default DROP setzen

Damit sinkt das Risiko einer Aussperrung erheblich.

Firewall zuerst im Testsystem testen

Bei komplexen Regelwerken lohnt sich eine Testumgebung.

Besonders bei:

• Clustern
• Ceph
• mehreren VLANs
• SDN
• Migration
• High Availability

sollten Firewalländerungen nicht blind auf einer produktiven Umgebung getestet werden.

Konfigurationsbackup

Die Proxmox Firewallkonfiguration ist Teil der Proxmox-Konfiguration und sollte ebenfalls gesichert werden.

Bei Clusterinstallationen befinden sich entsprechende Konfigurationsdateien im Proxmox Cluster File System unter /etc/pve. Proxmox nennt dort unter anderem zentrale sowie VM-spezifische Firewall-Konfigurationen.

Vor größeren Änderungen sollte deshalb ein aktuelles Backup beziehungsweise eine dokumentierte Konfiguration vorhanden sein.

Proxmox Firewall oder externe Firewall – was ist wichtiger?

Beide erfüllen unterschiedliche Aufgaben.

Externe Firewall

Beispielsweise pfSense, OPNsense oder FortiGate:

kontrolliert:

Internet ↔ Netzwerk

und:

VLAN ↔ VLAN

Proxmox Firewall

kontrolliert zusätzlich:

Netzwerk ↔ Host

und:

Netzwerk ↔ einzelne VM

Damit entsteht mehrschichtiger Schutz.

Beispiel für Defense in Depth

Ein öffentlich erreichbarer Webserver könnte geschützt werden durch:

Ebene 1

Perimeter Firewall

erlaubt:

TCP 443

Ebene 2

Proxmox Firewall

erlaubt:

TCP 443

Ebene 3

Linux Firewall innerhalb der VM

erlaubt:

TCP 443

Ebene 4

Webserver

nur benötigte Dienste

Ebene 5

regelmäßige Updates

Ein Fehler in einer einzelnen Ebene führt damit nicht automatisch zur vollständigen Offenlegung des Systems.

Proxmox Firewall Best Practices

1. Managementnetz verwenden

Proxmox sollte nicht aus jedem VLAN administrierbar sein.

2. TCP 8006 nicht weltweit öffnen

Webinterface besser über VPN oder Managementnetz erreichbar machen.

3. SSH beschränken

Nur Administratornetze zulassen.

4. Default Deny für Server prüfen

Nur tatsächlich benötigte Dienste freischalten.

5. Security Groups verwenden

Wiederkehrende Regeln nicht duplizieren.

6. IP Sets verwenden

IP-Adressen logisch gruppieren.

7. Aliases verwenden

Regeln verständlich halten.

8. VM-Firewall aktivieren

Nicht vergessen, die Firewall am virtuellen Netzwerkinterface zu aktivieren.

9. Gast-Firewall eingeschaltet lassen

Windows- beziehungsweise Linux-Firewall weiterhin verwenden.

10. IPv6 berücksichtigen

Nicht ausschließlich IPv4 absichern.

11. Regeln dokumentieren

Jede besondere Freigabe sollte nachvollziehbar sein.

12. Logging gezielt verwenden

Nicht unnötig Millionen DROP-Pakete protokollieren.

13. Clusterverkehr vorher prüfen

Corosync, Storage und Migration dürfen nicht unbeabsichtigt blockiert werden.

14. Backup der Konfiguration

Vor größeren Änderungen sichern.

15. Remotezugriff absichern

Wenn möglich über VPN statt direkter Internetfreigabe.

Typische Fehler bei der Proxmox Firewall

Firewall global aktivieren und sofort DROP setzen

Der Administrator sperrt sich selbst aus.

TCP 8006 aus dem gesamten Internet erlauben

Die Managementoberfläche ist unnötig exponiert.

SSH weltweit erreichbar lassen

Erhöht die Angriffsfläche.

Nur Datacenter-Regeln anlegen

Aber VM-Interface-Firewall nicht aktivieren.

Jede VM einzeln konfigurieren

Obwohl Security Groups deutlich einfacher wären.

IP-Adressen direkt in hunderten Regeln eintragen

Anstatt IP Sets beziehungsweise Aliases zu verwenden.

Windows Firewall deaktivieren

Nur weil bereits die Proxmox Firewall aktiv ist.

IPv6 ignorieren

Der Dienst bleibt möglicherweise über IPv6 erreichbar.

Clusterports blockieren

Der Cluster funktioniert anschließend nicht mehr korrekt.

Firewalländerungen ohne Backup

Fehler lassen sich schwieriger zurückrollen.

Einfache Firewall für einen einzelnen Proxmox Host

Bei einem einzelnen Server kann eine Grundkonfiguration beispielsweise folgendermaßen aussehen.

Management

Erlauben:

Admin-IP

→ TCP 8006

Admin-IP

→ TCP 22

Monitoring

Monitoring Server

→ benötigte Dienste

Alle anderen Zugriffe auf Host

DROP

Die VMs erhalten anschließend jeweils eigene Regeln.

Firewall für einen Proxmox Host im Rechenzentrum

Bei einem direkt im Rechenzentrum betriebenen Proxmox Server sollte die Absicherung noch restriktiver sein.

Ein mögliches Design:

Internet

↓

Hardware-/virtuelle Firewall

↓

Proxmox Management VLAN

↓

Proxmox Host

Zusätzlich:

VPN

↓

Management VLAN

Das Webinterface ist damit nicht direkt öffentlich erreichbar.

Virtuelle Maschinen können trotzdem über eigene öffentliche beziehungsweise geroutete Netze erreichbar sein.

Virtuelle pfSense auf Proxmox

Eine häufig verwendete Architektur besteht darin, pfSense selbst als VM auf Proxmox zu betreiben.

Beispielsweise:

Internet

↓

Proxmox NIC

↓

pfSense VM

↓

interne Bridges/VLANs

↓

Server VMs

Das funktioniert technisch sehr gut.

Allerdings muss die Netzwerktopologie sorgfältig geplant werden.

Insbesondere darf der Proxmox Managementhost nicht versehentlich ungeschützt am WAN hängen.

pfSense-VM schützt den Proxmox Host nicht automatisch

Das ist ein sehr wichtiger Punkt.

Wenn die physische WAN-Schnittstelle über eine Bridge auch eine Host-IP besitzt, kann Proxmox selbst möglicherweise direkt im WAN erreichbar sein.

Besser ist:

WAN Bridge

keine Host-IP

↓

nur pfSense WAN-Interface

Das Management erfolgt über ein separates internes beziehungsweise Managementinterface.

Dadurch liegt der Proxmox Host nicht direkt im öffentlichen Netz.

Proxmox Firewall zusätzlich zu pfSense?

Ja.

Auch wenn pfSense als zentrale Firewall verwendet wird, kann die Proxmox Firewall zusätzlich sinnvoll sein.

Beispielsweise:

pfSense erlaubt:

Server VLAN → Datenbank VLAN

aber:

Proxmox erlaubt innerhalb des Datenbank-VLANs nur:

Application Server → Datenbank VM

Damit kann die Zugriffskontrolle noch granularer gestaltet werden.

Brauche ich Suricata auf Proxmox?

Proxmox dokumentiert auch Möglichkeiten zur Integration von Suricata IPS.

Für viele kleine und mittlere Installationen würde ich IDS/IPS allerdings eher an der zentralen Firewall betreiben.

Beispielsweise:

• pfSense
• OPNsense
• Sophos
• Fortinet

Dort lässt sich der Netzwerkverkehr häufig zentraler analysieren.

Auf dem Hypervisor sollte die Komplexität nicht unnötig erhöht werden.

Wie sicher ist die Proxmox Firewall?

Richtig konfiguriert ist sie eine leistungsfähige zusätzliche Sicherheitsschicht.

Sie ersetzt jedoch nicht:

• externe Firewall
• Netzwerksegmentierung
• Updates
• sichere Accounts
• MFA
• Backup
• Monitoring

Besonders wichtig:

Eine Firewall kann keine unsichere Gesamtarchitektur reparieren.

Ein Proxmox Host mit offenem Managementzugang, schwachen Passwörtern und fehlenden Updates bleibt ein Risiko – selbst wenn einige Firewallregeln existieren.

Proxmox Firewall Checkliste

Vor Produktivbetrieb sollte geprüft werden:

Management

• eigenes Managementnetz?
• TCP 8006 eingeschränkt?
• SSH eingeschränkt?
• Remotezugriff über VPN?

Firewall

• Datacenter Firewall aktiv?
• Node Firewall konfiguriert?
• VM-Firewall aktiviert?
• Default Policies geprüft?

Regeln

• nur benötigte Dienste?
• Security Groups?
• IP Sets?
• Aliases?

Netzwerk

• VLANs getrennt?
• Backupnetz?
• Storage-Netz?
• Clusterkommunikation berücksichtigt?

Sicherheit

• IPv6 berücksichtigt?
• Gast-Firewalls aktiviert?
• keine unnötigen Portfreigaben?
• Logging eingerichtet?

Betrieb

• Konfigurationsbackup?
• Monitoring?
• Updates?
• Dokumentation?
• Notfallzugang?

Fazit: Proxmox Firewall richtig einrichten

Die integrierte Proxmox Firewall ist deutlich leistungsfähiger, als viele Administratoren zunächst vermuten.

Sie ermöglicht Firewallregeln auf mehreren Ebenen:

Datacenter

↓

Node

↓

VM / Container

Zusätzlich erleichtern:

• Security Groups
• IP Sets
• Aliases
• Logging

die Verwaltung größerer Umgebungen.

Für produktive Installationen empfehle ich eine mehrschichtige Architektur:

zentrale Netzwerkfirewall

VLAN-Segmentierung

Proxmox Firewall

Firewall innerhalb der VM

Besonders wichtig ist dabei ein restriktiver Zugriff auf die Proxmox-Managementoberfläche.

TCP 8006 und SSH sollten nach Möglichkeit nur aus:

• Managementnetz
• VPN
• definierten Administratornetzen

erreichbar sein.

Die Firewall sollte außerdem nicht einfach maximal restriktiv konfiguriert werden.

Sie muss zur tatsächlichen Netzwerkarchitektur passen.

Bei Clustern müssen beispielsweise:

• Corosync
• Storage
• Migration
• Backup

weiterhin zuverlässig funktionieren.

Richtig geplant wird die Proxmox Firewall damit zu einer wichtigen zusätzlichen Sicherheitsschicht für virtuelle Server und Container.

Proxmox Firewall und Netzwerk professionell einrichten

Sie betreiben Proxmox im Unternehmen oder Rechenzentrum und möchten Netzwerk und Firewall sauber absichern?

Unetifi unterstützt kleine und mittelständische Unternehmen bei der Planung, Einrichtung und laufenden Betreuung von Proxmox-Umgebungen.

Dazu können unter anderem gehören:

• Proxmox Installation
• Proxmox Firewall
• pfSense
• OPNsense
• VLAN-Konzeption
• Netzwerksegmentierung
• Managementnetze
• Proxmox Cluster
• High Availability
• Ceph
• Proxmox Backup Server
• VPN
• Monitoring
• Backup
• Migration
• laufende Wartung

Dabei betrachten wir nicht nur einzelne Firewallregeln, sondern die gesamte Netzwerk- und Virtualisierungsarchitektur.

So bleiben Proxmox Hosts und virtuelle Systeme sicher, performant und langfristig administrierbar.

Häufig gestellte Fragen zur Proxmox Firewall

Hat Proxmox eine eigene Firewall?

Ja. Proxmox VE besitzt eine integrierte Firewall für Datacenter-, Node-, VM- und Container-Ebene. Zusätzlich stehen Security Groups, IP Sets und Aliases zur Verfügung.

Brauche ich zusätzlich pfSense oder OPNsense?

Nicht zwingend, aber häufig ist es sinnvoll. pfSense oder OPNsense übernimmt typischerweise die zentrale Firewall- und Routingfunktion zwischen Internet und Netzwerken. Die Proxmox Firewall schützt zusätzlich Hosts, VMs und Container.

Welchen Port verwendet das Proxmox Webinterface?

Das Proxmox-Webinterface beziehungsweise die API verwendet standardmäßig TCP 8006.

Sollte Port 8006 öffentlich erreichbar sein?

Wenn möglich, nein. Besser ist der Zugriff über ein Managementnetz, VPN oder eingeschränkte Administrator-IP-Adressen.

Muss die Firewall bei jeder VM aktiviert werden?

Wenn die Proxmox Firewall für eine VM genutzt werden soll, muss die entsprechende Firewallfunktion am virtuellen Netzwerkinterface aktiviert sein.

Was sind Proxmox Security Groups?

Security Groups sind wiederverwendbare Gruppen von Firewallregeln. Eine Gruppe kann beispielsweise sämtliche Regeln für Webserver enthalten und anschließend mehreren VMs zugewiesen werden.

Was sind Proxmox IP Sets?

IP Sets bündeln mehrere IP-Adressen oder Netzwerke zu einer Gruppe. Dadurch können beispielsweise sämtliche Administratornetze über ein einzelnes Objekt in Firewallregeln verwendet werden.

Was ist besser – DROP oder REJECT?

DROP verwirft Pakete ohne direkte Antwort. REJECT lehnt die Verbindung aktiv ab. Welche Variante sinnvoll ist, hängt vom jeweiligen Netzwerk und Einsatzzweck ab.

Sollte ich die Windows Firewall innerhalb einer Proxmox VM deaktivieren?

Nein. Die lokale Windows- beziehungsweise Linux-Firewall sollte normalerweise zusätzlich aktiv bleiben. Dadurch entsteht eine weitere Sicherheitsschicht.

Kann ich Proxmox und pfSense zusammen betreiben?

Ja. pfSense kann beispielsweise als virtuelle Maschine auf Proxmox betrieben werden. Dabei muss allerdings darauf geachtet werden, dass der Proxmox Host selbst nicht ungeschützt über die WAN-Schnittstelle erreichbar ist.

Funktioniert die Proxmox Firewall auch mit LXC?

Ja. Auch Netzwerkinterfaces von Proxmox-LXC-Containern können die integrierte Firewall verwenden.

Sollte ich Default Deny verwenden?

Für viele Servernetze ist ein Default-Deny-Ansatz sinnvoll. Dabei werden nur ausdrücklich benötigte Verbindungen freigeschaltet. Die Regeln sollten jedoch zuerst vollständig vorbereitet und getestet werden, damit wichtige Dienste oder der eigene Managementzugang nicht blockiert werden.

Muss ich IPv6 ebenfalls absichern?

Ja. Wenn IPv6 aktiv ist, müssen auch IPv6-Verbindungen in das Sicherheitskonzept einbezogen werden. Nur IPv4 zu schützen kann dazu führen, dass Dienste weiterhin über IPv6 erreichbar sind.