Guest User!

You are not Sophos Staff.

This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Remote Access SSL - Best Practice beim Regelwerk

Hallo zusammen, 

es gibt ja mehrer Möglichkeiten Usern den Zugriff ins LAN zu erlauben und diesen zu reglementieren. Wie handhabt ihr das?

Mein Gedanke war:

- Einwahl via SSL
- Für Usergruppen SSL Profile hinterlegen, so wird klar getrennt wer was darf. 
- Wenn nun noch Differenzierungen innerhalb der Gruppen benötigt werden, so würde ich dies in der Firewall über Regeln definieren. Z.B. darf nicht der ganze VPN-Pool auf Maschine1 via RDP zugreifen, dann kann man entweder via Gruppe oder mit einzelnen Usernamen arbeiten, um den Zugriff zu erlauben oder zu verbieten.


- Alternativ wäre, ich erstelle nur ein SSL Profil und regel alles über die Zugehörigkeit der User zu bestimmten Gruppen und Firewall Regeln.

Was meint ihr? Welchen Weg sollte ich wählen?


This thread was automatically locked due to age.
  • Hi tetris,

    Also wenn die User auch Domain User sind, dann würde ich wie folgt vorgehen.
    Wenn nicht, dann lokale UTM User anlegen und in Gruppen packen.

    Im AD Gruppen anlegen oder lokale auf der UTM

    SSL VPN Profile anlegen - AD Gruppen hinzufügen oder halt lokale UTM User - Zugriff ins VLAN erlauben - Haken bei "Automatische Firewallregeln" raus

    Dann Firewallregeln erstellen, wohin Zugriff sein soll, vergiss nicht DNS, leider ist das (warum auch immer, immer noch nicht Profilabhängig!!! Nebenbei @Entwicklung: bitte ändern!)

    Aber wenn bereits Zugriff auf ein Host im Netzwerk da ist, dann löst man das nur mit VLANs, sonst ist er im LAN.

    Nice greetings
  • Hallo, 

    SSL VPN Profile anlegen - AD Gruppen hinzufügen oder halt lokale UTM User - Zugriff ins VLAN erlauben - Haken bei "Automatische Firewallregeln" raus

    Genau so mache ich es und definiere dann die entsprechenden Firewall Regeln.
    (User1 darf RDP auf Host1 oder analog eben mit Gruppen)
    Man könnte aber ja auch allen VPN Usern Zugriff auf alle Netze geben und nur noch via Firewall regel Zugriffe defnieren. Dann müsste man gar keine SSL Profile erstellen, das wäre der Gedanke.


    Aber wenn bereits Zugriff auf ein Host im Netzwerk da ist, dann löst man das nur mit VLANs, sonst ist er im LAN.

    --> Was meinst Du hier genau?

    Dann Firewallregeln erstellen, wohin Zugriff sein soll, vergiss nicht DNS
    --> Warum DNS? Würden dann nicht alle Anfragen von außen (auch lokales http z.B.) primär an den DNS des VPN gesendet? Das DNS ist doch nur interessant, wenn ich z.B. RDP via Hostname aufrufen möchte.

    Danke!
  • Hallo, 

    SSL VPN Profile anlegen - AD Gruppen hinzufügen oder halt lokale UTM User - Zugriff ins VLAN erlauben - Haken bei "Automatische Firewallregeln" raus

    Genau so mache ich es und definiere dann die entsprechenden Firewall Regeln.
    (User1 darf RDP auf Host1 oder analog eben mit Gruppen)
    Man könnte aber ja auch allen VPN Usern Zugriff auf alle Netze geben und nur noch via Firewall regel Zugriffe defnieren. Dann müsste man gar keine SSL Profile erstellen, das wäre der Gedanke.


    Ich erstelle SSL-VPN Profile und trage dann das Netzwerk ein, dies wird für das Setzten der Routen verwendet. Wichtig: Haken bei "Automatische FW Regeln" deaktivieren.
    Firewallregel (Beispiel):
    Allow: "Dienstleister User (Network)" - RDP - Server 1 (192.168.2.10/24)
    Allow: "Dienstleister User (Network)" - DNS - DNS Server (192.168.1.15/24)

    Das mit den SSL-VPN Profilen mache ich aus dem Grunde sehr granular, weil ich ja die Hoffnung habe, hier zukünftig DNS Einstellungen für jedes Profil machen zu können. Daher will ich diese Profile nutzen. Außerdem sieht es logischer aus [;)]


    Aber wenn bereits Zugriff auf ein Host im Netzwerk da ist, dann löst man das nur mit VLANs, sonst ist er im LAN.

    --> Was meinst Du hier genau?


    Falls ein Dienstleister auf einen Server drauf muss und du möchtest sicherstellen, dass der in dem Produktiv LAN kein "Mist" baut, erstelle ich dafür ein seperates VLAN --> nenn es DMZ, wo der Server dann drin ist.


    Dann Firewallregeln erstellen, wohin Zugriff sein soll, vergiss nicht DNS
    --> Warum DNS? Würden dann nicht alle Anfragen von außen (auch lokales http z.B.) primär an den DNS des VPN gesendet? Das DNS ist doch nur interessant, wenn ich z.B. RDP via Hostname aufrufen möchte.

    Danke!


    Korrekt, an den DNS des VPNs und diesen kannst du nur einmal global Einrichten und was ist, wenn du in das Netz gar kein Zugriff hast bzw. haben darfst, dann geht DNS nicht.

    Die UTM selbst ist nur Forwarder und hat keinen eigenen DNS Server.
    Stell dir vor, du hast vier Subnetzte oder mehrere Domänen hinter einer UTM.

    Mitarbeiter 1 - soll nur ins Produktiv LAN
    Mitarbeiter 2 - soll nur ins Marketing LAN
    Dienstleister 1 - soll nur auf eine bestimmte Maschine
    Dienstleister 2 - soll nur auf Share Point in der DMZ

    Untereinander haben die Netzwerke nicht unbedingt Zugriff und ggf. auch separate DNS Server.

    Ich habe Anwendungen die z.B. nur mit einem Hostnamen funktionieren.
    server1.firma.local 
  • Die Profile können auch sinnvoll sein, wenn man selektiv VPN Zugänge deaktivieren möchte oder nur auf Anfrage aktivieren.

    Aber das mit dem VLAN ist recht sinnfrei, wenn der Server trotzdem im LAN steht - ansonsten bräuchte man kein VLAN. Sobald der DL auf dem Zielsystem gelten eben nur noch dessen "Beschränkungen".
  • Ich bevorzuge es für Unternehmenszugehörige mit AD-Gruppen zu arbeiten, welchen dann Firewallregeln zugewiesen werden (Group Network). Profil ist hier ein Einziges mit allen Netzen.

    Für Dienstleister gibt es dann Firewallregeln mit User Network. Hier verwende ich übrigens recht oft die Einwahl via L2TP, da der ein oder andere sich den SSL-VPN-Client nicht installieren möchte.

    Eine Vielzahl von Profilen nutze ich eher selten da die Firewall Alles regeln kann.
    Eigentlich nur interessant wenn man dem Einwählenden nicht gleich alle Netze verraten möchte.

    DNS kann man übrigens auch über statische Einträge direkt in der UTM regeln, wenn man kein vollständiges Forewarding haben möchte, denn die UTM hat sehr wohl eine DNS-Funktionalität. Dann darf allerdings auch die bedingte DNS-Weiterleitung nicht aktiv sein.
    Aber ich stimme dem voll und ganz zu - es wäre ideal, wenn man den Profilen unterschiedliche DNS-Einstellungen geben könnte.

    Grüße
    Sebastian
  • Irgendwie stelle ich gerade fest, dass die SSL Profile lediglich kosmetisch Netze verstecken, aber niemanden aussperren.

    Wenn ich das Netz kenne, dann kann ich einfach Routen hinzufügen.

    Beispiel: Ein User bekommt nur 192.168.0.0/24 gepusht durchs SSL Profil, dann kann ich mit route add 192.168.1.0/24 usw.. auch die Route anlegen... 

    So kann man dann sich selber Zugriff in die Netze bauen. 

    An einer Firewall Regel führt also kein Weg vorbei!
  • Ich denke mal, das wenn du 192.168.0.0/24 als Zielnetz einträgst und den Auto-Firewall-Regel-Haken drin hast, wird auch nur eine Regel mit dem Zielnetz 192.168.0.0/24 erzeugt. Von daher sollte es egal sein, welche zusätzliche Routen der Client sich noch reinbastelt - solltest du aber sicherheitshalber test/verifizieren.

    Davon abgesehen bin ich selber aber auch ein Feund von manuell angelegten Firewall Regeln.

    Gruß
    Manfred
  • Das mag sein, aber mit den automatischen Regeln darf der User dann ja z.B. auch SMB. Wenn ich nur RDP zulassen möchte muss ich so oder so regeln definieren. 

    Somit macht glaube ich für mich Profil+autom. Regeln gar keinen Sinn [:(]
  • An einer Firewall Regel führt also kein Weg vorbei!

    Niemals nie nicht! Hast Du das in Frage gestellt?
  • Gehofft hatte ich es ;-)

    Also dass man (sinngemäß) definieren kann --> VPN Pool darf RDP nach Any-Network.

    Einschränken kann man es dann über die SSL Profile.
    Geht aber ja nicht, da Routen ja manuell hinzugefügt werden könnten.

    Also bleibt nur --> SSL Profil und Usergruppe und dann Regel --> Gruppe darf RDP auf Network-für-die-Gruppe
Share Feedback
×

Submitted a Tech Support Case lately from the Support Portal?