Firewall sucht Profi :)

Hi zusammen,
ich habe seit ein paar Tagen auch die UDM Pro und habe jetzt mal bei dieser Gelegenheit (CK2+ und USG mussten raus) mein komplettes Netzwerk überarbeitet.

Konkret bedeutet das, dass ich insgesamt 5 Netze erstellt haben - bitte nicht in Frage stellen wieso, weshalb, warum - ich mag einfach Ordnung

Hier mal kurz angerissen

• VLAN-ID = 1 = MGMT-LAN - das ist das default LAN, wo man auch keine VLAN-ID vergeben kann, weil es immer = 1 ist. Hier befinden sich der Vigor 165 (über den Port 2 des Vigors), meine UDM Pro, mein USW-16-POE-Gen2 und mein UAP-IW-HD.
• VLAN-ID = 10 = CAM_LAN - das ist das VLAN für meine Kameras (G3-Flex usw)
• VLAN-ID = 20 = HOME_LAN - das ist das VLAN für alle Geräte, die nicht in die anderen Kategorien passen - also sozusagen das "default" für meine Macs, iPads, iPhones, Drucker, Server usw.
• VLAN-ID = 30 = IOT_LAN - das ist das VLAN für alle IoT-Geräte wie z.B. Apple TVs, Apple HomePod, SmartTVs, SkyQ, AV-Receiver, Konsolen, Homey und alles andere "SmartHome-Zeugs" (also Steckdosen, Lichtschalter usw)
• VLAN-ID = 40 = VPN_LAN - das ist das VLAN, wo man landet, wenn man sich via VPN in mein heimisches Netz ein wählt
• VLAN-ID = 50 = GUEST_LAN - das ist das VLAN, wo meine Gäste drin landen - inkl. Guest-Landingpage usw.

Jetzt geht's mir darum, entsprechende Netzhärtungen vorzunehmen.

Mein zweites Ziel wäre - wie auch bei der WoL-Thematik - dass ich am Ende ausreichend Detailinfos zusammen habe, dass ich wieder eine Tutorial schreiben kann.

Dann wäre das Firewallthema nämlich einmal transparent für alle beschrieben. Leider hat mein Lieblings-UniFi-Mensch (Crosstalk Solutuions@Youtube) nämlich sein Video zum Thema Firewall mit einem EdgeRouter gemacht.

Da passt dann leider gar nichts - ich glaube selbst die Funktionsbeschreibung ist abweichend (zwischen EdgeOS und UnifiOS).

Aber genug geredet - jetzt erst mal zu dem, was ich bisher verstanden habe. Hier wäre es gut, wenn das mal einer verifizieren kann - nicht das ich schon Blödsinn gelernt/abgespeichert habe

Das doofe ist nämlich, dass es die Regeln natürlich nur in englisch definiert sind und es sich 1:1 übersetzt manchmal dämlich anhört.

Ich konzentriere mich hier auch ausschließlich auf IPv4, da man (aus meiner Sicht) im privaten LAN eh kein IPv6 braucht und es ja auch im WAN noch lange kein Standard ist.

Es gibt insgesamt 9 Bereiche für Firewallregeln, die ich wie folgt verstanden habe Wie man sieht - schon einige Lücken

