39
VPN für Arme - TCP in SSH tunneln mit Putty
Mit relativ einfachen Mitteln - und vor allem kostenlos - kann man beliebige auf TCP basierende Protokolle wie RDP mit einem SSH Tunnel absichern.
So ziemlich jede Firma benötigt / wünscht sichere Zugriffsmöglichkeiten auf interne Ressourcen (Mails, Dateien, Webanwendungen) vom Internet aus. In aller Regel wird dafür VPN eingesetzt. Grosse Firmen setzen dabei meist auf teure Profi-Lösungen wie Cisco ASA. Für kleinere Firmen gibt es kleinere, günstige VPN Server, beispielsweise von Netgear oder auch Draytec.
Die folgende Anleitung soll zeigen, wie man kostenlos und relativ einfach einen Fernzugriff auf interne Ressourcen bewerkstelligen kann.
Was man dafür benötigt:
Die "Idee" (die übrigens weder neu ist, noch von mir stammt) sieht nun so aus, dass der Benutzer, wenn er beispielsweise von zu Hause auf Firmen-Ressourcen zugreifen möchte, per RDP zugreift. Die RDP Verbindung wird zur Erhöhung der Sicherheit in einem SSH Tunnel geschützt. RDP (oder Remote Desktop Protocol) ist eine Anwendung, die Windows XP standardmässig mitbringt.
Einfach in "Start"..."Ausführen" eintippen mstsc und Enter drücken, dann startet der RDP Client schon.
Im folgenden Beispiel hat der firmen-interne SSH Server die IP 195.45.45.4.
Der firmen-interne Desktop-PC hat die IP 195.45.45.10.
Im Beispiel lauscht der SSH Server auf Port 22 (SSH Standard Port). Wie oben beschrieben kann man jedoch auch einen belibigen anderen TCP Port benutzen, der auf dem betreffenden Server noch nicht verwendet wird.
http://img87.imageshack.us/img87/8571/siebenvt9.png
1. Auf dem externen Client PC wird Putty installiert
http://the.earth.li/~sgtatham/putty/latest/x86/putty.exe
2.Putty wird so konfiguriert, dass über den SSH Tunnel der Firmen-Interne Desktop-PC des Mitarbeiters per RDP erreicht werden kann
In der Adresszeile gibt man die IP des SSH Servers den man in der Firma betreibt ein.
Falls der SSH Server hinter einer NAT Firewall sitzt, gibt man in Putty nicht die tatsächliche Firmen-interne Ip des SSH Servers an, sondern natürlich die öffentliche IP des Firmen-Routers, auf dem Anfragen an Port 22 an den SSH Server weitergeleitet werden.
http://img263.imageshack.us/img263/3044/einszk5.png
Unter SSH ... Tunnels gibt man die interne IP-Adresse des Desktop-PCs an, sowie den RDP Port 3389, auf den man per RDP zugreifen möchte. Source Port ist im Beispiel Port 22.
http://img171.imageshack.us/img171/4813/zweieb7.png
Durch Klick auf "ADD" wird die Einstellung in die Liste aufgenommen.
http://img187.imageshack.us/img187/7987/dreivf2.png
Nun bennen wir das erstellte Profil....
http://img172.imageshack.us/img172/8940/vierwh5.png
und speichern es unter einem aussagekräftigen Namen ab.
http://img187.imageshack.us/img187/2123/fuenftc6.png
3. Um auf den Firmen-intenen Desktop zuzugreifen, macht man nun folgendes
1. Putty starten.
2. Das gespeicherte Profil "RDP Verbindung" auswählen
3. Am Firmen-internen SSH Server einloggen mit dem auf dem SSH Server angelegten Benutzernamen/Passwort
4. den lokalen RDP Client starten mit Start...Ausführen...mstsc
5. Der Firmen-interne Desktop-PC (im Beipspiel 195.45.45.10), auf den man zugreifen möchte, muss so konfiguriert sein, dass RDP Zugriffe erlaubt sind. Dazu mache man einen Rechtsklick auf "Arbeitsplatz"..."Eigenschaften"..."Erweitert"..."Remote".
Ferner muss die XP Firewall Zugriff per RDP erlauben (TCP Port 3389).
http://img160.imageshack.us/img160/6696/rdperlaubbx2.png
6. RDP Client Konfiguration:
RDP Client auf dem Remote PC starten mit Start...Ausführen...mstsc
Zur Datenübertragung per RDP muss der lokale RDP Client über die "Optionen" konfiguriert werden:
http://img101.imageshack.us/img101/2323/zehncf8.png
Die RDP Verbindung startet man dann folgendermaßen:
Hinweis: Falls man den SSH Port wie oben beschrieben umgebogen hat, muss man hier den auch den Port wählen, den man als SSH Port definiert hat.
http://img528.imageshack.us/img528/7871/sechsob7.png
Damit starten wir eine stark verschlüsselte Verbindung zum Firmen-internen Desktop-PC, und können auch Dateien von und zum Rechner in der Firma transferien.
Der Vorteil dieser Lösung:
Preisfrage:
Weshalb spart man sich nicht das SSH Brimborium, und schaltet einfach Port 3389 in der Firewall frei und macht direkt RDP?
Kann man freilich machen! RDP verwendet nur eben (derzeit noch) eine Verschlüsselungsvariante die unter "professionellen" Maßstäben (was immer das sein mag) als weniger sicher eingestuft wird. Das tunneln in SSH erhöht also die Sicherheit vor Erschnüffeln der Zugangsdaten.
Andererseits kann man auch tatsächlich RDP Port 3389 auf der Firewall freischalten, aber nur bestimmten Quell-IP-Adressen den Zugang erlauben (über Firewall-Regeln). Dann ist die Gefahr eines feindlichen Zugriffs sehr sehr gering. Wenn man beispielsweise zu Hause immer eine IP aus dem 86.98 er IP-Bereich bekommt, könnte man genau diesen IP-Range auf der Firemenfiirewall für RDP Zugriffe öffnen, und damit einerseits den Komfort geniessen, völlig einfach und bequem per 'RDP auf den Firmenrechner zuzugreifen, und andererseits die Angriffsfläche massiv verkleinern, da eben nur Quell-IPs aus diesem IP-Bereich überhaupt in der Lage sein werden, per RDP zuzugreifen.
Die folgende Anleitung soll zeigen, wie man kostenlos und relativ einfach einen Fernzugriff auf interne Ressourcen bewerkstelligen kann.
Was man dafür benötigt:
- Die öffentliche IP des Firmen-Routers muss entweder eine statische IP-Adresse haben, oder aber einen DynDNS oder www.no-ip.com DNS Eintrag, so dass man das Firmen-Netz von extern jederzeit erreichen kann, auch bei wechselnder DSL IP-Adresse.
- Im Firmen-Intranet muss ein SSH Server stehen. Dies kann ein Linux-System sein (z. B. Suse oder Debian), oder OpenSSH auf Windows. Download OpenSSH für Windows: http://sshwindows.sourceforge.net/download/
- Auf dem SSH Server (Linux) User anlegen und SSH Passwörter definieren mit
adduser hans
passwd hans
*****
adduser fritzchen
passwd fritzchen
*****- Der Port an dem der SSH Server lauscht (per default Port TCP 22) muss an der Firmen Firewall freigeschaltet sein, oder Portforwarding des betreffenden Ports aktiviert sein. TIP: Falls man den SSH Deamon auf einen anderen Port, z. B. 443 ändert, ist gewährleistet, dass man ihn von ÜBERALL erreichen kann, da auch beispielsweise bei öffentlichen WLAN Hotspots dieser Port immer offen ist. Anfragen an den betreffenden Port müssen an den SSH Server weitergeleitet werden, wenn NAT im Einsatz ist. Falls kein NAT im Einsatz ist, muss der betreffende Port und die IP des SSH Serves von extern erreichbar sein. Tip: SSH-Deamon umbiegen auf einen anderen Port geht ganz leicht. In der sshd_config den Eintrag "Port 22" bearbeiten, und einfach den Wunschport eintragen, z. B. "Port 443". Hier der Auszug aus der SSHD Config datei unter /etc/ssh/sshd_config. Man kann auch mehrere Ports angeben, einfach untereinander in die config schreiben, z. B. Port 22 und Port 443. Nach dem Umstellen des SSH Ports muss man den SSH-Deamon noch neu starten mit /etc/init.d/sshd restart.
- Im Firmen-Intranet muss ein Client Rechner bereitstehen, der per RDP erreichbar ist Das kann in der Regel der Desktoprechner sein, den der Benutzer einsetzt, wenn er sich im Büro aufhält.
Die "Idee" (die übrigens weder neu ist, noch von mir stammt) sieht nun so aus, dass der Benutzer, wenn er beispielsweise von zu Hause auf Firmen-Ressourcen zugreifen möchte, per RDP zugreift. Die RDP Verbindung wird zur Erhöhung der Sicherheit in einem SSH Tunnel geschützt. RDP (oder Remote Desktop Protocol) ist eine Anwendung, die Windows XP standardmässig mitbringt.
Einfach in "Start"..."Ausführen" eintippen mstsc und Enter drücken, dann startet der RDP Client schon.
Im folgenden Beispiel hat der firmen-interne SSH Server die IP 195.45.45.4.
Der firmen-interne Desktop-PC hat die IP 195.45.45.10.
Im Beispiel lauscht der SSH Server auf Port 22 (SSH Standard Port). Wie oben beschrieben kann man jedoch auch einen belibigen anderen TCP Port benutzen, der auf dem betreffenden Server noch nicht verwendet wird.
http://img87.imageshack.us/img87/8571/siebenvt9.png
1. Auf dem externen Client PC wird Putty installiert
http://the.earth.li/~sgtatham/putty/latest/x86/putty.exe
2.Putty wird so konfiguriert, dass über den SSH Tunnel der Firmen-Interne Desktop-PC des Mitarbeiters per RDP erreicht werden kann
In der Adresszeile gibt man die IP des SSH Servers den man in der Firma betreibt ein.
Falls der SSH Server hinter einer NAT Firewall sitzt, gibt man in Putty nicht die tatsächliche Firmen-interne Ip des SSH Servers an, sondern natürlich die öffentliche IP des Firmen-Routers, auf dem Anfragen an Port 22 an den SSH Server weitergeleitet werden.
http://img263.imageshack.us/img263/3044/einszk5.png
Unter SSH ... Tunnels gibt man die interne IP-Adresse des Desktop-PCs an, sowie den RDP Port 3389, auf den man per RDP zugreifen möchte. Source Port ist im Beispiel Port 22.
http://img171.imageshack.us/img171/4813/zweieb7.png
Durch Klick auf "ADD" wird die Einstellung in die Liste aufgenommen.
http://img187.imageshack.us/img187/7987/dreivf2.png
Nun bennen wir das erstellte Profil....
http://img172.imageshack.us/img172/8940/vierwh5.png
und speichern es unter einem aussagekräftigen Namen ab.
http://img187.imageshack.us/img187/2123/fuenftc6.png
3. Um auf den Firmen-intenen Desktop zuzugreifen, macht man nun folgendes
1. Putty starten.
2. Das gespeicherte Profil "RDP Verbindung" auswählen
3. Am Firmen-internen SSH Server einloggen mit dem auf dem SSH Server angelegten Benutzernamen/Passwort
4. den lokalen RDP Client starten mit Start...Ausführen...mstsc
5. Der Firmen-interne Desktop-PC (im Beipspiel 195.45.45.10), auf den man zugreifen möchte, muss so konfiguriert sein, dass RDP Zugriffe erlaubt sind. Dazu mache man einen Rechtsklick auf "Arbeitsplatz"..."Eigenschaften"..."Erweitert"..."Remote".
Ferner muss die XP Firewall Zugriff per RDP erlauben (TCP Port 3389).
http://img160.imageshack.us/img160/6696/rdperlaubbx2.png
6. RDP Client Konfiguration:
RDP Client auf dem Remote PC starten mit Start...Ausführen...mstsc
Zur Datenübertragung per RDP muss der lokale RDP Client über die "Optionen" konfiguriert werden:
http://img101.imageshack.us/img101/2323/zehncf8.png
Die RDP Verbindung startet man dann folgendermaßen:
Hinweis: Falls man den SSH Port wie oben beschrieben umgebogen hat, muss man hier den auch den Port wählen, den man als SSH Port definiert hat.
http://img528.imageshack.us/img528/7871/sechsob7.png
Damit starten wir eine stark verschlüsselte Verbindung zum Firmen-internen Desktop-PC, und können auch Dateien von und zum Rechner in der Firma transferien.
Der Vorteil dieser Lösung:
- Kostenlos,
- leicht einrichtbar,
- sicherer SSH TUnnel verhindert das Ersniffen der Anmelde-Daten,
- der Benutzer hat seinen "gewohnten" Desktop zur Verfügung, mit Zugriff auf alle Ressourcen, die er auch im Büro hat.
Preisfrage:
Weshalb spart man sich nicht das SSH Brimborium, und schaltet einfach Port 3389 in der Firewall frei und macht direkt RDP?
Kann man freilich machen! RDP verwendet nur eben (derzeit noch) eine Verschlüsselungsvariante die unter "professionellen" Maßstäben (was immer das sein mag) als weniger sicher eingestuft wird. Das tunneln in SSH erhöht also die Sicherheit vor Erschnüffeln der Zugangsdaten.
Andererseits kann man auch tatsächlich RDP Port 3389 auf der Firewall freischalten, aber nur bestimmten Quell-IP-Adressen den Zugang erlauben (über Firewall-Regeln). Dann ist die Gefahr eines feindlichen Zugriffs sehr sehr gering. Wenn man beispielsweise zu Hause immer eine IP aus dem 86.98 er IP-Bereich bekommt, könnte man genau diesen IP-Range auf der Firemenfiirewall für RDP Zugriffe öffnen, und damit einerseits den Komfort geniessen, völlig einfach und bequem per 'RDP auf den Firmenrechner zuzugreifen, und andererseits die Angriffsfläche massiv verkleinern, da eben nur Quell-IPs aus diesem IP-Bereich überhaupt in der Lage sein werden, per RDP zuzugreifen.
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 62666
Url: https://administrator.de/contentid/62666
Printed on: April 18, 2024 at 13:04 o'clock
39 Comments
Latest comment
Moin!
Schon korrekt. Aber mit den geöffneten Laufwerken hast Du auch gleichzeitig ein Einfallstor für Verseuchungen aller Art, die keine Content Security abfangen kann... Das sollte zumindest jedem Anwender einer solchen Lösung deutlich bewusst sein.
Ansonsten: Super Idee!
Der Vorteil dieser Lösung:
- Kostenlos,
- leicht einrichtbar,
- sicherer SSH TUnnel verhindert das Ersniffen der Anmelde-Daten,
- der Benutzer hat seinen "gewohnten" Desktop zur Verfügung, mit Zugriff auf alle Ressourcen, die er auch im Büro hat.
Schon korrekt. Aber mit den geöffneten Laufwerken hast Du auch gleichzeitig ein Einfallstor für Verseuchungen aller Art, die keine Content Security abfangen kann... Das sollte zumindest jedem Anwender einer solchen Lösung deutlich bewusst sein.
Ansonsten: Super Idee!
Wieso das ?? Es gehen keinerlei CIFS Connections durch den Tunnel sondern nur RDP mit TCP 3389 zum Fernbedienen der lokalen Resourcen !
Als Zusatzlektüre empfiehlt sich in jedem Falle:
http://www.heise.de/netze/artikel/77595/3
Thema: Maulwurf. Dort sieht man auch das es mit
http://www.heise.de/netze/software/download/freesshd/33746
einen SSH Daemon für arme Windows Knechte gibt und ihnen den Umgang mit Linux auf der Serverseite erspart.
Ansonsten klasse Anleitung !
Als Zusatzlektüre empfiehlt sich in jedem Falle:
http://www.heise.de/netze/artikel/77595/3
Thema: Maulwurf. Dort sieht man auch das es mit
http://www.heise.de/netze/software/download/freesshd/33746
einen SSH Daemon für arme Windows Knechte gibt und ihnen den Umgang mit Linux auf der Serverseite erspart.
Ansonsten klasse Anleitung !
Aber mit den geöffneten
Mit nem herkömmlichen VPN Tunnel ist die Gefahr noch grösser, da der VPN Tunnel auch Würmern ermöglicht, sich ins Firmen-Netz zu schiessen, was bei ner RDP Verbindung so ohne weiteres nicht der Fall ist. Andererseits kann ein User über RDP freilich belibige infizierte Dateien von seinem lokalen Rechner auf den Firmenrechner übertragen. So ist das nunmal - doch wenn man die Möglichkeit einer Datenübertragung nicht hat, ist das für den Fernzugriff auch bisschen doof, will man doch des öfteren ne Word-Datei auf seinen lokalen PC kopieren, anstatt immer online zu arbeiten. Dass sowohl remote PC als auch Firmen-PCs mit den üblichen Schutzmechanismen u. Techniken ausgestattet sein sollten, sollte dem Benutzer klar sein. Doch das ist im Grunde ein anderes Thema.
Laufwerken hast Du auch gleichzeitig ein
Einfallstor für Verseuchungen aller Art,
die keine Content Security abfangen kann...
Das sollte zumindest jedem Anwender einer
solchen Lösung deutlich bewusst sein.
Ansonsten: Super Idee!
Einfallstor für Verseuchungen aller Art,
die keine Content Security abfangen kann...
Das sollte zumindest jedem Anwender einer
solchen Lösung deutlich bewusst sein.
Ansonsten: Super Idee!
Mit nem herkömmlichen VPN Tunnel ist die Gefahr noch grösser, da der VPN Tunnel auch Würmern ermöglicht, sich ins Firmen-Netz zu schiessen, was bei ner RDP Verbindung so ohne weiteres nicht der Fall ist. Andererseits kann ein User über RDP freilich belibige infizierte Dateien von seinem lokalen Rechner auf den Firmenrechner übertragen. So ist das nunmal - doch wenn man die Möglichkeit einer Datenübertragung nicht hat, ist das für den Fernzugriff auch bisschen doof, will man doch des öfteren ne Word-Datei auf seinen lokalen PC kopieren, anstatt immer online zu arbeiten. Dass sowohl remote PC als auch Firmen-PCs mit den üblichen Schutzmechanismen u. Techniken ausgestattet sein sollten, sollte dem Benutzer klar sein. Doch das ist im Grunde ein anderes Thema.
Vorweg: Es ging mir nicht darum, diese Idee herabzuwürdigen, die ist bestechend einfach und trotzdem sehr sicher!
Stimmt auffallend!
Das ist im Prinzip das, was ich damit ausdrücken wollte, denn Du hast völlig recht, dass es über einen herkömmlichen VPN-Tunnel viel unangenehmer werden kann.
Mir ging's auch eher darum, darauf hinzuweisen, dass ein Dateitransfer (und nicht die vorgestellte, wie schon gesagt tolle Idee) gewisse Gefahren mit sich bringt. Mein favorisierter Ansatz (zumindest da wo ich zuständig bin, und da ist auch ein entsprechendes Budget vorhanden) ist daher eine Citrix-Verbindung ohne Möglichkeit der Laufwerksverbindung (was sich auch für RDP deaktivieren lässt), und - weil es ja ohne Datenübertragung langweilig ist - einen FTP-Server mit Content-Security in der DMZ.
BTW: Ein FTP-Server sollte mit mit dieser Lösung auch noch betreibbar sein und ein "sicheres" Arbeiten samt Dateiaustausch somit auch möglich sein, oder?
Mit nem herkömmlichen VPN Tunnel ist die Gefahr noch grösser, da der VPN Tunnel auch Würmern ermöglicht, sich ins Firmen-Netz zu schiessen, was bei ner RDP Verbindung so ohne weiteres nicht der Fall ist.
Stimmt auffallend!
Andererseits kann ein User über RDP freilich belibige infizierte Dateien von seinem lokalen Rechner auf den Firmenrechner übertragen. So ist das nunmal - doch wenn man die Möglichkeit einer Datenübertragung nicht hat, ist das für den Fernzugriff auch bisschen doof, will man doch des öfteren ne Word-Datei auf seinen lokalen PC kopieren, anstatt immer online zu arbeiten.
Dass sowohl remote PC als auch Firmen-PCs mit den üblichen Schutzmechanismen u. Techniken ausgestattet sein sollten, sollte dem Benutzer klar sein. Doch das ist im Grunde ein anderes Thema.
Dass sowohl remote PC als auch Firmen-PCs mit den üblichen Schutzmechanismen u. Techniken ausgestattet sein sollten, sollte dem Benutzer klar sein. Doch das ist im Grunde ein anderes Thema.
Das ist im Prinzip das, was ich damit ausdrücken wollte, denn Du hast völlig recht, dass es über einen herkömmlichen VPN-Tunnel viel unangenehmer werden kann.
Mir ging's auch eher darum, darauf hinzuweisen, dass ein Dateitransfer (und nicht die vorgestellte, wie schon gesagt tolle Idee) gewisse Gefahren mit sich bringt. Mein favorisierter Ansatz (zumindest da wo ich zuständig bin, und da ist auch ein entsprechendes Budget vorhanden) ist daher eine Citrix-Verbindung ohne Möglichkeit der Laufwerksverbindung (was sich auch für RDP deaktivieren lässt), und - weil es ja ohne Datenübertragung langweilig ist - einen FTP-Server mit Content-Security in der DMZ.
BTW: Ein FTP-Server sollte mit mit dieser Lösung auch noch betreibbar sein und ein "sicheres" Arbeiten samt Dateiaustausch somit auch möglich sein, oder?
Hi @all,
@einfach-mal-die-klappe-halten
Sehr schönes Tutorial. Hätte es selber nicht besser hinbekommen.
Sowas kann man immer brauchen bzw. die Fragen zu VPN für RemoteControl steigen monatlich an. Somit hast du uns (Bin mir fast sicher) eine Menge Schreibarbeit erspart.
Gruß
Dani
@einfach-mal-die-klappe-halten
Sehr schönes Tutorial. Hätte es selber nicht besser hinbekommen.
Sowas kann man immer brauchen bzw. die Fragen zu VPN für RemoteControl steigen monatlich an. Somit hast du uns (Bin mir fast sicher) eine Menge Schreibarbeit erspart.Gruß
Dani
BTW: Ein FTP-Server sollte mit mit dieser
Lösung auch noch betreibbar sein und ein
"sicheres" Arbeiten samt
Dateiaustausch somit auch möglich sein,
oder?
Lösung auch noch betreibbar sein und ein
"sicheres" Arbeiten samt
Dateiaustausch somit auch möglich sein,
oder?
Ich habs auch garnicht als "Herabwürdigung" empfunden - macht doch Spass, bisschen zu fachsimplen (ich leide leider auch des öfteren unter Klug###eritis.... ein weit verbreiteter Infekt...).
FTP sollte im Prinzip genauso tunnelbar sein, nur muss man da eben Ports 20 und 21 statt 3389 nehmen. Ich benutze ehrlichgesagt FTP garnicht. Weshalb soll ich Anwendungen nutzen, die unverschlüsslete Anmeldedaten als auch Daten übertragen, wenn es genügend sichere Anwendungen wie SSH gibt, die zudem genausoviel kosten und genauso einfach einzurichten sind.
Für reine Datenübertragung wäre SFTP oder SCP das Medium der Wahl.
HTTPS ist auch sicher, aber eben langsamer aufgrund des höheren Protokoll Overheads.
RDP hat - im Vergleich zu Citrix - halt auch den Vorteil der TOTALEN Desktop-Luxus.
Ich "hole" mir meinen Büro Desktop quasi nach hause auf den Monitor.
Bei Citrix muss ich mit den angebotenen Anwendungen arbeiten, was meiner Erfahrung nach viel weniger komfortabel ist. Und die ICA Protokoll Komprimierung macht die Bildschirm-Ausgabe auch schlechter, als dies bei RDP der Fall ist. Ferner ist Citrix fehleranfälliger und komplexer zu administrieren. Mit RDP muss ich ja im Grunde garnichts kaufen, und kaum was wissen, und es läuft superb stabil.
Wenn ich per RDP arbeite, vergesse ich oft sogar, dass ich im Grunde auf einem weit entfernten Rechner arbeite, ich habe tatsächlich das Gefühl, am Firmen-Desktop zu sitzen.
Hi @all,
@einfach-mal-die-klappe-halten
Sehr schönes Tutorial. Hätte es
selber nicht besser hinbekommen. Sowas
kann man immer brauchen bzw. die Fragen zu
VPN für RemoteControl steigen monatlich
an. Somit hast du uns (Bin mir fast sicher)
eine Menge Schreibarbeit erspart.
Gruß
Dani
@einfach-mal-die-klappe-halten
Sehr schönes Tutorial. Hätte es
selber nicht besser hinbekommen.
Sowaskann man immer brauchen bzw. die Fragen zu
VPN für RemoteControl steigen monatlich
an. Somit hast du uns (Bin mir fast sicher)
eine Menge Schreibarbeit erspart.
Gruß
Dani
Danke für die Blumen.
Naja, ich denke mir eben - weshalb soll sich ne 5-Mann Firma vom örtlichen IT-Dienstleister eine überteuerte und meist überdimensionierte VPN Lösung aufschwatzen lassen, wenn das Leben doch so einfach sein kann....
Es gibt meist mehrere Wege zum Ziel - ich stehe auf die einfachen, stabilen Lösungen.
Kommt aber auch immer auf die Bedürfnisse und vor allem Grösse der Firma an, was die "richtige" Lösung ist.
Ich habs auch garnicht als "Herabwürdigung" empfunden - macht doch Spass, bisschen zu fachsimplen (ich leide leider auch des öfteren unter Klug###eritis.... ein weit verbreiteter Infekt...).
Oh, ein Leidensgenosse! Ich sammele bei Freunden und Kollegen auch gern "KS"-Punkte ;o)
FTP sollte im Prinzip genauso tunnelbar sein, nur muss man da eben Ports 20 und 21 statt 3389 nehmen. Ich benutze ehrlichgesagt FTP garnicht. Weshalb soll ich Anwendungen nutzen, die unverschlüsslete Anmeldedaten als auch Daten übertragen, wenn es genügend sichere Anwendungen wie SSH gibt, die zudem genausoviel kosten und genauso einfach einzurichten sind.
Für reine Datenübertragung wäre SFTP oder SCP das Medium der Wahl.
HTTPS ist auch sicher, aber eben langsamer aufgrund des höheren Protokoll Overheads.
Für reine Datenübertragung wäre SFTP oder SCP das Medium der Wahl.
HTTPS ist auch sicher, aber eben langsamer aufgrund des höheren Protokoll Overheads.
Gut, hast recht, antikes FTP ist natürlich im Zusammenhang mit Sicherheit nicht zielführend, streich einfach FTP und setze SFTP oder ein gesichertes Datenübertragungsmedium Deiner Wahl. Wer bin ich, dass ich Dir da Vorschriften machen will? Hauptsache, es macht sich jemand Gedanken um die Content-Security ;oþ
RDP hat - im Vergleich zu Citrix - halt auch den Vorteil der TOTALEN Desktop-Luxus. Ich "hole" mir meinen Büro Desktop quasi nach hause auf den Monitor.
Bei Citrix muss ich mit den angebotenen Anwendungen arbeiten, was meiner Erfahrung nach viel weniger komfortabel ist. Und die ICA Protokoll Komprimierung macht die Bildschirm-Ausgabe auch schlechter, als dies bei RDP der Fall ist. Ferner ist Citrix fehleranfälliger und komplexer zu administrieren. Mit RDP muss ich ja im Grunde garnichts kaufen, und kaum was wissen, und es läuft superb stabil.
Bei Citrix muss ich mit den angebotenen Anwendungen arbeiten, was meiner Erfahrung nach viel weniger komfortabel ist. Und die ICA Protokoll Komprimierung macht die Bildschirm-Ausgabe auch schlechter, als dies bei RDP der Fall ist. Ferner ist Citrix fehleranfälliger und komplexer zu administrieren. Mit RDP muss ich ja im Grunde garnichts kaufen, und kaum was wissen, und es läuft superb stabil.
Aaaalso...
- Desktop: Bei RDP hast Du im Hinblick auf Desktops nur insofern einen Vorteil, dass Du den Desktop auf Deinem Büro-PC unmittelbar nutzen kannst. Den Desktop meines Citrix-Admin-Servers mit allen Werkzeugen, allen Laufwerken und das ganze im Gott-Modus kann ich auch einfach als Anwendung freigeben ;o)
- Desktop: Bei RDP hast Du alles zur Verfügung, was Du am Arbeitsplatz auch zur Verfügung hast. Klaro. Bei Citrix kannst Du (als Citrix-Admin) alle Anwendungen freigeben, die Du für die Administration von zu Hause brauchst und kannst mit ihnen alles machen, was Du zu hause am Bildschirm so treiben möchtest. Auf meinen drei Bildschirmen zu Hause kann ich diverse Konsolen (Hyena, Citrix MC, visionApp Remote, ...) als Seamless Applications über meinen Desktop verteilen, wie ich will ;o)
- Komprimierung: Die Bildschirmausgabe wird allen Ernstes schlechter? *grübel* Moment, ich vergleiche mal... Nö, sorry, ICA-Kompression ist ebenso verlustfrei, wie bei RDP, falls Du JPG-Artefakte haben willst, nimm lieber ein VNC-Derivat mit Kompression! ICA und RDP nehmen sich in der Darstellungsqualität nix, ich bin bei ICA allerdings etwas komfortabler, was Texteingaben angeht, da der ICA-Client die Eingaben schon mal vorsorglich darstellt, bevor das Echo vom Server kommt...
- "Komprimierung": Ach so, was Du meinen könntest, ist die einstellbare Farbtiefe in Citrix. Ganz einfach: Das kannst Du bei RDP und Citrix von 8 Bit bis 24 Bit frei wählen ;oþ Ich persönlich sehe keinen Vorteil mehr darin, Citrix-Applikationen mit 256 Farben zu betreiben, die bekommen 24Bit Farbtiefe und basta.
- Fehleranfälliger: Wie man's nimmt, es ist halt komplexer und hat eine umfangreichere Technik dahinter. Trotzdem kann ich mich in meinen bisherigen Jahren als Citrix-Admin nicht beschweren, dass mir mal 'ne Farm unterm Hintern zusammengekracht wäre. Was ich zugebe ist, dass der Client (ICA-Web-Client) manchmal das Stück Software ist, mit dem man (den Quelltext in 72-Punkt-Schrift in Blei gegossen und in Säcke abgefüllt) den Programmierer verprügeln möchte ;o) Der aktuelle Web-Client 10.0 hat mit manchen Citrix 4.0-Farmen an manchen Client-PCs z.B. ein echtes Problem, das sich nur durch Downgrade auf 9.23 beheben lässt - der nicht mehr zum Download zur Verfügung steht (schlagen wir doch die Web-Admins gleich mit)...
- Komplexer zu administrieren: Natürlich, ein Maschinengewehr ist auch komplizierter, als ein Knüppel, mit beiden kann man Leute stilllegen ;o) Aber wenn eine Citrix-Farm mit entsprechendem Web-Interface da ist, wär's dumm, für die Fernwartung auf die vorhandene Infrastruktur zu verzichten. Zumal da oftmals schon ein Secure Access Gateway oder ähnliches mit Zwei-Faktor-Authentifizierung hinterhängt. Ich hatte ja auch nicht dem kleinen Unternehmen Citrix als Alternative zu Deiner Lösung empfohlen, sondern gesagt, was ich normalerweise tun würde ;o)
- "Mit RDP muss ich ja im Grunde garnichts kaufen, und kaum was wissen, und es läuft superb stabil.": Diesen Satz könnte ich jetzt einfach so stehen lassen. Tu ich auch!
Wenn ich per RDP arbeite, vergesse ich oft sogar, dass ich im Grunde auf einem weit entfernten Rechner arbeite, ich habe tatsächlich das Gefühl, am Firmen-Desktop zu sitzen.
Das kenne ich auch. Wobei ich das auch dann noch kenne, wenn ich in Detmold per Internet über eine Citrix-Farm in Kassel via RDP und 4 MBit-Leitung meinen Arbeitsplatz-Desktop in Detmold fernbediene ;o) Das geht sowas von wunderbar und ist noch nicht mal spürbar langsamer, als RDP allein... Ist zwar im Prinzip 'ne Fernbedienung mit Fernbedienung, hat aber den Vorteil eines Secure Access Gateways und der gesicherten Verbindung nach drinnen. Der Nachteil - wenn man so will - ist, dass die Laufwerksverbindung via RDP nicht mehr klappt, wenn ich sie bei Citrix deaktiviert habe...
Wieso das ?? Es gehen keinerlei CIFS Connections durch den Tunnel sondern nur RDP mit TCP 3389 zum Fernbedienen der lokalen Resourcen !
Ist völlig richtig, wollte ich damit auch gar nicht aussagen, siehe unten...
Gutes Tutorial!
Aber eine Frage (am Rande) bleibt offen: Ich wollte auch RDP tunneln, jedoch scheiterte dies an freeSSHd welches zwar eine SSH Verbindung zulies. Jedoch keine RDP-Verbindung. Wurde das gefixt??
(atm läuft bei mir alles über openSSHd)
MfG
Stephan
Aber eine Frage (am Rande) bleibt offen: Ich wollte auch RDP tunneln, jedoch scheiterte dies an freeSSHd welches zwar eine SSH Verbindung zulies. Jedoch keine RDP-Verbindung. Wurde das gefixt??
(atm läuft bei mir alles über openSSHd)
MfG
Stephan
@Stephan
Mit freeSSHd hab ichs nicht getestet, da RDP durchzutunneln.
Weshalb es nicht funktionieren sollte, wüsste ich nicht.
Im Grunde "müsste" dem SSH Deamon ja egal sein, WAS man da durchtunnelt.
Vielleicht lag der Fehler ja wo anders, und nicht am freeSSHd.
Werde ich bei Gelegenheit mal testen.
Ich benutze jedenfalls nen "normalen" Linux Server, und es flutscht wie frisch gebohnert.
@50240
Danke fuer das ausfuehrliche Kommentar zu Citrix.
Ich kann nur meine rein subjektiven Eindrücke wiedergeben, im direkten Vergleich zw. Citrix wie ich es kenne und eben RDP. Presentation Server 4 ist wahrscheinlich nochmal ne Ecke feiner als die alte Version, die ich kenne.
Mit freeSSHd hab ichs nicht getestet, da RDP durchzutunneln.
Weshalb es nicht funktionieren sollte, wüsste ich nicht.
Im Grunde "müsste" dem SSH Deamon ja egal sein, WAS man da durchtunnelt.
Vielleicht lag der Fehler ja wo anders, und nicht am freeSSHd.
Werde ich bei Gelegenheit mal testen.
Ich benutze jedenfalls nen "normalen" Linux Server, und es flutscht wie frisch gebohnert.
@50240
Danke fuer das ausfuehrliche Kommentar zu Citrix.
Ich kann nur meine rein subjektiven Eindrücke wiedergeben, im direkten Vergleich zw. Citrix wie ich es kenne und eben RDP. Presentation Server 4 ist wahrscheinlich nochmal ne Ecke feiner als die alte Version, die ich kenne.
@50240
Danke fuer das ausfuehrliche Kommentar zu Citrix.
Ich kann nur meine rein subjektiven Eindrücke wiedergeben, im direkten Vergleich zw. Citrix wie ich es kenne und eben RDP. Presentation Server 4 ist wahrscheinlich nochmal ne Ecke feiner als die alte Version, die ich kenne.
Danke fuer das ausfuehrliche Kommentar zu Citrix.
Ich kann nur meine rein subjektiven Eindrücke wiedergeben, im direkten Vergleich zw. Citrix wie ich es kenne und eben RDP. Presentation Server 4 ist wahrscheinlich nochmal ne Ecke feiner als die alte Version, die ich kenne.
Vermutlich ist Dein (optischer) Eindruck schon das, was man in den Citrix-Schulungen so eingetrichtert bekommt ;o) Und Citrix 4.0 und 4.5 sind nicht nur "feiner" als 3, mit vielen tollen neuen Features, sondern in jeder Version für den Hersteller die sprichwörtliche Lizenz zum Geld drucken... Also wer nicht wirklich mit größeren Mengen Anwendungen und Anwendern Server Based Computing betreibt, kommt mit dem RDP-Desktop prima aus...
Hallo!
also alles schön und gut.
Sehr nettes Tutorial. Hätte ich das bloß schon vor 3 Jahren gehabt, hätte ich mir das nicht in mühsamer Kleinarbeit alles aneignen müssen. (naja... hatte auch was für sich...)
Ich persönlich halte dies bei einen kleinen Useranzahl für "fast" das Richtige.
Wir haben diese Lösung mittlerweile durch eine OpenVPN Server auf einem Debiansystem abgelöst. Auch u.A. wg. der Useranzahl. Hierbei kann ich nach Belieben die schönsten Dinge mit anstellen: neue User, abgetrennte Subnetze für jeden Client, unterschiedliche Firewallrestriktionen, revoken was das Zeug hält und auch ne Menge anderer Dinge.
Das Einzige, was anfangs schwer war, war die Installation auf den Clients der Benutzer. Das hab ich durch ein Installationsscript gelöst. (Teils Batch, Teils VBA, usw.).
Werde wenn ich Zeit habe, mal ein Tutorial schreiben, was genau dieses Thema beinhaltet. Wird aber sicherlich vorm Wochenende nicht hinhauen
Drei Sachen noch zum Schluß...
(Die einzigen Schönheitsfehler und auch ein Sicherheitsrisiko bei deiner Lösung!)
1.) In welcher Art und Weise hast du sichergestellt, dass NUR der Port 3389 vom lokalen Netz von und zu deinem SSH Server transportiert wird, so dass man keine anderen Ports tunneln und nutzen kann? Durch Firewallregeln? (Stichwort: Erfindungsreicher und trickreicher Enduser, der sowas mal einfach probiert...)
2.) Was passiert, wenn mal ein Mitarbeiter kündigt oder ein Laptop mit diesem Putty verloren geht? Hat der User sich evtl. sogar das Passwort irgendwo in einer Datei auf dem Desktop aufgeschrieben? Hast du Mittel/Vorkehrungen gegen diese Lücke? Kannst Du sehen und kontrollieren wer gerade und wie lange derjenige schon online ist. Kannst Du den Zugang revoken?
3.) Um die zweite Frage schon fast zu beantworten, arbeite beim SSH-Server doch mit Zertifikaten. Einen SSH-Server im Internet offen stehen zu lassen, der zum Beispiel auch root-Anmeldungen ohne Zertifikat erlaubt, ist höchst kritisch, z.B. durch Brute-Force Attacken. (so wie es bei uns ständig passiert... wir arbeiten mit Zertifikaten.) Schau einfach mal in die Logfiles deines Servers.
Alles im allem ist das Tutorial trotzdem sehr gut, aber es ist auch mit Vorsicht zu genießen.
Wenn man Wert für einen etwas gehobenen Sicherheitsstandard legt (perfekt geht ja fast nie), dann würde ich diese Lösung maximal privat und NICHT bei Firmen einsetzen.
So long,
Gruß Markus
also alles schön und gut.
Sehr nettes Tutorial. Hätte ich das bloß schon vor 3 Jahren gehabt, hätte ich mir das nicht in mühsamer Kleinarbeit alles aneignen müssen. (naja... hatte auch was für sich...)Ich persönlich halte dies bei einen kleinen Useranzahl für "fast" das Richtige.
Wir haben diese Lösung mittlerweile durch eine OpenVPN Server auf einem Debiansystem abgelöst. Auch u.A. wg. der Useranzahl. Hierbei kann ich nach Belieben die schönsten Dinge mit anstellen: neue User, abgetrennte Subnetze für jeden Client, unterschiedliche Firewallrestriktionen, revoken was das Zeug hält
und auch ne Menge anderer Dinge.Das Einzige, was anfangs schwer war, war die Installation auf den Clients der Benutzer. Das hab ich durch ein Installationsscript gelöst. (Teils Batch, Teils VBA, usw.).
Werde wenn ich Zeit habe, mal ein Tutorial schreiben, was genau dieses Thema beinhaltet. Wird aber sicherlich vorm Wochenende nicht hinhauen
Drei Sachen noch zum Schluß...
(Die einzigen Schönheitsfehler und auch ein Sicherheitsrisiko bei deiner Lösung!)
1.) In welcher Art und Weise hast du sichergestellt, dass NUR der Port 3389 vom lokalen Netz von und zu deinem SSH Server transportiert wird, so dass man keine anderen Ports tunneln und nutzen kann? Durch Firewallregeln? (Stichwort: Erfindungsreicher und trickreicher Enduser, der sowas mal einfach probiert...)
2.) Was passiert, wenn mal ein Mitarbeiter kündigt oder ein Laptop mit diesem Putty verloren geht? Hat der User sich evtl. sogar das Passwort irgendwo in einer Datei auf dem Desktop aufgeschrieben? Hast du Mittel/Vorkehrungen gegen diese Lücke? Kannst Du sehen und kontrollieren wer gerade und wie lange derjenige schon online ist. Kannst Du den Zugang revoken?
3.) Um die zweite Frage schon fast zu beantworten, arbeite beim SSH-Server doch mit Zertifikaten. Einen SSH-Server im Internet offen stehen zu lassen, der zum Beispiel auch root-Anmeldungen ohne Zertifikat erlaubt, ist höchst kritisch, z.B. durch Brute-Force Attacken. (so wie es bei uns ständig passiert... wir arbeiten mit Zertifikaten.) Schau einfach mal in die Logfiles deines Servers.
Alles im allem ist das Tutorial trotzdem sehr gut, aber es ist auch mit Vorsicht zu genießen.
Wenn man Wert für einen etwas gehobenen Sicherheitsstandard legt (perfekt geht ja fast nie), dann würde ich diese Lösung maximal privat und NICHT bei Firmen einsetzen.
So long,
Gruß Markus
1.) In welcher Art und Weise hast du
sichergestellt, dass NUR der Port 3389 vom
lokalen Netz von und zu deinem SSH Server
transportiert wird, so dass man keine anderen
Ports tunneln und nutzen kann? Durch
Firewallregeln? (Stichwort: Erfindungsreicher
und trickreicher Enduser, der sowas mal
einfach probiert...)
Stimmt - in dem Tutorial geht es exemplarisch nur um Port 3389.
Ohne weiteres könnte ein User auch andere Dinge tunneln, z. B. POP3, SMTP usw.
Andererseits - sind das nicht alles Dinge, auf die er auch im Intranet Zugriff hat?
Authentisieren muss er sich an der Ressource selber ja eh nochmal, also kann er beim "Fernzugriff" auch nicht mehr als er im Intranet eh dürfte. Er kann also nicht ohne Weiterees auf "alles" zugreifen, er braucht wie immer auch Berechtigungen an den Ressourcen selber.
Man "könnte" jedoch auch auf dem SSH Server filtern, falls man das möchte.
2.) Was passiert, wenn mal ein Mitarbeiter
kündigt oder ein Laptop mit diesem Putty
verloren geht? Hat der User sich evtl. sogar
das Passwort irgendwo in einer Datei auf dem
Desktop aufgeschrieben? Hast du
Mittel/Vorkehrungen gegen diese Lücke?
Kannst Du sehen und kontrollieren wer gerade
und wie lange derjenige schon online ist.
Kannst Du den Zugang revoken?
kündigt oder ein Laptop mit diesem Putty
verloren geht? Hat der User sich evtl. sogar
das Passwort irgendwo in einer Datei auf dem
Desktop aufgeschrieben? Hast du
Mittel/Vorkehrungen gegen diese Lücke?
Kannst Du sehen und kontrollieren wer gerade
und wie lange derjenige schon online ist.
Kannst Du den Zugang revoken?
Wenn ein Mitarbeiter sein Passwort aufs schwarze Brett schreibt - dagegen gibts ausser Erschiessen kein Kraut mit dem man das regeln könnte.
Wird der Benutzer gekündigt oder hat jemand sein SSH Passwort, dann kann man den Benutzer locker vom SSH Server entfernen, oder das Passwort ändern.
3.) Um die zweite Frage schon fast zu
beantworten, arbeite beim SSH-Server doch mit
Zertifikaten. Einen SSH-Server im Internet
offen stehen zu lassen, der zum Beispiel auch
root-Anmeldungen ohne Zertifikat erlaubt, ist
höchst kritisch, z.B. durch Brute-Force
Attacken. (so wie es bei uns ständig
passiert... wir arbeiten mit Zertifikaten.)
Schau einfach mal in die Logfiles deines
Servers.
beantworten, arbeite beim SSH-Server doch mit
Zertifikaten. Einen SSH-Server im Internet
offen stehen zu lassen, der zum Beispiel auch
root-Anmeldungen ohne Zertifikat erlaubt, ist
höchst kritisch, z.B. durch Brute-Force
Attacken. (so wie es bei uns ständig
passiert... wir arbeiten mit Zertifikaten.)
Schau einfach mal in die Logfiles deines
Servers.
Klar gibts gerade auf Port 22 Brute Force Attacken.
Im Tutorial ging es aber darum wie man RDP in SSH tunneln kann.
Dass man SSH auch auf andere Ports umbiegen kann und dass gerade "Standardports" gerne gebruteforced werden, ist nicht das Thema dieses Tutorials.
Statt Zertifikaten kann man auch Key-Authentisierung auf dem SSH Server erzwingen und damit nur bestimmte Keys zulassen, die sich überhaupt per SSH einloggen dürfen, sowie Root Login verbieten. Wenn man komplexe Passwörter u. untypische Anmeldenamen nimmt, ist ne Brute Force Attacke auch nicht gerade erfolgsversprechend.
Hi,
ja ich stimme natürlich in deinen Punkten überein.
Ich habe mehr oder weniger mit meinem Eintrag das Ziel verfolgt, eventuellen "Nachmachern" oder "Newbies" die Problematik noch ein wenig durchschaubarer zu machen (ohne Garantie auf Vollständigkeit natürlich, so wie du treffend geantwortet hast).
Es ist halt meistens nicht alles auf den ersten Blick so einfach wie es dann scheint. ;)
Ich denke, dass das Thema in diesem Tutorial ziemlich gut und auch anschaulich beschrieben ist!
*THUMBS UP*
Gruß und einen schönen Feierabend
Markus
ja ich stimme natürlich in deinen Punkten überein.
Ich habe mehr oder weniger mit meinem Eintrag das Ziel verfolgt, eventuellen "Nachmachern" oder "Newbies" die Problematik noch ein wenig durchschaubarer zu machen (ohne Garantie auf Vollständigkeit natürlich, so wie du treffend geantwortet hast).
Es ist halt meistens nicht alles auf den ersten Blick so einfach wie es dann scheint. ;)
Ich denke, dass das Thema in diesem Tutorial ziemlich gut und auch anschaulich beschrieben ist!
*THUMBS UP*
Gruß und einen schönen Feierabend
Markus
Gutes Tutorial!
Aber eine Frage (am Rande) bleibt offen: Ich
wollte auch RDP tunneln, jedoch scheiterte
dies an freeSSHd welches zwar eine SSH
Verbindung zulies. Jedoch keine
RDP-Verbindung. Wurde das gefixt??
(atm läuft bei mir alles über
openSSHd)
MfG
Stephan
Aber eine Frage (am Rande) bleibt offen: Ich
wollte auch RDP tunneln, jedoch scheiterte
dies an freeSSHd welches zwar eine SSH
Verbindung zulies. Jedoch keine
RDP-Verbindung. Wurde das gefixt??
(atm läuft bei mir alles über
openSSHd)
MfG
Stephan
Hallo Stephan,
stehe genau vor dem gleichen Problem mit Freeshd wie du. Ich komme in die SHELL des Servers, allerdings lässt er RPD auf Port 3389 bzw. nichts anderes zu.
Du sagst mit OpenSSH funktioniert? Ich glaube ich habe heute noch nicht ausgeschlafen, aber ich finde von OpenSSH keinen Installer für Windows. Gibt es dort auch ein GUI oder ist OpenVPN ausschließlich befehlszeilenorientiert?
Ich könnte es bei Gelegenheit mal mit freeSSHd probieren.
OpenSSH für Windows gibts hier:
http://sshwindows.sourceforge.net/download/
Da musst aber die Anleitung lesen, damit man die lokalen Windows User zu ssh usern macht. So hab ich das zumindest in Erinnerung.
Alternative: Irgend ein kleines Linux als virtuelle Maschine laufen lassen, zb. DamnSmallLinux ist echt mickrig klein und ruckzuck startklar. Das Ding braucht ja nur nen SSH-Deamon, sonst so gut wie nix.
OpenSSH für Windows gibts hier:
http://sshwindows.sourceforge.net/download/
Da musst aber die Anleitung lesen, damit man die lokalen Windows User zu ssh usern macht. So hab ich das zumindest in Erinnerung.
Alternative: Irgend ein kleines Linux als virtuelle Maschine laufen lassen, zb. DamnSmallLinux ist echt mickrig klein und ruckzuck startklar. Das Ding braucht ja nur nen SSH-Deamon, sonst so gut wie nix.
hi,
ich hab nicht ganz kapiert, um welche Laufwerke es sich handelt Aber mit den geöffneten Laufwerken hast Du auch gleichzeitig ein Einfallstor für Verseuchungen aller Art, die keine Content Security abfangen kann...
Falls ihr das Clientmapping meint, dann kann man dies ja ganz einfach per GPO deaktivieren!
ich hab nicht ganz kapiert, um welche Laufwerke es sich handelt Aber mit den geöffneten Laufwerken hast Du auch gleichzeitig ein Einfallstor für Verseuchungen aller Art, die keine Content Security abfangen kann...
Falls ihr das Clientmapping meint, dann kann man dies ja ganz einfach per GPO deaktivieren!
Gemeint ist der Zugriff von einem Desktop PC in der Firma auf die Laufwerke des externen Remote Clients. Über RDP kann man ja darauf zugreifen,und damit wäre es möglich, infizierte Dateien auf den Firmen-Desktop PC zu übertragen.
Wenn man das untersagt, kann man keine Dateien mehr vomoder zum Remote Client senden, was aber in vielen Fällen notwendig ist.
Wenn man das untersagt, kann man keine Dateien mehr vomoder zum Remote Client senden, was aber in vielen Fällen notwendig ist.
Hallo,
zu dem HowTo habe ich noch eine andere Frage.
Könnte man mit einem Linux(SSH-Server) auch eine Authentizierung auf einen Radius-Server(Windows) mit Token (Safeword) erzwingen.
Wenn ja, was braucht man dafür, bzw. wo kann ich eine brauchbare Anleitung finden.
Ich habe nämlich einmal eine kommerzielle Lösung (SSL-Gateway von Sonicwall) getestet und war mit der
Geschwindigkeit nicht zufrieden. Eine SSL-Verbindung auf unseren Mailserver im Netz (ebenfalls SSL) war grottenlangsam. Scheinbar war das zuviel für das Gateway... erst SSL auspacken dann wieder einpacken.
Grund für den Einsatz der Lösung war eigentlich das man sicher erst einmal mit dem Token anmeldet und dann
erst weitergeleitet wird. Man hätte zwar den Mailserver direkt per SSL ansprechen können, aber der kann eben auch
keine Tokenabfrage
Die hier angesprochenen Lösungen mit Zertifikat ist ja nur etwas, wenn man ein Laptop im Einsatz hat.
Aus einem Hotel-PC, das ist bei uns beliebt, geht das nicht.
Das wäre sicher auch eine tolle Sache für kreative Tuxe. Eine kleine Minidistri, die ähnlich wir IP-Cop nur
eine Funktion "SSL-Gateway" bereitstellt, mit allen Möglichkeiten die eine kommerzielle Lösung bietet.
Hätte ich nur mehr Ahnung davon...dann wäre das mein nächstes Projekt...
Jörg
zu dem HowTo habe ich noch eine andere Frage.
Könnte man mit einem Linux(SSH-Server) auch eine Authentizierung auf einen Radius-Server(Windows) mit Token (Safeword) erzwingen.
Wenn ja, was braucht man dafür, bzw. wo kann ich eine brauchbare Anleitung finden.
Ich habe nämlich einmal eine kommerzielle Lösung (SSL-Gateway von Sonicwall) getestet und war mit der
Geschwindigkeit nicht zufrieden. Eine SSL-Verbindung auf unseren Mailserver im Netz (ebenfalls SSL) war grottenlangsam. Scheinbar war das zuviel für das Gateway... erst SSL auspacken dann wieder einpacken.
Grund für den Einsatz der Lösung war eigentlich das man sicher erst einmal mit dem Token anmeldet und dann
erst weitergeleitet wird. Man hätte zwar den Mailserver direkt per SSL ansprechen können, aber der kann eben auch
keine Tokenabfrage
Die hier angesprochenen Lösungen mit Zertifikat ist ja nur etwas, wenn man ein Laptop im Einsatz hat.
Aus einem Hotel-PC, das ist bei uns beliebt, geht das nicht.
Das wäre sicher auch eine tolle Sache für kreative Tuxe. Eine kleine Minidistri, die ähnlich wir IP-Cop nur
eine Funktion "SSL-Gateway" bereitstellt, mit allen Möglichkeiten die eine kommerzielle Lösung bietet.
Hätte ich nur mehr Ahnung davon...dann wäre das mein nächstes Projekt...
Jörg
Ich denk das könnte man relativ einfach beispielsweise über Radius machen.
Der Client sendet seine Anmeldedaten an den SSH Server, und dieser gibt die Anfrage an den RAdius Client weiter, der wiederum mittels Radiusprotokoll mit dem Token-Server kommuniziert.
Geht so zumindest mit RSA Radius Server (RSA SecurID).
Ja, auf unsicheren PCs in Hotels ist es wohl tatsächlich keine gute Idee, "sensible" Passworte eingeben zu müssen. Ist andererseits immer eine Abwegung zwischen Aufwand und Sicherheitsgewinn. Meist ist der Aufwand höher als der Sicherheitsgewinn. Bei ner Bank beispielsweise ist Sicherheit das Wichtigste. Bei ner kleinen Schreinerei-Klitsche sind die Daten jedoch weniger spannend, als dass man mit überzogenen Sicherheitsvorstellungen Geld verbrennen sollte.
Der Client sendet seine Anmeldedaten an den SSH Server, und dieser gibt die Anfrage an den RAdius Client weiter, der wiederum mittels Radiusprotokoll mit dem Token-Server kommuniziert.
Geht so zumindest mit RSA Radius Server (RSA SecurID).
Ja, auf unsicheren PCs in Hotels ist es wohl tatsächlich keine gute Idee, "sensible" Passworte eingeben zu müssen. Ist andererseits immer eine Abwegung zwischen Aufwand und Sicherheitsgewinn. Meist ist der Aufwand höher als der Sicherheitsgewinn. Bei ner Bank beispielsweise ist Sicherheit das Wichtigste. Bei ner kleinen Schreinerei-Klitsche sind die Daten jedoch weniger spannend, als dass man mit überzogenen Sicherheitsvorstellungen Geld verbrennen sollte.
Ja, danke für die Antwort.
Werde ich mal ausprobieren.
Jörg
Werde ich mal ausprobieren.
Jörg
Moin Leute,
bin hier in einer Firma, wo das ganze System schon so läuft wie beschrieben. Mit LINUX Suse. Dieser startet beim booten einen VPN und ein Z.E.U.S. Internet Gateway 3.5.
Wenn der Bootvorgang abgeschlossen ist, steht "login:"
wie lege ich hier neue User an? Ich komme aus diesem ZEUS nicht raus.
Bin in Sachen LINUX bisher noch absolut nicht fit. Das muss sich schnellstens ändern.
Vielen Dank für Hilfe
bin hier in einer Firma, wo das ganze System schon so läuft wie beschrieben. Mit LINUX Suse. Dieser startet beim booten einen VPN und ein Z.E.U.S. Internet Gateway 3.5.
Wenn der Bootvorgang abgeschlossen ist, steht "login:"
wie lege ich hier neue User an? Ich komme aus diesem ZEUS nicht raus.
Bin in Sachen LINUX bisher noch absolut nicht fit. Das muss sich schnellstens ändern.
Vielen Dank für Hilfe
alternativ könnte man z.b. Heimarbeitsplätzen oder sog. "Road-Warriors" einen OpenVPN-Client einrichten. So braucht man nur den/ die OpenVPN-Port(s) freischalten.. denn Port 3389 ist gut bekannt.. und die Port-Spoofer schlafen nicht..
OpenVPN ist ebenfalls kostenlos, und bietet einen kompletten Port-Bereich wie im LAN..
Den OVPN-Client auf die Workstations, den OVPN-Server auf den File, bzw. DC und schon funktioniert das... habe ich hier auch so realisiert
OpenVPN ist ebenfalls kostenlos, und bietet einen kompletten Port-Bereich wie im LAN..
Den OVPN-Client auf die Workstations, den OVPN-Server auf den File, bzw. DC und schon funktioniert das... habe ich hier auch so realisiert
"Im folgenden Beispiel hat der firmen-interne SSH Server die IP 195.45.45.4.
Der firmen-interne Desktop-PC hat die IP 195.45.45.10. "
Mus auch der firmen-interne Desktop-PC eine Öffentliche IP Adresse haben?
Der firmen-interne Desktop-PC hat die IP 195.45.45.10. "
Mus auch der firmen-interne Desktop-PC eine Öffentliche IP Adresse haben?
wenn du den direkten Weg vom Internet haben willst ja.. wobei der Desktop-PC dann in eriner DMZ hängen würde, was ich nicht empfehle,
wenn du Routest, kannst Du den Port durch die Firewall direkt an den Arbeitsplatz routen.. somit gibt es nur eine öffentliche IP, an dem aber verschieden andere Geräte dranhängen.. nur der Port leitet halt weiter
wenn du Routest, kannst Du den Port durch die Firewall direkt an den Arbeitsplatz routen.. somit gibt es nur eine öffentliche IP, an dem aber verschieden andere Geräte dranhängen.. nur der Port leitet halt weiter
Hallo DocDOS!
Danke für deine Antwort. Habe noch zwei fragen:
1. Wen ich zB. 50 Clients habe, die alle mit privaten IP Adressen belegt sind, wie wird’s dann funktionieren? Wird es einfach durch User anlegen in SSH Server genügen.
2. Ich vermute das der SSH Server zwei Netzwerkkaten haben muss: mit dem externe NIC und öffentliche IP an Firewall angeschlossen, weil mit interne NIC und private IP an Switch oder Intranet. Stimmt?
Mit freundlichen Grüßen,
buzuku
Danke für deine Antwort. Habe noch zwei fragen:
1. Wen ich zB. 50 Clients habe, die alle mit privaten IP Adressen belegt sind, wie wird’s dann funktionieren? Wird es einfach durch User anlegen in SSH Server genügen.
2. Ich vermute das der SSH Server zwei Netzwerkkaten haben muss: mit dem externe NIC und öffentliche IP an Firewall angeschlossen, weil mit interne NIC und private IP an Switch oder Intranet. Stimmt?
Mit freundlichen Grüßen,
buzuku
Hallo DocDOS!
Danke für deine Antwort. Habe noch zwei
fragen:
1. Wen ich zB. 50 Clients habe, die alle mit
privaten IP Adressen belegt sind, wie
wird’s dann funktionieren? Wird es
einfach durch User anlegen in SSH Server
genügen.
Am Besten ist es, du lässt dir für den SSH-Server ein Zertifikat ausstellen und fügst es dort ein. Die Clients versorgst Du mit dem gleichen Zertifikat. Normalerweise sollte aber User im SSH-Server anlegen genügen.. der Zertifikatsaustausch müsste eigendlich dann automatisch erfolgen.
2. Ich vermute das der SSH Server zwei
Netzwerkkaten haben muss: mit dem externe NIC
und öffentliche IP an Firewall
angeschlossen, weil mit interne NIC und
private IP an Switch oder Intranet. Stimmt?
Netzwerkkaten haben muss: mit dem externe NIC
und öffentliche IP an Firewall
angeschlossen, weil mit interne NIC und
private IP an Switch oder Intranet. Stimmt?
Wenn Deine Firewall gleichzeitig den SSH-Server stellt hast Du recht.. mit IPCop geht das sogar ganz leicht, der hat sogar einen funktionierenden SSH-Server bereits eingebaut.
Mit freundlichen Grüßen,
buzuku
buzuku
"Im folgenden Beispiel hat der
firmen-interne SSH Server die IP
195.45.45.4.
Der firmen-interne Desktop-PC hat die IP
195.45.45.10. "
Mus auch der firmen-interne Desktop-PC eine
Öffentliche IP Adresse haben?
Nein, das war nur ein Beispiel, FALLS man in der Firma öffentliche IPs verwendet.
Falls intern private IPs benutzt werden, macht man - wie in der Anleitung beschrieben- Portforwarding auf dem Router klar. Der SSH Server braucht auch keine zweite Netzwerkkarte. Bei mehreren Usern die auch Files transferieren wollen wäre jedoch ein Gigabitinterface keine schlechte Idee. Bei 50 Usern weiss ich nicht ob ic die RDP-in-SSH Lösung nehmen würde, da wäre eine der üblichen VPN Lösungen wohl besser geeignet. Schliesslich müssten ja sonst in der Firma ständig 50 Desktop PCs laufen, und allein der STrom den die Saugen macht eine VPN Lösung in dem Fall billiger. Die RDP-in-SSH Lösung macht eher Sinn bei ner Handvoll Usern.
helo ..
stefan hatte hier glaub probleme mit dem " freeSSHd Server ", dass hatte ich auch,
doch ich habe herausgefunden das wen man z.b.p RDP über SSH tunnelt.
man konfigurier in putty das port forwarding anders:
und zwar so:
Source port = 22
Destination = 127.0.0.1:3389
danach mit dem rdp client eine verbindung zu localhost:22
danach sollte es auch mit " freeSSHd Server " funktionieren.
denke das ist wohl am server dass das port forwarding localhost:und an den remote port 3389 geleitet werden muss.
für ein call wäre ich froh.
lowbyte
stefan hatte hier glaub probleme mit dem " freeSSHd Server ", dass hatte ich auch,
doch ich habe herausgefunden das wen man z.b.p RDP über SSH tunnelt.
man konfigurier in putty das port forwarding anders:
und zwar so:
Source port = 22
Destination = 127.0.0.1:3389
danach mit dem rdp client eine verbindung zu localhost:22
danach sollte es auch mit " freeSSHd Server " funktionieren.
denke das ist wohl am server dass das port forwarding localhost:und an den remote port 3389 geleitet werden muss.
für ein call wäre ich froh.
lowbyte
So erst mal vielen Dank für das tolle Tut ;)
Habe das wie oben beschrieben ausprobiert und es funktioniert auch fast..
Also, per Putty und ssh einloggen funktioniert auch super.
Dann per mstsc lokalhost:22 funktioniert auch so weit..
Ich sehe den Anmeldebildschirm. Geb mein Benutzername und Passwort ein und ab dann wird alles schwarz..
Kurze Zeit darauf beendet er die RPD Verbindung mit folgendem Fehler:
The Connection was ended because of a network error. Pls try connecting to the remote computer again..
Mit normaler IP Eingabe also ohne SSH funktioniert es noch.
Irgendwas muss ich falsch machen..
Habe auf meinem XP SP3 via VMWARE Xubuntu installiert auf dem läuft der ssh.
und per RPD will ich auf den XP Rechner.
Vielleicht kann mir einer helfen.
Habe das wie oben beschrieben ausprobiert und es funktioniert auch fast..
Also, per Putty und ssh einloggen funktioniert auch super.
Dann per mstsc lokalhost:22 funktioniert auch so weit..
Ich sehe den Anmeldebildschirm. Geb mein Benutzername und Passwort ein und ab dann wird alles schwarz..
Kurze Zeit darauf beendet er die RPD Verbindung mit folgendem Fehler:
The Connection was ended because of a network error. Pls try connecting to the remote computer again..
Mit normaler IP Eingabe also ohne SSH funktioniert es noch.
Irgendwas muss ich falsch machen..
Habe auf meinem XP SP3 via VMWARE Xubuntu installiert auf dem läuft der ssh.
und per RPD will ich auf den XP Rechner.
Vielleicht kann mir einer helfen.
hmm.. schwierig.. da müsste man genau wissen, was Du da sonst noch so eingestellt hast.
Ich habe mal einen ähnlichen Fall gehabt, und hab damals festgestellt, daß es an der VMware Workstation lag. Nachdem ich die Flat-Files der VM auf nen Server geparkt hatte und dort die VM mittels VMware-Player gestartet hatte, lief es problemlos..
Könnte aber auch sein, daß eine Verbindung auf localhost nicht hinhaut, denn für die SSL-Verbindung und RDP ist Deine VM ja nicht "er selber" sondern ein PC irgendwo im LAN.
Ich habe mal einen ähnlichen Fall gehabt, und hab damals festgestellt, daß es an der VMware Workstation lag. Nachdem ich die Flat-Files der VM auf nen Server geparkt hatte und dort die VM mittels VMware-Player gestartet hatte, lief es problemlos..
Könnte aber auch sein, daß eine Verbindung auf localhost nicht hinhaut, denn für die SSL-Verbindung und RDP ist Deine VM ja nicht "er selber" sondern ein PC irgendwo im LAN.
Hallo Spacyfreak,
tolles Tut. Vor allem, weil es so einfach ist. Die einfachen Lösungen, die mit einfachen Boardmitteln zu erreichen sind, werden nämlich meistens vergessen.
sapcoach
tolles Tut. Vor allem, weil es so einfach ist. Die einfachen Lösungen, die mit einfachen Boardmitteln zu erreichen sind, werden nämlich meistens vergessen.
sapcoach
Hallo,
wir haben im Büro 4 Clients die mittels LAN an einen Dlink Router (Dlink 624+) angeschlossen sind. Es gibt also keinen Server. Die Clients werden mit den dynamischen IP-Adressen von dem Router DHCP versorgt.
Hätte man auch unter diesen bescheidenen Umständen VPN einzurichten? Wohl nicht, weil der SSL-Server irgendwo laufen müsste.
Frage: Angenommen, dass wir einen Server kaufen würde, wie leistungsfähig sollte es sein? Für die SSL selbst würde wohl ein älterer Büropc ausreichen, oder?
Die Betriebsystem sind sonst gemischt. An drei PCs laufen Windows XP Pro und an einem Windows 7 64bit...
Danke für die Info.
Gr. I.
wir haben im Büro 4 Clients die mittels LAN an einen Dlink Router (Dlink 624+) angeschlossen sind. Es gibt also keinen Server. Die Clients werden mit den dynamischen IP-Adressen von dem Router DHCP versorgt.
Hätte man auch unter diesen bescheidenen Umständen VPN einzurichten? Wohl nicht, weil der SSL-Server irgendwo laufen müsste.
Frage: Angenommen, dass wir einen Server kaufen würde, wie leistungsfähig sollte es sein? Für die SSL selbst würde wohl ein älterer Büropc ausreichen, oder?
Die Betriebsystem sind sonst gemischt. An drei PCs laufen Windows XP Pro und an einem Windows 7 64bit...
Danke für die Info.
Gr. I.
Hallo,
auch auf die Gefahr hin, dass ich nciht so ganz verstanden habe, wozu Du jetzt nen VPN im LAN brauchst.. ich gehe mal davon aus, dass Du nen Zugang von Extern auf euer LAN haben willst, oder?
für dieses Vorhaben benötigst Du mindestens Folgendes:
- einen PC mit Linux (Distribution wäre egal), Leistungsklasse: Pentium II ab 266 MHz, 64 MB RAM, HDD größer 2 GB, von Linux unterstützte Netzwerkkarte (statische IP)
- OpenVPN Server-Installation auf diesem PC
- falls benötigt DynDNS-Account mit einem gültigen Host
- Port-Forwarding (meistens Port 1194 UDP) zum obigen Linux-PC
Also die Anschaffung einer teuren Serverhardware würde ich nicht empfehlen, weil diese Leistungsklasse wiet über das Ziel hinaus schießt.
Schau Dir auch mal als Alternative die Linux-Distribution IPCOP an (www.ipcop.org). Somit könnte euer Router auch gleich in Rente gehen, da der IPcop Firewall, Router, (Open)VPN-, DHCP-Server und Web-Proxy beinhaltet. Einfach zu steuern übers Web... und das Beste ist, es kostet noch nicht mal was..
Gruß
Doc
auch auf die Gefahr hin, dass ich nciht so ganz verstanden habe, wozu Du jetzt nen VPN im LAN brauchst.. ich gehe mal davon aus, dass Du nen Zugang von Extern auf euer LAN haben willst, oder?
für dieses Vorhaben benötigst Du mindestens Folgendes:
- einen PC mit Linux (Distribution wäre egal), Leistungsklasse: Pentium II ab 266 MHz, 64 MB RAM, HDD größer 2 GB, von Linux unterstützte Netzwerkkarte (statische IP)
- OpenVPN Server-Installation auf diesem PC
- falls benötigt DynDNS-Account mit einem gültigen Host
- Port-Forwarding (meistens Port 1194 UDP) zum obigen Linux-PC
Also die Anschaffung einer teuren Serverhardware würde ich nicht empfehlen, weil diese Leistungsklasse wiet über das Ziel hinaus schießt.
Schau Dir auch mal als Alternative die Linux-Distribution IPCOP an (www.ipcop.org). Somit könnte euer Router auch gleich in Rente gehen, da der IPcop Firewall, Router, (Open)VPN-, DHCP-Server und Web-Proxy beinhaltet. Einfach zu steuern übers Web... und das Beste ist, es kostet noch nicht mal was..
Gruß
Doc
@DocDOS
Das ist Unsinn so einen PC Boliden dahinzustellen.... ein 20 Euro Router mit OpenVPN tut es auch:
OpenVPN Server installieren auf pfSense Firewall, Mikrotik. DD-WRT oder GL.inet Router
Oder wer etwas basteln will:
OpenWRT Low Cost Router für LAN bzw. VLAN Routing inklusive OpenVPN Server
Zudem haben heute viele billige Consumer Router wie z.B. die von Draytek oder auch Fritzboxen u.a. von sich aus VPN Support schon gleich mit an Bord.
Wenn man sich also vorher nur ein paar Gedanken zum Thema VPN macht und nicht gleich kritiklos den billigsten Mist wie Dlink 624+ u.a.beschafft, stellt sich einem das Problem der VPN HW gar nicht erst !!!
Das ist Unsinn so einen PC Boliden dahinzustellen.... ein 20 Euro Router mit OpenVPN tut es auch:
OpenVPN Server installieren auf pfSense Firewall, Mikrotik. DD-WRT oder GL.inet Router
Oder wer etwas basteln will:
OpenWRT Low Cost Router für LAN bzw. VLAN Routing inklusive OpenVPN Server
Zudem haben heute viele billige Consumer Router wie z.B. die von Draytek oder auch Fritzboxen u.a. von sich aus VPN Support schon gleich mit an Bord.
Wenn man sich also vorher nur ein paar Gedanken zum Thema VPN macht und nicht gleich kritiklos den billigsten Mist wie Dlink 624+ u.a.beschafft, stellt sich einem das Problem der VPN HW gar nicht erst !!!
@aqui
Mag vielleicht etwas heftig klingen, aber 1. traue ich den LinkSys-Routern nicht über den Weg (teilweise gewaltig instabil und besonders schnell sind die auch nicht immer) und 2. kann man mit IPCop noch wesentlich mehr anstellen..
Außerdem war das eine Beispiel-Konfiguration, natürlich tut es auch was kleineres, je nach Anforderung und Größe des zu schützenden Netzwerks.. aber bitte immer bedenken, dass jedes Datenpaket bei OpenVPN per Software verschlüsselt wird und das entsprechend Datenleistung braucht. Bringt irgendwie nix, wenn 20 Leute gleichzeitig per OpenVPN-Client eingeloggt sind und der Datendurchsatz höllisch in die Knie geht (ist mir mit einem LinkSys-Router schon passiert, sollte 1 GBit von Netz A nach Netz B bringen hatte aber makimal nur 4 MB/s durchgelassen)
Mag vielleicht etwas heftig klingen, aber 1. traue ich den LinkSys-Routern nicht über den Weg (teilweise gewaltig instabil und besonders schnell sind die auch nicht immer) und 2. kann man mit IPCop noch wesentlich mehr anstellen..
Außerdem war das eine Beispiel-Konfiguration, natürlich tut es auch was kleineres, je nach Anforderung und Größe des zu schützenden Netzwerks.. aber bitte immer bedenken, dass jedes Datenpaket bei OpenVPN per Software verschlüsselt wird und das entsprechend Datenleistung braucht. Bringt irgendwie nix, wenn 20 Leute gleichzeitig per OpenVPN-Client eingeloggt sind und der Datendurchsatz höllisch in die Knie geht (ist mir mit einem LinkSys-Router schon passiert, sollte 1 GBit von Netz A nach Netz B bringen hatte aber makimal nur 4 MB/s durchgelassen)
Ich hab alles so gemacht wie esoben steht. Zwar unter Windows 7 und zusamen mit einem Linux Server wo SSH sowieso läuft (allerdings ein einer VIRTUELLEN MASCHINE), ich bekom allerdings beim Verbinden mit RDP einen schwarzen Bildschirm bzw. kurz den Desktop gezeigt und dann nichts mehr. SSH und RDP reagiert nicht und die Verbindung wird unterbrochen. Woran kann das liegen?
@vBurak
Wie in deinem Originalthread zu diesem Thema
RDP über SSH Tunnel
ist das mit sehr großer Wahrscheinlichkeit ein nicht gelöstes MTU Problem auf den beteiligten Geräten !
Wie in deinem Originalthread zu diesem Thema
RDP über SSH Tunnel
ist das mit sehr großer Wahrscheinlichkeit ein nicht gelöstes MTU Problem auf den beteiligten Geräten !
