[SOLVED] PVE Firewall - Regel invertieren

Ingo S

Renowned Member
Oct 16, 2016
333
38
68
41
Hallo zusammen

Ich will schon lange in unserer DMZ eine Host isolation umsetzen, so dass die Hosts in der DMZ sich untereinander nicht mehr erreichen können. Da die alle im gleichen Netz sind kann unsere "normale" Netzwerk Firewall da nicht viel ausrichten.

Ich bin jetzt noch nicht so richtig vertraut mit der ganzen Sache, aber mein Konstrukt wäre, alles zu erlauben, das NICHT aus dem Netz der DMZ kommt. Das würde mit einer Regel jeden Traffic verwerfen, der von Hosts in der DMZ kommt. Nur ich finde nicht, wie ich das umsetzen kann.

Oder muss ich tatsächlich 2 Regeln bauen?
IN DROP -source <DMZ Netz>
IN ACCEPT -source 0.0.0.0/0
 
Ein drop und ein accept brauchst Du jedenfalls mindestens, egal ob das beides eine Regel oder eins die default policy ist.
Alternative: vlans die untereinander nicht geroutet werden.
Könnte auch funktionieren: statt route aufs lokale Netz nur eine host route aufs Gateway. Dahin dann die default route. Ggf. lokales Netz auf lo routen, für das Gateway hat die host route Priorität.
 
In vielen Firewalls gibts halt auch ein "negate rule" o.ä.. Das ist in bestimmten Konstellationen einfacher.

Alternative: vlans die untereinander nicht geroutet werden.
Das funktioniert zwar, skaliert aber nur ganz ganz mies. Da braucht man für jede VM in der DMZ ein eigenes Netz.

statt route aufs lokale Netz nur eine host route aufs Gateway. Dahin dann die default route. Ggf. lokales Netz auf lo routen, für das Gateway hat die host route Priorität.
Ja, technisch funktioniert auch das. Grundsätzlich ist aber alles was auf einer potentiell kompromittierten Maschine konfigurierbar ist, als unsicher anzusehen. Ich muss ja nur auf der kompromittierten Maschine das Routing ändern und fertig. Außerdem gibts in der DMZ auch ein paar Maschinen, die z.B. mit dem Mailserver kommunizieren müssen. Das ginge dann auch nicht. Da bleibt nur Firewall

Habe es gelöst bekommen.
1686827627348.png
Das ist okay so. Den Rest macht eh unsere "normale" Firewall.
 
Das funktioniert zwar, skaliert aber nur ganz ganz mies. Da braucht man für jede VM in der DMZ ein eigenes Netz.
Irgendwas ist ja immer. Jedenfalls ist das die gründlichste Methode.
Ja, technisch funktioniert auch das. Grundsätzlich ist aber alles was auf einer potentiell kompromittierten Maschine konfigurierbar ist, als unsicher anzusehen. Ich muss ja nur auf der kompromittierten Maschine das Routing ändern und fertig.
Das nützt allerdings nichts, wenn alle anderen Maschinen ebenfalls so konfiguriert sind, dann können die nämlich auf den SYN nicht antworten, selbst wenn rp_filter auf 0 steht und den durchläßt :)
Außerdem gibts in der DMZ auch ein paar Maschinen, die z.B. mit dem Mailserver kommunizieren müssen. Das ginge dann auch nicht. Da bleibt nur Firewall
Doch, da würde man dann einfach noch eine host route mehr setzen.
Habe es gelöst bekommen.
View attachment 51648
Das ist okay so. Den Rest macht eh unsere "normale" Firewall.
Moment, hat out die default policy ACCEPT, oder wieso funktioniert das? Die letzte Zeile sollte auch out sein, und dann den ganzen Block nochmal als in.
Da gäbe es möglicherweise noch ein Schlupfloch, nämlich source routing über die DMZ Firewall. Die läßt das hoffentlich nicht zu.
 
Die sauberste Methode wäre das über VLANs zu segmentieren. Also: DMZ-Host1 in VLAN101, DMZHost2 in VLAN102 usw... Alles ander ist Quatsch und die Aussage "das skaliert nicht gut" ist noch viel mehr Quatsch! Denn genau für solche Fälle wurden VLANs entwickelt und das ist heute unter anderem als "Microsegmentation" bekannt. Wenn dir mir als 4000 VLANs nicht als Skalierbarkeit für deine DMZ reichen, bist du eh in der Thematik VXLAN.

