DMZ oder besser DMZs?
-
@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.
-
@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 :)
-
@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.
-
@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 :)
-
@JeGr Bei den Gateways bin ich mir eh unsicher, ich sollte das vielleicht selbst testen.
-
@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.
-
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.
-
@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. :)
-
-
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.
-
@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.
Don't forget to upvote 👍 those who kindly offered their time and brainpower to help you!
If you're interested, I'm available to discuss details of German-speaking paid support (for companies) if needed.
-
@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.
-
@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.
-
@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).
-
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.
-
@JeGr Es ist und bleibt aber eine Regelverletzung.
-
@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.
-
@JeGr said in DMZ oder besser DMZs?:
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.
Ich sehe das im Widerspruch zu dem hier, wo etwas durchs Gateway gepresst wird, obwohl ja ebenfalls unnötig. Aber wie gesagt, mir fehlt da wohl der Blick fürs große Ganze und solange es Sinn für dich macht, alles supi.
-
@Bob-Dig said in DMZ oder besser DMZs?:
wo etwas durchs Gateway gepresst wird, obwohl ja ebenfalls unnötig.
Das passiert aber nur, weil es nicht die Firewall selbst ist, also keine lokale IP. Ergo wird es geroutet. Und statt der Routing Tabelle wird eben durch die Regel (PBR) dann das Gateway "erzwungen" und das Paket da rausgepresst. Wenns aber nirgends hin muss - bleibts zu Hause :)
-
@JeGr said in DMZ oder besser DMZs?:
- rejected alles was DMZ_net auf DMZ_net ist (wäre standard)
Moin Jens,
ich habe nochmal eine Frage dazu.
Was wäre hierfür das Anwendungsgebiet. Wenn ich einen Switch angeschlossen hätte, so könnte pfSense auf dem selben Interface eh nichts filtern, weil der Verkehr allein über besagten Switch liefe, korrekt? Was beträfe das also, vielleicht wenn ich Ports in pfSense gebridged hätte?
