Sicherheit für externen RDP-Zugriff via DDNS erhöhen

[BomberHarry]

Hallo,
ich habe mir die Tage eine DynDNS angelegt, damit ich von extern auf meine Maschine zugreifen kann.

Folgendes habe ich geändert:
- extern über Port 50000 erreichbar, portforwarding nach geänderten Port 21000 (default ja 3389)
- lokalen Adminkonto deaktiviert und 16-stelliges generiertes Kennwort vergeben
- separaten Adminnutzer mit anderem Namensschema vergeben, Passwort ebenfalls 16-stellig

Was kann ich noch ändern, um möglichst sicher zu sein oder gar im Falle eines "Hacks" dem Typen möglichst wenig Informationen biete? Eventuell das verbundene Netzlaufwerk mittels Registry-Key ausblenden? Dem "User zum Verbinden" garkeine Administrativen Rechte geben und bei mangelnden Berechtigungen mit administrativen User (Ausführen als) authentifizieren?


PS: Habe mal gelesen, dass man den Default 3389 Port auch intern ändern soll. Welchen Sinn ergibt das eigentlich? Wenn ein Botnetz meine öffentliche IP und sämtliche externe Ports durchprobiert, wird er doch beim richtigen sowieso auf den intern-geändernden Port durchgereicht? Dass man den Standardport von extern ändert wäre mir schon logischer, da somit möglicherweise weniger Treffer passieren.

 

[fdsonne]

Mir fällt da spontan das hier ein:
How to Enable and Secure Remote Desktop on Windows

Aber so 100% würde ich dem RDP so aber nicht vertrauen. Nichtmal 99%
Ne im Ernst. Sinnvollerweise sollte man sowas, sofern man die Möglichkeiten dazu hat, über ein TerminalServer Gateway abfackeln. Dieses Gateway stellt man üblicherweise in eine DMZ. Den Access von Außen schützt man via Firewall und bestenfalls noch einem IPS (mit Mechanismen zur Abwehr von Fehlversuchen, Stichwort Fail2Ban bspw.). Je nachdem, was man genau will, bieten sich dort verschiedene Produkte an.

Ein anderer Ansatz wäre so eine Art Firewall User Authentication von extern zu machen. Mit der man bspw. seine externe source IP (also mit der man versucht die RDP Verbindung aufzubauen) erst über eine Firewall Freischaltung den Zugriff auf den Port erlaubt.

Das Ganze kann man natürlich auch kombinieren. Je nach Sicherheitsbedrüfnis... Die Frage ist eher, wie hoch ist dieses Bedürfnis wirklich? Im Ernstfall kann sich der potentielle Angreifer durch Lücken oder sonstwas Zugriff auf die Kiste erhaschen. Und damit dann allerhand Unannehmlichkeiten bewerkstelligen. Denn ist er einmal auf der Kiste drauf, dann hat er wohl zu 99% Zugriff auf die meisten internen Ressourcen. Zumal die Schutzmaßnahmen gegen Angreifer, um so weiter man sich von extern ins interne Netz reinbewegt häufiger immer schwächer werden. Gerade auch was Kennwörter und allgemein Zugriffsmöglichkeiten angeht.

 

[0711]

adminitrativen usern den zugriff entziehen
Kennwort nach x fehlversuchen sperren
bei bedarf ein zweiten authentifizierungsfaktor nutzen
port ändern sehe ich keinen sinn
rdp Gateway ist ne Idee, je nach Bedürfnis
i.d.R. sehe ich das als ausreichend...

ansonsten gibt's hier auch n paar tipps
https://security.berkeley.edu/node/94

und einiges von fdsonne genannten

 

[UsAs]

Was fdsonne schrieb

Alleinig die strukturierte Regelung der administrativen Konte ist schon ein großer Schritt, der sonst oft außer acht gelassen wird.

 

[BomberHarry]

Sry dass ich erst jetzt schreibe.

Also ich sehe schon, dass da eine gewisse Arbeit drinnen steckt, wenn man es versucht sehr sicher auszulegen. Jedoch habe ich hier nicht die Mittel und nichtmal keine Firewall davor geschaltet, nur auf den Maschinen. Auf Source IPs einzuschränken sehe ich etwas krumm an. Möchte mich gerne von überall (Smartphone, Freunde) draufschalten.

Wie wäre das mit dem zweiten Authentifizierungsfaktor (Zwei-Faktor-Authentifizeierung)? wie binde ich die ein?

Stichwort Firewall: Wie wäre das denn, wenn ich tatsächlich eine davorhängen würde? Gerne auch als Linux-VM mit dem Fail2Ban, die dann als Gateway dient. Bei der Firewall blocke ich eingehend alles, außer den freigegebenen Remoteport. Und wenn von intern eine Verbindung nach extern aufgebaut wird, dann kann der doch wieder rein, weil ja die Verbind steht und die Firewall das ja weiß oder?

 

