Immer häufiger sehen sich Administratoren mit der Aufgabe konfrontiert, Daten zwischen mehreren Standorten auszutauschen. Sei es nun der Versicherungskonzern, der allen Mitarbeitern die neuesten Informationen und Konditionen zukommen lassen will, oder der Verlag, der von seinen Korrespondenten Manuskripte erhält. Zunehmender Beliebtheit erfreut sich auch das Konzept des Homeworkers, der seine Aufgaben zu Hause erledigt und nur noch die Ergebnisse an 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 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. Beinahe überall sind Internet-Verbindungen verfügbar, die zudem 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 bei den meisten Administratoren jedoch 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.
OpenSSH für sichere Datenübertragung
Die Secure Shell SSH erlangte zunächst im Unix-/Linux-Umfeld erhebliche Bedeutung, 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. 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 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.
Für Linux steht in den meisten Distributionen bereits ein fertiges Paket zur Verfügung, das oft sogar automatisch installiert wird. Die aktuelle Version ist openssh-3.91p1-3.1.
Installation von OpenSSH
Installation und Konfiguration von OpenSSH sind via YaST schnell erledigt: Sie lassen lediglich das Paket und eventuell noch kssh anwählen und installieren. Das Paket kssh ist ein einfaches grafisches Frontend für ssh, mit dem man die Optionen per Mausklick auswählen kann. Die Konfiguration lässt sich sogar speichern, so dass Sie beim nächsten Mal nur das Profil laden müssen.
Das Paket openssh-3.91p1-3.1 enthält die Client- und Server-Komponente, die wir auf dem Linux-Rechner zu Hause benötigen, damit ein Zugriff von außen möglich wird.
Auf dem Rechner im Firmen-LAN reicht die Client-Komponente. Wenn es sich dabei um einen Windows-Rechner handelt, finden Sie in dem Artikel OpenSSH unter Windows die notwendige Anleitung.
An der Default-Konfiguration des Servers sind keine weiteren Arbeiten notwendig, er wird sogar schon als automatisch startender Dienst eingerichtet. Sollten Sie einzelne Optionen ändern wollen, finden Sie die Konfigurationsdatei sshd_config im Ordner /etc/ssh. Um eigene RSA-Schlüssel für den Host zu erstellen, öffnen Sie eine Kommandozeile und erzeugen ihn mittels
ssh-keygen -b 2048 -t rsa -f /etc/ssh/ssh_host_rsa_key -C "Host-Key für Host abc"
Geben Sie bei der Frage nach der Passphrase nichts ein, sonst kann OpenSSH den Schlüssel nicht verwenden. Analog erzeugen Sie einen DSA-Schlüssel.
ssh-keygen -b 2048 -t dsa -f /etc/ssh/ssh_host_dsa_key -C "Host-Key für Host abc"
Danach ist der OpenSSH-Dienst neu zu starten, damit der neue Schlüssel aktiviert wird:
/etc/init.d/sshd restart
Einrichtung der Benutzer
Per Default dürfen alle Linux-User auch per SSH auf den Rechner zugreifen. Das ist sicherlich nicht in jedem Fall wünschenswert, denn bestimmte Dienste legen eigene Benutzer-Accounts an, die eigentlich nur lokal agieren sollen. Aus diesem Grund sollten Sie eine spezielle Gruppe erzeugen, in die Sie Benutzer eintragen, die per SSH auf den Rechner zugreifen können.
Nennen Sie die Gruppe beispielsweise ssh-user und tragen in /etc/ssh/sshd_config die folgende Zeile ein:
AllowGroup ssh-user
Sie können sshd auch direkt mitteilen, welche Benutzer den Dienst nutzen dürfen. Verwenden Sie dazu die Option AllowUser mit einer kommaseparierten Liste der Benutzer-Accounts.
AllowUser derdarf
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. Es ist übrigens auch möglich, mit Konqueror auf sftp oder scp eines OpenSSH-Servers zuzugreifen. Geben Sie dazu einfach den URL fish://entfernter_server ein.
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-Mail-Server 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 Mail-Client auf den Host localhost und den Port 20110 umkonfiguriert werden - und schon kann die Mail verschlüsselt übertragen werden, ohne dass der Mail-Server 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 Ziel-Servers 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 des 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 andersherum. 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
OpenSSH bietet eine Vielzahl an Kommandozeilen-Optionen. Der einzugebende Befehl kann also sehr schnell recht unübersichtlich werden. Mit kssh gibt es für den KDE-Desktop ein komfortables Tool, bei dem sich die einzelnen Optionen per Mausklick einstellen lassen. Ein Klick auf "Connect" startet dann ssh mit den gewählten Parametern.
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 Portnummer 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.
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.
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 Sicherheits-Policies der Firma unbedingt einhalten, sonst wird der sichere Tunnel schnell zu einem Einfallstor für Hacker und Viren. (mha)