DMZ oder besser DMZs?

JeGr

Da die Sachen alle in VMs laufen und virtuelle Adapter nichts kosten, ist meine Überlegung nun, diese Server zu separieren und jedem sein eigenes virtuelles Interface zu geben und daraus jeweils eine DMZ zu machen.

Wenn die Büchsen nichts miteinander zu tun haben müssen/sollen, spräche m.E. nichts dagegen. Ist eher die Frage nach Segmentierung vs. Mikrosegmentierung. Letzteres hat natürlich mehr Aufwand mit Interfaces, VLAN, Regeln etc., dafür steht dann eben auch die Kiste allein in ihrem Netz und darf nur genau das was du sagst. Und kann nicht andere, nebenstehende Kisten mit angrabbeln.

Von daher - why not. Und das /48er HE.net musste ich schon lange anfangen ^^ Muss jetzt aber nochmal komplett von vorn anfangen, weil sich das Prefix geändert hat (anderer Peer).

Ich würde da wegen einer Kiste ggf. nicht mal DHCP großartig anfangen, sondern direkt einfach statisch konfigurieren :)

Grüße

Bob.Dig

@JeGr Hallo Jens,

in einem anderen Thread habe ich gerade deine Empfehlung gelesen, für eine DMZ auch "diese Firewall" zu blocken, da dies auch die WAN-IP inkludieren würde.
Gut, wäre ich als Anfaenger natürlich nie drauf gekommen.

Meine Noobfragen darauf:

Kann ein interner Host auf der WAN-IP mehr Schaden anrichten, als es ein externer könnte?

Oder greifen tatsächlich einige Schutzmaßnahmen hier nicht, bspw. pfBlocker?

Oder wäre es mehr ein Problem des Monitorings?

Eine weitere Frage, ich habe hier einen xmpp-Server zu Hause, den ich mit einem internen Client ebenfalls an der WAN-IP anspreche und kein Split-DNS nutze. Da ich auch keine NAT-Reflection eingerichtet habe, geht das vermutlich nur, weil der Server auf einem anderen Interface gehostet wird. Würde ich hier nun ebenfalls "diese Firewall" blocken, hätte das negative Auswirkungen? Aber ich vermute mal nein.

JeGr

@Bob-Dig said in DMZ oder besser DMZs?:

Kann ein interner Host auf der WAN-IP mehr Schaden anrichten, als es ein externer könnte?

Ja. Gehen wir vom normalen Spielplatz aus:

WAN Interface: Nur erlaubt was muss. WebUI DEFINITIV nicht. Vllt. OVPN offen, sonst nüscht.
LAN Interface: Aus Faulheit LAN allow any rule drin. LAN darf somit eh alles.
DMZ Interface: Soll NICHT ins LAN können, stehen Server oder sonstwas drin, von da aus darf man nur ins Internet (wegen Updates o.ä.) aber sonst nichts. Alles andere (von außen oder LAN) darf nur reinconnecten, aber sonst darf die DMZ herzlich wenig.

Jetzt schotten wir die DMZ ab.

Erlaubt Ping auf pfSense zum Debugging
erlaubt DNS/NTP auf pfSense
rejected alles was DMZ_net auf DMZ_net ist (wäre standard)
rejected alles RFC1918, damit DMZ nicht in andere lokale Netze darf
allow any (damit ins Internet)

Und Tada, mit dem Set haben wir die externe IP der Firewall auf dem WAN vergessen. DMZ Host verbindet sich jetzt mit <firewall_IP:port> -> geht nicht. Klar wir haben DMZ auf DMZ Netz geblockt und im DMZ Netz natürlich auch die DMZ IP der Firewall. LAN IP der Firewall geht auch nicht -> RFC1918 rejected.
Aber <ext_ip:port> der Firewall ... hmm ... ist ja eine öffentliche IP und die haben wir erlaubt! Tadaa, da das Paket auf dem DMZ Interface "zuerst" ankommt, wird der State geschrieben, erlaubt und da die Firewall beim Processing erkennt "ey die IP bin ja ich" geht die WebUI auf.

