FW-Regel soll ssh auf eine IP verbieten -- läuft aber nicht

[white_rabbit]

Hallo.
Ich habe versucht, eine Regel zu erstellen, die in dem WiFi-Netz den Zugriff per ssh auf den Controller verbieten soll. Diese Regel habe ich bei den Regeln zum WiFi ganz nach oben gesetzt und so angelegt:

Code Select Expand


Ablehnen:
Protokoll      Quelle     Port     Ziel                Port   Gateway Zeitplan Beschreibung
IPv4 TCP/UDP   WiFi-Netz   *       IP des Controllers   22     *      *        ssh Zugriff soll auf Controller verboten sein


Leider greift sie nicht -- ich komme weiterhin per ssh auf den Controller. 
Liegt das daran, dass die IP des Controllers im gleichen Netz liegt? Oder wie muss die Regel richtig lauten?
Eine andere Regel scheint ja weiterhin Vorrang zu haben?
Danke für einen guten Tipp.

[mike69]

Hallo.

Zeig mal die kompletten Rules.

[white_rabbit]

Ok, hier alle Regeln ... die erste Regel greift nicht (weder eingehend noch ausgehend) -- ich vermute, weil die FW hier gar nicht im Spiel ist?!


Das WiFi-Netz lautet 172.16.0.0/16

... sehe gerade: Kann es auch sein, dass es mit einer "Anti-Lockout-Regel für SSH"
zusammenhängt? Die dürfte es aber nur im LAN und nicht im WiFi-Netz geben?

[CoolTux]

Wer oder was ist "der Controller"? Wenn es nicht die Firewall selbst ist dann geht es nicht wenn beide im selben Netz sind. Logisch dann geht es an der Firewall vorbei da beide direkt miteinander kommunizieren.

[white_rabbit]

"der Controller" ist eine VM, auf der der Unifi-Controller läuft -- also die Software, die die AccessPoints steuert. Die läuft (notgedrungen?) im gleichen Netz wie die Accesspoints und die Clients, die sich mit den AccessPoints verbinden. Zumindest ist mir kein Weg bekant, wie/ob man das trennen kann?
Daher wollte ich den AccessPoints aber keinen SSH-Zugriff auf den Controller gewähren.
Ich könnte natürlich eine Software-FW auf dem Controller selbst aktivieren und es dort verbieten -- aber schöner wäre es natürlich, wenn alles zentral an einer Stelle wäre...

[CoolTux]

Ok verstehe.
Also Controller und AP müssen in der Tat im selben Netz sein. Die Clients allerdings nicht, das ist Unsinn.
Ich habe meinen Controller im 10.6.4.x und das Management Interface des AP auch, meine Clients hingegen sind im 10.6.9.x oder im 10.6.120.x oder im 10.6.34.x er Netz.

[white_rabbit]

hmmm -- dann musst du mir erklären, wie ein Gastportal / Hotspot-Funktion / Captive-Portal von Unifi funktioniert, wenn die Clients nicht auf den Controller zugreifen können??

[CoolTux]

Warum sollten die Clients denn auf den Controller zugreifen? Ausnahme Captive-Portal.
Der Controller bekommt seine Infos vom AP. Also wer ist seit wann und wie am AP angemeldet. Die Clients reden gar nicht mit dem Controller. Ausnahme Gastnetz mit Portal-Anmeldung.

[white_rabbit]

Also wir lassen hier mehrere WiFi-Netze mit verschiedenen Aufgaben über die gleichen APs laufen. Eins davon ist für Gäste und funktioniert mit einem Voucher-System. Meines Wissens müssen diese Clients auf die Weboberfläche des Controllers umgleitet werden. Wenn der also in einem anderen Netzwerk ist, finden die Clients ihn nicht ...
Unter normalen Umständen *sollen* die clients natürlich gar nicht auf den Controller zugreifen -- weder per https noch per ssh. Aber mit Voucher bzw Portalseite ist es unumgänglich, fürchte ich?!

[CoolTux]

Es gibt etwas das nennt sich Routing. Und wenn man dann noch an der Firewall den Zugriff erlaubt klappt das auch mit dem Aufruf des Portals aus einem anderen Netz heraus. Voraussetzung ist natürlich eine physische Verbindung. Am "richtigsten" macht man sowas mit VLANs.

[white_rabbit]

Also "Routing" ist im Controller selbst nicht aktivierbar, wenn man kein UGS einsetzt. Wir haben einen Layer3-Router von Cisco, der das dann übernehmen müsste -- die einzutragenden Regeln sind mir aber nicht 100%ig klar. Oder meintest  du das so, dass die Route in der OPNSense FW hinzugefügt werden müsste?

[CoolTux]

Also im Normalfall ist die OPNsense ja der Mittelpunkt der hier besprochenen Netze. Dadurch ist jedes Netz in der Firewall (OPNsense) vertreten und kann dann entsprechend reguliert werden.

[white_rabbit]

Na gut, nehmen wir mal an, ich würde den Controller aus dem Adressbereich, den die Clients bekommen, herausnehmen ...
Im Moment hat der Controller die IP 172.16.16.253,
        die OpnseseFW im WLAN die IP 172.16.16.254
und die Clients erhalten per DHCP (auf OPNSense für dieses Netz aktiviert) den
Bereich 172.16.0.0/21

Nehmen wir mal an, dass der Controller da raus soll und z.B. die IP 10.16.1.4 bekommen soll (eine Adresse im LAN) -- was dann? Würde es reichen, unter OPNSense eine statische Route für 172.16.0.0 -> 10.16.1.4 anzulegen  Welches Gateway?

[CoolTux]

Ich beantworte Dir gerne die Fragen. Aber ohne Dir da jetzt zu nahe treten u wollen und im vollen ernst. Wenn Du diesbezüglich kein Grundwissen hast (Netzwerktechn.) empfehle ich da lieber jemanden zu beauftragen. Ansonsten kann das ganze Sicherheitstechn. voll in die Hose gehen.

Also unter der Voraussetzung das physisch alle Fäden an der Firewall zusammen laufen ist das Gateway bei allen Clients immer die IP der Firewall. Die Firewall hat statische Routen für alle eingerichteten Netze die sie selber hat. Also selbst eine IP trägt egal ob physisch oder virtuell.


Grüße

[white_rabbit]

Hi. In deinem letzten Satz ist ein typo -- ist so nicht zu verstehen.
Ich frage mich, welches Sicherheitsrisiko größer ist: zusätzliche Route setzen oder Controller einfach in dem WLAN lassen?