"How to make Windows remote control products secure? Drop the machine off a cliff. Okay, so that's not always an option." (Sonnenreich & Yates: Building Linux and OpenBSD Firewalls)

Für Unix-Systeme ist es ganz klar, Fernwartung geschieht mittels ssh. Welche Möglichkeiten gibt es aber für Windows, zumal man unter Windows eigentlich nicht nur textorientiert administrieren kann, sondern die grafische Oberfläche benötigt? Hier soll eine kurze Übersicht gegeben werden, die die Alternativen für die Remote-Administration von Windows-Systemen (für Server und auch Desktop) darstellt. Derzeit kann das RRZN keine abschließende Empfehlung aussprechen, wir sind selbst noch in der Evaluierung der Alternativen (diese Seite stellt bisher eigentlich nur eine Literaturrecherche dar).

Die Windows-Versionen XP-Professional und 2003 liefern standardmäßig die Möglichkeit mit, sich remote mittels Remote-Desktop an den Systemen anzumelden. Davon zu unterscheiden ist die "Remote-Unterstützung" (s.u.).

• Zwar keine Klartextübertragung der Passwörter und Inhalte, aber anfällig für Man-In-The-Middle-Attacken.
• Seit Server 2003 SP1 Unterstützung für SSL (ab RDP-Version 5.2), das die MITM-Attacken ausschließt. Dafür ist auf Client-Seite ein neuerer Remote-Desktop-Client nötig, wobei dieser in XP-SP3 bereits enthalten ist (Konfiguration vgl. GWDG-Nachrichten).
• Unter Unix steht ein Client zu Verfügung, rdesktop, der allerdings nicht SSL unterstützt (RDP-Version 5).
• Keine Übertragung einzelner Dateien möglich, stattdessen Übermittlung eines Verzeichnisses als Netzwerk-Share und darüber Dateiaustausch.
• Benötigt TCP-Ports 3389 (früher wohl teils 3390).
• Für die Verbindung von XP-SP3-Rechnern zu Vista oder Server 2008 sind zusätzliche Einstellungen auf der XP-Seite nötig, vgl. MS-KB 951608. Dieses beinhaltet das händische Editieren von Registry-Einträgen. Alternativ kann das Erzwingen der Authentifizierung auf Netzwerkebene (Network Level Authentication, NLA) serverseitig deaktiviert werden, was keinen sonderlichen Sicherheitsverlust darstellt.

Remote-Desktop Web Connection

Neben dem Remote-Desktop gibt es noch eine über http und Port 80 abgewickelte Variante, diese sollte aber nicht zum Einsatz kommen, da zusätzlich der IIS (Internet Information Server) auf dem zu administrierenden Rechner aktiviert werden muss.

Remote-Unterstützung

Remote Unterstützung geschieht auf Anforderung, d.h. am fernzuwartenden Rechner muss der Anwender eine Einladung zur Remote-Unterstützung aussprechen. Daher ist dieses nur eine Möglichkeit zur Nutzerunterstützung, nicht jedoch zur Fernwartung.

• Microsoft: Schrittweise Anleitung, Administration von Remote-Unterstützung
• Benötigt TCP-Port 3389.

VNC ist ein Tool bzw. Protokoll, das nicht nur für Windows sondern ganz allgemein für grafische "Terminalanwendungen" gedacht ist (so gibt es auch ein X11-Server mit VNC-Ausgabe). Das Protokoll ist zwar ursprünglich unverschlüsselt und bot keine Dateiübertragung, es gibt aber diesbezüglich inzwischen Erweiterungen und neuere Protokollvarianten, die nun auch bessere Kompression anbieten. Bisher wurde VNC häufig in Verbindung mit ssh benutzt, ssh lieferte die Verschlüsselung und Dateiübertragung. Wird allein VNC eingesetzt, so muss die verwendete Variante genau betrachtet werden. Grundsätzlich gilt für VNC:

