DMZ zu viele Rechte
-
Super, danke für den Hinweis. Ich werde es später mal testen. Ich habe zusätzlich noch ein Outbound NAT vom WAN auf die DMZ konfiguriert, zwecks privater IP der DMZ. Grundsätzlich kann ich davon ausgehen, dass das sauber konfiguriert ist?
-
@nonick said in DMZ zu viele Rechte:
@AK_47-2 Die Diagnose / Ping Funktion geht auch ohne Firewallregel. Diese Seite ist für Diagnose Zwecke gedacht, da wären Firewall Regeln eher hinderlich.
Eigendlich nicht. Da @AK_47-2 im LAN eine "allow any to any" Regel hat, geht das pingen natürlich.
Die DMZ Rules sollten eigendlich greifen, da darf kein Ping durchgehen.@AK_47-2
Hast Du ein Proxy installiert, squid zum Beispiel? Wenn ja und beide Netze sind konfiguriert, greift keine Rule.Kleiner Tip am Rande. Wenn es mehr Netze werden wird, kann es unübersichtlich mit dem Regelwerk werden, falls du jedes voneinander abschotten willst. Einfach ein Alias erstellen mit den Adressbereichen der RFC 1918, quasi die Class A, B und C Netze für den privaten Bereich und das zum blocken nehmen, das blockt alles interne.
Mike
-
@mike69 said in DMZ zu viele Rechte:
Eigendlich nicht. Da @AK_47-2 im LAN eine "allow any to any" Regel hat, geht das pingen natürlich.
Das war ja auch nicht das Problem.
Die DMZ Rules sollten eigendlich greifen, da darf kein Ping durchgehen.
Genau das hat ihn verunsichert, da trotz der DMZ Regel Ziel !LAN net ein Ping vom DMZ Interface zu einem LAN Client auf der Diagnose Seite funktioniert. Du kannst auf dieser Seite jeden Client auf jeder Schnittstelle anpingen, unabhängig von den Firewallregeln.
-
Ich hatte schon von einem Client in der DMZ erfolgreich auf einen LAN-Host pingen können, was ja eigentlich nicht sein sollte. Ein Proxy ist nicht installiert.
Das Netzwerk besteht aus einem DrayTek Vigor 165, arbeitet im Bridge Mode und fungiert demnach nur als Modem, die PFSense baut per PPPoE die Internetverbindung auf und übernimmt ebenfalls Routing.
Das mit dem Alias ist ein guter Tip, ich möchte das Netzwerk sowieso bald mit VLAN's segmentieren und bin auch schon im Testlauf, aktuell haben wir jedoch Layer-2 Switches im Einsatz, die wahrscheinlich auch bald ersetzt werden, jedoch möchte ich nicht zu viele Baustellen auf einmal eröffnen, da hier etliches beachtet werden muss auf dem Switch(Trunk, PVID, VLAN's) und das zusätzliche routen zwischen Netzen, die untereinander ereichbar sein sollen.
Wenn ich davon ausgehen kann, dass die Rules sauber sind, wäre meine nächste Idee an der Hardware zu schauen.
Die PFSense läuft aktuell auf einem Eigenbau, hier ist ein ASUS Server Mainboard mit vier RJ-45 Ports im Einsatz, heute kommen jedoch meine bestellten Intel-NIC's, mit denen ich den nächsten Testlauf wage.Hat jemand noch eine Idee, woran es scheitern könnte?
-
@nonick Ich versuche das dann nochmal mit den Clients, beim letzten Testlauf hatte es glaube ich auch leider geklappt, dass der Ping durchging, aber ich schiebe es jetzt einfach mal auf einen Fehler meinerseits und versuche es erneut.
-
-
Um das Problem nochmal eben klarzustellen. Es ist tatsächlich so, dass die PFSense über alle regeln hinweg "pingt", Clients kommen nicht in ins LAN aus der DMZ, umgekehrt funktioniert das jedoch problemlos, so wie es sein soll.
Die PFSense hält sich jedoch nicht daran, sei es jetzt so, weil es so gewollt ist oder schlicht weil doch ein Fehlaufbau durch mich vorliegt.
Jedoch wurden meine Regeln bei Clients sauber befolgt, sowohl was die DMZ angeht als auch alle VLAN's, die ich am Wochenende ebenfalls nach viel Bastelei auf einem Layer-2 Switch umgesetzt habe.Trotzdem besten Dank für jegliche Hilfe:)
-
@AK_47-2 said in DMZ zu viele Rechte:
Die PFSense hält sich jedoch nicht daran
Warum sollte sie das tun? Sie steht ja nicht vor der versperrten Tür, sondern ist bereits dahinter.
Wenn du tatsächlich die pfSense selbst blockieren möchtest, könntest du es mit ein ausgehenden Übergreifenden Regel versuchen. Hab ich aber noch nie getestet. Macht für mich keinen Sinn, die pfSense selbst zu blockieren.
-
@viragomann
Im Endeffekt hast du natürlich Recht, man darf sich das Ping/Diagnose-Tool eben nicht als (DHCP-)Client in der betrachteten Schnittstelle vorstellen, sondern eher als eine Art Wächter, der im dreidimensionalen Regeln auf einer zweidimensionalen Schnittstelle übergehen kann.Das hat bei mir jedoch zum Trugschluss geführt, dass die Regeln nicht greifen, Aus meiner Position heraus ergab es nur keinen Sinn in dem Moment, dass man die Schnittstelle dann im Ping betrachtet, aus einer anderen Sicht fallen mir jetzt natürlich Gegenbeispiele ein, die diese Unterscheidung zweckmäßig machen.
Dafür weiß man es aber jetzt beim nächsten Mal besser:) -
Ja, andere Firewalls mögen auch Testtools mitbringen, um die eigenen Regeln zu testen. Die Tools der pfSense könnten dann auch als solche verstanden werden. Trifft aber hier nicht zu.
-
@AK_47-2 said in DMZ zu viele Rechte:
sondern eher als eine Art Wächter, der im dreidimensionalen Regeln auf einer zweidimensionalen Schnittstelle übergehen kann.
Wa?
Egal was es ist, gib mal was ab.
Spass beiseite. Wie @viragomann es schon erwähnt, sitzt der Ping der Sense hinter der FW. Die Sense ist der Gateway aller deine Netze, also besitzt sie logischerweise eine IP in allen Netzen. Ist ja nicht schlimm, kann nur der Admin des Routers pingen. Wenn das ein Anderer kann ist sowieso alles zu spät, dann ist das System kompromittiert.
-
@AK_47-2 said in DMZ zu viele Rechte:
Im Endeffekt hast du natürlich Recht, man darf sich das Ping/Diagnose-Tool eben nicht als (DHCP-)Client in der betrachteten Schnittstelle vorstellen, sondern eher als eine Art Wächter, der im dreidimensionalen Regeln auf einer zweidimensionalen Schnittstelle übergehen kann.
Nein, du hast hier IMHO ein Verständnisproblem. Ein Router (also auch pfSense) spricht - sofern NICHT anders angegeben - immer so DIREKT wie möglich mit einem Ziel. Wenn du also nen direkten Link in die DMZ hast wird auch VON der DMZ IP der Firewall direkt mit der DMZ IP des Servers gesprochen. Dass dort dann keine Regeln vom WAN/LAN/sonstwo greift dürfte einleuchten. Wenn man VOM LAN aus testen will, muss man beim Pingen auch die LAN IP auswählen, dann läuft das Paket auch korrekt durch den Filter. Vorher nicht. Das hat nichts damit zu tun, dass die Diagnostics Seiten "außerhalb des Filters existieren" oder irgendein 3D Bullshit ;) Man muss nur richtig auswählen, dann klappt es auch :P
Darum predige ich auch immer in meinen Workshops "Location, location, location!" - Wo kommt das Paket her, wo gehts hin und WO trifft es ZUERST auf die Firewall. In deinem Fall trifft es bei einem Ping mit Default Settings ... tadaa ... gar nicht auf die Firewall/den Filter, weils direkt vom Interface gesendet wird ;)
Ich hab es außerdem schon an anderen Stellen geschrieben: natürlich kann man mit !XY Regeln arbeiten, das wird aber schnell derart konfus und führt zu Situationen, die unbeabsichtigte Dinge tun, dass ich es bislang noch nie wirklich empfehlen konnte. Da macht man lieber 1-2 Regeln mehr und hat diese logischer aber konkreter definiert und hat auch später keine Überraschungen, wenn man plötzlich doch mal 4 oder 5 statt 3 Interfaces hat.
Grüße Jens
-
Dann hilf mir doch bitte meine Verständnisprobleme zu beheben.
Konstruktive Kritik ist immer gut, zum 3D Bullshit kommen wir, wenn du mich nicht überzeugen kannst später.
Ich weiß, dass ein Router IP-Netze verbindet, was das jedoch damit zu tun hat, dass man aus einer Schnittstelle pingen kann, die per ACl verboten wurde, leuchtet mir nicht ein, jedenfalls nicht so wie du es beschreibst.Na klar, wenn ich von der DMZ in die DMZ pinge greifen keine Regeln anderer Schnittstellen, es sei denn ich würde einen Host verbieten...Soweit so gut.
VOM LAN aus testen wollte ich auf jeden Fall nicht, denn vom LAN in die DMZ soll es ja definitiv gehen.
Andersrum jedoch nicht. Entweder habe ich mich unmissverständlich ausgedrückt oder du hast dir den Sachverhalt nicht vernünftig vor Augen geführt.Du siehst ja ganz deutlich, dass die Quelladresse aus der DMZ kommt laut Diagnose Tool und ich einen Host im LAN anpinge, was per ACL verboten wurde.
Wieso funktioniert das also?
Und welche Einstellung muss ich deiner Meinung nach auswählen, damit ich im Diagnose Tool Packet loss von der DMZ ins LAN habe? Würde das sehr gerne austesten und etwas dazu lernen.
Verstehe mich nicht falsch, ich habe es zuerst genauso gesehen wie du und lasse mich gerne belehren und lerne dann etwas neues dazu, genau deswegen habe ich den Thread ja auch aufgemacht.Fazit: Ich habe deinen Beitrag jetzt so verstanden, dass ich, wenn ich von einem Interface in genau dieses pinge, keine Regeln greifen können und gebe dir 100% Recht, ansonsten erkläre mir bitte genau, wo deiner Meinung nach das Verständnisproblem liegt.
Die !XY Regeln zum Verbot habe ich nur provisorisch zum Testen eingebaut, das werde ich sehr bald ändern und auch alle Regeln mit Aliasen überarbeiten, so wie empfohlen.
-
Eigentlich hatte es Jens schon geschrieben. Wenn du im Diagnose-Tool einen Ping absetzt, dann bist du ja schon direkt auf dem entsprechenden Interface und damit nach der Firewall. Wenn du von einem Client im Netzwerk aus Pingst, dann ist die Reihenfolge: RJ45 Buchse -> Firewall -> Interface.
-
Nabend @AK_47-2.
Die Regeln greifen, bildlich gesehen, immer in Richtung aktuelles Netzwerkinterface weiter in die Sense und von da raus in ein anderes Interface.
Regeln in der DMZ werden also am DMZ Netzwerkport, also incoming, abgearbeitet, bei einer block any to any rule wäre dann am Port Schluss.
Eine " allow tcp DMZ-NET to LAN-NET" würde an der DMZ Schnittstelle alle tcp Pakete durchlassen Richtung LAN Schnittstelle, udp und Co werden am DMZ Port geblockt. Regeln greifen nur an den eigenen Netzwerkports.Der Diagnose/Ping sitzt quasi zwischen den LAN- und DMZ Schnittstellen. Weil die Sense als Router in jedem Netzwerk vorhanden ist, im LAN wie auch im DMZ, kann eine Regel unter DMZ so nicht greifen. Eventuell eine "block any IP_der_Sense to DMZ-NET", da bin ich überfragt. Wenn das klappen würde, sägst Du dir den Baum unter deinen Füssen weg, dann gibt es kein Zugriff von LAN auf DMZ, weil die Sense als Gateway kein Zugriff auf DMZ hat.
Ob die Interfaces physikalisch oder virtuell als VLAN sind ist dabei egal.
Hoffendlich ist das irgendwie verständlich.
Oh, @nonick war schneller. :)