Ansonsten, aber das ist auch unschön, einfach mit Local-Proxy-ARP arbeiten, dann gibt sich deine Firewall für die Hosts immer als der jeweilige (im ARP-Request) angefragte Host aus. Das kann man schön firewallen. ABER - und das ist das Unschöne - je nach Implementierung und der Schnelligkeit der Antwort auf den initialen ARP-Request kann mal die Firewall oder der "echte" Host antworten (ähnlich wie bei 2 DHCP-Servern in einem L2-Segment) . Und wie (der initiale Host) dann auf 2 ARP-Responses reagiert, ist implementationsabhängig...

Mit irgendwelchen Routen auf dem potenziell kompromittierten Host zu Arbeiten ist auch Blödkram.

Segmentiere es mit VLANs, das ist sauber und der einfachste Weg.
 
Last edited:
Das nützt allerdings nichts, wenn alle anderen Maschinen ebenfalls so konfiguriert sind, dann können die nämlich auf den SYN nicht antworten, selbst wenn rp_filter auf 0 steht und den durchläßt :)
Ja, stimmt. Daran hatte ich nicht gedacht. Aber es ist trotzdem nicht wirklich gut.
Doch, da würde man dann einfach noch eine host route mehr setzen.
Da habe ich dann aber einen komplett exposed Host, wo ich nur einen einzigen Dienst brauche.
Moment, hat out die default policy ACCEPT, oder wieso funktioniert das? Die letzte Zeile sollte auch out sein, und dann den ganzen Block nochmal als in.
Da gäbe es möglicherweise noch ein Schlupfloch, nämlich source routing über die DMZ Firewall. Die läßt das hoffentlich nicht zu.
Ja, die default Policy für out ist ACCEPT, denn die VMs in der DMZ müssen mit dem Internet kommunizieren und so spare ich mir eine Regel die equivalent zur default regel ist.
Mit Source Routing meinst du, wenn ich auf dem Host auch für das DMZ Netz die FW als Gateway eintrage? Das lässt die Firewall nicht zu.
Die sauberste Methode wäre das über VLANs zu segmentieren. Also: DMZ-Host1 in VLAN101, DMZHost2 in VLAN102 usw... Alles ander ist Quatsch und die Aussage "das skaliert nicht gut" ist noch viel mehr Quatsch! Denn genau für solche Fälle wurden VLANs entwickelt und das ist heute unter anderem als "Microsegmentation" bekannt. Wenn dir mir als 4000 VLANs nicht als Skalierbarkeit für deine DMZ reichen, bist du eh in der Thematik VXLAN.
Mit "das skaliert nicht gut" ist gemeint, dass der Pflegeaufwand mit jedem Host größer wird, nicht das mir die VLANs nicht reichen würden. Natürlich sind VLANs für genau sowas gedacht. Wir nutzen das auch um unsere internen Netze zu segmentieren und zu isolieren.
Für jeden Host in der DMZ jedoch ein eigenes VLAN/Netz zu erzeugen ist mir zu aufwändig und wird mir in der config zu unübersichtlich. Das macht eher Sinn wenn man sehr viel mit Software defined networking arbeitet und das alles zentral managen kann. Das haben wir hier allerding nicht im Einsatz.
Ich denke, die PVE Firewall ist eine gute Lösung dafür.
Sie kann vom kompromittierten Host nicht erreicht und manipuliert werden und so wie die Regeln jetzt angelegt sind, verhindert sie effektiv den Zugriff der DMZ Hosts untereinander. Letztendlich wird das ähnlich sicher sein, wie unsere OpnSense.
Ansonsten, aber das ist auch unschön, einfach mit Local-Proxy-ARP arbeiten,
Das klingt in der Tat ziemlich unschön. o_O
 

About

The Proxmox community has been around for many years and offers help and support for Proxmox VE, Proxmox Backup Server, and Proxmox Mail Gateway.
We think our community is one of the best thanks to people like you!

Get your subscription!

The Proxmox team works very hard to make sure you are running the best software and getting stable updates and security enhancements, as well as quick enterprise support. Tens of thousands of happy customers have a Proxmox subscription. Get yours easily in our online shop.

Buy now!