Internet Zugang "! RFC1918" vs. block RFC1918 any - any

NOCling

NTP, DNS über eine INT Gruppe auf This Firewall erlaubt, fertig.
Ich erlaube 500/4500 also mein IPsec über Floating von überall auf die Firewall, intern wie extern.

Dann brauchst du nur noch die ganzen IPv6 Deny Regeln pro Netz eine, weil ja dynamisch und damit das Netz Objekt benötigt wird fürs reject.

Unter Extern immer Block, intern reject, weil ich kein bock habe auf den Timeout warten zu müssen, will gleich sehen, geht nicht, nicht erlaubt.

Bob.Dig

@NOCling said in Internet Zugang "! RFC1918" vs. block RFC1918 any - any:

NTP, DNS über eine INT Gruppe auf This Firewall erlaubt, fertig.

Oder Du ZwangstNATest das gleich auf die Firewall.

slu

@Bob-Dig said in Internet Zugang "! RFC1918" vs. block RFC1918 any - any:

Blocken immer großzügig, da würde ich mich nicht (auf Ports) beschränken.

Auch ein guter Punkt! Dann muss ich aber erst DNS und Co. erlauben bevor ich alles auf die Firewall blockiere.

Zwischen den Jahren möchte ich mal die ganzen Regel durchgehen, hab in den letzten Wochen einige Sachen mitgenommen und das gilt es anzuwenden.

slu

@NOCling said in Internet Zugang "! RFC1918" vs. block RFC1918 any - any:

NTP, DNS über eine INT Gruppe

Du meinst über die Interfaces / Interface Groups richtig?

NOCling

Ja, einfach im nächsten Meeting fragen, dann gehen wir das sicherlich durch.

JeGr

@slu said in Internet Zugang "! RFC1918" vs. block RFC1918 any - any:

Was spricht als Regel gegen Destination "! RFC1918"? Bei any any hab ich immer etwas Sogen das ich was übersehen habe und ein Loch in die Firewall reiße ohne es zu bemerken...

Haben wir doch alles erst am Freitag durchgekaut?

in !RFC1918 ist trotzdem die Firewall auf der Public IP erlaubt!! Je nach Kontext ist das eine Lücke die man garantiert NICHT will.
Logische Konstrukte wie "OR", "AND", "X-OR" etc. sind nicht für jeden einfach zu durchscuane
eine zweite !(NOT) Regel kann das komplette Regelset zerschlagen
oft genug ist RFC1918 allein zu invertieren NICHT genug. Das Netz besteht auch noch aus anderen Bereichen, wie Multicast, APIPA, CGNat (100.64.0.0/10), DSLite Space, etc. etc. etc. was man nicht freigeben sollte oder will. Und alles in immer größere Aliase zu packen, nur damit man am Ende eines mit !NOT veredeln kann, ist ziemlich "meh"
weitere Ausschlüsse - wenn man sie sinnvoll loggen will wie Blocklisten - machen nur Sinn als explizite Regeln, sonst kein Logging (pfBlocker). Und wenn ich dann eh Regeln für Blocklisten anlege, wirds langsam witzlos
Übersichtlichkeit. Pro Regel logging, einfacheres Debugging, etc.

slu

@JeGr said in Internet Zugang "! RFC1918" vs. block RFC1918 any - any:

Haben wir doch alles erst am Freitag durchgekaut?

Ja, gerade bei dem Part war ich (unfreiwillig) abgelenkt

@JeGr said in Internet Zugang "! RFC1918" vs. block RFC1918 any - any:

in !RFC1918 ist trotzdem die Firewall auf der Public IP erlaubt!! Je nach Kontext ist das eine Lücke die man garantiert NICHT will.

In dem Netgate Beispiel [1] würde man ja den Firewall Zugriff auch über die WAN Adresse erlauben
weil Destination "any" und nicht geblockt oder liege ich ganz falsch?

[1] https://docs.netgate.com/pfsense/en/latest/_images/wifivpn-isolation.png

JeGr

@slu würde man, ja. Wenn die Firewall selbst die public IP hat (oder IP6 in dem Fall ebenfalls, da wir hier ja kein einfaches RFC1918 mehr blocken können), dann würde allow any am Ende bewirken, dass ich über die Public IP der Firewall bspw. auf WebUI oder SSH zugreifen könnte, obwohl ich das nicht soll.

Das Bild dass du gemeint hast stammt aus meinem Fundamentals Workshop für pfSense den wir anbieten und soll verdeutlichen, was mit dem Keyword "any" passiert, wenn ein Regelsatz von oben nach unten durchlaufen wird. Denn bei jedem Pass/Reject/Block, der über einem finalen "allow any" steht, werden natürlich Verbindungen schon weggefiltert, egal ob erlaubt oder verboten. Heißt: was tatsächlich dann als "any" ankommt, wird immer weniger und weniger:

Zu Beginn ist "any" noch wirklich jeder Traffic. Dann filtert man Dinge aus, lässt internen Traffic zu bestimmten Zielen durch, zur Firewall wegen DNS o.ä., dann zu internen Systemen, zu VPN Gegenstellen, etc. aber dann geht man irgendwann zur Netztrennung/-isolation über und schottet sich ggü anderen VLANs ab. Dann wird Zugriff via "this firewall" verboten - kein Zugriff auf die Firewall außer von Admins sollte erlaubt sein, auch nicht in einem LAN. Dann interne Adressen (RFC1918) und ggf. auch andere, wie RFC5737 (Testnetze), RFC6598 (CGNAT), RFC5771 (Multicast) abfiltern - die braucht im Normalfall niemand von intern nach extern (außer man hat z.B. Tailscale am Start das im CGNAT Bereich liegt). Dann bleiben theoretisch nur noch größtenteils externe IPs über. Davon dann noch Blocklisten wie pfBlocker PRI1, 2, 3... (oder andere, Firehol, etc.) noch wegfiltern und DANN bleibt quasi noch halbwegs sinnvolles Internet über.

Cheers

slu

@JeGr genau dieses Beispiel meinte ich, danke!

Ich plane über die Jahre einige Netze umzubauen und da werde ich die Firewall Rules auch umbauen, mit dem neuen Wissen/Ansatz sowieso...

JeGr

@slu
Klar :) Ist ja immer ein iterativer Prozess. Man lernt wieder was dazu, baut was um, und irgendwann machts dann Sinn mit dem neuen Stand dann einfach nochmal tabula-rasa zu machen und neu anzufangen.