Das Internet besteht nicht nur aus Webseiten und FTP-Servern. Andere interessante Anwendungen bleiben vielen Nutzern verschlossen, weil der Firmen-Proxy nur zwei Dienste kennt. Doch Transconnect kann meist Abhilfe schaffen.

Firewalls und Proxies erlauben in vielen Firmen nur HTTP- und FTP-Verbindungen von innen nach außen. Das kann beabsichtigt sein und der Sicherheitspolitik des Unternehmens entsprechen, häufig liegt es aber nur an einer unflexiblen Proxy-Administration. Damit bleiben viele Perlen des Internets ausgesperrt (siehe Listing 1 und 2).

CVS und IRC, SSH und Yahoo Messenger, Fetchmail oder Whois – alle diese Anwendungen lassen sich mit Transconnect nutzen, ohne an der Proxy-Konfiguration etwas zu verändern. Transconnect nutzt dazu die HTTPS-Connect-Methode des Proxies.

Diese Methode des HTTP-Protokolls soll eigentlich verschlüsselte und authentifizierte Verbindungen über den Proxy zu Webservern im Internet ermöglichen. Damit die Authentifikation klappt, muss der Proxy nach dem Verbindungsaufbau alle Daten unverändert weiterleiten. Somit eignet er sich für fast beliebige Protokolle – vorausgesetzt er erlaubt Verbindung zu beliebigen Ports und nicht nur zum HTTPS-Port 443 (siehe Abbildung 1).

Listing 1: Kein CVS-Zugang

List8ing 2: Kein IRC-Zugang

Abbildung 1: Der Client verbindet sich mit dem Proxy, teilt ihm über die Connect-Methode den gewünschten Server und Port mit und authentifiziert sich. Der Proxy verbindet dann Client und Server mit einem Tunnel.

Installation ins Home-Verzeichnis

Das weniger als 20 KByte große Paket ist innerhalb kürzester Zeit installiert und in Betrieb gesetzt; hierfür sind nicht mal Root-Rechte erforderlich. Transconnect steht unter der GPL und funktioniert derzeit auf Linux, Solaris und auf verschiedenen BSD-Unixen.

Nach »make« und »make install« (»./configure« ist nicht erforderlich) landet die Mini-Bibliothek »tconn.so« im Verzeichnis »$HOME/.tconn«, und zwar gemeinsam mit der Konfigurationsdatei »tconn.conf«. Die Konfiguration ist zuerst an die Gegebenheiten anzupassen. Die wichtigsten Einträge betreffen den Proxy-Server und – falls nötig – die Benutzer-Authentifizierung. Listing 3 zeigt ein kurzes Beispiel.

Listing 3: Beispiel-Konfiguration

Konfiguration

Der Proxy-Server muss in der Konfig-Datei mit seiner IP-Adresse spezifiziert sein. Das hängt damit zusammen, dass die Transconnect-Bibliothek selbst nicht auf die Libc-Funktion »gethostbyname()« zugreifen kann.

Transconnect soll sich nur um Verbindungen nach außen kümmern und muss daher wissen, welche Adressen zum lokalen Netzwerk gehören. Die »localnet«-Einträge enthalten die entsprechenden Daten, also den Netzwerkanteil der eigenen Adresse zusammen mit der Netzmaske. Zu dieser Liste gehört auch das Loopback-Device (IP-Adresse 127.0.0.1).

Der Proxy-Port (hier 8080) kann, je nach lokalen Gegebenheiten, auch anders lauten (häufig 3128).

Falls der Proxy ohne Abfrage von Benutzername und Passwort funktioniert, sollten die Zeilen »proxyuser« und »proxypass« auskommentiert bleiben. Da manche Proxies unverständlicherweise nur bestimmte Browser (User-Agents) nach draußen passieren lassen, kann die Konfigurationsdatei einen entsprechenden String enthalten, der den Proxy zufrieden stellt.

Transconnect nutzen

Nach der Konfiguration ist Transconnect bereit für den Einsatz. Mit Hilfe der Umgebungsvariablen »$LD_PRELOAD« und Function Interposing[1] erweitert die »tconn.so«-Bibliothek fast jedes Programm:

