lcer00
Goto Top

OPNSense: DMZ richtig definieren mit IPv4+6

Hallo zusammen,

Ich möchte auf meiner OPNSense ein Interface zur DMZ machen. Bisher war das nicht erforderlich, da ich 2 Firewalls in Reihe verwende, aber die vorgeschaltete bintec be.ip soll in den Ruhestand gehen. Ich möchte, dass die DMZ-Hosts frei in das Internet kommunizieren können, nicht jedoch in eines der anderen 6 angeschlossenen Netze/Interfaces. Mit dem Ergebnis bin ich aber nicht so richtig zufrieden, es wirkt auf mich sehr gebastelt.

Ich habe folgende Regeln auf dem DMZ-Interface (eingehend) erstellt:
  1. IPv4+6 auf Lokale Firewall verbieten
  2. IPv4+6 nach WAN-Netzwerk erlauben (schließt IPv4 und IPv6 ein damit das Gateway, derzeit die bintec, erreicht wird)
  3. IPv4 nach RFC1918_Private_Networks blockieren
  4. IPv6 nach RFC4193_ULA blockieren
  5. IPv6 nach Globalem Prefix des Standortes blockieren
  6. IPv4+6 nach überall erlauben

(davor stehen die zugelassen Dienste, wie DHCP)

Muss das wirklich so sein? Oder geht das irgendwie eleganter. Ich will doch eigenlich nur:
  1. Internet erlauben
  2. Alles andere blockieren

Grüße

lcer

Content-Key: 5978459580

Url: https://administrator.de/contentid/5978459580

Printed on: April 27, 2024 at 15:04 o'clock

Member: aqui
aqui Feb 14, 2023 updated at 13:42:21 (UTC)
Goto Top
1.)
Was soll "lokale Firewall" bedeuten?? Wenn damit das DMZ Interface gemeint ist ist das richtig.
2.)
Die Regel ist eigentlich unsinnig und überflüssig, denn wenn du eine Kaskade betreibst hat die Firewall ja eh eine Default Route auf den Bintec. Die Regel ist also sinnfrei und macht nur dann Sinn wenn du aus dem DMZ Netzwerk das Management IP Interface des Bintec erreichen willst oder Hosts im Koppelnetz sind. Normal will man das aus der DMZ ja eher nicht und im P2P Koppelnetz sollten in der Regel auch keinerlei Hosts sein, also ist diese Regel eher falsch bzw. überflüssig.
Überflüssig deshalb, weil sie ja mit der Internet Regel eh auch automatisch abgefackelt wird. Sinnvoll wäre also eher ein deny auf das Koppelnetz um den Management Zugriff aus dem DMZ Segment auf den davor kaskadierten Router zu blocken!
3.)
Blockiert dann aber auch allen Traffic von der DMZ in interne Netze sofern du da einen RFC1918 Adressierung verwendest. Wenn in der DMZ z.B. ein Mailhost steht scheitert von intern das Abholen der Mails mit z.B. IMAP. Wenn das so gewollt ist, ist das aber OK.
5.)
Hat dann die gleichen Auswirkungen wie 3.
Oder geht das irgendwie eleganter.
Alias erzeugen mit allen reservierten, nicht gerouteten IP Netzen (RFC1918, RFC6890, Bogons etc): https://en.wikipedia.org/wiki/Reserved_IP_addresses die denyen und den Rest erlauben. face-wink
https://insights.sei.cmu.edu/blog/best-practices-for-network-border-prot ...
Member: lcer00
lcer00 Feb 14, 2023 at 13:42:18 (UTC)
Goto Top
Zitat von @aqui:

1.)
Was soll "lokale Firewall" bedeuten?? Wenn damit das DMZ Interface gemeint ist ist das richtig.
2.)
Die Regel ist unsinnig und überflüssig, denn wenn du eine Kaskade betreibst hat die Firewall ja eh eine Default Route auf den Bintec. Die Regel ist also sinnfrei und macht nur dann Sinn wenn du aus dem DMZ Netzwerk das Management IP Interface des Bintec erreichen willst. Normal will man das aus der DMZ ja nicht also ist diese Regel eher falsch.
Stimmt, Ziel-IP ist ja nicht das nicht an das Gateway ... -> kann also weg.
3.)
Blockiert dann aber auch allen Traffic von der DMZ in interne Netze sofern du da einen RFC1918 Adressierung verwendest. Wenn in der DMZ z.B. ein Mailhost steht scheitert von intern das Abholen der Mails mit z.B. IMAP. Wenn das so gewollt ist, ist das aber OK.
Den würde ich über den Regeln vorher erlauben.
5.)
Hat dann die gleichen Auswirkungen wie 3.
Oder geht das irgendwie eleganter.
Alias erzeugen mit allen reservierten, nicht gerouteten IP Netzen (RFC1918, RFC6890, Bogons etc): https://en.wikipedia.org/wiki/Reserved_IP_addresses die denyen und den Rest erlauben. face-wink

Also muss ich tatsächlich als letztes eine Allow-All-Regel einfügen. Das fühlt sich falsch an, da man ja eigentlich besonders restriktiv sein will. Ist aber eigentlich logisch.

Grüße

lcer
Member: aqui
Solution aqui Feb 14, 2023 updated at 13:50:51 (UTC)
Goto Top
Den würde ich über den Regeln vorher erlauben.
Dann ist das perfectly OK.
Also muss ich tatsächlich als letztes eine Allow-All-Regel einfügen.
Die Firewall hat ja immer ein implizites "Deny any any" an ihren Ports, verbietet also generell alles was nicht erlaubt ist. Ferner gilt immer die "First match wins" Regel. Eine Firewall ist eine Firewall und kein Router. Arbeitet bekanntlich immer im Default mit einem Whitelisting Konzept und nicht einem Blacklisting Konzept wie Router das tun.
Weisst du als alter Netzwerk Hase ja auch alles selber und kannst dir damit deine Frage dann selber beantworten! 😉
DHCP musst du übrigens nicht explizit zulassen, das macht die Firewall schon automatisch selber wenn dort ein DHCP Server werkelt.
Member: lcer00
lcer00 Feb 14, 2023 at 13:55:41 (UTC)
Goto Top
Zitat von @aqui:

Den würde ich über den Regeln vorher erlauben.
Dann ist das perfectly OK.
Also muss ich tatsächlich als letztes eine Allow-All-Regel einfügen.
Die Firewall hat ja immer ein implizites "Deny any any" an ihren Ports, verbietet also generell alles was nicht erlaubt ist. Ferner gilt immer die "First match wins" Regel. Eine Firewall ist eine Firewall und kein Router. Arbeitet bekanntlich immer im Default mit einem Whitelisting Konzept und nicht einem Blacklisting Konzept wie Router das tun.
Weisst du als alter Netzwerk Hase ja auch alles selber und kannst dir damit deine Frage dann selber beantworten! 😉
DHCP musst du übrigens nicht explizit zulassen, das macht die Firewall schon automatisch selber wenn dort ein DHCP Server werkelt.

Blöd ist halt, dass bei IPv6 noch zusätzlich die Globalen Adressen ausgenommen werden müssen. Insgesamt recht viele Möglichkeiten sich zu vertippen oder etwas zu vergessen. Aber die Alternative "Whitelisting aller echten Internetaddressen" ist auch keine Lösung.

Grüße

lcer