Firewall-Regeln im USG anpassen

[flo222]

Hallo zusammen,

mein Junior wollte unbedingt seinen eigenen Minecraft-Server, also hat er sich einen Raspberry Pi gekauft, und ich hab ihm alles für den Minecraft-Server drauf gepackt, funktioniert auch problemlos.

Damit er auch mit seinen Kumpels zocken kann, habe ich den Raspberry noch von außen mittels Portweiterleitung und DynDNS erreichbar gemacht, auch das funktioniert perfekt.

Allerdings ist damit natürlich auch erst einmal ein potentielles Einfallstor im Netzwerk, d.h. ich hab ein eigenes VLAN angelegt, in dem einzig der Raspberry hängt. Dieses VLAN ist auf einen definierten Port im Switch getagged. Ich hatte vorher schon VLANs, aber diese waren untereinander durchlässig. Das neue VLAN habe ich deswegen mit mehreren Regeln nach folgendem Muster in Richtung der anderen VLANs geblockt:



Damit ist nun zumindest das VLAN 30 (der Minecraft-Server) geblockt, und von dort kann nicht auf die anderen VLANs (10, 20, 77) zugegriffen werden. Die o.g. Regel gibt es insgesamt drei Mal.

Jetzt muss ich allerdings ja vom PC (im VLAN 77) per PuTTY von Zeit zu Zeit auf den Raspberry zugreifen können. Deswegen habe ich über den oberen Regeln noch folgende Regel eingeführt, mit der ich nun mittels SSH auf den Raspberry zugreifen kann:



Nun allerdings meine Bedenken: die letzte Regel sagt ja, dass das Minecraft-VLAN auf meinen PC zugreifen darf. Allerdings heißt das ja auch, dass es darauf zugreifen kann, wann immer ich den PC anhabe. Damit habe ich ja wieder ein potentielles Einfallstor. Ich würde aber gerne die umgekehrte Variante, nämlich dass ich das Recht habe, vom PC aus in das VLAN 30 zu dürfen, und ich dann auch eine Antwort bekomme. Aber das VLAN per se soll erst einmal nicht auf meinen PC kommen, sofern kein Aufruf von diesem erfolgt. Ein einfacher Tausch von Quelle und Ziel in der o.g. Regel führt aber nicht zum gewünschten Erfolg.

Hat jemand ne Idee, wo ich den Gedankenfehler habe?

 

[shag]

Deine oberen Regeln kannst du zusammenfassen (Option2). Zu deiner Frage, siehe Option3 beides hier beschrieben:

https://help.ui.com/hc/en-us/articl...USG-Firewall-How-to-Disable-InterVLAN-Routing

 

[flo222]

Genau nach der Anleitung bin ich vorgegangen. Ich hab nur nicht mit den Gruppen gearbeitet, da es mit drei Regeln im Endeffekt genauso schnell geht. Aber kann ich ja noch feinjustieren.

Die Option 3 habe ich probiert, aber hat nicht geklappt. Deshalb hab ich auch erst die andere Variante erstellt. Muss ich heute noch mal testen, warum es nicht ging.

 

[shag]

Du hast einzelne Paketoptionen aktiviert in der Block-Regel, halte dich stattdessen am besten auch an die Anleitung.

Den SSH Zugriff erlauben beinhaltet 3 Regeln:
1. Port 22 für MC Server als Ziel erlauben
2. Hergestellte+Zugehörige Verbindungen in die andere Richtung erlauben
3. VLANs gegenseitig blocken.

In der Reihenfolge.

Gruß

 

[flo222]

Den SSH Zugriff erlauben beinhaltet 3 Regeln:
1. Port 22 für MC Server als Ziel erlauben
2. Hergestellte+Zugehörige Verbindungen in die andere Richtung erlauben
3. VLANs gegenseitig blocken.

Jetzt muss ich nochmal zu den einzelnen Punkten nachfragen:

1. Ich habe nun drei Gruppen erstellt. In der einen Gruppe sind die PCs, in der nächsten ist nur die IP des Minecraft-Servers enthalten (Minecraft Server Adresse), in der anderen ist nur der Minecraft-Port 22 enthalten (Minecraft Server Port). Hierzu habe ich folgende Regel erstellt:


2. Die zugehörigen Verbindungen vom Management LAN (in dem die PCs hängen) auf das MC-VLAN habe ich nach meinem Verständnis mit folgender Regel freigegeben:


