Remotezugang absichern

CommodoreX64

Experte
Thread Starter
Mitglied seit
05.02.2015
Beiträge
81
Hallo zusammen,

ich wollte mal nachfragen, wie ich einen privaten Remotezugang am sinnvoll absichern kann bzw. wie ihr das so macht.
Wenn ich unterwegs bin, habe ich ganz gerne die Möglichkeit über RDP zuhause auf meine Server im Keller zuzugreifen um was nachzuschauen etc.

Aktuell habe ich an meiner Fritzbox 7590 den MyFritz Dienst konfiguriert. Den RDP Port 3389 habe ich für das durchschleifen auf einen anderen Port gelegt. Das ist zwar kein wirklicher Securitygewinn, allerdings reichts um die nervigen Briefe von der Telekom ("Ihr Heimnetz ist unsicher / befallen") zu verhindern. Intern zeigt die Weiterleitung auf einen kleinen Intel NUC, auf dem Windows Server 2016 läuft und der quasi nur RDS Sprungserver spielt. Den NUC schalte ich nur an, wenn ich unterwegs bin. Bin ich zuhause und brauche keinen Remote Access ist der NUC aus. Spart Strom und sicher ist sicher ;)
Vom Nuc aus kann ich mich dann einfach weiter verbindenden auf meine anderen Server. Auf dem Nuc selbst liegen keine Daten oder so.

Sieht also quasi so aus:
RDP Client ---> Internet ---> Fritzbox ---> NUC ---> Server

Aus Sicherheitsgründen ist der normale Administrator Account auf dem NUC deaktiviert. Stattdessen wird ein andere User für den Remotezugriff verwendet, der ein Passwort mit 20+ Zeichen hat. Weiter Nuteraccounts gibt es auf dem System nicht. Die Lockout Policy ist so eingestellt, dass der Account nach 10 fehlgeschlagenen Versuchen für 1 Stunde gesperrt wird. Automatic Updates sind eingeschaltet. Zudem ist NLA aktiviert.

Denkt ihr, dass mein jetztiges Setup "sicher genug" ist oder hättet ihr da Brauchschmerzen?
Vorteil davon den RDP Port direkt durchzuschleifen ist für mich eben, dass man von jedem Rechner weltweit quasi drauf kommt. Das wäre bei einem VPN z.B. nicht gegeben, da ich auf arbeit nicht einfach ein VPN einrichten kann. Über RDP komme ich aber problemlos nach Hause auf meine Maschinen.

Danke & Grüße,
CommodoreX64
 
Zuletzt bearbeitet:
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Eindeutiges unsicher. Da hätte ich ja selbst mit einem im Hintergrund-laufenden-Teamviewer weniger Bauchschmerzen. Gab erst im Mai/Juni eine fette Sicherheitslücke im Remotedesktop.
Ideal wäre auf jeden Fall ein VPN. Kann auch auf einer VM Laufen. Solange Ihr in der Firma keine SSL decryption laufen habt (was ich nicht denke, wenn sogar der RDP Port offen ist), geht SSTP auf jeden Fall durch. Gibt's auch Android Client dafür. Windows geht eh, wurde damals von MS ins Leben gerufen.
 
Eindeutiges unsicher. Da hätte ich ja selbst mit einem im Hintergrund-laufenden-Teamviewer weniger Bauchschmerzen. Gab erst im Mai/Juni eine fette Sicherheitslücke im Remotedesktop.
Wie gesagt, der Server wird innerhalb von 24 Stunden automatisch gepatched und rebootet. Andere Softwarelösungen haben ebenso schon Sicherheitsproblematiken gehabt wie RDP auch. Zudem ist bei meinem RDS Server NLA eingeschaltet. Dadurch waren die Sicherheitslücken, welche du meinst, bei mir nicht ausnützbar, weil man sich vor Verbindungsausbau authentifizieren muss.
Daher sehe ich nicht, warum hier ein VPN unbedingt sicherer sein sollte. Auch dafür brauche ich einen durchgeschleiften Port.
 
