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

slu

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

Mit deiner Regel werden jetzt Blocks nach RFC1918 nicht geloggt.

Ich (glaube) jetzt verstehe ich dich, weil meine Regel zu einem Match führt wird nicht geloggt, das meintest Du?

NOCling

Wenn man die Blocks sehen will, dann brauchst halt die zwei, ansonsten halt nicht.

Nicht vergessen die WAN IP zu blocken, sonst kommen auch Gäste auf die Firewall, weil die ist !RFC1918 erreichbar.

slu

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

Nicht vergessen die WAN IP zu blocken, sonst kommen auch Gäste auf die Firewall, weil die ist !RFC1918 erreichbar.

Jap das habe ich, war mir damals auch nicht bewusst aber eigentlich logisch :)
Block Destination "This Firewall (self)" 80/443/22 bevor die "! RFC1918" 80/443 kommt.

NOCling

Davor alles erlauben, z.B. in einer Int Gruppe oder Floating und dann alles blocken, ich mache über eine Int Gruppe.
Und die WAN IP der Firewall kannst du für alles blocken, da sollte kein interner hin, weil auch Nat reflection Regeln landen ja davor, bzw. sollten dort landen.

Bob.Dig

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

Block Destination "This Firewall (self)" 80/443/22 bevor die "! RFC1918" 80/443 kommt.

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

viragomann

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

Was spricht als Regel gegen Destination "! RFC1918"?

Meiner Meinung nur, dass so manche das Regelwerk damit nicht durchblicken. Wenn du weißt, was du tust, kannst du es auch so machen.
Und dich eben die Blocks nicht interessieren. Die fallen dann eben von der Deny-any Regel abgefangen, die man auch loggen kann.

Edit:
Muss da noch ergänzen: Das zitierte Beispiel in den pfSense Docs verwendet eine Reject-Regel, die den anfragenden Client sofort zu erkennen gibt, dass hier nichts geht. Das erreicht die Default-Deny Regel natürlich nicht.

slu

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

Davor alles erlauben, z.B. in einer Int Gruppe oder Floating und dann alles blocken, ich mache über eine Int Gruppe.

Mit dem "Davor alles erlauben" hast Du mich jetzt abgehängt, ich blocke den Zugriff auf die pfSense selber immer als aller erstes in den Regeln.

Was ich jedoch noch nicht verwende sind Interface Groups und damit hätte ich mir wohl schon einiges an Arbeit gespart und nicht alle möglichen Regel kopieren müssen.

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.