DMZ oder besser DMZs?
-
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.
-
@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? -
Da ich Bridging auf der Sense vermeide wie Teufel und Weihwasser und ich das einfach Unfug finde, ja vielleicht. Es blockiert gegenüber "_address" eben jegliche Adresse aus dem "_net" auch wenn ich der Firewall mehrere IPs gebe. Ggf. will ich ja wirklich nur innerhalb des Netzes filtern. Anderer Punkt: NAT Reflection unterbinden. Bei Reflects wäre der Zugriff tatsächlich von _net auf _net weil die IP aus der DMZ auf die externe IP geht, auf der FWL umgeschrieben wird auf die DMZ IP und dann wieder in die DMZ geht. Ich möchte aber ggf. gar nicht dass sich Kiste 1 selbst via extern aufruft oder Kiste 2 über extern aufruft, sondern die sollen direkt intern miteinander reden um direkter zu kommunizieren und Latenz zu sparen. Rejecte ich das, merkt man das sofort ob/was für ein Zugriff da zum Tragen kommt.
-
@JeGr Danke Dir.
Denke, damit ist das Thema DMZ hinreichend beschrieben. Schönes WE. -
Oder bis später? ;)
-
@Bob-Dig said in DMZ oder besser DMZs?:
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.
Hatte gerade mal wieder einen Ausfall. Nun läuft's wieder, aber IPv6 geht noch nicht und ich sehe, dass die Verbindung über IPv4 erfolgt, wie gesagt, ohne NAT Reflection. Faszinierend.
-
Ich habe jetzt die DMZs fertig angelegt.
Was mich noch stört ist die Reihenfolge der Interface in pfSense, insbesondere unter Firewall / Rules. Gibt es hier eine Möglichkeit Ordnung bzw. eine gewünschte Reihenfolge einzurichten? Ggf. welche Risiken wären damit verbunden?
Und spricht etwas dagegen, den ganzen /48er und den /64er von HE in einen Alias zu packen und ihn dann quasi als RFC1918-Alias zu nutzen?
Würde die Regelerstellung vereinfachen.Und wenn ich unter dieser ASN-Nummer von meinem ISP gucke, dann sehe ich dessen gesamtes IPv6-Netz? Das könnte ich ja auch noch dem Alias hinzufügen, um sicherzustellen, dass auch mein dynamischer IPv6-Prefix nie angegrabbelt werden kann?
-
@Bob-Dig said in DMZ oder besser DMZs?:
Was mich noch stört ist die Reihenfolge der Interface in pfSense, insbesondere unter Firewall / Rules. Gibt es hier eine Möglichkeit Ordnung bzw. eine gewünschte Reihenfolge einzurichten? Ggf. welche Risiken wären damit verbunden?
Deshalb hatte ich da schonmal gesagt, ich sortiere die alphabetisch und benenne die Interfaces mit Prefixen. Dann ist das meine Sortierung :)
System / General -> Sortierung mit Haken auf alphabetisch. Dann einfach den Namen ändern. Fertig.