Bezeichnung	Funktion / Beschreibung	Nutzbar für ...
WAN IN	Bezeichnet den Traffic, der IN das WAN Netzwerk kommt und IN andere Netzwerke will.	z.B. Port-Forwarding - also Traffic, der vorne am Gateway ankommt und an ein Ziel (Client) geleitet werden soll
WAN OUT	Bezeichnet den Traffic, der AUS dem WAN Netzwerk kommt und IN andere Netzwerke will	??? Gibt es hier einen Usecase?? Aus meiner Sicht macht hier doch nur sowas Sinn wie "ich will nicht, dass jemand aus meinem Netz einen FTP Server bedient." Ergo "drop" ich alles was über Port TCP 21 von der Quelle "xyz" zum Ziel "alles" geht. 1. UseCase von kaetho - siehe HIER
WAN LOCAL	Bezeichnet den Traffic, der über den WAN Port auf die UDM/USG (Local) will.	Grundsätzlich ist hier "Drop" gesetzt, damit niemand aus dem Internet, auf die UDM/USG zugreifen kann. Dieser Bereich wird automatisch um Regeln erweitert, sobald ihr den VPN-Server aktiviert, da es ja dann notwendig ist, dass L2TP Traffic für den Verbindungsaufbau zum UDM/USG kommt.
LAN IN	Bezeichnet den Traffic, der IN das LAN Netzwerk kommt und IN andere Netze will	Hier habe ich z.B. die Regel zum Härtung von IoT-Spam. Sprich "DROP" jeglichen Traffic vom Netz "IOT_LAN" in das Netz "HOME_LAN"
LAN OUT	Bezeichnet den Traffic, der innerhalb des LAN-Netzwerk möglich ist Diese Annahme ist nicht verifiziert, da die englische Beschreibung "komisch" ist Zitat: Applies to IPv4 traffic that exists the LAN (egress), destined for this network (default accept).	Hier bin ich mir auch nicht sicher, ob es einen Usecase dafür gibt. Hängt aber auch mit dem Nichtverständnis der englischen Beschreibung zusammen. Wenn ich die englischen Beiträge richtig verstanden habe, ist diese Regel eigentlich auch obsolet, weil man mit LAN IN exakt das gleiche bewirken kann.
LAN LOCAL	Bezeichnet den Traffic der über das LAN Interface auf die UDM/USG (Local) will.	Auch hier habe ich z.B. die Regel zur Härtung von IoT-Spam- Sprich "DROP" jeglichen Traffic vom Netz "IOT_LAN" in das Netz "HOME_LAN"
GUEST IN	Bezeichnet den Traffic, der in das GUEST-Netzwerk kommt und IN andere Netze will.	Hier findet sich z.B. die Einstellung beim Gästeportal "Post-Authorization Restrictions" wieder Sprich "DROP" jedes Paket was in die verbotenen Netze will. (192.168/172.16/10.0) Aus meiner Sicht gibt es hier auch nichts mehr (sinnvolles!) einzuschränken oder zu erlauben. Wenn doch - gerne Beispiele schreiben
GUEST OUT	Bezeichnet den Traffic, der innerhalb des GUEST-Netzwerk möglich ist Diese Annahme ist nicht verifiziert, da die englische Beschreibung "komisch" ist Zitat: Applies to IPv4 traffic that exists the guest network (egress), destined for this network (default accept).	Hier gibt es eine Regel, die aber leider default ist, und somit für mich nicht klar ist, was hier überhaupt möglich ist bzw. was der Sinn hier ist. Vielleicht kann hier einer aufklären.
GUEST LOCAL	Regelt den Traffic aus dem GUEST-Netzwerk auf die UDM/USG (Local)	Da das Netzwerk im Sinne seiner Funktion extrem eingeschränkt ist, sind hier einige Regeln automatisch hinterlegt wie z.B. Zugriff auf DNS, ICMP, DHCP oder auf das Gästeportal. Aus meiner Sicht gibt es hier auch nichts mehr (sinnvolles!) einzuschränken oder zu erlauben. Wenn doch - gerne Beispiele schreiben

Bisher habe ich aus den englischen Videos/Tutorials nur zwei Regeln übernommen, die augenscheinlich auch funktionieren

Bereich	Aktion	Protokoll	Quelle	Ziel	Hinweis/Sinn
LAN IN	DROP	ALL	IOT_LAN | IPv4 Subnet	HOME_LAN | IPv4 Subnet	Alles im IOT_LAN kann keine Kommunikation ins HOME_LAN herstellen
LAN IN	DROP	ALL	IOT_LAN | IPv4 Subnet	MGMT_LAN | IPv4 Subnet	Alles im IOT_LAN kann keine Kommunikation ins MGMT_LAN herstellen
LAN LOCAL	DROP	ALL	IOT_LAN | IPv4 Subnet	MGMT_LAN | IPv4 Subnet	Alle im IOT_LAN kann keine Kommunikation ins MGMT_LAN Hinweis: Das ist z.b. etwas, was ich nicht verstehe. Warum müssen Regeln aus den Bereichen "WAN/LAN/GUEST LOCAL" überhaupt ein Ziel haben. Ich habe das so verstanden, dass hier das Ziel eh immer die UDM/USG ist...

Jetzt aber zu dem Zielstatus, den ich gerne hätte und trotz der o.a. Erkenntnisse einfach nicht gebacken bekomme

Generell will ich das ganze Inter-VLAN-Routing komplett verbieten und nur bestimmte Konstellationen erlauben.

Problem gelöst - siehe unten Regel "Block_IoT_to_LAN" (Beispielhaft für das IoT_VLAN)

Die Regel muss dann einfach nur dupliziert werden und die Quelle angepasst werden.

1) Ich will von einem definierten Client (feste IP) aus dem HOME_LAN auf ein Ziel (feste IP) im MGMT_LAN.

Selbst wenn ich das ganz grob nur mit "LAN IN" und ERLAUBE ALLES von Quelle "HOME_LAN" zu Ziel "MGMT_LAN" setze (Regel nach ganz oben!), funktioniert das nicht