VPN Client und RDP Client auf dein Handy - fertig. Zum "kurz mal nach schauen" mehr als ausreichend. RDP offen im Netz = mehr als fahrlässig.
 
Haben Microsoft Produkte in den letzten 30 Jahren durch Sicherheit geglänzt?

Wenn du der Überzeugung bist, dann machs halt... dein Rechner...
 
Was ist das für n Argument? Ich hatte nach einer konkreten Antwort gefragt, warum das "mehr als fahrlässig" sein soll. Konkrete Antwort ist was anders.
 
Das RDP-Protokoll gilt als unsicher und sollte keinesfalls offen im Internet erreichbar sein. Zur Not noch mit einer "Next Generation Firewall" dazwischen, die es zumindest etwas absichern kann...
 
Ich würde das etwas differenzierter betrachten: alles was am Netz hängt, *kann* vermutlich früher oder exploited werden -100% Sicherheit gibts nicht bei Internet Verbindung. Jetzt kommt es drauf an, wie man das Restrisiko einschätzt: Die Bots klappern meistens immer nur die Std Ports mit Std Benutzernamen ab.

Aktuell gepatches System, RDP Port nicht auf Std Port, zulässiger RDP User != Admin/Administrator/User sondern "krümelmonster" o.ä. ist schonmal sehr sicher.

Wenn Du dann noch den 24 Disconnect hast und alle 24 Std eine neue offizielle IP sollte da nichts passieren.

Ist ja auch immer eine Frage der Motivation des Angreifers: auf eine Unbekannte, wechselnde IP wo man nicht weis, was es da überhaupt zu holen gibt, wird abseits der o.g. Std Tests keiner viel Energie reinstecken, dazu gibt es genug einfachere Ziele.
 
Das Argument ist in meiner Antwort enthalten - du musst es nur extrahieren, dh., es ist nur eine Frage der Zeit, bis entweder eine Sicherheitslücke in RDP oder dessen Abhängigkeiten gefunden wird, oder hineingepatcht wird - woher ich das weiß? Aus der Erfahrung die man mit MS Produkten bisher gemacht hat...

Zum Anderen hast du dann eine zweistufige Authentifizierung - VPN und dann RDP - die Wahrscheinlichkeit, dass beides zur selben Zeit "broken" ist, kannst sicher selbst ausrechnen/einschätzen.

Und du fragst, ob es "sicher genug" ist, oder wir Bauchschmerzen haben - ganz offensichtlich haben wir eine sehr unterschiedliche Definitionen von "sicher genug". Daher kann ich dir nicht weiterhelfen.
 
Wenn Du ganz ehrlich bist: wolltest Du nicht einfach hören, dass das schon so passt?
Es haben Dir nun einige gesagt, dass es eben nicht passt. Was Du daraus machst, musst Du selbst entscheiden.
 
Zuletzt bearbeitet:
Wie wäre es denn mit Apache Guacamole mit Client Zertifikaten und MFA. Läuft bei mir sehr zuverlässig und ermöglicht SSH und RDP. Und es wird nur Port 443 (HTTPS) verwendet, d.h. Kein RDP/SSH nach außen offen.
 
Zuletzt bearbeitet:
Ich werfe mal Bitvise ins Spiel. Die haben einen SSH Server und Client für private Nutzung kostenfrei im Angebot. Darüber wird dann eine RDP Verbindung getunnelt. Du musst nur einen Port für SSH freigegeben und der Rest läuft darüber. Wenn du willst, kannst du den Login dann auch über Passkeys realisieren und den RDP Port kannst du dann auch wieder sperren.
So mache ich das schon seit etlichen Jahren und hatte bisher nie Probleme. Kannst im SSH Server auch einstellen, welche IP Bereiche sich einloggen dürfen und welche nicht usw.
 
Wieso so schwer? ;-)