Deshalb "This Firewall", denn dieses Makro/Alias enthält ALLE Firewall IPs die sie hat. Auch VIPs (Alias IPs, CARP IPs etc.) deren Zugriff geblockt wird. Darum ist This Firewall wichtig extra zu blocken. Man kann natürlich argumentieren, dass dann immer noch ein Login benötigt wird etc. und der interne Host weniger gefährlich ist. Klar, ist aber Abwägung und wenn ich schon ne DMZ aufmache, dann kann ichs ja richtig machen ;)

Oder greifen tatsächlich einige Schutzmaßnahmen hier nicht, bspw. pfBlocker?

Was von pfBlocker soll denn greifen? pfBlocker an der Stelle wären ja lediglich irgendwelche IP Blocklisten mit externen IPs. Du greifst aber von der DMZ auf deine eigene WAN IP zu. Was soll pfBlocker da blocken?

Oder wäre es mehr ein Problem des Monitorings?

Inwiefern Monitoring? Man darf eben auf eine IP des Systems zugreifen weil mans per Regel erlaubt hat. Gegen "eigene Dummheit" bei der Regelerstellung hilft auch Monitoring wenig :D

Da ich auch keine NAT-Reflection eingerichtet habe, geht das vermutlich nur, weil der Server auf einem anderen Interface gehostet wird

Eigentlich nicht. Wenn es geht, machst du NAT Reflection, andernfalls würdest du über die pfSense auf ihrer externen IP keinen XMPP Dienst erreichen, wenn der Server ne interne IP hat und du definitiv kein Split DNS machst. TCPdumpen und nachschauen hilft, aber ich würde raten, dass da doch NAT Reflection läuft.

Würde ich hier nun ebenfalls "diese Firewall" blocken, hätte das negative Auswirkungen? Aber ich vermute mal nein.

Hätte keine Auswirkung weil das ja auf dem LAN ist (oder nicht?) - auf dem LAN gilt ja eh die Anti-Lockout Regel ganz oben ;) Und du willst dich ja mit This Firewall auf dem LAN nicht selbst aussperren, oder?

Bob.Dig

@JeGr said in DMZ oder besser DMZs?:

rejected alles was DMZ_net auf DMZ_net ist (wäre standard)

rejected alles RFC1918, damit DMZ nicht in andere lokale

Würde die untere der beiden nicht die obere inkludieren?

Tadaa, da das Paket auf dem DMZ Interface "zuerst" ankommt, wird der State geschrieben, erlaubt und da die Firewall beim Processing erkennt "ey die IP bin ja ich" geht die WebUI auf.

Muss nicht alles verstehen als Homeuser, mir reicht's, wenn Du das sagst. Danke Dir!

Eigentlich nicht. Wenn es geht, machst du NAT Reflection, andernfalls würdest du über die pfSense auf ihrer externen IP keinen XMPP Dienst erreichen, wenn der Server ne interne IP hat und du definitiv kein Split DNS machst. TCPdumpen und nachschauen hilft, aber ich würde raten, dass da doch NAT Reflection läuft.

Hab zumindest nichts eingestellt, vielleicht ist es inzwischen Standard oder der XMPP-Server macht seine eigene Magic.

JeGr

@Bob-Dig said in DMZ oder besser DMZs?:

Würde die untere der beiden nicht die obere inkludieren?

Richtig, würde sie. Daher wird das meist weggelassen, was dann genau dazu führt, dass man denkt, man habe alles interne abgeschottet und die externe IP vergessen :)

Muss nicht alles verstehen als Homeuser, mir reicht's, wenn Du das sagst. Danke Dir!

Es ist simpel. Firewall UI ist erreichbar (theoretisch) unter jeder IP die die Firewall trägt. Interne IPs, DMZ IPs, VPN IPs, externe IP aufm WAN (außer du hängst hinter einem anderen Router, dann trifft das ganze Szenario nicht auf dich zu weil die WAN IP eh unter RFC1918 fällt :))
Pakete werden wie gefiltert? Auf dem Interface auf dem sie ALS ERSTES auf der pfSense aufschlagen. Da wird gefiltert. Eingehend. Ergo im Beispiel: DMZ Host versucht widerrechtlich FW UI anzugrabbeln und nutzt, weil alle internen IPs und VPN IPs nicht gingen, zuletzt die externe IP. Tadaa hat Erfolg, weil die nicht geblockt wurde (und in der letzten Regel, allow any [Internet] mit enthalten ist).

