Unifi Firewall Best Practice - Wiki Eintrag

Es gibt 19 Antworten in diesem Thema, welches 4.715 mal aufgerufen wurde. Der letzte Beitrag () ist von defcon.

  • Hallo zusammen,


    ich beschäftige mich aktuell mit den Firewall-Regeln meiner UDM-SE und habe deswegen (ganz vorbildlich) auch den Wiki-Eintrag bzgl. Firewall studiert und für mich adaptiert. Dabei ist mir speziell bei den LAN local Regeln aufgefallen, dass entweder die Regeln unsinnig sind oder ich noch ein grundsätzliches Verständnisproblem habe. Ich habe den Wiki-Eintrag auch direkt kommentiert, aber da der Autor nicht mehr aktiv im Forum zu sein scheint, wird da keine Reaktion mehr kommen.


    Zum Thema:

    Die im Wiki-Eintrag formulierten LAN-Local Regeln sollen unterbinden, dass von einem Subnet aus die Gateways der anderen Subnets erreichbar sind.

    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.

    Die Gateways der Subnetze sind jedoch noch aus den anderen Subnetze erreichbar.

    Beispiel: Von einem Gerät im LAN IoT (10.10.2.x) ist das Gateway des LAN 1 -Admin-LAN- (10.10.1.1) erreichbar. Somit auch USG oder UDM.

    Das wollen wir im nächsten Schritt unterbinden.

    Die angebotene Lösung funktioniert zusammengefasst so:

    • in jedem VLAN wird der Zugriff auf die anderen Subnetze gedropt.
    • Da es sich um LAN local Regeln handelt, betrifft es die Gatways in den jeweiligen Subnetzen.
    • Das Haupt-LAN wird nicht eingeschränkt.

    Im Endeffekt verhindern die Regeln, dass ich beispielsweise aus dem VLAN 10.10.2.0/24 das Gateway 10.10.1.1 erreiche. Also im Prinzip machen sie das, was die formulierte Anforderung war.


    Soweit so gut. Aber warum wollen wir das überhaupt?

    Wenn es darum geht, dass aus einem beliebigen Hinz und Kunz Subnet heraus die UDM/USG nicht konfigurierbar sein soll (was ich für sinnvoll hielte), dann bringen die Regeln nichts! Denn ich kann aus jedem Subnet logischerweise das jeweilge Standard-Gateway erreichen - und zwar auf allen Ports, also sowohl per http(s) als auch per ssh. Somit habe ich immer noch die Möglichkeit, aus jedem Subnet heraus, die Web-GUI der UDM/USG aufzurufen oder eine ssh-Verbindung herzustellen.


    Um das zu unterbinden, reichen 2 simple Regeln in LAN LOCAL:

    • erlaube aus dem Management/Default-LAN alles (wie bisher)
    • verbiete aus allen LANs den Zugriff auf die Ports 80, 443, 23 in allen Privaten Netzen nach RFC1918

    Das funktioniert gut.


    Aber was sollen die LAN local Regeln aus dem Wiki-Beitrag bewirken. Haben die einen tieferen Sinn, der sich mir nicht erschließt?

  • Also mein UXG Pro hat die 10.0.1.1 , mein Controller die 10.0.1.10 und ich komme aus meinen VLANs weder auf die Weboberfläche vom Gateway, noch vom Controller.


    Ich vermute mal du hast da bei den Gruppen irgendwas verbaselt, funktioniert bei mir einwandfrei, ich kann nur das Gateway des jeweiligen VLANs wo sich der Client drin befindet erreichen und sonst Nada

    Gruß

    defcon

  • Verstehe ich nicht. Wenn du aus deinem vlan das zugehörige default Gateway erreichst, dann erreichst Du über https://<default-Gateway> doch auch die Web-Oberfläche vom USG.

    Und da bei der UDM Controller und Gateway das gleiche Gerät sind…

  • Verstehe ich nicht. Wenn du aus deinem vlan das zugehörige default Gateway erreichst, dann erreichst Du über https://<default-Gateway> doch auch die Web-Oberfläche vom USG.

    Der Logik einer Firewall nach, sollte das so sein.

    Eine Firewall verbietet alles, was nicht expliziert erlaubt wird - leider arbeite Unifi an der Stelle nicht konsequent oder sage wir so, da gibt es noch Optimierungspotential.


    Bei meiner Firewall kann man zwar das Gateway des jeweiligen VLAN erreichen, aber noch lange nicht über die selbe IP sich an der Firewall selber anmelden - das muss expliziert per Regelwerk erlaubt werden ( Destination = "this firewall", Port = optional 22,443, 80 )


    Die sicherste Lösung ist immer noch, am Ende des Regelwerkes pro VLAN eine Drop-all Regel zu setzen

  • VLAN 99


    VLAN 10


    VLAN 20



    Client im Management LAN



    Unter LAN LOCAL legst du die Regeln an, um sämtlichen traffic zwischen den GWs zu droppen.

    Gruß

    defcon

  • Ich glaube, wir reden/schreiben aneinander vorbei.


    Konkretes Beispiel:

    • Das Default-LAN ist 10.10.1.0/24
    • Der Router sei eine UDM-Pro mit 10.10.1.1 (und natürlich auch mit 10.10.10.1, 10.10.20.1, ...)
    • Das zu betrachtende Client-Device sitzt im VLAN 20 mit 10.10.20.55


    Mit den LAN local Regeln aus dem Wiki passiert folgendes:

    Der Client 10.10.20.55 kann die UDM-Pro unter der IP 10.10.1.1 nicht erreichen.

    Aber der Client 10.10.20.55 kann die UDM-Pro unter der IP 10.10.20.1 erreichen.


    Sind wir uns bis hierhin einig?


    Meine Frage ist, was habe ich damit gewonnen?

    Ist es nur ein "Hygenie-Thema", so nach dem Motto aus dem 10.10.20.x Netz darf kein Zugriff auf iwas mit 10.10.1.x erfolgen, auch nicht auf 10.10.1.1- wohl wissend, dass das selbe Device unter 10.10.20.1 dann doch erreichbar ist?

    Oder hat es tatsächlich eine praktische Relevanz, die ich nicht sehe?

  • Aber der Client 10.10.20.55 kann die UDM-Pro unter der IP 10.10.20.1 erreichen.

    Nein, ich kann da werde mein UXG-Pro erreichen, noch den Selfhost-Controller auf Proxmox - weder pingbar noch ein Aufruf über den Browser.

    Mag sein das es bei der UDM/P/SE so ist, beim USG-Pro 4 was ich vorher hatte und auch beim UXG-Pro ist es nicht so wie von dir hier beschrieben und die haben ja auch beide zumindest mal Webinterfaces.

    Gruß

    defcon

  • Ok, dann haben wir da einen Unterschied zwischen UDM-SE (mein Gerät) und UXG-Pro.


    Ich werde am WE nochmal exakt die FW-Regel wie im Wiki beschrieben herstellen. (Aktuell habe ich eigene Regeln formuliert, um den Zugriff auf die UDM-SE zumindest auf den Ports 80, 443 und 23 aus den VLANs zu unterbinden).

    Wenn ich das von mir beschriebene Verhalten (weiterhin Zugriff auf das Web-UI und ssh aus den VLANs über die dem VLAN "zugewandte" IP-Adresse) reproduzieren kann, sollte man den Artikel im Wiki aus meiner Sicht aktualisieren - zumindest was das unterschiedliche Verhalten zwischen UXG-Pro und UDM-SE betrifft.


    Hat die UXG-Pro eigentlich vordefinierte Regeln unter LAN local? Die UDM-SE ist da nämlich blank.

  • Mach doch mal bitte ein paar Screenshots von den Firewall Gruppen, und den Reglen bei LAN Local

    Ich meine da war nix vordefiniert bei LAN Local, ist schon lange her, aber die vordefinierten starten ja im LAN mit 6000er nummern.

    Gruß

    defcon

  • Wir brauchen doch nicht bis zum WE warten. Ich habe ein Youtube Video gefunden, wo genau die Regeln wie im Wiki-Eintrag angelegt werden.

    Video


    Die Vorgehensweise ist wie im Wiki:

    • "established" und "related" erlauben (LAN IN)
    • Inter-VLAN-Kommunikation blockieren (LAN IN)
    • Ab 7:59 sieht man, wie die Gateways geblockt werden (Vorgehensweise haargenau wie im Wiki-Eintrag)
    • Ab 11:33 demonstriert das Video den Effekt:
      • aus einem VLAN können die Gateways der anderen Subnetze nicht mehr erreicht werden
      • sehr wohl aber noch das "eigene" Gateway aus jedem VLAN erreicht werden! (Timestamp 12:12)
    • Ab 12:33 wird ein extra Regel-Set erstellt, um den Zugriff auf http, https und ssh zu unterbinden
    • Ab 14:44 gibt's dann noch ein Regel-Set um auch die Pings auf die eigenen Gateways zu blocken!


    Wie gesagt: die letzten beiden Regel-Sets fehlen im Wiki!

  • Ich hab bei mir persönlich die Firewall nicht nach dem Wiki aufgebaut, bei mir ists ne Eigenlösung und sie funktioniert - hast ja die Screenshots gesehen. Auch ohne SSH & HTTPS Ports... man kommt nicht drauf

    Viele Wege führen halt nach Rom. Gut das es nun alles bei dir klappt, hätten aber sicher anhand von Screenshots den Fehler oder die zusätzlich benötigten Regeln schnell gefunden.

    Gruß

    defcon

  • Ernsthaft jetzt?

    Ich hab bei mir persönlich die Firewall nicht nach dem Wiki aufgebaut, bei mir ists ne Eigenlösung

    Ich eröffne ein Thema, in dem es um den Wiki-Eintrag zu den Firewall-Regeln geht und ich feststelle, dass die Regeln aus dem Wiki unzureichend sind. Und Du widersprichst, obwohl du Wiki-Regeln gar nicht implementiert hast? Respekt.

    Gut das es nun alles bei dir klappt, hätten aber sicher anhand von Screenshots den Fehler oder die zusätzlich benötigten Regeln schnell gefunden.

    Ich hatte bereits im allerersten Post geschrieben, dass ich für mich eine Lösung gefunden hatte. Es ging um das Regelwerk, das im Wiki dokumentiert ist.

  • Punkt 1

    Ich hatte meine Firewall schon ähnlich aufgesetzt gehabt wie es im Wiki steht, bevor es den Eintrag überhaupt gab. Außerdem bin ich nicht verpflichtet, jeden Wiki Eintrag auf Richtigkeit zu prüfen und nachzustellen.


    Punkt 2

    Stell dir vor, ich habe auch LAN Local regeln, aber halt anders umgesetzt… deswegen wollte ich auch Screenshots von dir.


    Punkt 3

    Sorry, dass ich mich nicht in dein Netzwerk geglaskugelt habe!


    Punkt 4

    Sorry, dass ich meine Firewall nicht nach deinen Bedürfnissen umgebaut habe um zu testen.


    Punkt 5

    Hardcopys und Screenshots wären geil gewesen, wäre innerhalb von 5 Minuten gefunden gewesen das Problem.


    Punkt 6

    Bereue es meine kostbare Zeit verschwendet zu haben.


    Punkt 7

    Dann schreib einen Wiki Eintrag dazu.


    Punkt 8

    Du hast auch meinen vollsten Respekt!

    Schönen Abend!


    P.S.

    No offense

    Gruß

    defcon

  • Meine Frage ist, was habe ich damit gewonnen?

    Ist es nur ein "Hygenie-Thema", so nach dem Motto aus dem 10.10.20.x Netz darf kein Zugriff auf iwas mit 10.10.1.x erfolgen, auch nicht auf 10.10.1.1- wohl wissend, dass das selbe Device unter 10.10.20.1 dann doch erreichbar ist?

    Oder hat es tatsächlich eine praktische Relevanz, die ich nicht sehe?

    Wie soll dein Device mit 10.10.20.x ins Internet kommen, wenn es nicht das Gateway .20.1. erreicht ?


    Das 10.10.20.x kein Device in 10.10.10.x erreicht, ist ja in den meisten Fällen gewollte - Inter-VLAN Kommunikation verhindern genannt, ansonsten kann man sich mit den VLAN's auch direkt sparen.

    Will du ein Device von 10.10.20.x in 10.10.10.x erreichen, muss du das erlauben.


    Das ein Device aus 10.10.20.x. aber per ssh oder https auf die UDM kommt mit 10.10.20.1 ist dann ein Designfehler des Firewallsystem von Unifi

    Bei meiner Firewall geht das definitiv nicht, da ich jeden Zugriff auf die Firewall selber per ssh oder https explizit per Regel freischalten muss und zwar für jedes VLAN und das ist auch richtig so.

  • Das ein Device aus 10.10.20.x. aber per ssh oder https auf die UDM kommt mit 10.10.20.1 ist dann ein Designfehler des Firewallsystem von Unifi

    Wie gesagt, bei mir ist es nicht so… wenn dann müsste ich es explizit freigeben. Ich klinke mich hier aber auch aus.

    Gruß

    defcon

  • Wie gesagt, bei mir ist es nicht so… wenn dann müsste ich es explizit freigeben. Ich klinke mich hier aber auch aus.

    Das man es freigeben muss - erwarte ich auch so.

    Da ich keine Unifi-FW nutzen, kann ich mich auch nicht mehr so richtig dran erinneren, wie das bei meiner UDMPro war.

  • Punkt 1

    Ich hatte meine Firewall schon ähnlich aufgesetzt gehabt wie es im Wiki steht, bevor es den Eintrag überhaupt gab. Außerdem bin ich nicht verpflichtet, jeden Wiki Eintrag auf Richtigkeit zu prüfen und nachzustellen.

    Natürlich bist Du nicht dazu verpflichtet. Hat Dich keiner gezwungen, hier zu antworten.

    Zitat

    Punkt 2

    Stell dir vor, ich habe auch LAN Local regeln, aber halt anders umgesetzt… deswegen wollte ich auch Screenshots von dir.

    Wieso Screenshots von mir, wenn es immer um die Firewall-Regeln ging, die im Wiki beschrieben sind - mit Screenshots.

    Zitat

    Punkt 3

    Sorry, dass ich mich nicht in dein Netzwerk geglaskugelt habe!

    Kein Ding. Es ging ja auch nie um mein Netzwerk, sondern (Achtung: Wiederholung!) um den Wiki-Eintrag

    Zitat

    Punkt 4

    Sorry, dass ich meine Firewall nicht nach deinen Bedürfnissen umgebaut habe um zu testen.

    Auch das hat niemand verlangt.

    Zitat

    Punkt 5

    Hardcopys und Screenshots wären geil gewesen, wäre innerhalb von 5 Minuten gefunden gewesen das Problem.

    Der Wiki-Eintrag (um den es die ganze Zeit ausschließlich ging) ist bestens dokumentiert mit Screenshots.

    Zitat

    Punkt 6

    Bereue es meine kostbare Zeit verschwendet zu haben.

    dito

    Zitat

    Punkt 7

    Dann schreib einen Wiki Eintrag dazu.

    Du wirst lachen - das war meine ursprüngliche Intention. Doch die Lust dazu, ist mir gehörig vergangen.

    Was denn dann, wenn es keine "offense" sein soll?


    Du hast echt ne merkwürdige Art. Aber Du liest ja hier nicht mehr mit.

  • Wie soll dein Device mit 10.10.20.x ins Internet kommen, wenn es nicht das Gateway .20.1. erreicht ?


    Das 10.10.20.x kein Device in 10.10.10.x erreicht, ist ja in den meisten Fällen gewollte - Inter-VLAN Kommunikation verhindern genannt, ansonsten kann man sich mit den VLAN's auch direkt sparen.

    Will du ein Device von 10.10.20.x in 10.10.10.x erreichen, muss du das erlauben.

    Dass 10.10.20.x das Gateway 10.10.20.1 erreichen muss, ist klar. Auch dass ich i.d.R. keine Inter-VLAN-Kommunikation möchte, habe ich nie bestritten.

    Zitat

    Das ein Device aus 10.10.20.x. aber per ssh oder https auf die UDM kommt mit 10.10.20.1 ist dann ein Designfehler des Firewallsystem von Unifi

    Bei meiner Firewall geht das definitiv nicht, da ich jeden Zugriff auf die Firewall selber per ssh oder https explizit per Regel freischalten muss und zwar für jedes VLAN und das ist auch richtig so.

    Das ist genau mein Punkt: So wie die UDM designt ist und das was der Wiki-Artikel an Standard Firewall Regeln beschreibt, führt zu der Konstellation, dass ein Device 10.10.20.x zwar nicht mehr auf 10.10.1.1 oder 10.10.10.1 zugreifen kann, aber er kann über 10.10.20.1 per ssh und Web-UI zugreifen.

    Der Wiki-Artikel beschreibt also eine - sagen wir mal - unvollständige Lösung. Um den Designfehler, wie Du ihn nennst, der UDM zu kompensieren, braucht's halt noch 1-2 Regeln, um zumindest die Ports 80, 443 und 23 zu verrammeln.

  • Komisch das es 99% der Leute mit ner UDM/P/SE validiert, mit Test umgesetzt bekommen, du aber nicht. Es hat vor dir keine Beschwerden gegeben, das wundert mich schon ziemlich, vor allem wenn man bedenkt, wie alt der Wiki Eintrag ist! Entweder vertrauen alle Blind aufs Wiki, oder keiner testet valide, was ich mir aber bei unserer Community kaum vorstellen kann, da hier alle ziemlich bedacht sind und sich Gedanken machen.


    No Offense weil:

    Es führen viele Wege nach Rom, selbst wenn nur die Stadtgrenze erreicht wird! (sagte ich bereits) und wenn man etwas anders umsetzt, als im Wiki beschrieben, kann trotzdem die Funktion erfüllt werden! Vielleicht sogar besser, wer weiß?! Jedenfalls brauche ich kein SSH, HTTPS oder HTTP zu sperren - ich miss es explizit freigeben… vielleicht mache ich auch was beim Firewalling falsch 😑 bitte korrigiert mich!

    Wieso Screenshots von mir, wenn es immer um die Firewall-Regeln ging, die im Wiki beschrieben sind - mit Screenshots.

    weil du gesagt hast, das dass Wiki "falsch" ist und das müssen wir prüfen und evtl. korrigieren!


    Kein Ding. Es ging ja auch nie um mein Netzwerk, sondern (Achtung: Wiederholung!) um den Wiki-Eintrag

    schon irgendwie, weil du hast ja ein Fehlverhalten festgestellt, bzw. einen Fehler entdeckt


    Du wirst lachen - das war meine ursprüngliche Intention. Doch die Lust dazu, ist mir gehörig vergangen.

    Dann tu es und Helfe anderen!


    Du hast echt ne merkwürdige Art. Aber Du liest ja hier nicht mehr mit.

    Jetzt ists persönlich, aber ist ok! Ich lese sehr wohl überall mit!

    Ich versuche immer da zu helfen, wo ich kann, wie gesagt, vielleicht haben wir uns hier missverstanden oder aneinander vorbeigeredet, wie auch immer!




    P.S.S.

    Wir sind hier ne sehr friedlich Community, also lass uns dabei bleiben, alle wollen "nur" helfen - manchmal kommt es auch zu Missverständnissen.


    Ich hatte mir eh schon vorgenommen, aber leider fehlt mir im Moment die Zeit um eine gute Anleitung zum Thema erweitertest Firewalling oder FW 2.0 zu schreiben...

    Gruß

    defcon