5
Firewall Konfigurationsoptimierung für RRAS VPN
Guten Tag zusammen
Nur kurz vorab: Mir geht es hier nicht darum, eine vorgeschriebene Lösung zu bekommen, sondern um Tipps, Anregungen, wie ich alles besser machen kann. Momentan bin ich mitten in meiner Ausbildung und habe folgendes Projekt am laufen:
Ich werde eine VPN Lösung mittels Microsoft RRAS realisieren, wobei ich RADIUS Netzwerkrichtlinien erstellt habe, zudem eine 2-Fach-Authentifizierung über DUO Mobile geschehen wird.(Authentifizierung über Handynummer mittels Push-Bestätigung).
Die Architektur sieht folgendermassen aus:
Ich habe eine DMZ in der der RRAS-VPN-Server steht. Darauf läuft logischerweise der RRAS-Service selber, wie auch der DUO Mobile Authentifizierungsproxy Service (Dieser baut dann die Verbindung zur DUO Cloud auf, welcher die Push Benachrichtigung rausschickt).
Im LAN ist die Produktive Umgebung. Hier bekommt der VPN-Client eine IP-Addresse zugeteilt. Hier stehen auch alle Server wie DC, Fileserver, Terminalserver und ein weiterer Radius Server, welcher die Netzwerkrichtlinien überprüft.
Nun zur aktuellen Firewallkonfiguration:
Von WAN zur DMZ bestehen aktuell folgende Access Rules:
- L2TP
- IPSEC(ESP) (Wird von L2TP benötigt)
- IKE (Für Schlüsselübertragung bei IPSEC)
- HTTP/S (Für SSTP VPN Verbindung)
Von DMZ zu LAN bestehen aktuell folgende Access Rules:
-Eigentlich gar keine, da ich vom VPN Server aus ins LAN Subnetz alles offen habe, also any any (ich weiss, deshalb bin ich hier...)
Nach draussen, also von LAN oder DMZ ins WAN, habe ich alles offen gelassen.
- Alles funktioniert so, der VPN Client kann sich ins LAN einwählen nachdem der DUO Mobile Push bestätigt wurde. Der VPN Client kann auch ins Internet. Das Ziel wäre nun natürlich die Ports einzuschränken. Und was wäre dann schöner für den "raus-weg"? Sollten die Ports dort auch eingeschränkt werden, oder wendet man das Default-Deny Konzept vor allem für den "rein-weg" an, wenn man in ein Netzwerk kommt?
Nun habe ich mir folgende Überlegungen gemacht, die Firewall "korrekter" zu konfigurieren und zwar folgendermassen:
Von WAN zur DMZ und Rückweg mit folgenden Access Rules:
- L2TP
- IPSEC(ESP) (Wird von L2TP benötigt)
- IKE (Für Schlüsselübertragung bei IPSEC)
- HTTP/S (Für SSTP VPN Verbindung)
- NTP (Für saubere Zeitsynchronisation)
- DNS (Für VPN Clients, Zugriff Internet)
Frage: Wieso kann ich trotzdem RDP machen auf den Terminalserver im LAN machen, ohne dass ich diesen Port freischalten muss?
Von DMZ ins LAN und Rückweg mit folgenden Access Rules:
- LDAP (NPS Authentifizierung und DUO Authentifizierung)
- Kerberos (Bin mir nicht sicher, aber wenn schon LDAP läuft)
- Radius (zwei Radius Server, somit logischerweise wird der Authentifizierungsport benötigt)
- UDP High Ports (Destination Ports bei Radius Source Port, wenn zwischen den Zonen die Authentifizierung übertargen wird)
- DNS (Namensauflösung; Internetzugriff)
- NTP (Saubere Zeitsynch.)
- HTTP/S (Internetzugriff)
So das wäre so meine Idee, wie ich das Umsetzen würde. Ich würde mich über Verbesserungsvorschläge, Tipps, Anregung/Bemerkungen freuen und natürlich dürft Ihr mich auch besser belehren, freue mich nur über ein Feedback!!
Ganz liebe Grüsse und viel Kraft während dieser Corona Zeit
Sara
Nur kurz vorab: Mir geht es hier nicht darum, eine vorgeschriebene Lösung zu bekommen, sondern um Tipps, Anregungen, wie ich alles besser machen kann. Momentan bin ich mitten in meiner Ausbildung und habe folgendes Projekt am laufen:
Ich werde eine VPN Lösung mittels Microsoft RRAS realisieren, wobei ich RADIUS Netzwerkrichtlinien erstellt habe, zudem eine 2-Fach-Authentifizierung über DUO Mobile geschehen wird.(Authentifizierung über Handynummer mittels Push-Bestätigung).
Die Architektur sieht folgendermassen aus:
Ich habe eine DMZ in der der RRAS-VPN-Server steht. Darauf läuft logischerweise der RRAS-Service selber, wie auch der DUO Mobile Authentifizierungsproxy Service (Dieser baut dann die Verbindung zur DUO Cloud auf, welcher die Push Benachrichtigung rausschickt).
Im LAN ist die Produktive Umgebung. Hier bekommt der VPN-Client eine IP-Addresse zugeteilt. Hier stehen auch alle Server wie DC, Fileserver, Terminalserver und ein weiterer Radius Server, welcher die Netzwerkrichtlinien überprüft.
Nun zur aktuellen Firewallkonfiguration:
Von WAN zur DMZ bestehen aktuell folgende Access Rules:
- L2TP
- IPSEC(ESP) (Wird von L2TP benötigt)
- IKE (Für Schlüsselübertragung bei IPSEC)
- HTTP/S (Für SSTP VPN Verbindung)
Von DMZ zu LAN bestehen aktuell folgende Access Rules:
-Eigentlich gar keine, da ich vom VPN Server aus ins LAN Subnetz alles offen habe, also any any (ich weiss, deshalb bin ich hier...)
Nach draussen, also von LAN oder DMZ ins WAN, habe ich alles offen gelassen.
- Alles funktioniert so, der VPN Client kann sich ins LAN einwählen nachdem der DUO Mobile Push bestätigt wurde. Der VPN Client kann auch ins Internet. Das Ziel wäre nun natürlich die Ports einzuschränken. Und was wäre dann schöner für den "raus-weg"? Sollten die Ports dort auch eingeschränkt werden, oder wendet man das Default-Deny Konzept vor allem für den "rein-weg" an, wenn man in ein Netzwerk kommt?
Nun habe ich mir folgende Überlegungen gemacht, die Firewall "korrekter" zu konfigurieren und zwar folgendermassen:
Von WAN zur DMZ und Rückweg mit folgenden Access Rules:
- L2TP
- IPSEC(ESP) (Wird von L2TP benötigt)
- IKE (Für Schlüsselübertragung bei IPSEC)
- HTTP/S (Für SSTP VPN Verbindung)
- NTP (Für saubere Zeitsynchronisation)
- DNS (Für VPN Clients, Zugriff Internet)
Frage: Wieso kann ich trotzdem RDP machen auf den Terminalserver im LAN machen, ohne dass ich diesen Port freischalten muss?
Von DMZ ins LAN und Rückweg mit folgenden Access Rules:
- LDAP (NPS Authentifizierung und DUO Authentifizierung)
- Kerberos (Bin mir nicht sicher, aber wenn schon LDAP läuft)
- Radius (zwei Radius Server, somit logischerweise wird der Authentifizierungsport benötigt)
- UDP High Ports (Destination Ports bei Radius Source Port, wenn zwischen den Zonen die Authentifizierung übertargen wird)
- DNS (Namensauflösung; Internetzugriff)
- NTP (Saubere Zeitsynch.)
- HTTP/S (Internetzugriff)
So das wäre so meine Idee, wie ich das Umsetzen würde. Ich würde mich über Verbesserungsvorschläge, Tipps, Anregung/Bemerkungen freuen und natürlich dürft Ihr mich auch besser belehren, freue mich nur über ein Feedback!!
Ganz liebe Grüsse und viel Kraft während dieser Corona Zeit
Sara
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 658240
Url: https://administrator.de/contentid/658240
Printed on: April 20, 2024 at 11:04 o'clock
5 Comments
Latest comment
- IPSEC(ESP) (Wird von L2TP benötigt)
Nicht nur das sondern bei L2TP auch noch- UDP 500 (IKE)
- UDP 4500 (NAT Traversal)
- UDP 1701 L2TP Handshaking
Ansonsten soweit alles ok. Grobe Schnitzer gibts nicht.
1
Moin Sara,
Eigentlich ist der Weg für DNS Forwarding genau anders herum, sprich LAN -> DMZ -> Internet. Meist stehen Filtersysteme Pi-Hole oder AdGuard in der DMZ.
Gruß,
Dani
Ich werde eine VPN Lösung mittels Microsoft RRAS realisieren,
welche Lösung genau (IPSEC bzw. L2TP, Direct Access oder Always Vpn On? Alle drei parallel auf einem Server zu realisieren ist technisch nämlich nicht machbar. Das liegt an den Technologien bzw. den Voraussetzungen der jeweiligen Methoden. Ich würde mich ausschließlich auf Always Vpn On konztieren. Damit ist nahe zu sichergestellt, dass die VPN Verbindung an jedem WLAN Hotspot funktionieren wird. Denn der Port 443/tcp ist selten blockiert. Frage: Wieso kann ich trotzdem RDP machen auf den Terminalserver im LAN machen, ohne dass ich diesen Port freischalten muss?
Kann es sein, dass für den Zugriff auf de RDS Hosts ein RD Gateway zum EInsatz kommt? Somit wird der Datenverkehr nicht über 3389 tcp/udp sodnern über 443/tcp abgewickelt. Das widerrum erlaubt dein Regelwerk. - Kerberos (Bin mir nicht sicher, aber wenn schon LDAP läuft)
Aus welchem Grund? Kerberkos nutzt erstmal Port 88/udp. LDAP läuft über Port 389/tcp bzw. hoffentlich bald über 636/tcp. - UDP High Ports (Destination Ports bei Radius Source Port, wenn zwischen den Zonen die Authentifizierung übertargen wird)
Macht aus meiner Sicht ebenfalls keinen Sinn. Radius läuft standardmäßig über Port 1812/tcp und 1813/tcp - je nach Konfiguration. Ich habe auch nochmals bei uns in der Doku nachgeschaut und wir haben keinen anderen Port für RADIUS von DMZx ins LANx offen. - LDAP (NPS Authentifizierung und DUO Authentifizierung)
Hmm, NPS läuft eigentlich wie oben geschrieben über Port 1812/tcp und 1813/tcp. - NTP (Saubere Zeitsynch.)
Mach für mich ebenfalls keinen Sinn. Fallsd du eine Zeitquelle vom Typ Stratum 1 im LAN hast, so gehört diese aus meiner Sicht in die DMZ. Wenn du NTP Server aus dem Internet nutzt, würde ich dazu tendieren, dass das LAN die Uhrzeit direkt von der Quelle im Internet abholt. - DNS (Namensauflösung; Internetzugriff)
Grundsätzlich gilt das Gleiche wie ich bei NTP ausgeführt habe. Warum muss der DNS Zugriff aus der DMZ ins LAN möglich sein?Eigentlich ist der Weg für DNS Forwarding genau anders herum, sprich LAN -> DMZ -> Internet. Meist stehen Filtersysteme Pi-Hole oder AdGuard in der DMZ.
Gruß,
Dani
1
Salut Dani
Danke dir für deinen Beitrag. werde mir das alles noch einmal anschauen!
Gruss
Sara
Danke dir für deinen Beitrag. werde mir das alles noch einmal anschauen!
Gruss
Sara
Danke dir für deine Erklärung!
Gruss
Sara
Gruss
Sara
Grundsätzlich gilt das Gleiche wie ich bei NTP ausgeführt habe.
NTP und DNS müssen (und sollten) auch nicht vom WAN in die DMZ geöffnet sein. Für die VPN Clients so oder so schon gar nicht. Deren DNS oder NTP Requests kommen, wenn überhaupt, ja immer verschlüsselt im IPsec Tunnel so das die Firewall diese gar nicht "sieht" und folglich diese Ports auch nicht offen haben muss. Von den Clients sieht sie ja nur IPsec ESP Traffic sonst nix. Von außen muss keiner auf DMZ oder LAN irgendwelche DNS oder NTP Requests machen, folglich haben diese Ports da auch nichts zu suchen.Von intern gehen NTP oder DNS Requests immer weil die FW ja stateful arbeitet. Wenn, dann sollte man nur die DNS Requests von intern auf den lokalen DNS bzw. dessen Host IP im Regelwerk setzen so das nur der lokale DNS Server nach draussen DNS Requests macht und keiner der Clients um z.B. mit externen DNS den lokalen zu umgehen. Sinnvoll wenn auf dem lokalen DNS Server ein Malware Filtering läuft wie z.B. beim PiHole Konzept.
1
