3
V-Server Windows 2016, RDP und VPN
Guten Morgen ins Forum,
bin neu hier im Forum. Beschäftige mich sonst eher mit MacOS, der Client-Seite und ein wenig Netzwerk, wollte mich jetzt aber auch mal aus der "Deckung" wagen und was neues probieren. Viele bisherige Fragen konnte ich mir anlesen - unter anderem auch hier im Forum. Jetzt habe ich allerdings ein, zwei Verständnisprobleme und hoffe, Ihr könnt mir dabei auf die Sprünge helfen:
Szenario:
V-Server, Windows 2106 Server Standard
Clients sind iOS, ggfs. Windows 10 und MacOS
Zugriff soll erfolgen auf eine dort laufende Software (Access-DB mit Interface) mittels Remote Desktop der kompletten Oberfläche – nicht nur der Software. Der V-Server/Strato hängt offenbar vogelfrei im Netz! Mir ist klar, dass es Vorbehalte dagegen gibt, Maschinen ohne getrennte HW-VPN-Applicance einzusetzen. Das lässt sich zum momentanen Stand aber erstmal nicht ändern. Ggfs. anfallende Daten auf dem Server werden lokal gebackuped und der Server im Notfall zurückgesetzt. Es hängt kein Multimillionen-Dollar-Unternehmen an dem Setup
RDP-Port modifiziert, AutoUpdate aktiviert, Usernamen mod., Standardports großteils geschlossen, Netzwerkauth. aktiviert, 128 bit erzwungen (gpedit, secpol) usw. erfolgt und funktioniert.
Frage 1: Wenn ich VPN (mit festem Schlüssel, manueller Adressvergabe) aktiviere funktioniert das zwar ... aber nur parallel. D.h. mein RDP verbindet auf dem modifizierten Port und ebenso kann ich eine VPN aufbauen und der Server hat weiterhin "Internetzugang". Wie erzwinge ich aber, dass RDP über den Tunnel läuft? Bzw. lass ich den modifizierten RDP-Port "offen"? Dann habe ich ja keine Gewinn an Sicherheit. Vermutlich muss ich das entsprechend routen oder womöglich ebenso den 443 für nutzen?! Bisher habe ich mich erstmal ... ne zweimal erfolgreich "ausgeschlossen" ... was aber bei näherer und fernerer Betrachtung irgendwie plausibel erscheint
Frage 2: Kann ich GRE/PPTP auch deaktivieren? Bisher schließe ich die zwei Ports (47/1723). Ist das "Best Practice"? Die Anmeldungen lassen sich ja nicht auf 0 reduzieren ohne eine Fehlermeldung zu erhalten.
Frage 3: Lokales privates Zertifikat ist im IIS erzeugt und für die VPN auch definiert. Soweit so gut. Nur gebe ich den doch eigentlich nicht aus?! Bzw. wie erzeuge ich einen Public-Schlüssel, den ich dann dem Client bei der VPN-Konfiguration mit auf den Weg gebe?!
Frage 4: Muss in der Firewall – mit Ausnahme der VPN-Ports – am Ende überhaupt noch etwas offen sein? So Sachen wie "Kernnetzwerk" klingen irgendwie wichtig
Soviel zum Thema Selbstoffenbarung
VG aus dem Süden der Republik.
bin neu hier im Forum. Beschäftige mich sonst eher mit MacOS, der Client-Seite und ein wenig Netzwerk, wollte mich jetzt aber auch mal aus der "Deckung" wagen und was neues probieren. Viele bisherige Fragen konnte ich mir anlesen - unter anderem auch hier im Forum. Jetzt habe ich allerdings ein, zwei Verständnisprobleme und hoffe, Ihr könnt mir dabei auf die Sprünge helfen:
Szenario:
V-Server, Windows 2106 Server Standard
Clients sind iOS, ggfs. Windows 10 und MacOS
Zugriff soll erfolgen auf eine dort laufende Software (Access-DB mit Interface) mittels Remote Desktop der kompletten Oberfläche – nicht nur der Software. Der V-Server/Strato hängt offenbar vogelfrei im Netz! Mir ist klar, dass es Vorbehalte dagegen gibt, Maschinen ohne getrennte HW-VPN-Applicance einzusetzen. Das lässt sich zum momentanen Stand aber erstmal nicht ändern. Ggfs. anfallende Daten auf dem Server werden lokal gebackuped und der Server im Notfall zurückgesetzt. Es hängt kein Multimillionen-Dollar-Unternehmen an dem Setup
RDP-Port modifiziert, AutoUpdate aktiviert, Usernamen mod., Standardports großteils geschlossen, Netzwerkauth. aktiviert, 128 bit erzwungen (gpedit, secpol) usw. erfolgt und funktioniert.
Frage 1: Wenn ich VPN (mit festem Schlüssel, manueller Adressvergabe) aktiviere funktioniert das zwar ... aber nur parallel. D.h. mein RDP verbindet auf dem modifizierten Port und ebenso kann ich eine VPN aufbauen und der Server hat weiterhin "Internetzugang". Wie erzwinge ich aber, dass RDP über den Tunnel läuft? Bzw. lass ich den modifizierten RDP-Port "offen"? Dann habe ich ja keine Gewinn an Sicherheit. Vermutlich muss ich das entsprechend routen oder womöglich ebenso den 443 für nutzen?! Bisher habe ich mich erstmal ... ne zweimal erfolgreich "ausgeschlossen" ... was aber bei näherer und fernerer Betrachtung irgendwie plausibel erscheint
Frage 2: Kann ich GRE/PPTP auch deaktivieren? Bisher schließe ich die zwei Ports (47/1723). Ist das "Best Practice"? Die Anmeldungen lassen sich ja nicht auf 0 reduzieren ohne eine Fehlermeldung zu erhalten.
Frage 3: Lokales privates Zertifikat ist im IIS erzeugt und für die VPN auch definiert. Soweit so gut. Nur gebe ich den doch eigentlich nicht aus?! Bzw. wie erzeuge ich einen Public-Schlüssel, den ich dann dem Client bei der VPN-Konfiguration mit auf den Weg gebe?!
Frage 4: Muss in der Firewall – mit Ausnahme der VPN-Ports – am Ende überhaupt noch etwas offen sein? So Sachen wie "Kernnetzwerk" klingen irgendwie wichtig
Soviel zum Thema Selbstoffenbarung
VG aus dem Süden der Republik.
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 458541
Url: https://administrator.de/contentid/458541
Ausgedruckt am: 17.11.2024 um 17:11 Uhr
3 Kommentare
Neuester Kommentar
Zitat von @Visucius:
Frage 1: Wenn ich VPN (mit festem Schlüssel, manueller Adressvergabe) aktiviere funktioniert das zwar ... aber nur parallel. D.h. mein RDP verbindet auf dem modifizierten Port und ebenso kann ich eine VPN aufbauen und der Server hat weiterhin "Internetzugang". Wie erzwinge ich aber, dass RDP über den Tunnel läuft? Bzw. lass ich den modifizierten RDP-Port "offen"? Dann habe ich ja keine Gewinn an Sicherheit. Vermutlich muss ich das entsprechend routen oder womöglich ebenso den 443 für nutzen?! Bisher habe ich mich erstmal ... ne zweimal erfolgreich "ausgeschlossen" ... was aber bei näherer und fernerer Betrachtung irgendwie plausibel erscheint
Du machst dir zu allererst eine zusätzliche Firewall-Regel die den RDP-Port nur über das VPN-Interface oder das private VPN-Subnetz zulässt. Dann richtest du dein VPN ein (L2TP o. IPSec / SSTP & Co.) bloß kein PPTP mehr, das ist unsicher hoch drei und knackt dir jemand in null komma nichts. Die Ports dafür natürlich ebenfalls schließen.Frage 1: Wenn ich VPN (mit festem Schlüssel, manueller Adressvergabe) aktiviere funktioniert das zwar ... aber nur parallel. D.h. mein RDP verbindet auf dem modifizierten Port und ebenso kann ich eine VPN aufbauen und der Server hat weiterhin "Internetzugang". Wie erzwinge ich aber, dass RDP über den Tunnel läuft? Bzw. lass ich den modifizierten RDP-Port "offen"? Dann habe ich ja keine Gewinn an Sicherheit. Vermutlich muss ich das entsprechend routen oder womöglich ebenso den 443 für nutzen?! Bisher habe ich mich erstmal ... ne zweimal erfolgreich "ausgeschlossen" ... was aber bei näherer und fernerer Betrachtung irgendwie plausibel erscheint
Für L2TP o. IPSec oder IKEv2 benötigt werden Ports 4500, 1701(nur bei L2TP) und 500 UDP und ESP "Protokoll" (Nr.50). Wenn hingegenen SSTP genutzt wird wird Port 443 TCP benötigt. ALLE ANDEREN PORTS sind INBOUND zu schließen.
Achtung Reihenfolge einhalten das du dir nicht selbst die Verbindung kappst. Also die Ports erst schließen wenn die VPN Verbindung wasserdicht funktioniert und RDP über die VPN-Verbindung und de zusätzliche Regel funktioniert. Erst dann die RDP Regel die für extern gilt deaktivieren.
Als Backup habe ich für sowas immer einen SSH-Server in der Hinterhand, dann komme ich auch so noch an die Konsole, sollte ich mir selbst die Verbindung gekappt haben. Oder man nutzt die Rettungskonsole wenn es der Anbieter anbietet.
Frage 2: Kann ich GRE/PPTP auch deaktivieren? Bisher schließe ich die zwei Ports (47/1723). Ist das "Best Practice"? Die Anmeldungen lassen sich ja nicht auf 0 reduzieren ohne eine Fehlermeldung zu erhalten.
Sicher wenn kein PPTP genutzt wird was man heutzutage nicht mehr sollte, dicht machen!!Frage 3: Lokales privates Zertifikat ist im IIS erzeugt und für die VPN auch definiert. Soweit so gut. Nur gebe ich den doch eigentlich nicht aus?! Bzw. wie erzeuge ich einen Public-Schlüssel, den ich dann dem Client bei der VPN-Konfiguration mit auf den Weg gebe?!
Ein Zertifikat brauchst du nur wenn du SSTP nutzt oder IPSec durch eine Zertifikatsauthentifizierung absicherst bzw. IKEv2 nutzt. Dazu erstellt man am sich am besten eine kleine CA z.B. auch mit XCA und stellt damit die Zertifikate aus.
Frage 4: Muss in der Firewall – mit Ausnahme der VPN-Ports – am Ende überhaupt noch etwas offen sein? So Sachen wie "Kernnetzwerk" klingen irgendwie wichtig
Damit RDP trotzdem über die VPN Verbindung funktioniert erstellst du ja wie ich dir oben schon geschrieben habe eine Firewall-Regel die den Port nur über ein bestimmtes Subnetz oder einen bestimmten Adapter zulässt.
RDP sollte man niemals offen im Netz verfügbar machen, was man gerade wieder durch die aufgetauchte Lücke sieht.
Wenn ich dir das Grundrauschen im Netz mal zeigen würde würdest du mit den Ohren schlacken wieviele Scans nach RDP stattfinden, auch auf unbekannten Highports finden diese statt d.h. mit dem Verschieben auf einen Highport hat man nur eine trügerische Sicherheit! Also immer schön nur übers VPN zulassen.
Long time no hear
Hallo in die Runde. Jetzt habe ich mich nochmal mit der Thematik auseinandergesetzt. Eine lokale ParallelsVM waren da doch ne riesen Hilfe. Wahrscheinlich prangt in den Logfiles von Strato schon ein roter Punkt neben meinem Vertrag
@139920: Danke für Deine Tipps. Es scheiterte immer am gleichen "Denkfehler". Ich dachte, ich müsste RDP zwingen, dass es durch die VPN geht. Bzw. dass der Port sich innerhalb der VPN magically wieder öffnet, ... sozusagen Feenstaub.
Aber ein Absatz in der weiter unten verlinkten Uni-Rostock-Anleitung half weiter: Innerhalb der VPN bekommen beide Seiten (Server und Client) ja ne eigene IP (bei mir manuell, dabei der Server autom. "die niedrigste") und ich "scope/begrenze" den Firewall-Zugang von RDP später einfach auf diesen (internen) IP-Bereich! So blockt diese FW-Regel Pings an diesen Port mit der öffentlichen VM-Server-IP.
Ist das so richtig?!
Das mit ssh ist ne prima Idee. Sehe aber gerade, dass es mit dem öffnen von Port 22 alleine auf Windows noch nicht getan ist. Ok, das guck ich mir mal bei Gelegenheit genauer an. Coole Sache, kannte ich bisher nur von Linuxspielzeug.
Und weil ich (noch) hoffe, dass auch andere so doof sind wie ich, stelle ich das Vorgehen und Setup hier einfach mal ein zur Diskussion und Hilfe oder zur Abschreckung anderer. Kritik erwünscht:
Strato V-Server Windows Server 2016 V20:
Mit Remote Desktop anmelden
Settings: Updates einspielen - neu starten
Datenträgerverwaltung: C: vergrößern wegen späterer Updates - neu starten
Computerverwaltung: User ändern in admin.hi;
Passwort anpassen; Eigenschaften > Einwählen > gestatten - neu starten
secpol.msc: Lokale\Security\... NTLMv2, lokale User, ... anpassen
siehe: https://www.youtube.com/watch?v=0NoP9X15l5g
gpedit.msc: Computer\Policies\Windows Components\Remote Desktop Services\Remote Desktop Session Host\Security (SSL, Netzwerkebene, RPC), (16 bit, Maxauflösung, Cleartype deakt.), (Neuverbinden, MaxVerbind., Protokolle definiern)
gpedit.msc: Computer\Windows\Sicherheit\Firewall: Port TCP und UDP öffnen (nur nötig, wenn ein modifizierter RDP-Port gewünscht ist)
regedit: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp\PortNumber (nur nötig, wenn ein modifizierter RDP-Port gewünscht ist)
Servermanager: RemoteAccess installieren,
Servermanager > Routing und Remote Access: VPN konfigurieren, Ports für GRE und PPTP reduzieren und da auch "Demand Dial routing" raus, VPN-IPs manuell vergeben, VPN-Schlüssel festlegen, ...
Alle anderen FW-Ports "inbound" schließen (inkl. UDP, inkl. Remote Management, GRE, PPTP) - VPN vom Client aus testen
gpedit.msc: Computer\Windows\Sicherheit\Firewall: Scope des vorhin angelegten RDP-Ports auf vergebene IPs reduzieren
IP bei RDP Client anpassen (IP vom 1. Platz der manuell vergebenen IP-Range)
Computerverwaltung: Ggfs. 2. User anlegen und in die Remote Access Group aufnehmen
Anbei einige Links, die mir geholfen haben. Vieles im Netz bezieht sich ja auf "MS-fremde Firewalls" und andere Strukturen (ADS, Gateways, ...)
https://www.mvps.net/docs/how-to-secure-remote-desktop-rdp/
https://www.wikihow.com/Secure-a-Remote-Desktop
https://www.thomasmaurer.ch/2016/10/how-to-install-vpn-on-windows-server ...
https://www.infrastrukturhelden.de/microsoft-infrastruktur/remote-access ...
https://www.itmz.uni-rostock.de/nd/anwendungen/software/windows/sicherhe ...
Hallo in die Runde. Jetzt habe ich mich nochmal mit der Thematik auseinandergesetzt. Eine lokale ParallelsVM waren da doch ne riesen Hilfe. Wahrscheinlich prangt in den Logfiles von Strato schon ein roter Punkt neben meinem Vertrag
@139920: Danke für Deine Tipps. Es scheiterte immer am gleichen "Denkfehler". Ich dachte, ich müsste RDP zwingen, dass es durch die VPN geht. Bzw. dass der Port sich innerhalb der VPN magically wieder öffnet, ... sozusagen Feenstaub.
Aber ein Absatz in der weiter unten verlinkten Uni-Rostock-Anleitung half weiter: Innerhalb der VPN bekommen beide Seiten (Server und Client) ja ne eigene IP (bei mir manuell, dabei der Server autom. "die niedrigste") und ich "scope/begrenze" den Firewall-Zugang von RDP später einfach auf diesen (internen) IP-Bereich! So blockt diese FW-Regel Pings an diesen Port mit der öffentlichen VM-Server-IP.
Ist das so richtig?!
Das mit ssh ist ne prima Idee. Sehe aber gerade, dass es mit dem öffnen von Port 22 alleine auf Windows noch nicht getan ist. Ok, das guck ich mir mal bei Gelegenheit genauer an. Coole Sache, kannte ich bisher nur von Linuxspielzeug.
Und weil ich (noch) hoffe, dass auch andere so doof sind wie ich, stelle ich das Vorgehen und Setup hier einfach mal ein zur Diskussion und Hilfe oder zur Abschreckung anderer. Kritik erwünscht:
Strato V-Server Windows Server 2016 V20:
Mit Remote Desktop anmelden
Settings: Updates einspielen - neu starten
Datenträgerverwaltung: C: vergrößern wegen späterer Updates - neu starten
Computerverwaltung: User ändern in admin.hi;
Passwort anpassen; Eigenschaften > Einwählen > gestatten - neu starten
secpol.msc: Lokale\Security\... NTLMv2, lokale User, ... anpassen
siehe: https://www.youtube.com/watch?v=0NoP9X15l5g
gpedit.msc: Computer\Policies\Windows Components\Remote Desktop Services\Remote Desktop Session Host\Security (SSL, Netzwerkebene, RPC), (16 bit, Maxauflösung, Cleartype deakt.), (Neuverbinden, MaxVerbind., Protokolle definiern)
gpedit.msc: Computer\Windows\Sicherheit\Firewall: Port TCP und UDP öffnen (nur nötig, wenn ein modifizierter RDP-Port gewünscht ist)
regedit: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp\PortNumber (nur nötig, wenn ein modifizierter RDP-Port gewünscht ist)
Servermanager: RemoteAccess installieren,
Servermanager > Routing und Remote Access: VPN konfigurieren, Ports für GRE und PPTP reduzieren und da auch "Demand Dial routing" raus, VPN-IPs manuell vergeben, VPN-Schlüssel festlegen, ...
Alle anderen FW-Ports "inbound" schließen (inkl. UDP, inkl. Remote Management, GRE, PPTP) - VPN vom Client aus testen
gpedit.msc: Computer\Windows\Sicherheit\Firewall: Scope des vorhin angelegten RDP-Ports auf vergebene IPs reduzieren
IP bei RDP Client anpassen (IP vom 1. Platz der manuell vergebenen IP-Range)
Computerverwaltung: Ggfs. 2. User anlegen und in die Remote Access Group aufnehmen
Anbei einige Links, die mir geholfen haben. Vieles im Netz bezieht sich ja auf "MS-fremde Firewalls" und andere Strukturen (ADS, Gateways, ...)
https://www.mvps.net/docs/how-to-secure-remote-desktop-rdp/
https://www.wikihow.com/Secure-a-Remote-Desktop
https://www.thomasmaurer.ch/2016/10/how-to-install-vpn-on-windows-server ...
https://www.infrastrukturhelden.de/microsoft-infrastruktur/remote-access ...
https://www.itmz.uni-rostock.de/nd/anwendungen/software/windows/sicherhe ...
1
@139920: Frage 3 - der Bahnhof ....
Ich bin soweit gekommen, dass ich über den ILS ein lokales/privates Zertifikat angelegt habe. Das liegt jetzt auf dem Server. Und ich kann dieses Zertifikat auch im RAS bei den VPN-Einstellungen auswählen (anstelle vom Schlüssel). Nur denke ich, irgendwie muss dieses Zertifikat doch auch beim VPN-Client landen?! Sonst können die das doch nicht abgleichen?!
Und im dem Zusammenhang war mir das PGP-Thema mit privaten und öffentlichen Schlüsseln in den Sinn gekommen ...
Eine andere Frage:
Ich habe ja jetzt den TCP-Port von RDP wo anders hingeschubst. Die anderen Ports inbound bis auf VPN zu. D.h. der seit Version 10 benutzte UDP-Port 3389 von RDP ist auch zu. Gibt es - ebenso wie beim TCP-Port einen regedit-Pfad um diesen ebenso anzupassen?
Ich bin soweit gekommen, dass ich über den ILS ein lokales/privates Zertifikat angelegt habe. Das liegt jetzt auf dem Server. Und ich kann dieses Zertifikat auch im RAS bei den VPN-Einstellungen auswählen (anstelle vom Schlüssel). Nur denke ich, irgendwie muss dieses Zertifikat doch auch beim VPN-Client landen?! Sonst können die das doch nicht abgleichen?!
Und im dem Zusammenhang war mir das PGP-Thema mit privaten und öffentlichen Schlüsseln in den Sinn gekommen ...
Eine andere Frage:
Ich habe ja jetzt den TCP-Port von RDP wo anders hingeschubst. Die anderen Ports inbound bis auf VPN zu. D.h. der seit Version 10 benutzte UDP-Port 3389 von RDP ist auch zu. Gibt es - ebenso wie beim TCP-Port einen regedit-Pfad um diesen ebenso anzupassen?
