9
VPN und RDP Sicherheitsaspekt
Verständnisfrage zur Sicherheit einer kombinierten VPN + RDP Verbindung
Hallo,
ich verbinde mich per VPN von zu Hause auf meinen Büro-Router (Draytek 2820) und anschliessend per Remote-Desktop (mit lokaler Server-IP) auf den Büro-Server. Diese Verbindung ist ja hinreichend sicher.
Ich kann mich aber natürlich auch ohne vorherige VPN-Verbindung direkt über RDP einwählen, wenn ich die öffentliche IP-Adresse (kommt von DynDns) verwende, weil ich mit der ja auch letztlich auf dem Router lande.
Den Port 3389 habe ich freigeschaltet, den brauch ich ja auch für die interne RDP-Verbindung, oder?
Das scheint mir grundsätzlich wieder unsicher zu sein, weil jeder ja durch rumprobieren von öffentlichen IP's mal spasshalber eine RDP-Verbindung aufbauen kann, um zu schauen was passiert.
Kann ich das irgendwie sicherer machen, indem ich z.B. festlege, dass nur bestimmte externe IP's über RDP zugelassen werden, oder kann man evtl. festlegen, dass RDP nur über interne IP's erlaubt ist.
Grüße
Hallo,
ich verbinde mich per VPN von zu Hause auf meinen Büro-Router (Draytek 2820) und anschliessend per Remote-Desktop (mit lokaler Server-IP) auf den Büro-Server. Diese Verbindung ist ja hinreichend sicher.
Ich kann mich aber natürlich auch ohne vorherige VPN-Verbindung direkt über RDP einwählen, wenn ich die öffentliche IP-Adresse (kommt von DynDns) verwende, weil ich mit der ja auch letztlich auf dem Router lande.
Den Port 3389 habe ich freigeschaltet, den brauch ich ja auch für die interne RDP-Verbindung, oder?
Das scheint mir grundsätzlich wieder unsicher zu sein, weil jeder ja durch rumprobieren von öffentlichen IP's mal spasshalber eine RDP-Verbindung aufbauen kann, um zu schauen was passiert.
Kann ich das irgendwie sicherer machen, indem ich z.B. festlege, dass nur bestimmte externe IP's über RDP zugelassen werden, oder kann man evtl. festlegen, dass RDP nur über interne IP's erlaubt ist.
Grüße
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: 150042
Url: https://administrator.de/contentid/150042
Ausgedruckt am: 15.11.2024 um 23:11 Uhr
9 Kommentare
Neuester Kommentar
Hallo,
Den Port 3389 habe ich freigeschaltet, den brauch ich ja auch für die interne RDP-Verbindung, oder?
Du hast diesen Port aber ja nicht am outside inteface des Routers freigeschaltet, oder?
Da der Traffic durch den Tunnel geht bist du ja Bestandteil des lokalen Netzes wenn du dich per VPN einwählst.
Traffic der durch den Tunnel kommt wird ja nicht ausgewertet und braucht diese Freigabe somit auch nicht.
brammer
Den Port 3389 habe ich freigeschaltet, den brauch ich ja auch für die interne RDP-Verbindung, oder?
Du hast diesen Port aber ja nicht am outside inteface des Routers freigeschaltet, oder?
Da der Traffic durch den Tunnel geht bist du ja Bestandteil des lokalen Netzes wenn du dich per VPN einwählst.
Traffic der durch den Tunnel kommt wird ja nicht ausgewertet und braucht diese Freigabe somit auch nicht.
brammer
Hi!
Den Zugang ohne VPN nutzbar zu machen, würde ich sein lassen. Jede Lücke im freigegebenen Protokoll (hier RDP) macht das Firmennetzwerk verwundbar, mal abgesehen von der Möglichkeit dass Angreifer sich hier mit Passwörtern ausprobieren können. Darum gibt es VPN! Eine Beschränkung auf einige externe IP-Adressen finde ich da nicht wirklich sicher. Was hast du gegen die VPN-Lösung?
Den Zugang ohne VPN nutzbar zu machen, würde ich sein lassen. Jede Lücke im freigegebenen Protokoll (hier RDP) macht das Firmennetzwerk verwundbar, mal abgesehen von der Möglichkeit dass Angreifer sich hier mit Passwörtern ausprobieren können. Darum gibt es VPN! Eine Beschränkung auf einige externe IP-Adressen finde ich da nicht wirklich sicher. Was hast du gegen die VPN-Lösung?
Hallo zusammen und danke für die Antworten.
@brammer: Ja, Ich hatte den Port 3389 freigeschaltet, dachte ich bräuchte den Port auch für intern. Habe es gerade geändert.
@ atbs84: Ich möchte ja nur über VPN die Verbindung aufbauen, kam mir dann nur komisch vor, dass es über RDP + öffentliche IP eben auch geht. Hat sich ja jetzt geklärt mit dem Port 3389
Grüße
@brammer: Ja, Ich hatte den Port 3389 freigeschaltet, dachte ich bräuchte den Port auch für intern. Habe es gerade geändert.
@ atbs84: Ich möchte ja nur über VPN die Verbindung aufbauen, kam mir dann nur komisch vor, dass es über RDP + öffentliche IP eben auch geht. Hat sich ja jetzt geklärt mit dem Port 3389
Grüße
Da die meisten Router PAT können musst du ja gar nicht 3389 außen freischalten, sondern du nimmst einfach einen hohen Port wie 43185.
Kaum jemand hat so lange Zeit um alle 65k Ports auf Verbindungen zu prüfen...
Neuere Versionen von RDP haben auch eine Verschlüsselung, aber das betrifft ja nur den Datenverkehr in einer Sitzung.
Kaum jemand hat so lange Zeit um alle 65k Ports auf Verbindungen zu prüfen...
Neuere Versionen von RDP haben auch eine Verschlüsselung, aber das betrifft ja nur den Datenverkehr in einer Sitzung.
Kaum jemand hat so lange Zeit um alle 65k Ports auf Verbindungen zu prüfen...
Das stimmt heute wohl (leider) nur sehr eingeschränkt - auch wenn ich das heute immer noch in diversen Foren zu lesen bekomme.Bereits an einem zügigen DSL-Link dauert ein Portscan über alle denkbaren Ports kaum mehr eine Minute.
Wer da z.B. gezielt ran will, wird sich davon sicher unbeeindruckt halten. Wer sogar irgendwo auf der Strecke Traffic mitschneiden kann, braucht nicht mal mehr scannen.
Aber auch "Bösewichte" mit nicht spezifiziertem Ziel haben Tools, die diesen Aufwand für ganze Subnetze recht effizient bewältigen und Dank solcher wie ähnlicher "HowTos" in der Windows Welt hat sich auch herumgesprochen, das sich das immer häufiger lohnt...
Zudem ist es derartigen Angreifern meist ziemlich egal, wessen System sie da kompromittieren / mißbrauchen. Wer also denkt, "wen interessiert schon MEIN Netz" ist ziemlich auf dem Holzweg.
Ein "verdrehter" Port bietet heute bereits keinen wesentlichen Sicherheitsgewinn, es sei denn man nimmt an das sich unter den Bösewichten im Internet nur "Kiddies" bewegen. Derartige "Security by Obscurity" Konzepte gelten nicht umsonst als obsolete...
Ein offenes Port-Forwarding auf eine Inhaus-Windows Maschine sollte - wenn überhaupt - nur in Betracht gezogen werden, wenn man das Inhaus-System mit der selben Sicherheitsmerkmalen wie dem eines Internet-Servers ausstattet sowie auch die Sicherheitsolicies solcher zum Tragen kommen. Ob das eine für jeden typischen LAN-Admin bewältigbare Aufgabe darstellt, bleibt mal dahingestellt.
Die Verbindung über ein VPN per einem dedizierten (VPN-)Router konzentriert ist derzeit wohl die einzige Topologie, die man hier einem Anwender mit einem Rest an Grundbedarf an Sicherheit empfehlen kann und sollte, zumal heute quasi jeder übliche Heim- und Hof-Router - aus gutem Grund - irgendeine integrierte VPN-Funktionalität mitbringt..
cheers,
Niels Dettenbach.
Hallo,
@syndicat.com
inhaltlich richtig aber ein bisschen verspätet, oder?
Der Ursprungsbeitrag ist vom 31.08.2010.
Oder soll ich hier eine verdeckte art der Eigenwerbung reindeuten?
brammer
@syndicat.com
inhaltlich richtig aber ein bisschen verspätet, oder?
Der Ursprungsbeitrag ist vom 31.08.2010.
Oder soll ich hier eine verdeckte art der Eigenwerbung reindeuten?
brammer
Ich antworte wenn ich lese und der Beitrag war von 2010 - also bei Lesern wohl immer noch aktuell (bin per Hinweis eines Anwenders hier gelandet, der - wohl wegen dieses Artikels - ebenso argumentierte...).
cheers,
Niels.
cheers,
Niels.
Bereits an einem zügigen DSL-Link dauert ein Portscan über alle denkbaren Ports kaum mehr eine Minute.
Leg dir einfach mal bei einem normalen Webserver SSH von 22 auf irgendeinen anderen Port und schau was mit den ganzen Bruteforce-Scripts passiert - ja, es hilft.
Zudem kann heute praktisch jeder gute Router Portscans erkennen und abschießen und wenn man es richtig drauf anlegt kann man auch mit Portknocking spielen - ein Portscanner wird sowas nicht mehr finden.
Leg dir einfach mal bei einem normalen Webserver SSH von 22 auf irgendeinen anderen Port und schau was mit den ganzen Bruteforce-Scripts passiert - ja, es hilft.
Ich bestreite nicht, das man damit die mittlere Zahl der (ungerichteten) Angriffsversuche gegen einzelne Dienste reduziert. Andererseits reicht auch nur ein erfolgreicher Angriff...Bruteforce-Attacken und Portscans sind zwei verschiedene Dinge - auch wenn Sie nicht selten in Kombination zur Anwendung kommen. Der meiste heutige ungerichtete (!) SSH-BF-Traffic kommt wohl ohne Portscan zustande und hier spielt auch "Psychologie" eine nicht unwesentliche Rolle. In etwa: "Wer an seinem System die Standard-Ports für SSH etc. verdreht, der hat womöglich auch sonst noch einiges für die Absicherung des Systems getan (obgleich auch das heute auch nicht mehr so stimmt, da immer mehr Produkte / Lösungen per Default mit verdrehtem Port daherkommen).
Für SSH (an einem Host mit "gehärtetem" System) ist das Port-Verdrehen eine sinnvolle Maßnahme sein - für RDP o.a. LAN-typische Dienste eines Windows Systems gilt das m.E. aber lange nicht.
Zudem kann heute praktisch jeder gute Router Portscans erkennen und abschießen und wenn man es richtig drauf anlegt kann man auch mit Portknocking spielen - ein
Portscanner wird sowas nicht mehr finden
Ahh,Portscanner wird sowas nicht mehr finden
ein halbwegs intelligent durchgeführter Portscan umgeht wohl jedes "gängige" IDS / IPS (und das erst recht bei 0815 Routern) - so jedenfalls meine Erfahrung (die Möglichkeiten der stetig wachsenden organisierten IP-Kriminalität wie Bot-Netze usw. gar nicht mal einbezogen). Gegen typische Kiddie-Scans z.B. des Nachbarjungen mögen die Lösungen dagegen erfolgreich helfen.
Aber nicht zuletzt - kann jemand ungetunnelten Traffic auf der Strecke mitschneiden (denkbare Szenarien gibt es da für viele Anwender mehr als genug), spielt das "Port-Verstecken" für einen Angriff kaum eine bis keine Rolle.
Dazu kommt:
RDP ungetunnelt über öffentliche Netze zu schicken, ist - betrachte man sich allein die Sicherheitshistorie der Microsoft Implementierungen - insbesondere ohne Absicherung durch asym. x509 Ktypto-Zertifikate - eine an sich "mutige" Aktion. Aber das wäre eine gesonderte Thematik.
