Immer häufiger sehen sich Administratoren mit der Aufgabe konfrontiert, Daten zwischen mehreren Standorten auszutauschen. Sei es nun der Versicherungskonzern, der allen Mitarbeitern die neusten Informationen und Konditionen zukommmen lassen will, oder der Verlag, der von seinen Korrespondenten Manuskripte erhält. Zunehmender Beliebtheit erfreut sich aber auch das Konzept des Homeworkers, der seine Aufgaben zu Hause erledigt und nur noch die Ergebnisse in die Firma übermittelt.
Allen Aufgaben gemeinsam ist die Notwendigkeit, die Daten vertraulich, unmodifiziert und vor allem authentifiziert zu erhalten. Man will sich ja nicht von irgendeinem Hacker oder Konkurrenten gefälschte Daten unterschieben lassen. Bisher hat man dieses Problem häufig mit Remote Access Systemen gelöst und zusätzliche Sicherheit mittels Callback erzielt. Die Hardware-Investitionen an der Hauptstelle, immerhin müssen genügend Einwahlpunkte zur Verfügung stehen, und die laufenden Kosten für Verbindungen, die ja wie normale Gespräche von den Carriern abgerechnet werden, sind jedoch immens.
Eine günstigere Alternative bietet das Internet: Sehr viele Firmen haben ohnehin bereits eine Standleitung ins Internet und beinahe überall sind Internet-Verbindungen verfügbar, die zudem auch noch nach günstigeren Tarifen abgerechnet werden als Einwählverbindungen. Insbesondere die weite Verbreitung von günstigen DSL-Flatrates lässt dieses Szenario für Homeworker ideal erscheinen.
Nachteile von VPN
Das Internet gilt jedoch bei den meisten Administratoren zu Recht als "böse und gefährlich". Dementsprechend sind ein Großteil der LANs vom Internet durch eine Firewall abgeschottet. Ein direkter Datenaustausch ist also gar nicht erst möglich. Zudem könnten die Daten unterwegs abgehört oder gar verändert werden.
Um dennoch das kostengünstige Internet ohne Kompromisse als Übertragungsmedium nutzen zu können, setzen viele Administratoren auf VPN-Technologie und richten ein Security-Gateway ein. Doch dieser Aufwand ist nicht immer unbedingt notwendig. Wenn es beispielsweise nur um das Überspielen von neuen Daten geht oder der Hauptrechner in der Filiale ab und zu per Remote Desktop ferngewartet werden soll, lässt sich schon mit SSH einiges erreichen. Der große Vorteil: Die Filialen oder Heimarbeitsplätze können über handelsübliche DSL-Router mit eingebauter NAT-Firewall abgesichert werden. Eine gesondert einzurichtende und zu verwaltende Firewall in jeder Filiale ist hier nicht mehr notwendig. Bei einer VPN-Lösung über IPsec müsste man entweder eine Firewall mit dem Security Gateway aufsetzen oder spezielle und deutlich teurere Router verwenden, da IPsec über NAT derzeit nicht funktioniert.
SSH für sichere Datenübertragung
Die Secure Shell SSH hat zunächst im Unix-/Linux-Umfeld erhebliche Bedeutung erlangt, weil die Standardverfahren zur Fernwartung sich als nicht sicher genug erwiesen haben. Insbesondere Telnet, bei dem alle Daten inklusive der Anmeldung im Klartext übertragen werden, ist sicherheitsbewussten Administratoren ein Dorn im Auge. Aber SSH hat mehr zu bieten als nur eine sichere Kommandozeile. Das Programm sftp (secure FTP) realisiert einen abgesicherten FTP-Transfer und mit scp (secure Copy) kopieren Sie Dateien zwischen entferntem Host und lokalem Rechner, falls auf dem Server kein sftp läuft. Das mächtigste Feature von SSH ist allerdings die Möglichkeit, mittels Port-Umleitung jedes beliebige Protokoll abzusichern - beispielsweise POP3 oder SMTP, die ja auch im Klartext übertragen. Dabei arbeitet SSH wie ein Proxy: Auf der einen Seite der gesicherten Verbindung nimmt es die Daten entgegen und auf der anderen Seite leitet der Server die Daten an die richtige Applikation weiter.
Mittlerweile sind auch für Windows verschiedene Implementationen von SSH verfügbar, unter anderem die von Mark Bradshaw. Dabei handelt sich um ein Paket aus den Kommandozeilen-Utilities für die Clients und einem Server-Dienst für Windows NT/2000/XP. Dieses Paket wird allerdings nicht mehr weitergepflegt. Das Nachfolgeprojekt von Michael Johnson steht jedoch schon bereit. An der Konfiguration ändert sich nichts, lediglich die Verzeichnisstruktur ist etwas anders.
Installation von OpenSSH
Installation und Konfiguration der SSH-Implementation von Mark Bradshaw sind schnell erledigt. Die Setup-Routine bietet lediglich die Möglichkeit, das Zielverzeichnis zu ändern, und die Auswahl, welche Komponenten (Client, Server) eingerichtet werden sollen. Auf dem späteren SSH-Server in der Außenstelle installieren wir beide Komponenten, auf dem Rechner im Firmen-LAN nur die Client-Komponente.
An der Default-Konfiguration des Servers sind keine weiteren Arbeiten notwendig, er ist sogar schon als automatisch startender Dienst in Windows eingerichtet. Sollten Sie einzelne Optionen ändern wollen, finden Sie die Konfigurationsdatei sshd_config im Ordner ssh unterhalb des Installationsverzeichnisses. Um eigene Schlüssel für den Host zu erstellen, öffnen Sie eine Kommandozeile und erzeugen ihn mittels
ssh-keygen -b 1536 -t rsa -f ssh_host_rsa_key -C "Host-Key für Host abc"
Geben Sie bei der Frage nach der Passphrase nichts ein, ansonsten kann OpenSSH den Schlüssel nicht verwenden. Danach ist der OpenSSH-Dienst über den Dienstemanager von Windows neu zu starten, damit der neue Schlüssel aktiviert wird.
Einrichtung der Benutzer
Mit dem Programm mkpasswd richten Sie die Benutzer für den SSH-Zugang ein:
mkpasswd -l -u lokalerbenutzer >> ..\\etc\\passwd
Dabei ersetzen Sie lokalerbenutzer durch den jeweiligen Benutzernamen auf dem Rechner. Das wiederholen Sie für jeden einzelnen Benutzer, der via SSH Zugriff haben soll. Bei Bedarf können Sie nun noch die Home-Verzeichnisse der User anpassen. Per Default sind nämlich alle Benutzer auf das Installationsverzeichnis von OpenSSH eingestellt. Die verschiedenen Optionen in passwd sind durch Doppelpunkte getrennt. Ändern Sie einfach den vorletzten Wert beim Benutzer von /ssh auf das entsprechende Benutzerverzeichnis unterhalb des Ordners Dokumente und Einstellungen. Also beispielsweise/Dokumente und Einstellungen/lokalerbenutzer. Achten Sie dabei auf die Verwendung von / anstatt \\. Kopieren Sie in dieses Benutzerverzeichnis den Ordner \\Programme\\NetworkSimplicity\\ssh\\.ssh. Dort können Sie mittels der Datei rc anpassen, welche Befehle beim Login des Benutzers auszuführen sind. In dieses Verzeichnis kommen dann auch die öffentlichen Schlüssel des Users, wenn Sie statt der Passwort-Authentifizierung eine per Public/Private Key durchführen wollen. Im nächsten Schritt erstellen Sie die group-Datei mit:
mkgroup -l >> ..\\etc\\group
Auf dem Router in der Außenstelle ist lediglich der Port 22 per Virtual Server auf den Rechner mit dem OpenSSH-Server umzuleiten. Damit ist der Server konfiguriert.
Auf den Clients können Sie dann bereits mit dem Befehl
ssh lokalerbenutzer@secure.zielrechner.de
eine Verbindung aufbauen und auf der Kommandozeile des OpenSSH-Servers arbeiten.
Port-Forwarding
Das nützlichste Feature von SSH ist allerdings das Port-Forwarding. Dabei leitet SSH Verbindungen, die auf Ports am Client geöffnet werden, verschlüsselt an den SSH-Server weiter, der den Datenstrom entschlüsselt und dann weiter auf den spezifizierten Port am Server vermittelt.
Das grundsätzliche Kommando dafür lautet
ssh benutzer@sshrechner -L lokaler_port:sshrechner:entfernter_port
Soll also beispielsweise der POP3-Mailserver auf dem entfernten Rechner mittels verschlüsselter Übertragung erreicht werden, reicht folgender Befehl:
ssh benutzer@sshrechner -L 20110:sshrechner:110
Nun muss nur noch der Mailclient auf den Host localhost und den Port 20110 umkonfiguriert werden und schon kann die Mail verschlüsselt übertragen werden, ohne dass der Mailserver POP3 über SSL unterstützt.
Port-Forwarding auf entfernte Rechner
Um die Übersicht zu behalten, verwenden wir auch in den folgenden Beispielen immer die Original-Portnummer des zu tunnelnden Dienstes plus 20000.
Das Port-Forwarding funktioniert nicht nur auf Ports am SSH-Server, sondern auf beliebige Rechner. Dazu ist einfach die Adresse des endgültigen Zielservers anzugeben:
ssh benutzer@sshrechner -L lokaler_port:zielrechner:entfernter_port
Damit lässt sich beispielsweise ein Intranet-Webserver erreichen, der nicht unbedingt auf dem SSH-Server laufen muss. Über das Kommando
ssh benutzer@sshrechner -L 20080:intranetserver:80
und den Aufruf der URL http://localhost:20080 werden die Daten aus dem Intranet verschlüsselt übertragen. Dabei ist zu beachten, dass nur der Weg zwischen SSH-Client und -Server gesichert ist. Die Strecke vom SSH-Server zum Intranet-Server jedoch nicht mehr. Mittels Port-Forwarding lassen sich fast alle TCP-basierenden Dienste tunneln, wie beispielsweise HTTP , SMTP , POP3 , IMAP oder NNTP . FTP funktioniert dagegen nicht, dafür dient der bei OpenSSH mitgelieferte SFTP-Server.
Das Remote Forwarding funktioniert analog zum lokalen Weiterleiten, allerdings genau anders herum. Eine Verbindung kommt auf einem Port am SSH-Server an und wird von dort durch den Tunnel zum Client geschickt. Das Kommando dafür lautet:
ssh benutzer@sshrechner -R entfernter_port:sshclient:lokaler_port
Ist der Tunnel erst einmal aufgebaut können Sie mit den Kommandos scp (secure copy) und sftp (secure ftp) Dateien zwischen den beiden Rechnern hin und her schieben. Wem die Kommandozeile dafür zu aufwendig ist, der kann mit Shareware-Tools wie Secure iXplorer Pro von i-Tree komfortabel per Drag und Drop arbeiten.
Remote Control via VNC
Fernwartung ist gerade für Administratoren oder Helpdesk-Mitarbeiter in der Firmenzentrale ein hilfreiches Mittel, um entfernte Benutzer bei Problemen zu unterstützen, ohne sich erst auf den Weg machen zu müssen. Und das ist ohnehin nicht immer möglich, weil der Nutzer unter Umständen zu weit entfernt ist. Programme wie VNC oder PC Anywhere bieten die entsprechenden Funktionen. VNC ist zwar Freeware, dafür bietet es jedoch keine Verschlüsselung. Mit OpenSSH lässt sich dieses Manko beheben.
Der VNC-Server wartet im Allgemeinen auf Port 5900 auf eingehende Verbindungen. Es müsste also eigentlich reichen, irgendeinen lokalen Port auf diesen Port am entfernten Rechner umzuleiten. Die Client-Anwendung VNCviewer nimmt allerdings keine Port-Nummer als Parameter an, sondern erlaubt lediglich eine so genannte Display-Nummer, zum Beispiel:zielrechner:0. Display-Nummern größer 0 verweisen auf die Ports nach 5900, also Display 2 auf Port 5902. Der Trick ist also, den lokalen Port 5902 auf den entfernten Port 5900 umzuleiten
ssh benutzer@sshrechner -L 5902:sshrechner:5900
und dann den VNCviewer mit localhost:2 zu starten. Dieser versucht nun, über den Port 5902 eine Verbindung zu einem lokalen Server aufzubauen, der allerdings von SSH auf den entfernten Rechner umgeleitet wird.
Remote Control via Remote Desktop
Wer das Remote Desktop Protocol (RDP) von Windows XP über SSH verwenden will, muss auch einen Trick anwenden. Zunächst ist ein beliebiger lokaler Port auf den Port 3389 des Rechners mit XP-Professional umzuleiten:
ssh benutzer@sshrechner -L 23390:xprechner:3389
XP erlaubt es Ihnen jedoch nicht, sich mit localhost:23390 zu verbinden. Kopieren Sie also die Dateien mstsc.exe und mstscax.dll aus dem System32-Verzeichnis in ein anderes Verzeichnis und bearbeiten mittels Rechtsklick die Eigenschaften von mstsc.exe. Dort stellen Sie unter Kompatibilität "Windows 95" ein und die Verbindung funktioniert einwandfrei.
Doppeltunnel mit SSH
Mit den bisherigen Verfahren haben wir erreicht, dass aus der Firmenzentrale eine Verbindung zu einem Rechner in der Außenstelle hergestellt werden kann. Wenn Sie jetzt beispielsweise von Ihrem Arbeitsplatz aus Daten ins Home Office übertragen wollen, ist das nun problemlos möglich. Der andere Weg - Sie sitzen zu Hause und brauchen dringend Daten von Ihrem Arbeitsplatz - ist damit noch nicht offen. Wenn in der Firma kein SSH-Server steht oder die Firmen-Firewall von außen keine SSH-Verbindungen zulässt, haben Sie zunächst schlechte Karten. Mit einem kleinen Trick können Sie allerdings dennoch eine sichere Verbindung aufbauen. Hier kommt das Remote Port Forwarding ins Spiel.
Zunächst muss der Rechner im Home Office ins Internet eingewählt sein und SSH-Verbindungen annehmen, aber das ist ja bereits konfiguriert. Auf dem Arbeitsrechner in der Firma muss auch der SSH-Server installiert sein. Dort öffnen Sie zunächst einen Tunnel ins Home Office:
ssh benutzer@arbeitsrechner -R 2022:heimrechner:22
Dazu müssen Sie lediglich die IP-Adresse des Rechners zu Hause wissen. Mit Diensten wie MyJack oder DynDNS ist das jedoch kein Problem.
Diesen Tunnel lassen Sie einfach geöffnet und öffnen durch diesen Tunnel einen weiteren zu Ihrem Arbeitsrechner in der Firma:
ssh benutzer@heimrechner -p 2022
Sollte Ihr Administrator aus irgendeinem Grund an der Firewall SSH-Verbindungen nach außen unterbinden, können Sie den SSH-Server zu Hause auch auf einen anderen Port hören lassen, beispielsweise den Port 80 von HTTP.
Ihren Administrator werden Sie mit dieser Konfiguration allerdings nicht wirklich glücklich machen: Immerhin schießen Sie ein Loch durch die Firewall und das Firmennetz ist nur noch so gut geschützt, wie Ihr eigener Rechner zu Hause. Am besten reden Sie also vorher mit dem Administrator und klären das ab - immerhin drohen im schlimmsten Fall auch arbeitsrechtliche Konsequenzen.
Wake on LAN
Damit der zu erreichende Rechner nicht ständig eingeschaltet bleiben muss, bietet sich eine Lösung mit Wake on LAN (WoL) an. Dabei handelt es sich um ein Verfahren, mit dem sich ein vernetzter Rechner durch ein speziell geformtes Datenpaket aus Stand-by oder Hibernation aufwecken lässt. Damit das funktionieren kann, müssen das Motherboard und die Netzwerkkarte WoL unterstützen.
Um den Rechner aufzuwecken, schickt man ein Ethernetpaket mit dem Inhalt "xxxx" ins lokale Netz. Dies ist notwendig, weil der Rechner nicht unbedingt über eine IP-Adresse verfügt. Die NiC kann sich allerdings anhand der MAC-Adresse erkennen und dann den Aufweckvorgang starten. Hier wird schon ein erstes Problem deutlich, man müsste sich eigentlich im selben LAN befinden, wie der zu weckende Rechner, was aber allein schon aufgrund der Aufgabenstellung nicht der Fall ist.
Web-Konfiguration für DSL-Router sichern
Da wir in unserem Szenario einen kleinen DSL-Router als NAT-Firewall einsetzen wollen, kommt hier also ein Router in Frage, der von sich aus Clients aufwecken kann. So ein Gerät ist beispielsweise der Barricade 7004WBR von SMC. Das Problem ist allerdings, dass man dazu die Web-Administration über das Internet frei schalten muss. Alternativ kann man auch einen SSH-Tunnel nutzen, der erst ins entfernte LAN geht und dann von dort aus auf den Router weiterleitet:
ssh user@secure.zielrechner.de -L 20080:routerip:80
Danach können Sie über die URL http://localhost:20080 den Router sicher konfigurieren, ohne Angst vor unerbetenen Lauschern haben zu müssen.
Dazu muss der SSH-Server allerdings dauerhaft laufen. Eine andere Möglichkeit ist das Senden eines gerichteten Broadcast-Pakets. Wenn der Router (wie beispielsweise der WaveMaxx PRO von 1stWAVE) das unterstützt, wird dabei ein Broadcast-Paket erst als normales IP-Paket an den Router geschickt, der dieses dann als Broadcast in "seinem" LAN verbreitet.
Ein nicht nur wegen seiner WoL-Funktion hilfreiches Tool ist beispielsweise PowerOff. Es bietet zusätzlich auch noch Fernwartungs-Funktionen, um einen Rechner neu zu starten oder in Standby/Hibernation zu schalten.
Fazit
Es muss nicht immer eine teure oder konfigurationsintensive Firewall-Lösung sein, wenn es um einfache Datentransferaufgaben geht. Selbst Aktualisierungen oder Replikationen von Datenbank-Servern in der Außenstelle sind ohne Probleme möglich.
Die Sicherheit ist dabei gewährleistet, sofern immer die aktuellsten Versionen der SSH-Server und Clients eingesetzt werden. Authentifizierung und Verschlüsselung laufen nach standardisierten Verfahren, so dass Sie auch fremde Tools verwenden können, um mehr Komfort zu erreichen. Ganz wichtig ist allerdings die Sicherheit auf den Rechnern in Home Offices. Wenn ein Mitarbeiter diese Zugangsmöglichkeit nutzen will, muss er auch auf seinem Heimarbeitsrechner die Sicherheitspolicies der Firma unbedingt einhalten, sonst wird der sichere Tunnel schnell zu einem Einfallstor für Hacker und Viren. (mha)