export LD_PRELOAD=$HOME/.tconn/tconn.so

Alle im Folgenden aus dieser Shell gestarteten Netzwerkprogramme verbinden sich über den Proxy mit ihrem Ziel, vermittelt von Transconnect. Der Mechanismus scheitert allerdings, wenn das Client-Programm über Set-UID-Rechte verfügt.

Mit der Technik, die Transconnect nutzt, lässt sich beliebiger Code in ein Programm einschleusen. Wenn das Programm keine zusätzlichen Rechte hat, ist das unkritisch – der User könnte ja auch selbst Software schreiben und ausführen, die diese Funktionen enthält. S-Bit-Programme laufen aber mit anderen Rechten (häufig Root), als sie der Aufrufer hat. Aus Sicherheitsgründen kann und darf Function Interposing dann nicht funktionieren.

Nicht immer möglich

Ein Beispiel hierfür ist SSH: Der Client ist häufig mit Set-UID-Root-Rechten installiert. Nur so kann die Host-basierte Client-Authentifikation funktionieren. SSH muss dazu einen geheimen Schlüssel lesen, den der Benutzer nicht kennen darf. Wer diese Form der Authentifikation nicht benötigt und SSH mit Transconnect nutzen will, kann einfach eine Kopie des Programms anlegen, die ihm dann selbst gehört und kein Set-UID-Bit mehr hat. Diese Kopie lässt sich dann mit »$LD_PRELOAD« und »tconn.so« benutzen.

Die jeweiligen Sicherheitsrichtlinien beachten

Neben den technischen Grenzen kann es auch weitere Gründe geben, die gegen Transconnect sprechen. Die Bibliothek umgeht den Proxy zwar nicht und durchlöchert ihn auch nicht, sie verwendet lediglich die Funktionen, die der Proxy zur Verfügung stellt. Trotzdem sollte man im Firmennetz vorher klären, ob der Einsatz gegen die Sicherheitspolitik verstößt. Durch Sicherheitslücken in den Client-Programmen können sich durchaus Probleme ergeben.

Manche Programme (vor allem Browser wie Netscape, Mozilla oder Konqueror) sind bereits für den Umgang mit Proxies ausgelegt. In ihrer eigenen Konfiguration erwarten sie die Proxy-Adressen. Fragt der Proxy zwecks Authentifizierung nach dem Benutzernamen und dem Passwort, zeigen die Clients dem Benutzer einen entsprechenden Dialog, der auszufüllen ist. Diese Programme brauchen kein Transconnect. Manche können die Benutzername-Passwort-Kombination speichern und müssen den Benutzer dann nicht mehr fragen.

Andere Programme scheitern, sobald sich ihnen ein Proxy in den Weg stellt. Selbst wenn sie einen Proxy verwenden können, bleiben viele doch hängen, falls der Proxy die Verbindung nur nach erfolgreicher Authentifizierung erlaubt. Sie können nicht mit den Rückfragen nach Benutzername und Passwort umgehen. In diesen Fällen ist Transconnect durchaus nützlich.

Wenn Transconnect aktiv ist, stellt es die Verbindungen für Proxy-agnostische Clients sicher, ohne die Programme zu modifizieren – und ohne Änderung am Proxy. Transconnect baut die Verbindung zum Server über den Proxy auf, ohne dass es die betroffenen Programme bemerken. Die »tconn.so«-Bibliothek setzt sich dazu zwischen das Programm und die C-Bibliothek und ersetzt die »connect()«-Funktion der Libc durch eine eigene Variante.

Eingeschmuggelte Funktionen

Um diesen Mechanismus zu erklären, ist ein kleiner Ausflug in die Welt der Bibliotheken nötig. Die meisten Programme nutzen Funktionen, die in Libraries definiert sind und dadurch mehreren Programmen zur Verfügung stehen. Solche Bibliotheksfunktionen lassen sich auf zwei Arten einbinden: Das statische Linken kopiert ihren Code direkt in die ausführbare Datei, die Bibliothek selbst (»lib Biblio.a«) ist danach nicht mehr erforderlich.

