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

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.

slu

Ich bin fleißig am Firewall Rules umbauen.

Frage, wie macht ihr das mit dem DNS oder NTP Dienst?
Auf jedem Netz/VLAN extra laufen lassen oder nur auf dem LAN Interface?

Eigentlich spricht nichts dagegen wenn man diese nur im LAN laufen lässt und dann auf den anderen "unsicheren" Netzen einfach ein Access auf "LAN address" und 53 + 123 erlaubt, oder übersehe ich da was (Sicherheitstechnisch)?

NOCling

Ich lasse die über Int group auf This Firewall zu, damit ist jedes Interface möglich.
Aber ich weise dann im DHCP Pool für das jeweilige Netz die lokale IP als DNS und NTP zu.

Zudem biege ich das noch per NAT um, für Clients die meinen die DHCP Option ist optional...

Bob.Dig

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

oder übersehe ich da was (Sicherheitstechnisch)?

Unschön, zumal das lokale Interface ja eh im DHCP voreingestellt ist.

slu

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

Aber ich weise dann im DHCP Pool für das jeweilige Netz die lokale IP als DNS und NTP zu.

So hatte ich das seither auch, dachte nur ich bin faul und mache zukünftig ntp.localdomain welcher dann auf ein (LAN) interface zeigt.

Beim DNS kommt es vom DHCP, da stimmt da brauche ich nichts zu machen.

JeGr

@slu NTP bringt dir zumindest bei Windows leider gar nichts, weil Windows einfach zu fucking dämlich ist, NTPs per DHCP auszulesen. Mit einem DNS Namen brauchst du da schon gar nicht anzufangen.
Somit ist das leider immer noch händische Sache, das sauber einzurichten - oder zu machst einfach harakiri-hijacking und leitest die NTP Calls einfach auf dem Interface um. Das klappt eigentlich wie bei DNS recht schick :)

Ich würde da auch immer das eigentliche Interface präferieren. Zero Knowledge geht vor allem anderen: Was der Client nicht weiß oder wissen muss, braucht ihn auch nicht zu interessieren. Das GW kennt er schon. DNS und NTP kann er dann von dort auch gern haben. Und wenn er sich nicht dran hält wird er einfach transparent eingefangen und darauf umgeleitet ohne es zu merken. Probiert man natürlich erstmal mit einem Testnetz aus, aber klappt im Normalfall ganz fortrefflich.

Somit hat man auch keine komischen Zugriffe die theoretisch über Netzgrenzen gehen (auch wenn sie auf der Firewall bleiben). Aber alleine andere VLANs zu kennen und zu wissen, dass da was ist, ist schon mehr als notwendig.

Cheers

slu

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

NTP bringt dir zumindest bei Windows leider gar nichts, weil Windows einfach zu fucking dämlich ist, NTPs per DHCP auszulesen.

Oh ja das Probleme kenne ich, habe den NTP per GPO erzwungen weil die Zeit immer ein paar Minuten plus/minus war. Seit die GPO den pfSense NTP erzwingt ist die Zeit synchron.

Aber gut möglich das ich mein Samba nicht ordentlich konfiguriert habe...

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

Somit hat man auch keine komischen Zugriffe die theoretisch über Netzgrenzen gehen (auch wenn sie auf der Firewall bleiben). Aber alleine andere VLANs zu kennen und zu wissen, dass da was ist, ist schon mehr als notwendig.

Das ist natürlich ein guter Punkt, ich fürchte bei mir wird das jetzt so ein bischen ein Hybrid Modus :)
Hatte mir auch schon überlegt nur ein "dummy" VLAN Interface für das Zeug anzulegen, dann dachte ich mir wieder dann kann ich gleich das LAN Interface NTP/DNS freigeben...

Ja ich weiß, Details...