3. Ich habe alle privaten IP-Ranges gemäß der Anleitung in eine Gruppe gepackt, und nun alle VLANs gegenseitig voneinander geblockt:


Damit sollte nach meinem Verständnis ja der Zugriff vom PC via PuTTY auf den Raspberry klappen. Alle Regeln sind in aktiviert, und von der Reihenfolge her so wie oben aufgeführt. Leider komme ich aber nun nicht mehr auf den Raspberry.

Außerdem habe ich insbesondere mit der dritten Regel noch so meine Probleme. Diese blockt alle VLANs untereinander, aber ich wollte eigentlich nur das VLAN30 den Zugriff auf den Rest verweigern (und gerne auch umgekehrt). Die anderen VLANs sollen aber gerne durchlässig sein. Hier finden sich die ganzen IoT-Sachen, und die kann ich dann ja auch nicht mehr steuern. Und ja, mir ist schon klar, dass der Mehrwert eines VLANs bei Durchlässigkeit nicht gegeben ist, aber ich will jetzt nicht 20 Baustellen, sondern erst einmal das eine Problem lösen, bevor ich das nächste angeh.

Grüße
Flo

Ergänzung (7. November 2020)

So, ich hab jetzt mal weiter rumprobiert, und mit folgenden beiden Regeln läuft es jetzt so wie ich es mir vorstelle:



Damit komme ich nun mittels PuTTY vom PC auf den Raspberry. Wenn ich vom PC aus Pings absetze, kann ich das komplette Netzwerk anpingen.

Wenn ich auf dem Raspberry bin, kann ich zwar problemlos den Raspberry selbst oder auch die 8.8.8.8 anpingen, sobald ich aber versuche, eine IP aus meinem eigenen Netzwerk anzupingen, scheitert das an einer Zeitüberschreitung.

Da das Thema für mich jetzt aber nicht unbedingt eines ist, mit welchem ich mich täglich befasse, wollte ich nachfragen, ob ich was wichtiges übersehen habe.

Grüße
Flo

 

[Raijin]

Ich komme leider erst jetzt dazu zu antworten, weil mir das auf dem Handy zu anstrengend war

Die Connection States hast du ja nun schon gefunden, ich möchte nur noch kurz ein paar Hintergrundinfos dazu liefern. Eine Connection wird stets vom Router getracked. D.h. das USG merkt sich anhand der verschiedenen Pakettypen (zB SYN für eine Verbindungsanfrage) in welchem Status eine Verbindung ist.

New - Das ERSTE Paket einer Verbindung (SYN), wirklich nur das erste
Established - Alles nach dem SYN, wenn selbiges mittels ACK vom Ziel bestätigt wurde
Related - Verbindungen aus vordefinierten Abhängigkeiten (zB FTP Command und Data Verbindungen)
Invalid - Alle Pakete, die nicht zugeordnet werden können bzw. nicht zum State passen


Bei einer DMZ funktioniert das im Prinzip so:

Hauptnetzwerk ---new---> DMZ ---established---> PC
DMZ ---new--->|||||drop||||| PC
DMZ ---new---> www ---established--> DMZ


Dein Ruleset könnte daher so aussehen:

WAN_IN = Standard bzw. vom Setupwizard so oder ähnlich vordefiniert)
1) Allow established/related
2) Drop invalid
3) Allow PortweiterleitungX
4) Default drop

MAIN_IN bzw. WAN_OUT = Standard bzw. vordefiniert
1) Default allow

DMZ_IN
1) Allow established/related
2) Drop invalid
3) Allow dst != VLANx-Subnetz
4) Default drop

Damit darf die DMZ überall hin antworten (1), ungültige Pakete werden gedropped (2), aber neue Verbindungen (alles was 1 und 2 passiert ist zwangsläufig state=new) sind lediglich erlaubt, wenn sie nicht ins Haupt-VLAN gehen. Verbindungsversuche ins Haupt-VLAN fallen durch bis zum default drop. Packt man nun alle relevanten VLANs in eine Gruppe, kann man Regel 3 gegen die Gruppe matchen, also zB "Allow dst != grpMainVLANs".

Theoretisch kann man man Regel 1 auch weglassen (dann aber bei 3 new+related matchen), aber das ist ein gängiger Shortcut, der die Performance erhöht. Ist bei einem kurzen Ruleset zwar vernachlässigbar, aber aus Prinzip baue ich die immer ein damit man das nicht vergisst, wenn es mal relevant werden könnte.