Jetzt verständlicher? :)

Hab zumindest nichts eingestellt, vielleicht ist es inzwischen Standard oder der XMPP-Server macht seine eigene Magic.

Würde mich wundern. Kannst ja in die Port Forward Regel reinsehen, default ist da Use system default. Und wenn du bei System>Advanced>Firewall&NAT mal Pure NAT eingestellt hast o.ä. dann ist das bei jedem Forward automatisch drin. Ansonsten vielleicht ein Relay o.ä. das da aushilft oder er announced auch seine interne IP irgendwie :)

Bob.Dig

@JeGr said in DMZ oder besser DMZs?:

Pakete werden wie gefiltert? Auf dem Interface auf dem sie ALS ERSTES auf der pfSense aufschlagen. Da wird gefiltert. Eingehend. Ergo im Beispiel: DMZ Host versucht widerrechtlich FW UI anzugrabbeln und nutzt, weil alle internen IPs und VPN IPs nicht gingen, zuletzt die externe IP. Tadaa hat Erfolg, weil die nicht geblockt wurde (und in der letzten Regel, allow any [Internet] mit enthalten ist).

Jetzt verständlicher? :)

Ja, danke Dir. Mir fehlt halt dieses Verständnis für die "unsichtbaren" Regeln und dass es so schnell gehen kann...

Hier nun meine überarbeitete DMZ-Regel.

JeGr

@Bob-Dig said in DMZ oder besser DMZs?:

Ja, danke Dir. Mir fehlt halt dieses Verständnis für die "unsichtbaren" Regeln und dass es so schnell gehen kann...

Warum unsichtbar? Wie gesagt, man erlaubt es ja, vergisst eben nur, dass die externe IP der Firewall auch in "any minus RFC1918" mit drin ist. Da ist sonst nix versteckt :)

Bei dir ist es also

Reject alles was Firewall ist (also auch kein DNS oder NTP oder ähnliches erlaubt, ergo wohl statische Konfiguration oder DHCP mit non-local settings)
Ansonsten IOT Netz nach any minus RFC1918 push über VPN raus.

Jup. Da ist nirgendwo die Firewall drin. Vorher wäre es selbst mit IOT_net/adress aber OK gewesen, weil andere Interfaces der Firewall mit privaten IPs du ausgeschlossen hast (RFC1918) und du allen Verkehr der nicht spezifiziert ist übers VPN rausschiebst. Damit kommt sowieso kein Paket aus IOT direkt an das WAN Netz. Müsste man austesten, aber ich meine, damit wäre die WAN IP nicht zugreifbar.

So ist aber eh besser :)

Bob.Dig

@JeGr Bei den Gateways bin ich mir eh unsicher, ich sollte das vielleicht selbst testen.

Bob.Dig

@JeGr Ich hab jetzt ein paar Versuche gestartet, aber es ist mir nie gelungen auf die Firewall zu kommen, wenn RFC1918 geblockt wurde, auch ohne verstellte Gateways etc. nicht. Wie hätte ich das testen müssen?

Der xmpp-Client verbindet sich übrigens mit IPv6, was die Sache wohl erklärt. Das doofe daran, ich wollte ja damit bewusst ein Stück weit und einfach die Erreichbarkeit von außen testen, was so wahrscheinlich gar nicht funktioniert. Gut, ich hab ja immer noch StatusCake.

NOCling

Danke das hatte ich nicht auf dem Schirm, ging tatsächlich mit der WAN IP.
Also neue Regel für alle DMZ Netze DENY Mgmt Alias.

Arbeite nur mit den Floauting Rouls, da ich nicht für jedes Int alles anlegen will.

JeGr

@NOCling said in DMZ oder besser DMZs?:

Arbeite nur mit den Floauting Rouls, da ich nicht für jedes Int alles anlegen will.

