Default Deny Policy - wie Zugang zum Internet konfigurieren?

BSA66

Hallo,

per Standard wird ja sämtlicher ausgehender Traffic auf einem lokalen Interface heraus (außer LAN) geblockt.
Möchte ich bspw. VLAN10 Zugang ins Internet, aber zu keinen lokalen Adressen gewähren, handhabe ich das aktuell so, dass ich eine "Default Allow selfNet to any*" Regel erstelle, und über dieser dann bspw. mind. eine Block-Regel für lokale Adressen aktiviere. (z.B. wie beschrieben über ein Alias "RFC 1918").
Evtl partiellen Zugang zu einem Drucker in einem Subnetz muss ich dann aber wieder über der "Block thatNet" bzw. "Block RFC 1918" spezifisch via Single Host + Port (bspw) erlauben.

Ist hierfür eine elegantere Lösung bekannt?

Zwei grundlegende Gedanken.

ein "Default Allow any any" - "Explicit Deny any thatNet" ist ja eigentlich das Gegenteil dessen, wie man im Regelfall an das Thema Sicherheitspolicy herangehen soll ("Default Deny Policy")
ein neu erstelltes Netzwerk (außer LAN) erhält diese Policy bei Erstellung daher wohl standardgemäß auch genau so ("no access to nowhere")
im LAN wird, so wie ich gelesen habe, daher Abstand von der Standard-Policy genommen, damit normale User (wie ich z.B. :-) ) zunächst erst einmal überhaupt Zugang ins Internet erlangen können und nicht zuletzt noch frustriert den Hammer als letzten Lösungsweg wählen (bzw. die Foren mit "Funktioniert ja gar nichts hier" - Beiträgen fluten)

Diverse Ressourcen legen eine solche Policy nahe.

Meine Fragen nun

Wie das Wissen um die richtige Policy am besten umsetzen?

(Eine "Allow selfNet to WAN {Address;Net}" funktioniert nicht)
Liegt das an mir, oder daran, dass bspw. mein DNS für eine beliebigedomain.net eine Destination von 123.456.789.123 übermittelt und eine Verbindung zu dieser IP daher geblockt wird, da diese IP ja eben nicht dem erlaubten Bereich WAN{Address;Net} entspricht... ?

Wie kann man für ein bestimmtes Netzwerk eine Default Deny Policy fahren und für dieses Netz dennoch das Internet zugänglich machen?

--

Der einzige Lösungsweg, der mir bisher einfällt wäre, sich das RFC zu schnappen welches die routbaren IP's im Internet definiert und diese in ein Alias "Standard Routing IP Ranges" (bzw. das jew. RFC X..) zu packen. Dazu ein Alias für die benötigten oder zu erlaubenden Ports und zusammen in eine PASS-Regel.

Gibt es einen besseren Weg? Wie kann man eine Default Deny Policy für bestimmte Netze umsetzen bzw. wie wäre eine solche am ehesten umzusetzen?

Dank & Grüße
BSA66

viragomann

@bsa66 said in Default Deny Policy - wie Zugang zum Internet konfigurieren?:

Ist hierfür eine elegantere Lösung bekannt?

Nachdem die pfSense nur das erlaubt, was explizit in einer Pass-Regel ausgedrückt ist, kannst du alle Ziele, die du erlauben möchtest, auch in eine einzige Regel packen. Alles von dieser Regel nicht Erfasste, wird blockiert.

Um bei deinem RFC 1918 Alias zu bleiben, furmuliere ich die Pass-Regel unter Nutzung der Invert-Funktion:

pass   *   *   *   !RFC1918   *   *   *   *   none

Bei Destination ist also "invert match." angehakt und der RFC1918 Alias angegeben.

Ist aber im Grunde Geschmacksache, ob mit einer Regel formuliert oder mit mehreren. Für dich und andere soll es übersichtlich sein und den gewünschten Zweck erfüllen.
Es gibt hier im Forum auch namhafte Gegner meiner Methode.

@bsa66 said in Default Deny Policy - wie Zugang zum Internet konfigurieren?:

(Eine "Allow selfNet to WAN {Address;Net}" funktioniert nicht)

Möchtest du das wirklich? Macht nur Sinn, wenn du NAT Reflection verwendest.

@bsa66 said in Default Deny Policy - wie Zugang zum Internet konfigurieren?:

Liegt das an mir, oder daran, dass bspw. mein DNS für eine beliebigedomain.net eine Destination von 123.456.789.123 übermittelt und eine Verbindung zu dieser IP daher geblockt wird, da diese IP ja eben nicht dem erlaubten Bereich WAN{Address;Net} entspricht... ?

Ich fürchte, das verstehe ich nicht ganz. Wenn die vom DNS zurückgegebene IP nicht erlaubt ist, wird der Zugriff natürlich geblockt, unabhängig, ob die IP zu deinem WAN net gehört oder nicht.

@bsa66 said in Default Deny Policy - wie Zugang zum Internet konfigurieren?:

Wie kann man für ein bestimmtes Netzwerk eine Default Deny Policy fahren und für dieses Netz dennoch das Internet zugänglich machen?

Default deny gilt immer. Die Default allow-Regel am LAN kann auch geändert / entfernt werden.
Ansonsten ist das wohl schon mit obigen Beispiel beantwortet.

Grüße

BSA66

Entschuldige die verspätete Antwort.

@viragomann said in Default Deny Policy - wie Zugang zum Internet konfigurieren?:

Nachdem die pfSense nur das erlaubt, was explizit in einer Pass-Regel ausgedrückt ist, kannst du alle Ziele, die du erlauben möchtest, auch in eine einzige Regel packen. Alles von dieser Regel nicht Erfasste, wird blockiert.

Ja, ich habe auch ein wenig darüber nachgedacht und bin dabei zu einem Schluss gekommen, auf den ich aber etwas weiter unten eingehe.
Momentan läuft es bei mir quasi andersherum. Alles ist erlaubt, mit Ausnahme des RFC1918 Alias.

Ist aber im Grunde Geschmacksache, ob mit einer Regel formuliert oder mit mehreren. Für dich und andere soll es übersichtlich sein und den gewünschten Zweck erfüllen.

Übersichtlich ist mein Regelset, allerdings ist auch quasi außer lokalen Netzen nichts geblockt, weder als Dest-IP noch D-Port.

(Eine "Allow selfNet to WAN {Address;Net}" funktioniert nicht)

Möchtest du das wirklich? Macht nur Sinn, wenn du NAT Reflection verwendest.

Nein, wenn ich es richtig verstanden habe, vermutlich nicht. Ich bin zwar noch am lernen, aber einen für meine Bedürfnisse positiven Aspekt von NAT Reflection konnte ich jetzt auf Anhieb zumindest nicht direkt ausmachen. Einzig für Testzwecke der eigenen Erreichbarkeit von außen, denke ich, könnte man es kurzzeitig ausprobieren, z.B. um die eigene Domain aus dem eigenen Netzwerk heraus zu pingen.
Dafür das NAT Reflection aus ist spricht jedenfalls, dass wenn ich meine eigene Domain anpinge der Ping <1ms liegt, also lokal.

Ich fürchte, das verstehe ich nicht ganz. Wenn die vom DNS zurückgegebene IP nicht erlaubt ist, wird der Zugriff natürlich geblockt, unabhängig, ob die IP zu deinem WAN net gehört oder nicht.

Völlig richtig. Davon war ich auch ausgegangen, bin mittlerweile aber davon überzeugt. Daher habe ich beschlossen von einer Default Deny Any Any bzw. des Ersetzens der Default Allow zunächst für mein Netzwerk auch erst einmal Abstand zu nehmen.

Default deny gilt immer. Die Default allow-Regel am LAN kann auch geändert / entfernt werden.
Ansonsten ist das wohl schon mit obigen Beispiel beantwortet.

Grüße

Da mein Hauptziel in erster Linie ein besseres Verständnis ist bin ich von einer Default Deny auf IP-Basis abgerückt, das ist für meine Bedürfnisse sinnvoll de facto so nicht umsetzbar (ich möchte offenen Zugriff auf das WWW).
Was ich jedoch evtl noch ausprobieren könnte ist eine Default Deny auf Dest-Portbasis. Dass das im Echtlauf auch kein Zuckerschlecken wäre, vor allem mit Netflix, Steam, TeamSpeak & Co ist mir bewusst.
Allerdings denke ich mir, dass es in einer virtuellen Windows / Linux Umgebung mit relativ vertretbarem Aufwand machbar sein sollte. Der einzige Vorteil wäre, dass man mal einen Überblick erhält welche Dienste zu welchen Zielports (in einer Standardinstallation) kommunizieren.
Das es auch Webseiten gibt, die auf 8080, 8181 und wohl auch 81 lauschen habe ich mittlerweile auch gelesen. Und natürlich auch, dass sehr viel Schadsoftware sich über diese Ports "zuhause" anmeldet, vor allem wohl auch gerne 8080 und 8181 (was die wohl auch genutzten Ports für HTTP betrifft).

Ob das ganze für ein Heimnetzwerk noch einen Vorteil bringt bezweifele ich somit zunächst einmal. Für Lernzwecke kann sowas natürlich dennoch schon Sinn machen.

Was ich also für mich extrahieren konnte war, dass es je nach Ansprüchen für ein Netzwerk natürlich Bedingung sein kann, eine strikte Default Deny Any Any zu fahren, auf die SRC bezogen vermutlich nur noch bei entsprechend dokumentierten Applikationen. Auf die Dest-Ebene jedoch kann man, je nach gewünschtem Nutzungserlebnis, einen etwas strikteren Umgang auf D-Port vermutlich mit ausreichend Aufwand auch für zuhause anleiern.
Wie gesagt, den Nutzen (für meine Ansprüche an mein Netzwerk) stelle ich in kein gutes Verhältnis zum nötigen Aufwand, auch nicht für einen D-Port basierten Umgang. Aber das ist ein anderes Thema... :-)

Grüße