[fdsonne]

Also ich sehe schon, dass da eine gewisse Arbeit drinnen steckt, wenn man es versucht sehr sicher auszulegen. Jedoch habe ich hier nicht die Mittel und nichtmal keine Firewall davor geschaltet, nur auf den Maschinen. Auf Source IPs einzuschränken sehe ich etwas krumm an. Möchte mich gerne von überall (Smartphone, Freunde) draufschalten.

Das kann man wie gesagt machen, wenn du so ne Art Firewall User Authentication fährst. Du schaltest dann die public IP, mit der dein Device von extern kommt, einfach über eine Schnittstelle frei. Je nach Einsatz und Verfahren läuft die Verbindung dann irgendwann in einen Timeout, wenn keine Daten mehr übertragen werden, oder du trennst die Verbindung danach wieder.
Das könnte man schon fast als zweiten Faktor ansehen Denn ohne Freischaltung der IP kein Zugriff möglich. Bestenfalls mit ner eigenen/anderen User Datenbank zur Freischaltung und natürlich anderen Informationen.

Alternativ könnte man das ganze auch so aufziehen, dass es Zertifikatsbasiert arbeitet. Und somit quasi völlig ohne Zutun deinerseits funktioniert. Dazu müsste man das Gerät mit einem Zertifikat ausstatten und ein Produkt wählen, was die Freischaltung via Zertifikat zulässt.

Wie wäre das mit dem zweiten Authentifizierungsfaktor (Zwei-Faktor-Authentifizeierung)? wie binde ich die ein?

Das kannst du wie oben angesprochen bspw. mit einem Terminal Server Gateway bewerkstelligen. Neuerdings heist das wohl RemoteDesktop Gateway.
Da gibts mehrere Produkte, die sowas können sollen. Von MS selbst gibts den ISA 2006 bzw. in neuerer Instanz den TMG 2010 Server.
Auch ein default Windows Server hat wenn ich das richtig in Erinnerung habe, eine Rolle als RemoteDesktop Gateway im Bauch.
Ansonsten könnte man sowas wohl auch via Sophos UTM Appliance (auch als VM erhältlich) machen. Entgegen der MS Geschichten kost die Lizenz für 3 Jahre Laufzeit für den Homebetrieb! nix
Mit dem Teil kannst du dir dann Webveröffentlichungsregeln bauen. -> und so auch an eine Zweifaktor Authentifizierung kommen.

Stichwort Firewall: Wie wäre das denn, wenn ich tatsächlich eine davorhängen würde? Gerne auch als Linux-VM mit dem Fail2Ban, die dann als Gateway dient. Bei der Firewall blocke ich eingehend alles, außer den freigegebenen Remoteport. Und wenn von intern eine Verbindung nach extern aufgebaut wird, dann kann der doch wieder rein, weil ja die Verbind steht und die Firewall das ja weiß oder?

Eingehend wird der Port nur an das Gatway geforwardet. Und das Gateway selbst baut dann intern eine Verbindung zum Zielserver (also zum RDP Port deiner Kiste) auf.
Dieser Port von extern muss natürlich frei geschalten werden, sonst geht logischerweise nix.

Mit intern zu extern hat das nix zu tun... Diese Richtung musst du seperat freischalten (oder auch nicht). Sprich wenn intern zu extern traffic erlaubt ist, heist das nicht, das auch extern zu intern traffic geht und andersrum.

 

[0711]

Wie wäre das mit dem zweiten Authentifizierungsfaktor (Zwei-Faktor-Authentifizeierung)? wie binde ich die ein?

Über Drittlösungen, entweder über ein Gateway/UTM (MS ISA/TMG würde ich aufgrund dessen dass diese abgekündigt sind nicht in Betracht ziehe, vom preis abgesehen ) wie über mir angesprochen oder über Lösungen wie jene hier https://github.com/LastSquirrelIT/MultiOneTimePassword-CredentialProvider oder von duosecurity oder oder welche den 2. Faktor für die windowsanmeldung bereitstellen.

 

[fsironman]

SSH-Tunnel mit public key.

Du baust erst ne ssh Verbindung auf richtest einen portweiterleitung von localhost:yyyy auf zielrechner:xxxx ein und verbindest dich dann ganz normal nur halt mit localhost:yyyy.

Dann kannst du aber theoretisch auch gleich vnc oder so benutzen.

 

[0711]

Dann kannst du aber theoretisch auch gleich vnc oder so benutzen.

was bedeutend langsamer ist...