Problem gelöst - siehe unten Regel "Allow Admin Mgmt"

2) Ich will, dass definierte Clients (feste IP) aus dem IOT_LAN auf ein Ziel (feste IP) im HOME_LAN zugreifen können.

z.B. AppleTVs und PS4 zum Server (Plex installiert)

Problem gelöst - siehe unten Regel "Allow_PLEX"

3) Der Homey soll seinen WOL Befehl an den Server senden können

Vermutlich gar nicht lösbar, da man WOL nicht von einem VLAN in ein anderes VLAN schicken kann

4) Ich will, dass definierte Clients (feste IP) aus dem HOME_LAN auf definierte Ziele (feste IP) im IOT_LAN zugreifen können

z.B. Mac, iPhones, iPads auf die AppleTVs

Problem gelöst - siehe unten Regel "Allow_Established_Related"

Und je nach Antworten kommen da sicherlich noch einige Fragen dazu -- was mir z.B. aktuell direkt einfällt, wo ist eigentlich der Unterschied bei Quelle/Ziel zwischen IPv4 Subnet und Gateway IP Adresse.

In meiner Welt, ist die Gateway IP Adresse doch sowieso geblockt, wenn ich IPv4 Subnet auswähle - oder?

Schon mal vielen Dank an alle, die sich an der Diskussion beteiligen - am Ende werde ich, wie oben beschrieben, mal ein Tutorial für alle machen, was man sinnvoll umsetzen sollte (IOT-Isolation) und was noch (und wie) geht

Schönen Abend zusammen,

Sehr gut - danke. Werde ich nachher oben man ergänzen. Früher oder später wird jemand genau das benötigen.

Die FW ist in der Tat alles andere als einfach - jedenfalls für Otto Normal. Das ist selbstselbst ne Windows-FW simple gegen....

Bin mal auf weiteres Feedback gespannt. Aktuell kann ich nicht weiter machen, weil Stromausfall 🙈😂

Das dürfte dann eigentlich ja auch das sein, was ich will

Nämlich von meinem AppleTV (VLAN-30 @ IOT_LAN) auf meinen unRAID-Server (Plex) der im VLAN-20 | HOME_LAN steht.

Ich werde heute Abend wieder was rumspielen - kann das nur machen, wenn die Frau das Netz nicht braucht - die hat nämlich nicht so viel Verständnis wenn immer wieder das Netz weg ist...

So... nach einer schönen nächtlichen Runde zwischen meiner UDM Pro und mir - mit kalter Pizza - kamen wir zu folgende Erkenntnisse bzw. Umsetzungen.

1) FW-Gruppe "RFC1918" erstellt. Diese beinhaltet die Netze 192.168.0.0/16; 172.16.0.0/12 und 10.0.0.0/8 und deckt somit alle meine VLANs ab.

2) FW-Gruppe "Local_Gateways" erstellt. Diese beinhaltet jedes Gateway aus jedem VLAN - in meinem Fall also 10.1.0.254 / 10.10.0.254 / 10.20.0.254 und 10.30.0.254.

3) FW-Gruppe "IoT_Server_Devices" erstellt. Diese beinhaltet jedes Device aus dem IoT_LAN, welches Zugriff auf meinen Server (der PLEX hosted) benötigt. z.b. 10.30.0.1 (PS4) oder 10.30.0.2 (ATV4k)

Jetzt habe ich unter LAN IN folgende Regeln erstellt. Wichtig - das sollte man auch in dieser Reihenfolge machen, da man sich sonst ggf. selber ausschließt

• Grüne Parameter = Source/Quelle
• Blaue Parameter = Destination/Ziel
• Gelb = Hinweistexte oder nicht verifizierte Informationen

LAN LOCAL-Regeln

1. Regel = "Allow_Established_Related"

Hinweis: Das ist wohl eine Standardregel, die man immer für jedes VLAN hinterlegen sollte, da sie (sofern ich das richtig verstanden habe) bereits bestehende Verbindungen weiterhin erlaubt.

Das soll wohl viel Arbeit sparen. Allerdings habe ich auch gelesen, dass man diese Regel nicht setzen soll, wenn man eine bereits bestehende Kompromittierung im Netz vermutet - was logisch klingt - weil ja sonst die nicht gewünschten Verbindungen weiterhin bestehen bleiben würden. Sollte ich die Regel FALSCH ausgelegt haben, bitte korrigieren.

2. Regel = "Allow_PiHole_DNS"

Hinweis: Diese Regel ist dafür da, dass die Geräte aus allen VLANs auch an meinen Pi-Hole für die DNS Auflösung kommen. Der Pi-Hole ist bei mir bei allen VLANs als DNS fest an Nummer 1 gesetzt!

