oder
Vorwort
Warum dies alles?
Ein Bekannter von mir hat einen Computer. Dieser Bekannte von mir hat viele Fragen, und ist vor allem nun wirklich kein Profi. Leider wohnt er nicht in meiner Stadt. Aber mein Bekannter hat Internet! Somit kam die Idee auf, seinen Rechner mittels RealVNC fernzusteuern, wenn es an's Eingemachte geht. Nach einem nahezu schockierenden Erlebnis (obwohl eine Passwortfrage auf dem fernzusteuernden Rechner installiert war, wurde er pltzlich von einem anderen User bernommen, der auch gleich in das "%Systemroot%" Verzeichns wollte, also da, wo alles Wichtige liegt) machte ich mich kundig, wie man die unverschlsselte und und aus eigener Erfahrung eindeutig unsichere bertragung von VNC absichern kann. Dies kam dabei heraus.
Eine Schritt-fr-Schritt - Anleitung, wie man auch mit wenig Erfahrung einen Tunnel zu einem entfernten Windows-Rechner aufbaut, um diesen dann mit SSH verschlsselt per RealVNC oder TightVNC fernzusteuern. Diese Anleitung bezieht sich wegen des verwendeten freeSSHd lediglich auf fernzusteuernde Windows NT 4.0, Windows 2000 und Windows XP - Systeme. Setzt man ein anderen SSH-Dmonen ein, funktioniert es aber sicherlich auch auf anderen Systemen.
Bezeichnungen
Im Folgenden wird der fernzusteuernde Rechner als Server (er stellt die VNC- und SSH-Dienste zur Verfgung), der fernsteuernde Rechner als Client (er loggt sich ein, um die Dienste zu nutzen) bezeichnet. zurck zum Anfang
1.2. Fr zustzliche Sicherheit kann man unter "Connections" "Only accept connections from the local machine" aktivieren, um wirklich nur Benutzer, die durch den Tunnel auf SSH zugreifen, zuzulassen. Bei "Accept connections on port:" und "Serve Java Viewer via HTTP on port:" kann man auch noch Nicht-Standard-Ports (also andere als 5800 und 5900) angeben, oder "Serve Java Viewer via HTTP on port:" deaktivieren. Eine eventuelle Firewall sollte in jedem Fall so eingestellt sein, dass man vom Internet aus nicht auf diese zwei Ports zugreifen kann (siehe 4.).
2. freeSSHD Einrichten
Hier gilt eigentlich dasselbe wie fr RealVNC: Man ldt auch dieses Programm herunter (hier zu bekommen) und installiert es. Wie RealVNC sollte auch freeSSHd nicht als Server laufen lassen, in diesem Fall knnte ein
Angreifer ebenso versuchen, den Rechner zu bernehmen - und freeSSHd mssen wir fr unser Unterfangen im Gegensatz zu RealVNC vom Internet aus erreichbar machen! 2.1 Unter "Users" erstellt man einen neuen Nutzer mittels "Add" (und nennt ihn natrlich anders als "[User]" ;-) ): 2.2.1 Unter "Authorization:" "Password stored as SHA1 hash" whlen. 2.2.2 Unter "Password" und "Password (again):" zweimal ein bitte sicheres Passwort eintragen. 2.2.3 Dem neuen Benutzer smtliche Rechte ("Shell", "SFTP" und "Tunneling") einrumen.
2.2 Unter "Tunneling" berprft man nun, ob Port Forwarding erlaubt ist. Wahlweise kann fr zustzliche Sicherheit auch noch "but forward only to localhost (127.0.0.1)" bzw. "but bind only to localhost (127.0.0.1)" aktiviert werden. Somit wird verhindert, dass man per SSH auf andere Rechner im Netz als den Server zugreifen kann, oder diese gar auf den Client. (Achtung! freeSSHd 1.0.10 hat einen Bug und speichert diese Einstellung nicht! Also besser 1.0.11 einsetzen!)
2.3 Bei maximaler Paranoia kann man auch unter "SSH" bei "Port:" einen anderen als den Standard-Port 22 eingeben.
3. DynDNS-Dienst Einrichten
Damit der fernzusteuernde Rechner auch immer unter ein und derselben Adresse ber das Internet zu erreichen ist, sollte ein DynDNS-Dienst eingerichtet werden. Ich fr meinen Teil habe immer erfolgreich den Dienst von DynDNS.org genutzt, der zudem von vielen Routern untersttzt wird, und zudem einen einfach zu bedienenden Update-Client fr Windows-Systeme anbietet, der hier herunterzuladen ist.
4. Firewall Einrichten
Da es eine nahezu unendliche Vielfalt an persnlichen Firewalls und Routern mit integrierter Firewall gibt, kann hier keine Universalanleitung angeboten werden, sondern nur die wesentlichen Punkte aufgelistet werden. 4.1 Persnliche Firewall: 4.1.1 freeSSHd muss vom Internet aus erreichbar sein (wenn der Rechner hinter einem Router hngt, reicht fr optimale Sicherheit sogar das eigene Netz aus). 4.1.2 RealVNC muss nur vom Subnetz / eigenen Netz aus erreichbar sein. Will man unterbinden, dass andere Nutzer des eigenen Netzes RealVNC direkt erreichen knnen (z.B. der hackende Bruder oder Nachbarn, die das Netz mitnutzen drfen), so kann man auch nur die Adresse 127.0.0.1 zulassen (das heit nur Nutzer, die selber auf dem Rechner eingeloggt sind, knnen mit RealVNC verbinden). 4.2 In einem Router integrierte Firewall (falls vorhanden): 4.2.1 Es muss ein Portforwarding (manchmal auch "Virtueller Server" genannt) zu dem Rechner eingerichtet werden, der ferngesteuert werden soll. Der weitergeleitete Port ist standardmig 22, wurde er in 2.3 gendert, muss natrlich dieser weitergeleitet werden. 4.2.2 Es empfiehlt sich eventuell aus Sicherheitsgrnden, als externen Port, der auf Port 22 am fernzusteuernden Rechner weitergeleitet wird, nicht den Port 22 zu nehmen um ein wenig zustzliche Sicherheit zu haben. 4.2.3 In jedem Fall sollten die Ports 5800 und 5900 bzw. die Ports aus 1.2 nicht vom Internet aus erreichbar sein! Ansonsten war der ganze Aufwand umsonst! Das war's beim Server! Mittels Shields UP!! kann man bei Bedarf noch austesten, ob bei gestartetem freeSSHd der zugeordnete Port auch wirklich erreichbar ist (das heit er muss als "open" gemeldet werden). zurck zum Anfang
5.2 Unter "Connection" -> "SSH" -> "Tunnels" muss nun noch dafr gesorgt werden, dass der VNC-Viewer auch durch den SSH-Tunnel an den VNC-Server des fernzusteuernden Rechners kommt. Dazu trgt man unter "Source Port" 5900 ein, unter "Destination" 127.0.0.1:5900. Sollte unter 1.2 der 5900-Port gendert worden sein, ist natrlich dieser einzutragen. Hat man nun auf "Add" geklickt, ssollte es so aussehen:
5.3 Nun noch unter "Session" mittels "Save" abspeichern, und fertig ist das Ganze. zurck zum Anfang
6.4 Nach Beendigung der Verbindung Stoppen des VNC-Servers ber Rechtsklick auf das Icon von RealVNC und "Close VNC Server" (falls das noch nicht vom Fernsteuernden erledigt wurde).
6.5 Per Linksklick auf das Icon von freeSSHd unter "Status" mit "Quit" den freeSSHd-Server beenden. Ab Version 1.0.11 geht das hnlich wie bei RealVNC mit Rechtsklick auf das freeSSHd-Icon und "Quit".
Putty hat nun hoffentlich erfolgreich die Verbindung zum Server aufgebaut, und fragt nun nach Login und Passwort. Dazu verwendet man die Daten, die man unter 2.1 auf dem Server eingetragen hat.
Danach landet man in einer ganz normalen "Eingabeaufforderung" - allerdings auf dem ferngesteuerten Rechner! (Anmerkung: Das untige Bild zeigt eine typische Anmeldung, wenn man man public / private keys verwendet. Mehr dazu unter 9.)
Nun ist PuTTY bereit zu tunneln. Also das Fenster erst dann schlieen, wenn man die Arbeit mit VNC beendet hat! 7.2 Man startet nun wie gewohnt mit "VNC Viewer 4" -> "Run VNC Viewer" den VNC Viewer. Als "Server" gibt man localhost oder 127.0.0.1 ein. Der VNC-Viewer verbindet dann mit dem fernsteuernden Rechner an Port 5900, wo ja das eine Ende des nun offenen SSH-Tunnels liegt.
Nachdem VNC den fernzusteuernden Rechner durch den Tunnel erreicht hat, wird nach dem unter 1.1.2 eingegebenen Passwort gefragt.
Hat man das als letzte Hrde eingegeben, startet VNC, und man kann an dem fernzusteuernden Rechner arbeiten, als wre es der eigene. 7.3 Nach Beendigung der Arbeit sollte man am besten erst den VNC-Viewer und dann PuTTY schlieen. Wahlweise kann man auch auf dem ferngesteuerten Rechner den VNC-Server wie unter 6.4 beschrieben direkt schlieen. zurck zum Anfang
Anhang
8. Sicherheit
Der mgliche Angriffspunkt auf das ferngesteuerte System wird vom unverschlsselten VNC auf das verschlsselte SSH umgeleitet. Somit ist deutlich schwerer in das System einzudringen, zudem SSH statt einem Passwort ein Login und ein Passwort verwendet. Generell ist ein Angriff sowieso nur dann mglich, wenn auf dem fernzusteuernden Rechner der SSH-Server (freeSSHd) gestartet wurde. Dennoch sollte fr SSH sicherheitshalber auf "kryptische" Benutzernamen und Passwrter geachtet werden. Richtet man die Port-weiterleitung wie unter 4. beschrieben ein, ist ein direkter Angriff auf VNC vom Internet aus nicht mglich, mit den unter 1.2 angegebenen Einstellungen knnen noch nicht einmal Nutzer des eigenen Netzes (der besagte hackende Bruder) per VNC eine Verbindung aufbauen.
9.2.3 Bei "Path for public keys:" trgt man nun das unter 9.1 erstellte Verzeichnis (standardmig "C:\Programme\freeSSHd\ssh_authorized_keys") ein.
9.3 Nun mssen die Schlssel erzeugt werden. Dies geschieht auf dem Client (oder einem beliebigen Rechner, auf dem PuTTY installiert ist) mithilfe des Programmes "PuTTYgen", das sich im StartmenOrdner von PuTTY findet: 9.3.1 Zuerst kann man unter "Number of bits in generated key:" die Sicherheit der zu erstellenden Schlssel einstellen. Der vorgegebene Wert 1024 ist schon recht gut, kann aber durchaus auch auf 2048 erhht werden. 9.3.2 Nun erstellt man mittels "Generate" einen neuen Schlssel, den man durch das (sinnlose ;-) ) Bewegen des Mauszeigers auf dem leeren Feld auch schn zufllig macht. Das Ganze dauert ein wenig, je nachdem, wie viele Bits der Schlssel haben soll.
9.3.3 Nachdem der Schlssel erstellt wurde, trgt man unter "Key comment:" den Namen des SSH-Users aus 2.1 ein. Unter "Key passphrase:" und "Confirm passphrase" trgt man hier das Passwort ein, das sinnvollerweise dem Passwort aus 2.1 entsprechen kann (aber meines Wissens nach nicht muss).
9.3.4 Mittels "Save private key" speichert man den "private key" in eine Datei (z.B. unter "C:\Programme\PuTTY"). Der Name ist hier im Endeffekt egal, sollte aber die Endung ".ppk" behalten.
9.3.5 Nun erstellt man eine neue, leere Textdatei mittels dem Editor z.B. auf dem Desktop, die wie der Benutzer aus 2.1 heien muss, aber keine Endung haben darf (also "[User]" anstatt "[User].txt"), und ffnet diese. 9.3.5 Nun kopiert man den Inhalt, der unter "Public key for pasting into OpenSSH authorized_keys file:" zu finden ist, in eben diese Datei, und speichert sie ab. (Nicht "Save public key" verwenden, da die so erstellte Datei das falsche Format hat.) 9.4 Die Datei, die den "public key" enthlt, kopiert man nun in den Ordner "ssh_authorized_keys" (also standardmig "C:\Programme\freeSSHd") auf dem Server. Danach sollte man sie aus Sicherheitsgrnden vom Client lschen. 9.5 Letztendlich muss PuTTY auf dem Client noch wissen, dass es einen bestimmten key fr die Verbindung benutzen soll. Dazu geht man auf dem Client bei PuTTY nach Laden des in 5. erstellten Profils auf "Connection" -> "SSH" -> "Auth", und gibt dort unter "Private key file for authentication:" den Ort des privaten Schlssels an.
9.6. Nachdem man unter "Session" mittels "Save" abgespeichert hat, kann man wie gewohnt ber "Open" verbinden, und es sollte dann so aussehen:
11. Fernsteuern eines Rechners, auch wenn kein User eingeloggt ist
Selbstverstndlich kann man freeSSHd und RealVNC auch als Server auf einem Rechner betreiben, so dass beide Programme andauernd auf diesem laufen; in diesem Falle kann man mit dem Rechner verbinden unabhngig davon, ob ein Benutzer eingeloggt ist oder nicht. Allerdings ist dann der SSH-Dmon andauernd zur Seite des Internets offen, was eine gewisse Sicherheitslcke bedeutet, denn wer mit SSH auf einen Rechner zugreifen kann, kann dort allerlei Bldsinn anstellen, vom Installieren von Software, ber Lschen von Dateien, bishin zur Formatierung der Festplatte. Punkt 9. beschreibt allerdings eine Mglichkeit, das ungewollte Einloggen / Hacken unter SSH zustzlich zu erschweren.