Firewall-Regeln für eine VM oder einen CT

Ihre Web-VM antwortet noch, aber Sie kommen an den Punkt, an dem eine zu weite Regel einen unnötigen Dienst öffnen oder SSH unterbrechen kann.

Die Proxmox-Firewall ist bereits aktiv und die Frage wird präzise: Soll man auf der VM-, Node- oder Gast-OS-Ebene schreiben?

Für eine VM oder ein Container sollten Sie vom Gast und seinen realen Flüssen ausgehen.

Lesen Sie die Optionen von net0, erstellen Sie die Regeln IN, entscheiden Sie über den Ausgang von OUT, und faktorisieren Sie nur die Regeln, die eine Gruppe verdienen. Die Proxmox-Kontrollen und der Anwendungstest bleiben von der Firewall des Hosts getrennt.

Die VM/CT-Regeln von Proxmox sollten von den realen Flüssen des Gastes ausgehen und nur dann faktorisieren, wenn sie wiederverwendbar sind.

Ziel festlegen, bevor Sie die erste Regel schreiben

Identifizieren Sie die VMID, die virtuelle Schnittstelle, die Gastadresse und die tatsächlich exponierten Dienste. Eine Debian-VM, die HTTP und HTTPS bereitstellt, hat nicht dieselben Eingänge wie ein Verwaltungscontainer, der von einem Bastion-Host aus zugänglich ist.

notieren Sie die tatsächliche VMID und die Schnittstelle net0 ;
listen Sie die eingehenden Ports und die zulässigen Quellen auf ;
halten Sie eine Konsole oder Administratorkonto auf dem Host bereit ;
überprüfen Sie, ob die Datacenter/Node-Firewall bereits bearbeitet wurde.

Die Zonen ersetzen sich nicht gegenseitig. Datacenter dient insbesondere wiederverwendbaren Bausteinen, Node betrifft den Host, und VM/CT filtert den Datenverkehr zu oder von dem Gast.

Die Firewall von Debian bleibt eine separate Schicht. Die offizielle Proxmox VE-Dokumentation beschreibt diese Trennung ebenso wie die Richtungen IN, OUT und FORWARD.

Wenn die Knotenfirewall noch nicht aktiviert ist oder Sie befürchten, Web-UI oder SSH zu verlieren, halten Sie an, bevor Sie Regeln für die VM schreiben, und konsultieren Sie die vorsichtige Aktivierung der Proxmox-Firewall, ohne den Zugriff zu verlieren.

Die Sperrung des Hosts bleibt hier außerhalb des Rahmens.

Lesen Sie die Optionen der VM und ihrer Schnittstelle

Bevor Sie schreiben, überprüfen Sie die Konfiguration vom Proxmox-Node aus. Ersetzen Sie <VMID> durch die numerische ID Ihrer VM :

qm config <VMID> --current

Überprüfen Sie dann in der Konfiguration der VM enable, policy_in, policy_out, log_level_in, log_level_out und ipfilter.

Jede Schnittstelle hat auch ihren eigenen Firewall-Indikator. Die allgemeine Option der VM reicht nicht aus, wenn das Flag von net0 deaktiviert bleibt.

[OPTIONS]
enable: 1
policy_in: DROP
policy_out: ACCEPT
log_level_in: nolog
log_level_out: nolog
ipfilter: 1

Dieser Block illustriert einen restriktiven Eingang und einen noch permissiven Ausgang. Es handelt sich nicht um eine Datei, die direkt kopiert werden sollte : Passen Sie die Werte für Ihre VM an und überprüfen Sie dann die generierte Konfiguration.

ipfilter dient hauptsächlich dazu, IP-Spoofing an der Schnittstelle zu begrenzen, nicht um eine HTTP- oder SSH-Whitelist zu erstellen.

Erlauben Sie nur die tatsächlich erforderlichen eingehenden Flüsse