...
Aktuell habe ich an meiner Fritzbox 7590 den MyFritz Dienst konfiguriert
...

Die einfachste Möglichkeit wäre dann wohl einfach die vorhandenen Möglichkeiten für eine VPN von AVM zu nutzen:

- Handy: MyFRITZ! - Heimnetzverbindung einrichten
- PC: FRITZ!Fernzugang einrichten

Geht beides easy, Du benötigst keine offenen Ports mehr (ausser dem MyFritz, den Du eh benutzt) - das einzige zu beachtende ist, dass damit keine Namensauflösung funktioniert. Also entweder per IP-Adressen auf die Rechner zugreifen oder mauelle Zuordnungen vornehmen.
Dann kannst Du per RDP auf den Server oder auf deine Rechner direkt zugreifen.
 
Wie wäre es denn mit Apache Guacamole mit Client Zertifikaten und MFA. Läuft bei mir sehr zuverlässig und ermöglicht SSH und RDP. Und es wird nur Port 443 (HTTPS) verwendet, d.h. Kein RDP/SSH nach außen offen.
Sieht sehr interessant aus. Werde ich mir auf jeden Fall genauer anschauen. Danke!

Ich werfe mal Bitvise ins Spiel. Die haben einen SSH Server und Client für private Nutzung kostenfrei im Angebot. Darüber wird dann eine RDP Verbindung getunnelt. Du musst nur einen Port für SSH freigegeben und der Rest läuft darüber. Wenn du willst, kannst du den Login dann auch über Passkeys realisieren und den RDP Port kannst du dann auch wieder sperren.
So mache ich das schon seit etlichen Jahren und hatte bisher nie Probleme. Kannst im SSH Server auch einstellen, welche IP Bereiche sich einloggen dürfen und welche nicht usw.
Danke! Werde ich mir auch anschauen.

Wenn Du ganz ehrlich bist: wolltest Du nicht einfach hören, dass das schon so passt?
Es haben Dir nun einige gesagt, dass es eben nicht passt. Was Du daraus machst, musst Du selbst entscheiden.
Nein, aber wenns passt auch ok. Ich habe zugegeben meine Zweifel an der Qualifikation einiger der Antwortenden. Aber wie du sagt, was ich draus machen kann ich dann ja mein Ding.

Das Argument ist in meiner Antwort enthalten - du musst es nur extrahieren, dh., es ist nur eine Frage der Zeit, bis entweder eine Sicherheitslücke in RDP oder dessen Abhängigkeiten gefunden wird, oder hineingepatcht wird - woher ich das weiß? Aus der Erfahrung die man mit MS Produkten bisher gemacht hat...
Ich wiederhole es gerne nochmal. NLA ist aktiv, NLA ist aktiv, NLA ist aktiv, NLA ist aktiv....

Die einfachste Möglichkeit wäre dann wohl einfach die vorhandenen Möglichkeiten für eine VPN von AVM zu nutzen:
Ich nutze von der MyFritz nur die DynDNS funktion. Den Rest nicht.
VPN kommt eben nicht wirklich in Frage, da ich nicht auf jedem Rechner von dem aus ich gerne Zugriff auf mein Heimnetz hätte einen VPN Client einrichten kann/darf.

Grüße, CommodoreX64.
 
Ist schon am Netz :) Dauert nämlich auch ziemlich lange, nmap die Ports scannen zu lassen und ist damit ein echter Sicherheitsgewinn, den Port zu ändern.
Ich würde halt wenigstens ein Portknocking an der Firewall einrichten, wenn es denn zwingend RDP sein muss.
Gegen einen SSH Tunnel spricht dagegen etwas weniger. Wobei auch SSH normalerweise nicht offen zugänglich sein sollte. Dafür ist aber ebenfalls ein Client notwendig (gibt zig verschiedene, nicht nur o.g., den ich übrigens nicht kenne).
 
