Absicherung Windows-VM

  • Ab sofort steht euch hier im Forum die neue Add-on Verwaltung zur Verfügung – eine zentrale Plattform für alles rund um Erweiterungen und Add-ons für den DSM.

    Damit haben wir einen Ort, an dem Lösungen von Nutzern mit der Community geteilt werden können. Über die Team Funktion können Projekte auch gemeinsam gepflegt werden.

    Was die Add-on Verwaltung kann und wie es funktioniert findet Ihr hier

    Hier geht es zu den Add-ons

fx999dev

Benutzer
Registriert
13. Dez. 2022
Beiträge
12
Reaktionspunkte
1
Punkte
3
Hallo,

ich wollte eure Meinung zu folgendem Setup hören (VPN ist nicht möglich, bitte nicht vorschlagen):
- Windows Server 2022 VM auf meines NAS
- Windows Server 2022 Standard RDP Port 3389 aktiv, RDP Zugang aber eingeschränkt nach Quell-IP des Docker Containers Apache Guacamole
- Windows Server 2022 Login abgesichert mit DUO 2FA

- Docker Container Apache Guacamole
- Standard Nutzername gelöscht, neuen Account mit Administratorrechten angelegt
- RDP Zugang zum Windows Server 2022 hinterlegt (ohne Passwort)
- 2FA auch für Apache Guacamole

- Synology Reverse Proxy Manager eingerichtet (und hier fangen die Fragen bei mir an):
Quelle:
- Protokoll HTTPS
- Hostname (DDNS gemapped auf meine öffentliche Ip meines Speedport)
- Port 61322
- HSTS aktivieren JA
- Zugangsprofil: RemoteAccess
Ziel:
Protokoll http
Hostname: Ip meiner Synology Diskstation
Port: 8348

Zugangsprofil sieht so aus:
Quell IP 1: Zulassen
Quell IP 2: Zulassen

Firewall Portforwarding Port 61322 auf DS, wenn man meine DDNS mit DDNS-Name:61322 anspricht.


Drei Sachen, die mir überhaupt nicht gefallen:
1.
Rufe ich DDNS-Name:61322 ohne https auf, bekomme ich:

400 Bad Request​

The plain HTTP request was sent to HTTPS port

nginx

Ich hätte hier am liebsten überhaupt keine Antwort des Servers.

2. Scheint mir die Zugriffskontrolle nicht zuverlässig zu funktionieren., wenn ich auf spezifische Quell-Ips einschränken möchte.
Stelle ich auf "Alle" verweigern, wird mir folgendes angezeigt:

Sorry, the page you are looking for is not found.​


Das finde ich auch richtig schlecht. Lieber wär mir auch hier überhaupt keine Antwort.

Nehme ich "Alle" verweigern raus, und nur "Zulassen" bei spezifischen Quell-Ips kann trotzdem jede Ip (getestet mit Handy im Mobilfunknetz) darauf zugreifen...

Ich hoffe, ihr könnt mir weiterhelfen.

a) Ist das grundsätzliche Setup "sicher"?
b) Lässt sich das mit der Zugriffskontrolle und dem nicht Antworten auf Anfragen irgendwie lösen?

Danke.


Edit:

Ich habe auch gerade mal mit der Firewall rumgespielt. Habe hier das gleiche Problem. Einschränkung auf Quell-Ips funktioniert überhaupt nicht. Stelle ich jedoch auf Quell-Ip "Alle verweigern" funktioniert das. Aber das nur spezifische zu erlauben, klappt überhaupt nicht.
??
 
Zuletzt bearbeitet:
Zu 1.
Da bräuchtest du eine Firewall, die nur https durchlässt.
Ich weiß nicht, ob sich der NGINX dazu bewegen lässt, nicht auf http zu antworten. Über die Syno-GUI jedenfalls nicht. Ich hab es aber gerade mal mit einem NGINX RP Docker Container getestet. Da geht dies auch nicht via GUI.
Zu 2.
Das ist leider bei dem NGINX RP der DS normal. Und lässt sich auch via UI nicht ändern. Da könntest du höchsten manuell nachsehen. Hier ein Link: https://www.synology-forum.de/threads/port-auf-url-umleiten.122546/#post-1019261
Im "richtigen" NGINX RP kommt da ein 403 Forbidden Error. So auch bei meiner Docker-Instanz.
Zu a)
100%ige Sicherheit gibt es nicht. Vor allem nicht bei Freigaben ins Internet. Hast du Geoblocking an? Zusätzlich könntest du evtl. CrowdSec nutzen.
Sicherer wäre es denke ich auch noch, wenn nicht der NGINX RP der DS verwendet wird. So hängt die DS mit einem Bein im Internet. Verwende lieber den NGINX RP im Docker Container.
Ansonsten hören sich deine Maßnahmen für mich erstmal sinnvoll an. Eine Alternative wäre natürlich, einen Remote Zugang via TeamViewer, RustDesk oder dergleichen zu realisieren.

Ansonsten:
"Zulassen" bei spezifischen Quell-Ips kann trotzdem jede Ip (getestet mit Handy im Mobilfunknetz) darauf zugreifen...
Das kann ich so nicht bestätigen.
Habe hier das gleiche Problem
Setze bitte ans Ende der Firewall Regeln und auch der RP-Regeln ein "deny all". Sollte dein Problem lösen.
 
  • Like
Reaktionen: Ronny1978
Das Problem ist, dass Tailscale vermutlich beim Client auch wieder VPN-Verbindungen anlegt bzw. eine Installation benötigt. Beim Client wird meistens bereits eine andere VPN-Verbindung bestehen und zwei VPN-Verbindungen vertragen sich vermutlich nicht. Sonst wäre VPN bereits das Mittel der Wahl gewesen.
 
Kommt darauf an. Bei einer WireGuard VPN-Verbindung zum Beispiel kannst du in der Config hinterlegen, welche IP-Adressen über das VPN geroutet werden sollen.
 

Additional post fields

 

Kaffeautomat

Wenn du das Forum hilfreich findest oder uns unterstützen möchtest, dann gib uns doch einfach einen Kaffee aus.

Als Dankeschön schalten wir deinen Account werbefrei.

:coffee:

Hier gehts zum Kaffeeautomat