Als die ersten Programme zur Fernsteuerung von Computern aufkamen, ging es meist um den halbwegs schnellen Zugriff auf den eigenen Rechner über quälend langsame Telefonleitungen und analoge Modems mit 9600 Bit pro Sekunde. Das war die Geburtsstunde von Programmen wie PC Anywhere, Carbon Copy oder Remotely-Anywhere. Mittlerweile bringt jede Windows-Version mit dem Remote-Desktop eine eigene Möglichkeit für diese Form des Zugangs mit. Allerdings ist die Basis des Remote Desktop – das RDP-Protokoll – nur sehr rudimentär implementiert und muss bei Cross-Plattform-Einsätzen ohnehin passen.
Doch zum Glück gibt es VNC. VNC steht für Virtual Network Computing und wurde von Mitarbeitern eines AT&T Labors (heute Olivetti & Oracle Research Laboratory) entwickelt. VNC arbeitet mit einem RFB genannten Protokoll (Remote Framebuffer), das vollkommen unabhängig von Betriebssystem, Window-Manager und Anwendung eingesetzt werden kann. So gibt es mittlerweile Client-Implementationen für alle Windows-Varianten einschließlich Windows Mobile, verschiedene Unix- und Linux-Derivate, Palm OS, Netware, Mac OS, Java, DOS, OS/2, RiscOS und BeOS. Server sind für Unix, Windows, Netware, Symbian und Mac OS verfügbar. Auch wenn die Implementationen von verschiedenen Quellen stammen, so ist, zumindest wenn es um die Basisfunktion geht, durch die Verwendung von RFB das problemlose Zusammenspiel zwischen Client- und Server-Software sichergestellt, egal unter welchem Betriebssystem.
Der VNC-Server leitet die Ausgabe des Displays auf einen TCP-Port weiter, per Default ist das 5900. Dort werden die Display-Daten vom Client abgeholt und die Maus- und Tastatureingaben weitergeleitet. Ebenfalls möglich ist die Verwendung eines Browsers als Client. Standardmäßig halten VNC-Server den Port 5800 für solche Anfragen offen, er kann jedoch ebenfalls frei gewählt werden.
Variationen eines Themas
Das ursprüngliche VNC wird auch heute noch als RealVNC bezeichnet und ist unter dieser Adresse zu finden. Lange Zeit war es still um die „Mutter des VNC“ – seit 2002 gibt es auch einen kommerziellen Ableger, der das Projekt weiterführt und neben den kostenpflichtigen auch eine, stark funktionsbeschränkte, kostenlose Version anbietet. Aktuell ist die Version 4.4. Doch in der Ruhepause waren andere Entwickler nicht untätig und haben zahlreiche eigene Versionen von VNC entwickelt. Ein paar Dutzend eigenständige oder auf dem ursprünglichen VNC basierende Variationen sind im Internet zu finden. Viele Administratoren schwören auf die eine oder die andere Implementation, zum Teil ist das Geschmacksache, es gibt allerdings auch deutliche Unterschiede im Funktionsumfang der Produkte. In jedem Fall sind Varianten mit einer aktiven Entwicklergemeinde sowie regelmäßigen Releases und Patches für den professionellen Einsatz sinnvoll. Nur so ist sichergestellt, dass Sicherheitslücken schnell und kompetent behoben werden. Zwei der wichtigsten VNC-Ableger sind TightVNC und UltraVNC.
TightVNC und UltraVNC
TightVNC wird aktiv weiterentwickelt, es ist voll kompatibel mit dem originalen VNC und beinhaltet auch eine einfache Funktion für den Dateitransfer zwischen Server und Client. Besonderer Clou ist eine Encoding-Variante der übertragenen Grafikdaten. Das „Tight“ Encoding ist speziell für langsame Verbindungen ausgelegt und macht das Arbeiten mit der Software selbst über ISDN-Leitungen sehr komfortabel. TightVNC gibt es für alle Desktop- und Server-Plattformen von Windows sowie für Linux und Unix. Eine reine Java-Implementation des Viewers ist ebenfalls erhältlich. TightVNC enthält auch einen sogenannten Mirror-Driver für die 32-Bit-Windows-Betriebssysteme, der die Bildschirmwiedergabe beschleunigt.
Auch UltraVNC ist vollständig mit dem Original kompatibel. Diese Variante gibt es jedoch nur für Windows. Sie bietet Authentifizierung sowohl über ein Passwort als auch über die NT-Domäne oder den Active-Directory-Verzeichnisdienst. Wie bei TightVNC sind unterschiedliche Zugriffsstufen, Viewer-Only und Vollzugriff möglich. Auch hier sorgt ein spezieller Grafiktreiber für schnelle Bildschirm-Updates. Dazu kann man noch Chat-Fenster zwischen Host und Client aufbauen und Dateien zwischen den beiden PCs transferieren.
Mittlerweile ist UltraVNC auch mit den entsprechenden Anpassungen für Vista versehen worden, sodass der Bildschirmaufbau auch für Microsofts neuestes Desktop-Betriebssystem beschleunigt und UAC unterstützt wird. Allerdings ist es um die Sicherheit nach der Passworteingabe schlecht bestellt. Diese übermittelt einen, mit einer Challenge/Response-Abfrage geschützten und per DES verschlüsselten, String. Während das Passwort noch verschlüsselt wird, wandern die folgenden Daten im Klartext über das Netzwerk, wo sie problemlos mitgeschnitten werden können. Um diesem Problem abzuhelfen, gibt es generell zwei Möglichkeiten. Die erste ist, ein VNC-Produkt zu verwenden, das eine Form der Verschlüsselung als Zusatzoption anbietet. Dazu gehören VeNCrypt, PowerVNC und UltraVNC. Die zweite Möglichkeit ist, einen sicheren Tunnel zwischen Host und Client aufzubauen und die VNC-Daten darüber zu schicken. Die bekanntesten Tools dafür sind SSH und ZeBeDee.
Grundinstallation
Unter Windows ähnelt sich die Installation aller VNC-Varianten und ist so simpel, dass eigentlich jede Anleitung überflüssig ist. In puncto Sicherheit sollte man jedoch ein paar Details beachten:
Diese drehen sich vor allem um den Schutz vor unbefugter Nutzung durch Dritte. Server und Client sind getrennt verfügbar, und sollten auch nur jeweils dort installiert werden, wo sie unbedingt benötigt werden. Beim Einsatz für Remote-Support hat der Viewer beispielsweise auf Arbeitsplätzen nichts verloren, der Server gehört nicht auf die hoch privilegierten Workstations der Administratoren. Meist kann auch festgelegt werden, ob der Server als Dienst oder als Anwendung laufen soll.
Geht es darum, Computer im lokalen Netz dauerhaft für die Administration bereit zu machen, ist der Einsatz als Service empfehlenswert. Damit startet der Server bei jedem Booten automatisch und wartet auf Verbindungen. Wenn es nur um gelegentlichen Support bei Benutzern geht, möglicherweise in einer externen Firma, dann ist der Applikationsmodus die bessere Wahl. So ist das Einfallstor VNC per Default geschlossen – eine Session erfordert das aktive Mitwirken des Benutzers vor dem Arbeitsplatz.
Zusätzlich sind über das Optionsmenü verschiedene Einstellungen, ebenfalls je nach VNC-Variante, möglich, die den Zugriff weiter einschränken. Beispielsweise kann man ein Fenster einblenden lassen, das den Benutzer um Erlaubnis für den Zugriff bittet und bei fehlender Bestätigung abbricht. Wie mit den meisten manuellen Sicherheitsvorkehrungen kann so etwas bei einem Fehler aber auch schnell dazu führen, dass das Remote-Troubleshooting scheitert.
Verschlüsselung
Da ist es doch besser, auf Verschlüsselung und Key-Dateien zu setzen, wie es UltraVNC anbietet: Diese VNC-Variante kann Verbindungen über sogenannte DSM-Plug-ins (Data Stream Modification) verschlüsseln. Es gibt zurzeit drei Varianten, die sicherste ist eine Implementation von AES mit 128 Bit Schlüssellänge. Der Host kann ein Key-File lesen und mit dem Key-File des Viewers vergleichen, es ist aber nicht unbedingt notwendig. Sobald das AES-Plug-in auf beiden Seiten eingesetzt wird, verschlüsselt es die Verbindung. Die Authentifizierung läuft dann nur über das VNC-Passwort.
Für die Nutzung der Plug-ins lädt man die gepackte Datei des gewünschten Plug-ins herunter und extrahiert die Dateien in das UltraVNC-Programmverzeichnis, in der Regel in C:\Programme\UltraVNC. Im Prinzip reicht die Datei mit der Endung „.dsm“, die anderen Files dienen nur der Information. Die „.dsm“-Datei muss sowohl auf dem Host als auch auf dem Client in das Verzeichnis kopiert werden. Wer jetzt in den Admin-Optionen auf das Auswahlfeld für das DSM-Plug-in unten links geht, findet in der Liste das neu installierte Modul und kann es per Mausklick freischalten.
Auf dem Server ist ein Restart von UltraVNC nötig, bevor die Änderung akzeptiert wird. Wählt man auch beim Client in den Optionen das Modul aus, ist schon die nächste Verbindung verschlüsselt. Allerdings ist mit diesem Verfahren die Passwortabfrage die einzige Barriere gegen unberechtigten Zugriff, schließlich kann auch ein Angreifer das DSM-Modul herunterladen und installieren. Darum sollten Sie auch passende Key-Dateien auf beiden Seiten nutzen, um die Authentifizierung zu stärken.
Eigenen Schlüssel erzeugen
Um einen Schlüssel zu erzeugen, öffnen Sie den UltraVNC-Client und klicken auf den Button „Config“ neben dem ausgewählten DSM-Modul. Der Suchdialog nach einer passenden Key-Datei wird angezeigt – tragen Sie einen Dateipfad und den Namen der Key-Datei (wie vorgeschlagen, allerdings ohne das vorangestellte „new_“) in das Feld ganz unten ein. Der Pfad ist nicht unwichtig, so liegt das File dort, wo es hingehört, und Sie müssen es nicht suchen. Ein weiterer Klick auf den Button „Gen Key“ reicht – die Key-Datei ist fertig. Diese muss ebenfalls in das Programmverzeichnis von UltraVNC kopiert werden und zwar auf der Client- und auf der Host-Seite!
Es sind zwar noch weitere Stellen im Dateisystem von Windows möglich, an denen UltraVNC die Datei findet, aber im Programmverzeichnis ist es am besten aufgehoben. Wenn Sie nun im Client oder auf dem Host den „Config“-Button für das DSM-Modul in den Admin-Optionen wählen, müsste im Ausgabefenster die Meldung „KEY FILE FOUND“ und „Using Key File“ erscheinen.
Eine Verbindung kommt ab jetzt nur noch zustande, wenn beide Computer über ein identisches Key-File verfügen. UltraVNC zeigt die korrekte Verschlüsselung während einer Session in der oberen Fensterleiste und bei den Verbindungsoptionen an. Im Test funktionierten auch Verbindungen zwischen unterschiedlichen UltraVNC-Versionen, solange sie zumindest neuer als 1.0 waren.
Einfach mit SSH
Wer mit anderen VNC-Varianten arbeiten oder weitere Anwendungen schützen möchte, ist auf die Trennung von Sicherheit und Applikation angewiesen. Der grundsätzliche Vorgang der sicheren Tunnelung ist immer gleich: Ein Teil der Tunnel-Software nimmt auf dem Client die Daten vom VNC-Client entgegen und schickt sie an den anderen PC. Dort werden sie von der Gegenstelle der Tunnel-Software angenommen und an den VNC-Host weitergereicht. Der Tunnel selbst ist verschlüsselt, und die Daten liegen nur im Arbeitsspeicher der beiden PCs im Klartext vor.
Wichtiger Hinweis: Per Default sind in den Admin-Optionen von VNC die sogenannten Loopback Connections abgeschaltet, Verbindungen mit localhost also verboten. Weil VNC bei Verwendung eines Tunnels die Daten nur an den localhost übergibt, müssen Sie auf dem Host die Option Loopback Connections erlauben.
Der Königsweg für den Tunnel zwischen Server und Client ist der Einsatz von SSH (Secure Shell). SSH ist für die Anwendung völlig transparent – die Anwendung, egal ob VNC, Telnet, FTP oder etwas anderes, kommuniziert mit ihren Gegenstellen abgeschottet in einem verschlüsselten Tunnel. Ein Authentisierungsmechanismus kann dafür sorgen, dass sich, ähnlich wie bei den DSM-Modulen von UltraVNC, kein Rechner im Internet erfolgreich als ein anderer ausgeben kann.
Weder beim Aufbau noch bei der Nutzung einer Verbindung überträgt Secure Shell Daten unverschlüsselt. Hierbei sorgt ein asymmetrisches Verschlüsselungsverfahren für die Geheimhaltung der verwendeten Schlüssel. Das kann allerdings kräftigen Konfigurations- und Lernaufwand erfordern, je nachdem wie sicher die Verbindung ausgestaltet werden soll. Einfacher machen es vorgefertigte SSH-Komponenten, die ohne viel Konfiguration auskommen.
SSH-Komponenten für VNC
Ein Tool für diesen Zweck ist SSHVNC. Die Software übernimmt den Client-Part der SSH-Verschlüsselung und enthält einer VNC-Viewer, sodass man darüber direkt mit einem Server kommunizieren kann. Zusätzlich sind verschlüsselte Telnet-, FTP- und Remote-Shell-Sessions möglich. Im Prinzip handelt es sich dabei um eine Kombination des TightVNC-Viewers mit dem VNC-Modul der SSHTools.
Der Nachteil: SSHVNC liegt seit vier Jahren in Version 0.1.3 vor. Die Software funktioniert zwar, wird aber augenscheinlich nicht mehr gepflegt und weiterentwickelt. Auf dem Client verlangt SSHVNC lediglich die IP-Adresse oder den Host-Namen des Servers sowie einen Benutzernamen für SSH. Das Tool baut eine Verbindung auf, fragt nacheinander das Passwort für SSH und VNC ab und startet eine VNC-Session.
Fehlt nur noch der SSH-Server auf dem Host. Bei Linux und Unix ist der Anwender fein raus, hier gehört ein SSH-Server zur Grundausstattung, er ist in allen aktuellen Linux-Distributionen enthalten. Bei Windows konnte man lange Zeit nur auf kommerzielle und damit kostenpflichtige Angebote oder OpenSSH/CopSSH zurückgreifen. OpenSSH ist zwar eine sehr leistungsfähige Lösung, doch die Konfiguration stellt den Administrator vor einige Hürden.
Mittlerweile gibt es jedoch eine einfachere Alternative: FreeSSHd. Die Software ist schnell installiert, einfach einzurichten und kostenlos, ideal für den schnellen und sicheren VNC-Zugang. Sie kann entweder automatisch beim Start von Windows mitgeladen oder nur auf Wunsch aus dem Programme-Menü aufgerufen werden. Neben SSH sind auch ein sFTP- und ein Telnet-Server integriert. Wer es ganz schnell und simpel haben will, kann die eingebaute Benutzerverwaltung von FreeSSHd nutzen oder sich über die Windows-User-Datenbank authentifizieren. Für SSH wird auch ein Public-Key unterstützt.
Alles mit SSH
Wenn der SSH-Server ohnehin schon steht, ist der Schritt zum kompletten Tunnel nicht weit. Ganz ohne vorgefertigte Hilfsmittel kommt man mit einem SSH-Client aus, über den die VNC-Daten getunnelt werden. Am bekanntesten in der Windows-Welt ist PuTTy. Auch hier ist die Installation ein Kinderspiel, und wer auf Public-Keys zur Authentifizierung verzichtet, muss auch bei der Konfiguration nur zwei Einträge beachten.
Zunächst den Namen oder die IP-Adresse des VNC-Hosts und dann die eigentliche Port-Weiterleitung. Die findet sich im Abschnitt SSH unter Tunnel. Im Feld Source-Port wählen Sie einen beliebigen freien Port des lokalen Rechners. Dort nimmt PuTTy die VNC-Daten des Viewers entgegen und schickt sie dann – Eintrag Destination – an den Host-Namen oder die IP-Adresse und den VNC-Port des Hosts.
Per Default liegt VNC immer auf Port 5900, darum ist Host-seitig keine weitere Konfiguration nötig. Der Ablauf sieht nun so aus: Zuerst etablieren Sie den SSH-Tunnel, indem Sie die Verbindung über PuTTy per Open aufbauen. Bei der Passwort-Authentifizierung öffnet sich nun ein Fenster, das Benutzername und Passwort abfragt.
Danach meldet sich der SSH-Server mit seiner Begrüßungsmeldung. Nun starten Sie den VNC-Viewer. Er soll in unserem Beispiel über Port 5500 kommunizieren, darum wird im Adressfeld des Viewers der eigene PC mit dem Eintrag localhost::5500 kontaktiert. Wichtig sind die beiden Doppelpunkte in der Mitte. Die Daten laufen jetzt zum lokalen Port 5500, werden von PuTTy entgegengenommen, verschlüsselt und auf Port 22 zum Host übertragen. Dort nimmt sie der SSH-Server in Empfang, entschlüsselt sie und gibt sie, wie in PuTTy konfiguriert, an den wartenden VNC-Host auf Port 5900 weiter. Klappt alles, will VNC nun das Passwort zur Anmeldung haben. Das Tunneling mit SSH funktioniert auch, wenn man die DSM-Module von UltraVNC einsetzt, doppelt gemoppelt also.
ZeBeDee – einfacher als SSH
Noch einfacher und unkomplizierter lässt sich dieselbe Aufgabe mit ZeBeDee absolvieren. Der Name kommt von Zlib Compression, Blowfish Encryption und Diffie-Hellman Schlüsselverwaltung. Das Tool ähnelt SSH in vielen Belangen. Es baut einen Tunnel zwischen Client und Server auf und sichert diesen durch starke Verschlüsselung. ZeeBeDee unterstützt zudem das Tunneling von UDP-Paketen.
Weil der Autor Wert auf besonders einfache Handhabung gelegt hat, ist ein ZeBeDee-Tunnel fast ohne Konfiguration aufsetzbar. Gerade diese Eigenschaft macht ZeBeDee interessant für Administratoren, die ihre VNC-Verbindung ohne großen Aufwand sichern wollen. Dazu laden Sie einfach die Datei herunter und entpacken sie in ein Verzeichnis auf Client und Host.
ZeBeDee ist ein reines Kommandozeilen-Tool, das eine ganze Menge kann. Wer sich dafür interessiert, findet hier die ausführliche, englische Beschreibung. Auf die Schnelle etabliert man einen VNC-Tunnel jedoch so: Auf dem Host starten Sie die ausführbare Datei zebedee.exe in einem DOS-Fenster mit dem Parameter -s: zebedee.exe -s. Das Fenster lassen Sie offen, ZeBeDee wartet im Hintergrund auf eine Verbindung. Am Client öffnen Sie ebenfalls ein DOS-Fenster und starten zebedee.exe mit den Parametern localport:ip-adresse-oder-hostname:remoteport. Um beim Beispiel von SSH zu bleiben: zebedee.exe 5500:193.175.100.201:5900. Nun können Sie den VNC-Viewer starten und analog zum SSH-Beispiel die Adresse localhost::5500 eingeben.
Fazit
Für kleine Firmen, die VNC ausschließlich im LAN benutzen, reichen die Authentifizierung per Passwort und dessen DES-Verschlüsselung in der Regel aus. Doch erst zusätzliche Sicherheitsmaßnahmen wie das Tunneling über SSH oder ZebeDee machen aus dem Tool eine rundum praxistaugliche Anwendung, die auch über das Internet sicher einsetzbar ist – etwa um Außenstellenmitarbeitern Support per Remote Desktop zu geben. (Elmar Török/mha)