Wer braucht schon ne funktionierende Scheibenbremsanlage am KFZ,
wenns auch die alten Latschen tun. Klappt ja bei Fred Feuerstein auch.
Du faehrst ja sicher langsam durch die Gegend, also wird schon nix passieren.

Fuer solche Themen gehoert ein VPN aufgebaut. Punkt.
 
Immer diese blöden Auto vergleiche, viele vergleichen Autos mit PC Teile, dabei hat das eine mit dem anderen nichts zu tun.
SSH würde ich auch nicht öffentlich den Port öffnen wenn es nicht unbedingt sein muss, wurde so vor paar Jahren schon öfters gehackt.

Wenn RDP offen sein muss, würde ich wie einige schon geschrieben haben, den standard Port in der Registry ändern.
Besser wer nur über VPN und RDp Port nur local zulassen.
 
Pubkey Auth only, StrictMode on, fail2ban on, Port auf nen random high port setzen und gut is, fahr ich schon über ne Dekade mit äußerst erfolgreich ohne übernommen worden zu sein.
 
Z.B. OpenVPN portable läuft ohne Adminrechte auf Windows.
Damit erledigt sich die Frage doch.
 
Immer diese blöden Auto vergleiche, viele vergleichen Autos mit PC Teile, dabei hat das eine mit dem anderen nichts zu tun.
SSH würde ich auch nicht öffentlich den Port öffnen wenn es nicht unbedingt sein muss, wurde so vor paar Jahren schon öfters gehackt.

Wenn RDP offen sein muss, würde ich wie einige schon geschrieben haben, den standard Port in der Registry ändern.
Besser wer nur über VPN und RDp Port nur local zulassen.

Du kreidest meinen bildlich gesprochenen Beitrag an, um dann security due obscurity zu empfehlen?
 
Weiß auch nicht, warum sich so gegen VPN gesträubt wird.
Einmal einrichten, verbinden, RDP wie im lokalen Netz nutzen und fertig ist die Laube.

Eigentlich das simpelste und mit am sichersten.
 
Welches Problem er mit einem VPN hat, hat er doch ausführlich geschildert. Er möchte von der Arbeit auf die Kisten schauen und darf dort keinen VPN Client installieren.
Für das Fritzbox VPN ist das meines Wissens aber notwendig.
Insofern wie gesagt die Idee mit dem SSTP, das über Windows eingerichtet werden kann. Bin mir nur nicht mehr sicher, ob man dafür Admin Rechte braucht. Als VPN Server eine VM.
 
Du könntest das ganze auch noch mit dynamischen ACLs und Claims absichern zusätzlich zu einigem schon genannten von obendrüber, sodass du nur von bspw. deinem Laptop eine VPN Einwahl durchführen kannst.
 
Als Notlösung kannst Du den RDP Port auch auf was anderes als 3389 umbiegen. Dazu noch einen IP Blocker wie IPBan und Du bist die meisten Angriffe los. Vielleicht kannst Du Dir auch eine VPN Verbindung mit IPSec einrichten, da bringt Windows schon einen entsprechenden Client von Haus aus mit.
 
Gefühlt sind mind. 60% der Posts gemacht worden, ohne den Rest zu lesen.
Er will kein VPN.
Er hat den Port schon geändert.
Es ist trotzdem schlecht und er will es trotzdem so.
 
Naja, so eindeutig ist das doch halt hier nicht. Alle bisherigen Aussagen dazu waren:

dass man von jedem Rechner weltweit quasi drauf kommt. Das wäre bei einem VPN z.B. nicht gegeben,
Vielleicht nicht von Haus aus, lässt sich aber problemlos machen. Also kein grundsätzliches Argument gegen ein VPN.

Daher sehe ich nicht, warum hier ein VPN unbedingt sicherer sein sollte.
Dass RDP über ein VPN sicherer ist, ist unbestreitbar. Also kein grundsätzliches Argument gegen ein VPN.