Als Fallback ist DNS = 1.1.1.1 und 1.0.0.1 gesetzt

3. Regel = "Allow_PLEX"

Hinweis: Diese Regel ist dafür da, dass die Geräte aus der Gruppe "IoT_Server_Devices" Zugriff auf den PLEX-Server bekommen. Da der Server nicht nur der Host von PLEX, sondern auch Dateiablage sensibler Daten, diverser VMs und Docker ist, habe ich mich für diese Gruppenregel entschieden. Man könnte auch einfach das ganze VLAN "IoT_LAN" Zugriff auf den Server geben. Das war mir zur kritisch.

In meiner Konstellation reicht es somit für den "Eindringling" nicht aus, nur im richtigen VLAN zu sein - er müsste auch in die FW-Gruppe administriert werden. Was nur geht, wenn man auf die UDM kommt.

Das habe ich aber - Regel kommt weiter unten - in Verbindung mit der FW-Gruppe "Local_Gateways" verboten

4. Regel = "Allow_WoL"

Hinweis: Diese Regel ist dafür da, dass die Geräte aus der Gruppe "IoT_Server_Devices" das MagicPacket für Wake on LAN an den Server senden können.

Hinweis 2: Hierfür habe ich bisher keine Lösung gefunden

Sowohl ICMP Freigabe als auch TCP/UDP 7-9 haben nicht zum Erfolg geführt

5. Regel = "Block IoT to LAN"

Hinweis: Mit dieser Regel wird alles, was nicht durch die Regeln 1-4 erlaubt wird, komplett geblockt. Das VLAN "IoT_LAN" ist somit (ausgehend) isoliert von meinen anderen VLANs.

Diese Regel kann natürlich jetzt beliebig dupliziert werden, um auch andere Inter-VLAN-Kommunikation zu verbieten.

Für z.B. ein Verbot vom HOME_LAN einfach bei SOURCE das Network HOME_LAN hinterlegen - und schon kann man aus dem HOME_LAN auch keine Inter-VLAN-Kommunikation mehr aufbauen.

So - ich habe meine LAN LOCAL Regeln noch erweitert. Daher habe ich die eine von dem vorherigen Post, hierhin verschoben.

Vorwort:

Für diese Regeln habe ich mir auch eine weitere Firewall-Gruppe angelegt.

Diese habe ich "Admin_Devices" genannt und enthält alle Geräte, die in Zukunft Zugriff auf die UDM erhalten sollen.

LAN LOCAL-Regeln

1. Regel = "Allow Admin Mgmt"

Hinweis: Mit dieser Regel wird sichergestellt, dass ich mit meinen Admingeräten (definiert durch die o.a. Firewall-Gruppe) weiterhin auf die UDM komme - und zwar aus jedem VLAN, da ja die andere Firewall-Gruppe (Local_Gateways) alle VLAN-IPs der Gateways enthält.

2. Regel = "Block IoT to Gateways"

Hinweis: Mit dieser Regel wird unterbunden, dass sich ein Client aus dem IoT_LAN auf eines der Gateways verbindet.

Ich habe die FW-Gruppe nur der Einfachheit gewählt - ich hätte auch überall die jeweilige IP des Gateways hinterlegen können.

Diese Regel werde ich für alle anderen VLANs auch setzen. Aber Achtung beim Nachmachen. Bitte immer erst die Regel #1 umsetzen, um weiterhin Zugriff zu haben!

3. Regel = "Block Home to Gateways"

Hinweis: Diese Regel ist fast identisch zu Regel #2 - bezieht sich jetzt aber auf das VLAN = HOME_LAN.

Auch hier gilt: Achtung beim Nachmachen. Bitte immer erst die Regel #1 umsetzen, um weiterhin Zugriff zu haben!

4. Regel = Block IoT to MGMT

Hinweis: Diese Regel verhindert den Zugriff von Clients aus dem IoT_LAN auf die restlichen Clients aus dem MGMT_LAN (Zugriff auf die Gateways wurde ja schon mit Regel #2 und #3 verboten)

Auch hier gilt: Achtung beim Nachmachen. Bitte immer erst die Regel #1 umsetzen, um weiterhin Zugriff zu haben!

5. Regel = Block HOME to MGMT

Hinweis: Diese Regel ist fast identisch zu Regel #4 - bezieht sich jetzt aber auf die Clients im HOME_LAN.

Auch hier gilt: Achtung beim Nachmachen. Bitte immer erst die Regel #1 umsetzen, um weiterhin Zugriff zu haben!