Wer das mag, kann das natürlich tun. Ich rate absolut davon ab. Ich hatte schon Firmen aufm Schirm die gedacht haben das ist ne super Idee. Ist es nicht, es war das totale Grauen weil man absolut null Übersicht mehr hatte. Gut, mit 2.4.5 ist nun endlich das Interface angezeigt worden, vorher konnte man nicht mal sehen, auf welchem IF Floats eigentlich konfiguriert sind. Aber nein, ich halte die nach wie vor für den Laien für zu gefährlich sich Löcher ins Regelwerk zu schießen weil man plötzlich mit Dingen wie "quick" "outbound/both" o.ä. experimentiert hat ohne zu realisieren was man tut. Da Floats auch noch default als Richtung "both" hatten/haben, ist mir das zu heikel und unübersichtlich. Ab ~30 Regeln halte ich das für total chaotisch. Dann lieber mehrere VLANs/LANs, die gleiche Regeln bekommen einfach per Interface Gruppe konfigurieren. Wesentlich weniger Gefahr damit was zu verbiegen als mit Floats. :)

Bob.Dig

@JeGr @NOCling Also bei mir ging es nicht mit der Internet-IP. Bitte mal genau das Testszenario beschreiben.

Edit: Mir fällt gerade ein, dass meine Internet-IP ja nicht an WAN anliegt, sondern eine CG-(1:1)NAT-Adresse... Ich müsste es wohl mit dieser versuchen, immer diese verdammten Sonderfälle.

Bob.Dig

Ok, konnte es jetzt mit meiner 100.65.xxx.xxx-IP, also meiner tatsächlichen WAN-IP, ebenfalls nachvollziehen, danke @JeGr !!

Edit: Und das in der Regel definierte Gateway verhindert den Zugriff ebenfalls nicht. Mein Eindruck zu Gateways ist, dass diese keine geprüften Voraussetzungen für eine Regel/Verbindung darstellen, sondern lediglich den Traffic anschließend ausleiten, sofern anwendbar.

JeGr

@Bob-Dig said in DMZ oder besser DMZs?:

Edit: Und das in der Regel definierte Gateway verhindert den Zugriff ebenfalls nicht. Mein Eindruck zu Gateways ist, dass diese keine geprüften Voraussetzungen für eine Regel darstellen, sondern lediglich den Traffic anschließend ausleiten, sofern anwendbar.

Nun es schiebt den Traffic dann aus der Firewall ausgehend aus dem angegebenen Interface. In dem Fall wird es aber dort behalten weil die Firewall merkt, dass sie selbst gemeint ist. Daher klappt es wohl auch gut. Wie gesagt, wenn du jetzt RFC Block nicht drin hättest und wolltest ins LAN zugreifen würde es nicht klappen, weil der Traffic übers VPN gepresst wird und dort dann am GW abgewiesen wird. Darum muss auch bei MultiWAN bspw. und Policy Regeln da entsprechend drauf geachtet werden, dass man interne Ausnahmen o.ä. definiert, die als Gateway "default" (*) angegeben haben, damit das interne Routing sauber läuft.

Bob.Dig

@JeGr gerade mal getestet und Du hattest, wie immer, recht. Aber jetzt wird es wieder schwierig für mich, dem ganzen logisch zu folgen. Warum ist das Gateway mal optional und dann wieder nicht.

JeGr

@Bob-Dig said in DMZ oder besser DMZs?:

Warum ist das Gateway mal optional und dann wieder nicht.

Warum sollte es optional sein? Dem kann ich jetzt nicht folgen.

Bob.Dig

@JeGr Na ja, warum konnte ich mit allein dieser Regel noch auf die Firewall zugreifen, wenn doch sämtlicher Traffic hätte ausgeleitet werden müssen. Du hattest schon was dazu geschrieben, ein logisches Problem aber bleibt (für mich).

JeGr

Weil die IP auf der Firewall bekannt ist. Warum sollte ich ein Paket routen, wenn ich es selbst bin? Ganz einfach. Klar kann ich auf das Paket noch den Sticker draufkleben "schicke es über VPN wenns raus geht" aber wenns nicht raus gehen muss - ist das eben obsolet.

Bob.Dig

@JeGr Es ist und bleibt aber eine Regelverletzung.

JeGr

@Bob-Dig said in DMZ oder besser DMZs?:

@JeGr Es ist und bleibt aber eine Regelverletzung.

Wie kommst du darauf? Nein ist es nicht?

Regel sagt "erlaube alles was NICHT RFC1918 ist und überall hin will". Zusätzlich sagst du damit "route wenn nötig als GW nicht per Default sondern per VPN". Da Routing unnötig -> Paket bereits am Ziel wenn Firewall erreicht - ist das alles komplett legitim.