VPN kommt eben nicht wirklich in Frage, da ich nicht auf jedem Rechner von dem aus ich gerne Zugriff auf mein Heimnetz hätte einen VPN Client einrichten kann/darf.
Ist ja auch nicht erforderlich, weil es wie gesagt auch Portable-Lösungen gibt, die keine Einrichtung/Installation/Setup usw erfordern. Etwas Anderes wäre es, wenn gründsätzlich die Nutzung jeder nicht bereits vorhandenen Software untersagt wäre, aber in solchen Situtationen ist doch sowieso jede priate Nutzung der Geräte noch viel strenger untersagt, wodurch die ganze Fragestellung ohnehin absurd wäre. Also ist auch hier kein grundsätzliches Argument gegen ein VPN zu finden.

Ich sehe hier bisher keinen definitiven Grund, weshalb es nicht mit z.B mit OpenVPN-Portable machbar sein sollte. Das erfordert keine Installation keine Adnminrechte und ist auf so ziemlich jedem System bis hin zu Smartphones verfügbar.
 
Zuletzt bearbeitet:
:rofl:
Und ein neuer Bot geht ans Netz.
Halte dich doch bitte aus meinem Thema fern. Ich habe meine Einschätzung deiner Qualifikation getroffen und werde deine Beiträge eh nicht mehr weiter beachten bzw... eigentlich besser gleich auf die Ignore-List setzen.

Ich würde halt wenigstens ein Portknocking an der Firewall einrichten, wenn es denn zwingend RDP sein muss.
Hast du das unter Windows Server schonmal erfolgreich konfiguriert?

Dass RDP über ein VPN sicherer ist, ist unbestreitbar. Also kein grundsätzliches Argument gegen ein VPN.
Ist ja auch nicht erforderlich, weil es wie gesagt auch Portable-Lösungen gibt, die keine Einrichtung/Installation/Setup usw erfordern. Etwas Anderes wäre es, wenn gründsätzlich die Nutzung jeder nicht bereits vorhandenen Software untersagt wäre, aber in solchen Situtationen ist doch sowieso jede priate Nutzung der Geräte noch viel strenger untersagt, wodurch die ganze Fragestellung ohnehin absurd wäre. Also ist auch hier kein grundsätzliches Argument gegen ein VPN zu finden.
Ich sehe hier bisher keinen definitiven Grund, weshalb es nicht mit z.B mit OpenVPN-Portable machbar sein sollte. Das erfordert keine Installation keine Adnminrechte und ist auf so ziemlich jedem System bis hin zu Smartphones verfügbar.
Weil es Geräte gibt, auf denen das Ausführen von nicht freigegebener Software untersagt ist. Alle VPN Clients gehören dazu. Das ist eben auf dem Laptop von ich meistens die RDP Verbindung aufbaue so und ich werds auch nicht ändern können.
Zudem habe ich dann das Problem, dass ich 2 VPNs gleichzeitig hätte. Eins in die Firma und eins nach Hause bzw. ich muss immer hin und her schalten was nervt. So habe ich einfach die normale VPN Verbindung in die Firma wenn ich unterwegs bin und kann bequem über RDP auf meine Server daheimd im Keller schauen.

Grüße, CommodoreX64
 
Bzgl. Portknocking meinte ich die vorgeschaltete Firewall, nicht die Windows Firewall.
Allerdings habe ich gerade nochmal nachgelesen, dass es scheinbar nur die 7590 gibt. Die könnte das höchstens mit CustomROM.

- - - Updated - - -

Bzgl. nicht erlaubter Software auf Firmengeräten - verstehe ich. Der onboard VPN Client erlaubt aber auch ohne weitere Software und ohne Administrationsrechte das Einrichten eines VPNs. Der onboard funktioniert zwar nicht mit der Fritzbox, aber daher auch mein Vorschlag mit der VPN-VM.
Zwei gleichzeitig aktive VPNs sollten auch unter Windows kein Problem sein.
 
Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh