Fragen zu Firewall-Regeln 2.0 by DEFCON

Es gibt 17 Antworten in diesem Thema, welches 4.771 mal aufgerufen wurde. Der letzte Beitrag () ist von Mosconi.

    Hallo Zusammen,


    ich habe mir gestern mal die Tapete "Firewall-Regeln 2.0 by Defcon" angesehen und dies versucht auf mein Netzwerk zu adaptieren.


    Einerseits möchte ich dieses Regelwerk nicht betreiben, ohne grob zu verstehen, was welche Regel macht, andererseits gibt es mit dem Regelwerk bei mir Probleme, bei denen ich hoffe, von euch Hilfe zu erhalten.



    1. Verständnisfrage

    Bsp: block all communication between VLANs: Hier werden die IP-Ranges als Ziel verwendet.

    Um zu verstehen, warum es hier richtig ist, die IP-Ranges zu nehmen wüsste ich gerne, was machen die IP-Ranges hier anders als die VLAN Gateway IP's?


    2. Verständnisfrage

    Was machen die "LAN local" Regeln anders als die "LAN in" Regeln?

    Welcher Sichheitsvorteil geht dabei z.B.hervor?


    Bevor ich nun zu den Problemen komme, vielleicht ein paar Fakten zu meinem Netzwerk:


    192.168.0.1 # mein MGMT LAN

    192.168.10.1 # mein DNS VLAN mit piHole

    192.168.20.1 # mein Home VLAN

    192.168.30.1 # (Kids Vorhalt)

    192.168.40.1 # mein IoT VLAN

    192.168.50.1 # (Kamera Vorhalt)

    192.168.60.1 # mein Gast VLAN


    1. Problem: admin device will nicht mit MGMT-LAN kommunizieren

    Mein admin Rechner ist im Home Vlan beheimatet.

    Dieser Rechner und noch ein weiterer sind im (admin devices)-Profil hinterlegt.

    Beide haben eine fixed IP.

    Will ich nun mit einem der beiden Rechner auf z.B. das MGMT LAN zugreifen (Bsp: 192.168.0.14) geht das nicht. Der Client aus dem MGMT LAN ist dann auch nicht anpingbar. :unamused_face:


    Pausiere ich die Regel 2013: "block communication between VLANs"

    mit den lokalen IP-Ranges:

    192.168.0.0/24

    192.168.10.0/24

    192.168.20.0/24

    192.168.30.0/24

    192.168.40.0/24

    192.168.50.0/24

    192.168.60.0/24


    dann klappt auch der Zugriff auf das MGMT LAN problemlos. :face_with_open_mouth: #Gottseidank gibt es die Pause-Funktion#


    Hat jemand ne Idee, wie ich der Ursache auf den Grund gehen kann?


    2. Problem: Mein Sorgenkind piHole

    Dieser steckt im DNS VLAN.

    Bei den Ports habe ich nur Port 53 eingetragen!

    Trage ich die piHole-IP in ein VLAN ein, hat mein Rechner schlagartig keine Lust mehr, eine funktionierende Internetverbindung aufzubauen. Trage ich die PiHole IP aber NUR als WAN DNS Server ein, so klappt die Internetverbindung mit meinem Rechner. Doch genau das möchte ich ja nicht.


    Woran kann es liegen, dass die piHole IP im VLAN überhaupt nicht funktionieren will?

    Fehlen aus eurer Sicht noch andere wichtige Ports außer Port 53?

    Wie könnte ich dem Problem auf die Schliche kommen?



    Schonmal vorab vielen Dank für die Hilfestellung


    Grüße Mosconi

  • Zum Hilfreichsten Beitrag springen

    • Hilfreich

    Hallo,


    das von DEFCON Ist als Leitfaden zu sehen und kann angepasst werden.


    Thema
    Firewall Regeln vereinfachen
    Hallo,


    ich habe mich beim Anlegen der FW Regeln an die Vorschläge auch hier aus dem Forum gehalten. Wenn ich mir aber die Regeln ansehe, sehe ich da vieles doppelt und dreifach.


    Also habe ich alle Lan-In Regeln rausgeworfen, die sich wie folgt nannten:


    Drop Netz/VLAN zu allen Gateways
    Drop Netz/VLAN zum UniFi Netz


    Die Regel -Drop alle internen Netze/VLAN- habe ich dahingehend geändert, das dort nun alle privaten Netze192.168.0.0/16, 172.16.0.0/12, 10.0.0.0/8 enthalten sind.


    Ich habe alles mögliche…
    thghh


    Du musst z.B. für Pihole den Zugriff aus allen Netzen zum DNS Netz erlauben.

    • Local Applies to traffic that is destined for the UDM/USG itself.
    • In Applies to traffic that is entering the interface (ingress), destined for other networks.
    • Out Applies to traffic that is exiting the interface (egress), destined for this network.

    Gruß

    defcon

    Gefällt mir 1

    Hallo Mosconi ,


    damit das mit den Port-Profilen einwandfrei funktioniert müssen alle - leider nicht näher benannten - Switches wenigstens VLAN-fähig sein, gern alle aus der UniFi-Serie, was die Konfiguration erheblich vereinfacht.


    Nun aber zu Deinem ersten Problem:

    Warum ist der Client nicht im DHCP reserviert oder meinst Du das mit "fixe IP"?

    Wie ist der Switch-Port konfiguriert, an dem die beiden besagten Clients hängen?

    Handelt es sich dabei um einen managed Switch?

    Welche fixe IP hast Du dem Client vergeben? Passt diese zum Port-Profil?

    Stimmen Gateway und DNS bei dem manuell konfigurierten Client?

    Wo ist das Profil admin devices erstellt? Legacy-View: Routing & Firewall --> FIREWALL --> Groups (IPv4 Address Group) oder wo? Kannst Du davon einen Screenshot bereitstellen?


    Cheers.

    Hallo Razer,


    erstmal vielen Dank für deine Hilfbereitschaft!


    Bei mir hat sich die Uhr in der Zwischenzeit etwas weitergedreht. Das soll heißen, ich habe viele Regeln erstmal wieder gelöscht und bin gerade daran, alles Stück für Stück aufzubauen. Das versuche ich aber grad noch nach dem alten Wiki Firewall Beitrag.


    Dazu habe ich eine Frage: Wenn ich die untere Regel anwende, ist mittels ping Befehl kein Client aus den anderen Subnetzen erreichbar. Das ist schon mal gut.

    Wenn ich aber auf meinem MacBook den IP Scanner anwerfe, bekomme ich trotzdem die Clients aus den anderen Subnetzen angezeigt.

    Jetzt weiß ich nicht genau, ob das so normal ist, oder ob da noch etwas nicht stimmt. Das MacBook hat in diesem Moment keine Berechtigung auf andere Subnetze zuzugreifen.


    *

    --------------------------------------------------------------------------------------------------------

    Regel 3 „block all communication between VLANs“


    SETTINGS>Routing & Firewall>FIREWALL>LAN IN>CREATE NEW RULE

    Name>>>block all communication between VLANs

    Action>>>Drop

    Source Typ>>>Address/Port Group

    IPv4 Address Group>>>all private IP-ranges RFC1918

    Destination Type>>>Address/Port Group

    IPv4 Adress Group>>>all private IP-ranges RFC1918

    >>mit Save abspeichern<<

    Wir haben mit Regel 3 die Kommunikation der Subnetze untereinander eingeschränkt. Geräte können sich über die Subnetz-Grenzen nicht sehen und auch nicht erreichen."

    --------------------------------------------------------------------------------------------------------

    Grüße aus dem Schwabenländle.

    also das kann ich so nicht bestätigen...
    ich hatte jedoch letztens das Problem, da habe ich jemandem Remote geholfen und da musste, damit die Regeln greifen die UDM/UDM Pro neu gestartet werden.

    Bei meinem UXG Pro verhält sich das nicht so... da greifen die Regeln sofort (FW 3.0.1) vermutlich gilt das auch für die UDM SE


    Des weiteren benutzt du ja auch das alte Tutorial, so wie ich es sehe.


    Zitat von Mosconi

    Was machen die "LAN local" Regeln anders als die "LAN in" Regeln?

    Welcher Sichheitsvorteil geht dabei z.B.hervor?

    Zum Thema Lan Local nochmal...

    Wenn du schon mit einem IP Scanner arbeitest, wird dir auffallen, dass die Gateway Adrerssen erreichbar sind... und das ist dass, was ich die ganze zeit versuche zu erklären! Dafür ist Lan Local zuständig.


    Zitat von Mosconi

    Woran kann es liegen, dass die piHole IP im VLAN überhaupt nicht funktionieren will?

    Fehlen aus eurer Sicht noch andere wichtige Ports außer Port 53?

    Wie könnte ich dem Problem auf die Schliche kommen?

    Im Pihole wirst du vermutlich das recommended Setting aktiv haben...


    Gruß

    defcon

    Zitat

    Zum Thema Lan Local nochmal...

    Wenn du schon mit einem IP Scanner arbeitest, wird dir auffallen, dass die Gateway Adrerssen erreichbar sind... und das ist dass, was ich die ganze zeit versuche zu erklären! Dafür ist Lan Local zuständig.

    Danke, das habe ich mittlerweile verstanden. Kannst du anhand des Screenshots erkennen, warum der IP Scanner hier aus dem IoT Netz in ein eigentlich geblocktes Netz schauen kann?



    Zitat von Mosconi

    Kannst du anhand des Screenshots erkennen, warum der IP Scanner hier aus dem IoT Netz in ein eigentlich geblocktes Netz schauen kann?

    Die Regel muss ins LAN IN, nicht ins LAN LOCAL

    So, bin wieder etwas weitergekommen. Der Neustart hat nun zumindest bewirkt, dass der Einblick in die anderen Subnetze nicht mehr so leicht möglich ist. Warum schreibe ich das: Wenn ich über nmap einen einfachen Portscan mache, findet nmap nichts. Mit einem anderen Scan sieht er doch noch, ob ein Client da ist oder nicht.

    Sodele, es scheint nun alles erstmal gut zu laufen. Firewall und Pi Hole funktionieren.

    Der PiHole wollte nicht, da ich in der Firewall DNS Freigabe anstelle "UDP und TCP" Any drinstehen hatte. Warum es mit "Any" nicht funktioniert ist mir ein Rätsel.


    Grüße und Danke an die Mannschaft für die Hilfe

    Zitat von Mosconi

    Mit einem anderen Scan sieht er doch noch, ob ein Client da ist oder nicht.

    Bin mir nicht sicher, Es kann sein das du das ICMP Protokoll explizit sperren musst auf LAN Local um das Pingen zu verhindern. Der Zugang sollte bereits über deine Regel geblockt sein.

    Ansonsten: Da du nicht schreibst womit du prüfst, es wäre auch möglich das dein Programm einen Puffer hat und nur davon ausgeht das die Clients noch da sind.

    Pingen geht bei mir nicht, trotz aktivem ICMP

    Gruß

    defcon

    Gefällt mir 1

    Achso, ein Geheimnis mach ich da nicht draus. Mit

    nmap -T4 - A -v -Pn (Client IP) habe ich nach erfolglosen Ping es versucht.

    ICMP ist in der Firewall bei mir nur unter "Guest V4/6" erlaubt.

    Heißt im Umkehrschluss wäre es damit in Lan local deaktiviert, oder?

    Einmal editiert, zuletzt von razor () aus folgendem Grund: Ein Beitrag von Mosconi mit diesem Beitrag zusammengefügt.

    Zitat von Mosconi

    Wenn ich aber auf meinem MacBook den IP Scanner anwerfe,

    Ich beziehe mich auf diesen Satz womit du die Rechner im Netzwerk trotzdem siehst

    Das mit nmap als Port Scanner hast du deutlich beschrieben. Ich ging davon aus, das du mit ‚sehen‘ einen Mac Scanner benutzt der Ping auslöst

    Shame on me... :winking_face: Du hast das schon richtig gelesen. Auf nem Mac habe ich noch nen IP Scanner drauf. Das ging damals vor 10 Jahren schneller als erst in die damalige Fritte sich einzuloggen und zu schauen, welcher Client welche IP hat.

    Allerdings ist Nmap da schon umfangreicher.


    Jetzt aber noch eine Frage an die Gelehrten....


    Seitdem ich meine Firewallregeln etwas angepasst habe, musste ich heute feststellen, dass ich von meinem Laptop nicht mehr auf das USG komme. Weder per Browser 192.168.0.1, noch per ssh oder Ping. Hänge ich den Laptop aber direkt ins MGMT Lan, komme ich auf das USG. Also blockt wohl irgendeine Firewall Regel. Was ich mir aber nicht erklären kann ist, mit die erste Regel ist die, dass meine Admin Rechner auf alle Netze dürfen. Die IP meiner beiden (admin) Rechner ist per DHCP reservation vergeben. Dies hatte ich auch nochmal geprüft. Wieso kommen beide Rechner nicht auf das USG? Auf die anderen Geräte im MGMT LAN (Cloud Key, NAS) komme ich mit beiden Laptops. Ich blocke zwar danach noch alle Netze und Gateways gegeneinander, aber mit der Regel sollte es doch klappen?