„Sicherheitsrisiko“ durch dynDNS + RDP Weiterleitung im VPN

Paulchengb

Enthusiast
Thread Starter
Mitglied seit
09.08.2006
Beiträge
294
Hallo zusammen,

ich würde gerne von zu Hause einen VPN Tunnel zu einem „kleinen Server“ in der Arbeit herstellen. Wie die VPN Einrichtung funktioniert, ist mir klar, aber ich habe ein kleines Sicherheitsbedenken.

1. Der Server hat keine feste IP. Wenn ich jetzt einen dynDNS-Service verwende und jmd. Unbefugtes diese URL kennt, könnte er über längere Zeit meinen Server attackieren, weil sich das Problem mit der 24 Zwangstrennung ja nicht „von selber“ löst. Es ist ein Win 2012 RC2 Server hinter einem LanCom Router. Ist dieser Gedanke korrekt und das Bedenken gerechtfertigt?

Angenommen, die Homepage der Firma ist unter Lexware Kundenstimmen erreichbar.
Ist es dann „unsicher“, vpn.meinefirma.de als Subdomain für das VPN zu verwenden oder sollte ich lieber eine neue Domain fernwartung.de anlegen, um über diese Domain meine Fernwartung zu realisieren? Die Homepage ist nicht auf dem Win-Server gehostet…

2. Win-Server-IP: 192.168.0.1
Das VPN soll über den LanCom Router aufgebaut werden und von zu Hause möchte ich eine Remotedesktop-Verbindung zum Rechner mit 192.168.0.2 aufbauen. Dazu muss ich einfach nur die passenden Ports des RDP an 0.2 weiterleiten, oder?
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
1. Wenn du ein VPN machst, machst du keine Portweiterleitung mehr. Bei VPN ist ja der Trick, dass du Teilnehmer des internen Netzes wirst, mit welcher konkreten Ausprägung auch immer.
Der VPN-Server weißt dir dann z.B. einen interne IP am Client zu. Für den Client wär es dann so, als wäre der Client vor Ort.
Wichtig ist der Hinweis, dass sich die IP-Netz nicht überlappen sollen. Dass passiert gerne mal mit 192.168.0.x/24 oder sowas. Was andere wäre es, wenn der Client dann exklusiv im VPN-Netz hängen soll mit kompletter Weiterleitung. Ist auch ein Sicherheitsfeature.

2. DNS für VPN Zugänge am Namenstechnisch komplett abkoppeln. Am Ende ist es ggf. aber auch egal, denn wenn der VPN-Server auf der selben IP läuft wie die Maindomain, dann hat der Angreifer eh die IP der Domain und wird auch rausbekommen, dass ein VPN-Server läuft und wird den penetrieren. Egal was da für ne Fernwart.de-Domain läuft.

3. Wie schon gesagt, ist bei einem VPN der normale Server nicht direkt angreifbar, sondern nur der VPN-Server und ggf. noch andere Dienste, die draußen sind. So dass dein normaler Server nichts davon mitbekommt, was draußen passiert. (unter der Voraussetzung es laufen keine Portforwards)

4. Server mit win2k12 gehören langsam entsorgt, egal on VPN oder nicht

5. VPN-Server sollte nach Möglichkeit ein extrem security-robustes Gerät sein. Denn ist der einmal geknackt, dann ist die Party groß...
Parallel dazu gehört die Verwendung eines Protokolls mit aktuelle Securityfeatures. Also nicht mit PPTP oder solchen Scherzen anfangen. Weiterhin gehört die Verwendung extrem komplizierter Passwörter oder Zertifikate dazu.

6. Deine Ausführungen zum Thema VPN lassen darauf schließen, dass du nicht so fit in dem Bereich bist. Da es sich wohl um was geschäftskritisches handelt, lieber einen Profi damit beauftragen.
Nicht wäre uncooler, als wenn die Bude zugemacht werden muss, weil jemand rausgefunden hat, dass Admin::1234567890 zum Zugang zum VPN reicht.

7. Was sich ggf. auch anbietet, wenn du den Zugang von der Arbeit aufbauen lässt. So kannst du @home steuern, wann der VPN-Server läuft und kannst ggf. sogar den Zugang vom Homenetz trennen, wenn man einen passenden Router einsetzt. Dann versucht die Arbeit z.B. alle 30min einen Einwahlversuch und du kannst @home den Server aktivieren, wenn du es denn gerade mal brauchst...
 
Zuletzt bearbeitet:
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