Beginnen Sie mit den Eingängen. Für eine Web-VM kommt SSH normalerweise von einem Bastion-Host oder einem Administrationsnetzwerk.

Die Ports 80 und 443 stammen vom Reverse-Proxy oder einer öffentlichen Quelle, die durch die Architektur vorgesehen ist. Eine Erlaubungsregel sollte daher das Protokoll, den Port, die Quelle und die Schnittstelle benennen, wenn diese Elemente bekannt sind.

[RULES]
IN ACCEPT -p tcp -dport 22 -source +admins -i net0
IN ACCEPT -p tcp -dport 80 -source +reverse_proxy -i net0
IN ACCEPT -p tcp -dport 443 -source +reverse_proxy -i net0

In diesem Beispiel sind +admins und +reverse_proxy separat definierte IPSets.

Die dokumentarische Adresse 192.0.2.0/24 kann ein Beispiel für ein Netzwerk in einem Beispiel oder einer Dokumentation veranschaulichen, aber sie repräsentiert nicht Ihr tatsächliches Netzwerk. Ersetzen Sie sie durch Ihre bestätigten Quellen, und kopieren Sie keine Adresse aus einem Tutorial.

Platzieren Sie die spezifischen Erlaubnisse vor einer DROP– oder REJECT-Politik. Eine global zu schnell hinzugefügte Ablehnung überdeckt die nützliche Regel.

Es verwandelt ein einfaches Versäumnis in einen SSH-Ausfall. Überprüfen Sie die Konfiguration, bevor Sie verschärfen, und halten Sie eine Host-Konsole bereit.

Entscheiden Sie über die OUT-Politik, bevor Sie sie streng machen

Ein erlaubte Ausgang lässt DNS, NTP, Updates, APT-Repositorys, Überwachung oder externe APIs funktionieren, solange die anderen Schichten sie filtern.

Eine restriktive Ausgabe erfordert eine präzise Inventarisierung: Das erste blockierte DNS-Paket reicht aus, um den Eindruck zu erwecken, dass die VM oder ihr Bridge ausgefallen ist.

VM-Fluss	Richtung	Beispiel	Risiko unter DROP
SSH-Verwaltung	IN	`+admins` zu 22/tcp	Zugriff verweigert, wenn die Quelle nicht aufgelistet ist.
HTTP/HTTPS	IN	`+reverse_proxy` zu 80/443	Der Webdienst wird unerreichbar.
DNS-Resolution	OUT	UDP/TCP 53 zum Resolver	APT und Namensaufrufe schlagen fehl.
Systemzeit	OUT	UDP 123 zu der NTP-Quelle	Die Uhr driftet, wenn kein anderer Mechanismus übernimmt.
Repositorys und APIs	OUT	TCP 80/443 zu den vorgesehenen Zielen	Updates und Überwachung können stoppen.

Ich bevorzuge es, policy_out: ACCEPT während der Inventarisierung beizubehalten und dann zu DROP zu wechseln, mit dokumentierten Ausgängen eins nach dem anderen.

Diese Wahl schützt die Verfügbarkeit des Dienstes während des Aufbaus. Es ersetzt keine ausgehende Politik, wenn Ihre Umgebung tatsächlich eine Whitelist erfordert.

[OPTIONS]
policy_out: DROP

[RULES]
OUT ACCEPT -p udp -dport 53 -dest dns_interne
OUT ACCEPT -p tcp -dport 53 -dest dns_interne
OUT ACCEPT -p udp -dport 123 -dest ntp_interne
OUT ACCEPT -p tcp -dport 80 -dest depots
OUT ACCEPT -p tcp -dport 443 -dest depots

Die Namen dns_interne, ntp_interne und depots müssen auf Ihre realen Adressen oder Gruppen verweisen. Die Syntax für mehrere Ports und Aliase sollte mit der installierten Version von Proxmox überprüft werden, bevor sie angewendet wird.

Faktorisieren Sie wiederholbare Regeln mit einer Sicherheitsgruppe

Eine Sicherheitsgruppe wird nützlich, wenn mehrere VMs oder Container dieselbe Funktion teilen.

Proxmox definiert sie auf Cluster-Ebene, dann ruft die Konfiguration jedes Gastes sie in ihrem Abschnitt [RULES] auf. Die Gruppe gilt für keine VM, solange Sie sie nicht in deren Regeln eingefügt haben.

# /etc/pve/firewall/cluster.fw
[group webserver]
IN ACCEPT -p tcp -dport 80
IN ACCEPT -p tcp -dport 443

# /etc/pve/firewall/<VMID>.fw
[RULES]
GROUP webserver

Halten Sie im Gruppe die tatsächlich gemeinsamen Regeln. Eine VM-spezifische Ausnahme bleibt in /etc/pve/firewall/<VMID>.fw. Diese Trennung vermeidet, dass alle Gäste geändert werden müssen, um einen einzigen Verwaltungsport zu korrigieren.

Benennen Sie die Quellen mit IPSet und Aliasen

Die IPSets fassen Adressen oder Netzwerke zusammen; die Aliase geben einer Adresse oder einem Netzwerk einen lesbaren Namen.

Die Regeln können sie als Quelle oder Ziel verwenden. So können Sie +admins oder dns_interne lesen, ohne bei jedem Durchgang eine Folge von IP zu interpretieren.

# /etc/pve/firewall/cluster.fw
[ALIASES]
dns_interne 192.0.2.53

[IPSET admins]
192.0.2.10

[IPSET reverse_proxy]
192.0.2.20
192.0.2.21

Die Adressen 192.0.2.10, 192.0.2.20 und 192.0.2.21 sind Dokumentations-Platzhalter. Ein IPSet wird mit dem Präfix + referenziert, zum Beispiel -source +admins.

Ohne dieses Präfix interpretiert Proxmox den Namen als Adresse oder Alias, und die Regel entspricht nicht der Absicht.

Verwechseln Sie ipfilter-net0 nicht mit einer anwendungsseitigen Whitelist.

Dieses IPSet, das an der Schnittstelle angeschlossen ist, hilft, das Spoofing von Quelladressen zu verhindern. Es entscheidet jedoch nicht, wer den Port 443 Ihrer Anwendung öffnen kann.

Lesen Sie die Reihenfolge der Regeln, bevor Sie die Politik verschärfen

Eine Gruppenregel oder eine lokale Regel hat nur dann Wirkung, wenn sie am erwarteten Ort gelesen wird. Platzieren Sie die genauen Zuordnungen vor der allgemeinen Ablehnung und lesen Sie die Konfiguration nach jeder Änderung erneut.

Gelesene Reihenfolge	Beispiel	Risiko, wenn zu niedrig platziert
1. Genauer Quelle und Port	SSH von `+admins` zu 22/tcp	Der Bastion-Host wird durch die Politik blockiert.
2. Wiederverwendbare Gruppe	`GROUP webserver`	Die Webports bleiben auf dieser VM geschlossen.
3. Dokumentierte Ausgaben	DNS, NTP, Repositorys	Der Dienst startet, verliert aber seine Abhängigkeiten.
4. Standardpolitik	`DROP` oder `REJECT`	Jeder vergessene Fluss landet hier.

Die offizielle Dokumentation beschreibt die Syntax IN/OUT, die Optionen --source, --dest, --dport und --iface sowie das Einfügen einer Sicherheitsgruppe.

Verwenden Sie die Form, die zu Ihrer Version passt, und überprüfen Sie die kompilierte Konfiguration, anstatt anzunehmen, dass die Gruppe aktiv ist.

Aktivieren Sie ein gezieltes Protokoll während des Tests

Die Proxmox-Protokollierung ist standardmäßig für gefilterten Verkehr deaktiviert. Die Optionen log_level_in und log_level_out aktivieren die Standardprotokolle der VM/CT, die in Firewall → Log sichtbar sind.

Die zum Protokoll hinzugefügte Stufe dient dazu, das Paket zu identifizieren: Sie erhöht nicht automatisch die Anzahl der protokollierten Pakete.

[OPTIONS]
log_level_in: info
log_level_out: nolog

[RULES]
IN ACCEPT -p tcp -dport 22 -source +admins -i net0 -log info

Aktivieren Sie die Stufe nur während des Tests des Flusses, der Sie interessiert, und stellen Sie dann nolog wieder ein, wenn das Volumen zu laut wird.

Eine globale permanente Protokollierung erschwert das Lesen der tatsächlichen Ablehnungen und erhöht das operationale Rausch.

Achtung: Ein leeres Protokoll beweist nicht, dass ein Dienst funktioniert. Es muss noch die Regel, die Antwort der Anwendung und den Netzwerkpfad von der tatsächlichen Quelle überprüft werden.

Kompilieren, testen und Rückschritte planen

Beginnen Sie mit dem Lesen des Status der Firewall auf dem Node :

pve-firewall status
pve-firewall compile

pve-firewall status liest und kompiliert die Regeln erneut: Eine Syntaxwarnung bleibt ein Problem, das vor dem Netzwerktest behoben werden muss.

pve-firewall compile ermöglicht das Betrachten der generierten Konfiguration.

Die offizielle Dokumentation zum pve-firewall beschreibt auch pve-firewall simulate, das helfen kann, eine Quelle, ein Ziel, einen Port und ein Protokoll zu simulieren, aber keinen Beweis für das Routing des Kernels oder das Funktionieren der Anwendung liefert.

Die endgültige Prüfung sollte von der erlaubten Quelle ausgehen und dann von einer Quelle, die abgelehnt werden muss, wenn Sie sie ohne Risiko verwenden können :

SSH von der erwarteten Administrations-IP mit ssh -v ;
HTTP oder HTTPS vom Reverse-Proxy mit curl -I https://<IP_VM> ;
DNS, NTP und APT von der VM, falls policy_out restriktiv ist ;
Lesen des Proxmox-Protokolls während des Testfensters und dann Rückkehr zu nolog.

Präsentieren Sie diese Befehle nicht als bereits durchgeführter Test : Sie bilden Ihr Validierungsprotokoll.

Ein erwartetes Ergebnis ist eine zugelassene Verbindung, die antwortet, ein verweigeter Fluss, der fehlschlägt, und eine konsistente Spur mit der überprüften Regel.

Wenn eine Regel die VM abschneidet, entfernen Sie diese Regel oder deaktivieren Sie vorübergehend die Firewall dieser VM/CT.

Setzen Sie policy_out: ACCEPT zurück, falls DNS, NTP oder Updates beeinträchtigt werden.

Verwenden Sie pve-firewall stop nicht als normale Rückschritt: Dieser Befehl entfernt die Proxmox-Regeln vom Host und kann den Server ungeschützt lassen.

Die Grenzen sichtbar halten

Eine VM ohne IP-Adresse, eine fehlende Bridge oder ein falsch übertragenes VLAN lässt sich nicht durch eine Firewall-Regel reparieren.

Wenn die Regel korrekt erscheint, der Gast jedoch keine IP-Adresse hat, gehen Sie zum Netzwerkdiagnose einer Proxmox-VM über, von der Bridge zum Gast : Netzwerk der VM wiederherstellen.

Bei einem Problem auf der Host-Seite behandelt der Leitfaden Proxmox-Bridge erstellen, ohne den Zugang zum Server zu verlieren die entsprechende Schicht.

Der Backend nftables proxmox-firewall bleibt in der Proxmox-Dokumentation 9.2.11 als technische Vorschau markiert.

Die obigen Beispiele konzentrieren sich weiterhin auf das Standard-Backend pve-firewall. Wenn Ihre Umgebung IPv6 verwendet, überprüfen Sie auch NDP und die IPv6-Adressen, anstatt nur von einem IPv4-Test auszugehen.