Für häufig genutzte Bibliotheken kommt eher dynamisches Linken in Frage. Hier werden die Funktionen erst beim Ausführen des Programms eingebunden. Die entsprechenden Libraries müssen dazu auf dem System vorhanden sein. Die wichtigste dieser »lib Biblio.so«-Dateien (so, shared Object) ist die Standard-C-Bibliothek »libc.so«. Sie stellt viele Grundfunktionen bereit, unter anderem »connect()«, die Verbindungen zu anderen Rechnern aufbaut.

Vorladung für die Bibliothek

Transconnect funktioniert, weil man den Aufruf von Funktionen in dynamisch gelinkten Bibliotheken abfangen kann. Dadurch lässt sich an die Stelle der ursprünglich aufgerufenen Funktionen eine beliebige andere Routine setzen; der eingefügte Code kann die originale Funktion selbst aber noch nutzen. Diese Technik ist als Function Interposing bekannt. Sie wurde entwickelt, um Statistiken und Profile über Funktionsaufrufe anzufertigen, die den Programmierern zur weiteren Optimierung oder zu Debugging-Zwecken dienen. Function Interposing benutzt unter Linux die Umgebungsvariable »$LD_PRELOAD«.

Programme, die beim Start ihre Shared Libraries laden, nutzen dazu den dynamischen Linker. Der wertet die Umgebungsvariable »$LD_PRELOAD« aus und bindet die darin gesetzte Library ein, bevor er irgendeine andere Bibliothek sucht. Wenn die Variable den absoluten Pfad zu »tconn.so« enthält, kommt diese Bibliothek vor allen anderen zum Zuge. In der Folge benutzt das Hauptprogramm die »connect()«-Funktion aus dieser Library und nicht mehr das Original aus der Libc. Die Preload-Wirkung auf das »cvs«-Kommando lässt sich über das Kommando »ldd« prüfen (siehe Listing 5).

Listing 4: CVS-Zugang mit Transconnect

Listing 5: Auswirkung von >>$LD_PRELOAD

Debugging

Im Test funktionierte Transconnect allerdings nicht auf Anhieb. Die einzige Fehlermeldung war ein lapidares »Hey, your proxy authentication is not working«. In solchen Fällen hilft die Debugging- Option, die in der Quellcode-Datei »tconn.c« gesetzt wird. Die zuständige Zeile »#define TCONN_DEBUG 0« am Anfang der Datei muss geändert werden:

#define TCONN_DEBUG 1

Nach erneutem »make && make install« bringt der nächste Verbindungsversuch eine Menge Hinweise. Es stellte sich heraus, dass Transconnect überhaupt nicht versuchte, sich beim Proxy zu authentifizieren. Der Proxy-User und das Passwort waren in »tconn.conf« zwar korrekt angegeben, aber auskommentiert (also selbst Schuld …). Nach dem Entfernen der Kommentarzeichen »#« funktionierten alle Verbindungen tadellos.

Erfahrungen

Auch in der täglichen Praxis konnte sich Transconnect bestens bewähren. Dem Autor dieses Artikels erschließt das Tool seit einigen Monaten den Zugang zu einigen Internet-Diensten, die er aus dem Firmennetz heraus vorher nicht nutzen konnte:

• Abendliches Chatten mit KDE-Entwicklern zwecks Erfahrungsaustausch über die Weiterentwicklung von KDE Print.
• Zugang zu den CVS-Sourcen verschiedener Programme (vor allem CUPS) mit den normalen CVS-Kommandos an Stelle von Web-CVS.
• Upload der KDE-Print-Dokumentation auf den CVS-Server.

Auch Htmldoc[5], das nicht nur lokale HTML-Dateien, sondern auch ganze Webseiten nach PDF konvertiert, profitiert von Transconnect. Eigentlich kann Htmldoc von sich aus Proxies benutzen – sofern diese kein Passwort verlangen. In der aktuellen Version kann sich Htmldoc nicht am Proxy authentifizieren. Transconnect löst dieses Problem; allerdings muss dazu die Htmldoc-interne Proxy-Konfiguration ganz weggelassen werden.

Fazit

Leider ist dieses nützliche kleine Tool derzeit noch weitgehend unbekannt. Bleibt zu wünschen, dass es baldmöglichst zum Standardrepertoire vieler Linux-Distributionen gehört. (fjl)