• Verschlüsselung, Dateitransfer, Bandbreitenbedarf je nach Produkt.
• Viewer (und auch Server) auf sehr vielen Plattformen.
• Benötigt TCP-Port 5900.

RealVNC

• Die freie Version unterstützt keine Verschlüsselung, in den kommerziellen TLS vorhanden.

TightVNC

• Gute Kompression, aber wohl inzwischen auch in anderen VNC-Produkten.
• Derzeit keine Verschlüsselung.
• Bietet Dateiübertragung.

UltraVNC

• Bietet Dateiübertragung.
• Verschlüsselung verfügbar (über Plugin).
• Open-Source (GPL).
• Anpassbarer Server in einer Exe-Datei für Unterstützungsanfragen (SingleClick-Addon), dabei Verbindungsaufbau vom Server zum Client möglich.
• Nur für Windows, Viewer aber auch in Java.
  Inzwischen wohl UltraVNC-Erweiterungen unterstützende Unix-Variante verfügbar (ssvnc).
  

Für Windows gibt es kommerzielle ssh-Daemons, freie basieren wohl meist nur auf Cygwin. Als Beispiel eines OpenSSH-Ports sei hier copSSH genannt, ein anderer zur freien Nutzung aber nicht Open-Source ist freeSSHd.

• Für Unix-Administration übliches Tool.
• Freie Implementierungen basieren auf Cygwin. Zumindest Cygwin-Dll wird installiert, dadurch evt. ungewohnte Dateipfade o.ä.
• SSH-Clients für fast alle Systeme verfügbar.
• Keine grafische Oberfläche, aber Remote-Desktop oder VNC können sicher mit SSH getunnelt werden.

SSL (Secure Socket Layer)

Da SSH häufig nur als Möglichkeit der Verschlüsselung einer TCP-Verbindung genutzt wird, soll in diesem Rahmen auch SSL erwähnt werden. Mit SSL ist sowohl eine Verschlüsselung als auch eine Authentifizierung (von Client und Server) möglich. Wenn ein Protokoll SSL bzw. TLS nicht unterstützt, kann die Verbindung mit Programmen wie STunnel über SSL umgeleitet werden.

Neben den oben aufgeführten Systemen, die bei Windows dabei sind oder als Freeware bzw. Open-Source zur Verfügung stehen, gibt es auch diverse kommerzielle Alternativen. Diese wurden aber bisher vom RRZN nicht getestet und seien hier nur der Vollständigkeit halber erwähnt:

• Symantec: pcAnywhere
• Dameware: Mini Remote Control
• Famatech: Remote Administrator (radmin)
• und sicherlich unzählige mehr ...
  

Zwei Kriterien sollte ein Remote-Administrationstool auf jeden Fall erfüllen:

• Unterstützung aller im Einsatz befindlichen Windows-Versionen,
• Möglichkeit der Dateiübertragung.

Daneben ist der Einsatz nur lokal im sicheren Netz möglich, wenn

• sichere Verschlüsselung

fehlen sollte. Generell sollte aber lieber gleich zu einer Variante mit Verschlüsselung gegriffen werden, da man nie sagen kann, dass das lokale Netz sicher sei. Zudem wachsen die Aufgaben: Fängt man mit der Fernadministration eines unwichtigen Systems an, so kann es sich leicht auf Systeme mit personenbezogenen Daten ausweiten.

Vor einer Empfehlung durch das RRZN müssen die verschiedenen Varianten in der Praxis getestet werden. Nicht beleuchtet wurden bisher u.a.:

• Authentifizierung Viewer an Server: Extra Passwort oder Windows-Login?
• Start des Servers als Dienst unter Windows.
• Unterschiedlicher Bedarf für echte Fernwartung (dauerhafter Dienst) und für Remote-Unterstützung eines Users (bei Bedarf).
• Mögliche Firewall-Probleme.