Die einen wollen alles kontrollieren, die anderen unbehelligt kommunizieren: Wenn Admins die Firewall zu sehr abdichten, dann kontern die Benutzer mit geheimen Tunneln und getarnten Kanälen. Welche Techniken beide Seiten einsetzen, beschreibt dieser Artikel.

Ein Tunnelbauer berichtet: “Vor etlichen Jahren saß ich in der Uni-Bibliothek vor einem alten Textterminal und wollte eine Webseite lesen. Dummerweise hatten die Terminals keinen Browser installiert – kein Problem, es gab spezielle Web-to-Mail-Gateways. Ich musste nur die URL in die Betreffzeile einer E-Mail tippen und sie an das Gateway adressieren. Das lud die Seite und sandte den Inhalt zurück zu mir. Heute dürfen die Studenten ohne Umwege im Web recherchieren. Dennoch benutzen manche das Gateway noch immer, etwa um auf gesperrte Seiten zuzugreifen.”

Es ist leicht, vom internen Netz ein Sicherheitsloch nach außen zu graben, vorbei an allen Firewall-Regeln und -Policys. Solche verborgenen Tunnel (Covert Channel) sind recht verbreitet, schwer aufzuspüren und – je nach Perspektive – ein Segen für die Benutzer oder ein Fluch für die Admins. Tunnelbauer wählen ein Protokoll, das von den geltenden Firewall-Regeln erlaubt ist, und widmen es kurzerhand um. Damit umgehen sie Sicherheitsrichtlinien, ohne dass die Firewall etwas merkt.

Egal wie aufwändig die Gegenmaßnahmen ausfallen, sie werden den geheimen Verkehr nie ganz verhindern. Wo immer es einen erlaubten Kommunikationskanal gibt, können ihn die Teilnehmer als Träger benutzen und darin weitere Nachrichten einbetten. Sie nutzen das, um vertrauliche Informationen ohne Spuren in den Logfiles nach außen zu übermitteln, dem Überwachungswahn des Chefs zu entkommen oder um eine Hintertür für Zugriffe von außen zu öffnen.

Tunnel-Klassen

Gestattet es ein Paketfilter den Insidern, wenigstens einen Port nach außen zu öffnen, dann genügt eine einfache PPP-Verbindung (Point to Point Protocol) als Tunnel. Der Insider muss nur einen Rechner im externen Netz so konfigurieren, dass der PPP-Daemon auf dem von der Firewall erlaubten Port lauscht.

Das kann durchaus Port 80 sein – ein reiner Paketfilter ahnt nicht, ob die Endpunkte über den Port wie üblich per HTTP oder wie hier per PPP kommunizieren (Abbildung 1). Mit passenden Routing-Einstellungen leitet die Gegenstelle im Internet alle Pakete von und zur internen Maschine wie gewünscht weiter. Wer neugierige Admins am Abhören hindern will, schützt die Verbindung zwischen internem und externem Tunnel-Endpunkt durch SSL/TLS (Secure Sockets Layer/Transport Layer Security).

VPN-Taktik

Die Technik ist etabliert, viele VPNs (Virtual Private Network) arbeiten so. Selbst der benötigte Root-Zugriff auf einen externen Rechner ist heute kein Problem, dank DSL-Flatrates oder gemieteter Root-Server. Selbst dynamisch zugewiesene IP-Adressen, die sich bei jedem Re-Connect ändern, sind keine Hürde: Es gibt genügend Dyn-DNS-Dienste, die dem Rechner einen Hostnamen spendieren und ihn korrekt auflösen.

Wer es bequem will, setzt im firmeninternen Rechner auf kreatives Routing mit IProute2 und IPtables. Die Routing-Entscheidungen seines Rechners fallen dann abhängig vom Inhalt der Pakete. Verbietet die Sicherheitspolicy beispielsweise Zugriffe auf Port 119 und 6667, dann müssen Verbindungen zu diesen Ports durch den Tunnel laufen. Alle anderen Daten sollten ganz unverdächtig den normalen Weg durch die Firmen-Firewall gehen. Nötig ist dazu, die zu tunnelnden Pakete mit einer »MARK«-Anweisung in IPtables zu markieren. IProute2 wertet diese Markierung aus und schiebt das Paket durch den Tunnel.

Abbildung 1: Die Firewall verhindert, dass interne Clients (links) direkt auf die verbotenen Server (rechts oben) zugreifen. Durch eine PPP-Verbindung über Port 80 zu einem erlaubten Server (rechts) umgeht ein Client diese Beschränkung und verschafft sich indirekten Zugriff.

Zur Auswahl stehen viele VPN-Implementierungen und einfache Skripte, die Tunnel mit dieser Technik erzeugen. Am Ende des Artikels sind einige Beispiele ausgeführt. Sehr umfassend ist das Konzept in einem Paper von Alex Dyatlov und Simon Castro erklärt [1].

HTTP-Tunnel

HTTP nimmt eine Sonderrolle ein, es ist heute beinahe überall gestattet. Folglich ist es ein idealer Träger für Tunnel und andere Protokolle. Die Grundidee ist einfach: Ein Tunnel-Daemon gibt sich als HTTP-Server aus; der Client sendet gefälschte Anfragen, die der Server mit imitierten HTTP-Antworten quittiert, in die er die gewünschten Daten einfügt. Das klappt sogar über eine Proxy-Firewall hinweg (Abbildung 2).

Die Implementierungen tarnen Anfragen und Antworten als HTTP unterschiedlich. Ein Request in HTTP 1.1 [2] besteht aus mehreren Headerzeilen, eine Leerzeile schließt sie ab:

Kommando Ressource HTTP/1.1
Host: Zielhost
X-Data: Daten

Standardisierte Kommandos sind »GET«, »PUT«, »HEAD«, »POST«, »OPTIONS«, »DELETE«, »TRACE« und viele mehr. Eigene Daten lassen sich in jedem Headerfeld verstecken. Der Absender hat lediglich dafür zu sorgen, dass die eingebetteten Daten so aussehen wie im jeweiligen Feld üblich. Andernfalls hätten Firewalls, die als Application Level Gateway arbeiten, leichtes Spiel. Es genügt meist, bei typischen Feldlängen zu bleiben und Leerzeichen durch Punkte oder Schrägstriche zu ersetzen:

GET http://hier.darf/was/hin.html HTTP/1.1
Host: auch.der.Rechnername.eignet.sich
X-Data: Im Datenfeld ist es sehr einfach

Ganz ähnlich die Antwort. Im einfachsten Fall packt der Server die Daten in eine HTML-Seite und liefert diese aus. Etwas trickreicher ist es, auch hier Headerfelder mit Nutzdaten zu füllen:

HTTP/1.1 200 OK
Date: Wed, 15 Jun 2005 21:07:58
Server: Ein Teil der Antwort 1.2.3
Content-Length: 31331
Content-Type: application/octet-stream
X-Data: Daten oder Gegenfragen zum Client

Um unentdeckt zu bleiben, könnte der Server eine Authentifizierung verlangen, bevor er dem Client Informationen liefert. Scheitert sie, liefert er unverfängliche HTML-Seiten und präsentiert sich als gewöhnlicher Webserver.

Statt einen eigenen Pseudo-Webserver zu entwickeln, bietet sich das »CONNECT«-Kommando aus dem HTTP-Standard an. Es ist die wohl einfachste Methode, um fremde Protokolle durch einen Proxy zu schleusen. Als Tunneleingang dienen auf dem Client einfache Programme wie HTTPort [3] oder HTTP-Tunnel [4]. Passende Gegenstellen listet [5]: Diese anonymen Proxys erwarten Anfragen auf TCP-Port 80 und verbinden den Client zu jedem gewünschten Server. Die Methode eignet sich für die meisten Protokolle, etwa SSH, IRC oder Telnet.

Abbildung 2: Die Firewall verhindert, dass der IRC-Client seinen Request direkt an den Server richtet. Er umgeht dies, indem er den IRC-Request in einem HTTP-Request verpackt, der über den Proxy die Firewall passiert und den das Tunnelende wieder auspackt und an den IRC-Server leitet.

Dummerweise haben auch Spammer dies entdeckt. Zur Gegenwehr filtern heute die meisten Firewall-Admins sämtliche »CONNECT«-Requests. Bei HTTPS-Verkehr gelingt ihnen das aber nicht, die SSL/TLS-Verschlüsselung schützt zudem die Privatsphäre des Tunnels und vereitelt das Abhören, daher ist sie in jedem Fall zu bevorzugen.

DNS und SMTP als Tunnel

Wenn es möglich ist, Daten im HTTP-Header zu verstecken, dann gelingt es auch bei anderen Protokollen. Etwa bei DNS (Domain Name System), hier dienen DNS-Querys und -Responses als Träger. Die Technik ist nicht sonderlich effizient, da sie nur kleine Datenmengen in wenigen UDP-Paketen unterbringt. UDP arbeitet zu allem Überfluss verbindungslos und damit nicht zuverlässig. Außerdem speichern DNS-Server die Antworten meist für Stunden (Cacheing).

DNS-Tunnel sind folgerichtig wenig populär. Interessant sind sie dennoch, da DNS oft noch durch eine Firewall kommt, die sich sonst extrem zugemauert gibt. Wenn der DNS-Traffic aber schlagartig zunimmt, ist die Gefahr groß, dass ein Admin etwas bemerkt.

Effizienter und weniger auffällig sind E-Mail-basierte SMTP-Tunnel [6]. Da eine typische E-Mail heute oft mit Bildern und anderem Kram auf mehrere MByte kommt, fallen die zusätzlichen Tunneldaten kaum auf. Für langfristige Verbindungen ist diese Variante dennoch gefährlich, da häufige SMTP-Verbindungen zu nur einem Server als Anomalie vielleicht Verdacht erwecken.

Abbildung 3: Während sich bei einer normalen TCP-Übertragung die Sequenznummer von Paket zu Paket erhöht (grün), missbraucht dieser TCP-Tunnel ihren Wert als Datenfeld – gut an der wilden Verteilung der Nummern (rot) zu erkennen.

Untere Schichten

Wenig überraschend gibt es auch viele Überlegungen, um Daten in TCP- und IP-Headern zu verstecken [7]. Zum Beispiel könnte die ISN (Initial Sequence Number) beim TCP-Verbindungsaufbau eine neue Bedeutung erhalten. Trickreicher ist es aber, die Acknowledgement Number zu verwenden: Dieses 32-Bit-Feld ist bei dem Verbindungsaufbau mit gesetztem SYN-Flag bedeutungslos.

Nach [8] stehen noch weitere Felder für praktisch beliebige Manipulationen zur Verfügung, da viele TCP/IP-Stacks deren Inhalt ignorieren, wenn sie ihn für irrelevant halten.

Auch durch gezieltes Fragmentieren von IP-Paketen lässt sich Information übermitteln oder durch ungültige Pakete, die eine Firewall durchdringen. Sogar für ICMP (Internet Control Message Protocol) gibt es Tunnel-Lösungen ([9], [10]). Sie nutzen Ping-ähnliche Anfragen und Antworten zur Datenübertragung.

Diese Techniken sind zwar wenig effizient, da recht leicht aufzuspüren (Abbildung 3), ihr besonderer Charme ist aber die Unabhängigkeit vom Applikationsprotokoll. In speziellen Situationen, wenn eine Firewall nur ein exotisches Protokoll durchlässt, sind IP-, TCP- oder ICMP-Tunnel sehr hilfreich. Sollte auch das nicht klappen, lässt sich selbst im Timing der Pakete wertvolle Information verbergen, siehe Kasten “Gekonnt verzögern”.

Gekonnt verzögern

Im Rahmen einer Diplomarbeit [30] wurde ein verdeckter Zeitkanal (Covert Timing Channel) in die Kommunikation zwischen Apache-Server und WWW-Client eingefügt, der weder Header-Informationen noch übertragene Daten verändert. Eine inhaltliche Analyse der Daten, etwa per Sniffer, findet keine Auffälligkeiten. Abbildung 4: Bei größerer Verzögerung (x-Achse) nehmen die Übertragungsfehler (y-Achse) exponentiell ab. Fehlerkorrektur verbessert erst bei hohen Verzögerungen die Qualität merklich. Bei großer Verzögerung wird die verdeckte Kommunikation aber immer auffälliger. Beim Ausliefern einer größeren Datei überträgt der Webserver die Daten in 4-KByte-Blöcken und verzögert einzelne Blöcke um wenige Millisekunden – abhängig von den verdeckt zu übertragenden Informationen, die der Kontroll-Daemon »ccdaemon« dem Webserver mitteilt. Der Empfänger untersucht, wie lange er auf das Eintreffen der Blöcke warten muss, und interpretiert die Wartezeiten als Nullen (unverzögert) oder Einsen (verzögert). Leicht geänderter Apache Für die Implementierung waren nur geringfügige Änderungen am Apache-Quellcode nötig. Die Funktionen »ap_send_fd()« und »ap_send_mmap()« (in der Datei »src/main/http_protocol.c«) enthalten Schleifen, die für den blockweisen Transport zuständig sind und sich in der geänderten Fassung um die gezielte Verzögerung kümmern. Ob er einen Block verzögern soll, erfährt der Apache vom Kontroll-Daemon. Der Empfänger analysiert die Verzögerungen nachträglich mit Hilfe statistischer Methoden, da ihm die durchschnittliche Dauer der verzögerten und unverzögerten Übertragung nicht vorab bekannt ist. Kapazität Der verdeckte Kanal überträgt mit jedem 4-KByte-Block auf dem Trägerkanal jeweils nur 1 Bit – die maximale (relative) Kapazität liegt, wenn es keine Übertragungsfehler gibt, also bei 1 Bit / 4 KByte = 0,003 Prozent. Schon kleine verdeckte (Text-)Botschaften brauchen daher große Trägerdateien. Niedrige Verzögerungszeiten führen zu hohen Fehlerraten – bis hin zur vollständig gestörten Übertragung. Fehlerkorrekturverfahren helfen nur bei hohen Verzögerungen mit ohnehin niedriger Fehlerrate. Abbildung 4 zeigt die Fehlerraten bei einer DSL-Anbindung von Server und Client; in lokalen Netzen ergeben sich niedrigere Fehlerraten. (Hans-Georg Eßer)

Die Vielfalt an fertig verfügbaren Tunnelprogrammen deckt auch so interessante Techniken ab wie die MSN-Shell [10], die eine Unix-Shell über das MSN-Messenger-Protokoll fernsteuert. Wer einen Tunnel braucht, hat die Wahl zwischen hunderten Implementierungen, die oft mehrere Methoden und Protokolle unterstützen. Die enorme Menge garantiert, dass niemand jede Variante kennt und Admins, Firewalls und Intrusion-Detection-Systeme die verborgenen Kanäle nur sehr schwer enttarnen können.

Malware

Neben Angestellten, die einen Tunnel durch die Firmen-Firewall graben, ist vor allem Malware (Viren, Würmer und Trojanische Pferde) berüchtigt dafür, verdeckte Kanäle zu verwenden. Nach einer Infektion nimmt die Schadsoftware Befehle an einem Netzwerkport entgegen oder sendet vertrauliche Daten nach außen. Beliebt sind dabei IRC-Server (Internet Relay Chat), da sie dem Angreifer zusätzliche Anonymität geben.

Viele Malware richtet auf dem einzelnen angegriffenen Rechner keinen erkennbaren Schaden an. Cracker, Spammer und Konsorten freuen sich aber über jeden Rechner und spannen ihn in groß angelegte DoS-Angriffe ein (Denial of Service) oder funktionieren ihn zur Spam-Schleuder um [11]. Oft bündeln sie zehn- oder hunderttausend Rechner zu so genannten Bot-Netzen, die dann gemeinsam enormen Schaden anrichten [12].

Für Cracker interessant sind geknackte Rechner für Island Hopping: Sie verbinden sich durch mehrere Relaisstationen mit dem nächsten Opfer. Der Weg ist dann kaum noch zurückzuverfolgen. Oft zeigt die Analyse des Netzverkehrs kaum verwertbare Spuren; dann hilft nur noch, in eingeschleustem Code nach Spuren zu fahnden. Michael Murr zeigt in einem Paper [13], wie er ein Trojanisches Pferd sehr detailliert analysiert und dabei dessen Tunneltechnik erforscht.

Wer selbst mit verdeckten Kanälen experimentieren will, kommt mit weniger Aufwand aus. Ein HTTP-Tunnel für beliebige TCP-Verbindungen ist schnell gegraben. Die Suche nach »TCP HTTP Proxy« auf Freshmeat liefert als ersten Treffer das Tool namens PR-Tunnel [14]. Herunterladen, auspacken und »make && make install« eintippen – fertig. Fehlt nur noch ein öffentlicher Proxy. Entweder man setzt einen eigenen auf (Tinyproxy [15] wäre eine gute Wahl) oder wird bei Multiproxy [5] fündig.

PR-Tunnel und Firepass

PR-Tunnel erwartet beim Aufruf mehrere Parameter. Hinter »-H« steht der HTTP-Proxy, nach »-P« dessen Portnummer. Am Ende braucht das Tool noch den lokalen Port sowie den Zielrechner und dessen Port. Ein vollständiges Kommando lautet: »prtunnel -H Proxyserver -P 80 6667 irc.funet.fi 6667«. Der IRC-Client muss sich künftig nur mit »localhost« verbinden, dann leitet der Tunnel die Verbindung zum Proxy und von dort per »CONNECT«-Kommando weiter zu »irc.funet.fi« auf Port 6667.

Weil eine Firewall die »CONNECT«-Methode recht leicht sperren kann, funktionieren raffiniertere Verfahren in der Praxis besser. Eine weitere Freshmeat-Suche, diesmal nach »TCP HTTP tunneling«, fördert zuerst Firepass [10] zutage. Es nutzt HTTP-»POST«-Kommandos. Das Paket enthält zwei Perl-Programme: ein CGI-Skript für den Server (»fpserver.cgi«) und ein weiteres Skript für den Client (»fpclient.pl«).

Damit das Gespann funktioniert, muss ein Webserver im externen Netz Perl-Skripte ausführen. In seinem CGI-BIN-Verzeichnis muss »fpserver.cgi« liegen und Zugriff auf »fpserver.conf« sowie »fpserver.allow« erhalten. Deren Originale stammen aus dem Unterverzeichnis »fpserver/conf« im Firepass-Paket. Die Vorlagen dokumentieren recht gut, welche Parameter sie verstehen.

Der Firepass-Server braucht noch zwei temporäre Verzeichnisse »inout« und »log«, die zum Beispiel in »/var/tmp« liegen können. Der HTTP-User braucht Schreibrecht, der Ort dieser Verzeichnisse ist in »fpserver.conf« einzutragen. Wo diese Konfigurationsdatei steht, erfährt das Skript durch den Aufruf »./fpserver.cgi configure /Pfad/fpserver.conf«. Läuft das Skript nicht, dann sind seine Rechte falsch gesetzt oder der Pfad zum Perl-Interpreter (erste Skriptzeile) ist falsch. Im Erfolgsfall legt es die Datei »fpcnf.cache« im gleichen Verzeichnis an, in dem das CGI-Skript liegt.

Auch der Client will konfiguriert sein. Optional sind die Einstellungen in »conf/fpclient.conf« und »conf/fpclient.allow«. Interessanter ist »conf/fpclient.rules«, hier stehen die Regeln, auf welchem lokalen Port und Transportprotokoll (TCP oder UDP) der Client Verbindungen entgegennimmt und wohin (ebenfalls Port und Protokoll) er sie leitet.

Das bereits bei PR-Tunnel verwendete Beispiel würde hier lauten: »6667 tcp irc.funet.fi 6667 tcp«. Nun genügt ein Aufruf des Clients mit »./fpclient.pl conf/fpclient.conf Server-Adresse/cgi-bin/fpserver.cgi« und schon öffnet sich ein Tunnel für den IRC-Client. Die Firewall sieht nur die gewöhnlichen HTTP-»POST«-Requests und deren Antworten.

PR-Tunnel und Firepass haben einen Schönheitsfehler: Sie leiten nur einzelne Ports durch den geheimen Kanal. VPN-Techniken schaffen mehr. Ein einfaches VPN, das den kompletten Datenverkehr durch einen Tunnel quetscht, der einen beliebigen Port benutzt, ist mit Stunnel [16] und einem PPP-Daemon [17] schnell aufgebaut.

Statt sich selbst die Mühe zu machen, empfiehlt es sich, fertige Tools einzusetzen, etwa OpenVPN (siehe den folgenden Artikel). Das Linux-Magazin 10/03 enthält sogar einen Heft-Schwerpunkt zu VPN-Techniken und -Produkten.

Abbildung 5a: Ein- und ausgehenden Verkehr eines Webmail-Dienstes (HTTPS-Verbindung). Der Server (rot) sendet wesentlich mehr Daten als der Client.

Abbildung 5b: Transportiert die HTTP-Verbindung einen verdeckten Datenkanal, ändert sich die Charakteristik. Jetzt sendet der Client deutlich mehr Daten.

Erkennungsdienst

So leicht es ist, einen Tunnel aufzusetzen, so schwer ist er aufzuspüren. Speziell verschlüsselte Kanäle (etwa SSL) bereiten jedem Admin Kopfschmerzen. Die Kryptographie verhindert, dass er den Verkehr entschlüsselt und analysiert. Statt sich an diversen Tricks zu versuchen ([19], [20]), sollte sich der Tunnel-Fahnder auf die äußere Charakteristik des Verkehrs konzentrieren.

Oft sind es sehr einfache Anzeichen, die einen geheimen Kanal verraten. HTTP-Verbindungen übertragen gewöhnlich wesentlich mehr Daten von extern nach intern als in die Gegenrichtung. Der Browser schickt eine kurze Anfrage an den Server, der mit großen Datenmengen antwortet (HTML-Seiten, Bilder, Sound und so weiter). Das äußert sich deutlich in einem Graphen, der ein- und ausgehenden Verkehr gegenüberstellt. Abbildung 5a zeigt das Beispiel eines Webmail-Servers, den der Client per HTTP über SSL (HTTPS) kontaktiert. Zu Beginn senden sich beide Daten zu, dann schickt der Server einen großen Block verschlüsselter Daten.

Verbirgt sich hinter der SSL-Fassade ein geheimer Tunnel statt des gewöhnlichen HTTP-Verkehrs, dann verlassen wesentlich mehr Daten das interne Netz. Das könnte zwar auch ein Anzeichen für einen Datei-Upload auf einen normalen Webserver sein; wer eine Charakteristik wie in Abbildung 5b sieht, hat es aber meist mit einem verdeckten Tunnel zu tun [21]. Dieser Graph zeigt einen HTTP-Tunnel ohne SSL; in einem verschlüsselten Tunnel würde der Client noch mehr Daten senden (Handshake, Schlüsselaustausch, Hashwerte …).

Abbildung 6a: Der Datenstrom enthält fragmentierte Pakete. Ethereal hebt das über Filter hervor: Die schwarze Kurve zeigt alle Pakete, die rote nur Fragmente mit einem Offset ungleich null (das erste Fragment wird dadurch nicht erfasst).

Abbildung 6b: Diese Darstellung vergleicht die Anzahl der Pakete, die zum Rechner »192.168.0.80« gerichtet sind (schwarz), mit jener der von ihm kommenden (rot). Die Gegenstelle sendet wesentlich mehr Daten.

Durchhaltevermögen

Verräterisch ist auch die Dauer einer Verbindung. Ein verdeckter Tunnel bleibt meist recht lange bestehen. Bei gewöhnlichem HTTP wartet der Client nur kurz auf die Antwort des Servers, in der Regel wenige Sekunden bis maximal zwei oder drei Minuten. Spätestens nach 10 oder 15 Minuten brechen die meisten Browser jede Verbindung ab.

Steht die Leitung dagegen mehrere Stunden, dann ist das ein klares Indiz für verborgene Tunnel. Auch eine hohe Anzahl von Verbindungen zu einem einzelnen Host ist eine typische Spur, ebenso häufige Verbindungsversuche am Abend zu einem einzelnen Rechner im Internet.

Um typische Anzeichen zu erkennen, empfiehlt es sich, für jeden Netzwerkadmin, zunächst selbst mit Tunnelvarianten zu spielen und deren Spuren aufzuzeichnen. Die folgenden Beispiele verwenden die Tunnel-Shell [22] zwischen den Hosts 192.168.0.33 und 192.168.0.80. Tcpdump zeichnet den Verkehr auf: »tcpdump -vvv -w tunfrag.dat«, für die Analyse sind die GUI-Frontends Ethereal [23] und Netdude [24] zu empfehlen.

Trickreiche Fragmente

Viele Firewalls lassen sich von fragmentierten Paketen austricksen: Das Internetprotokoll verteilt bei diesem Verfahren den Inhalt eines IP-Pakets auf mehrere Pakete. Die Header höherer Schichten berücksichtigt das Verfahren nicht. Damit beginnt nur der Inhalt des ersten Fragments mit einem TCP- oder UDP-Header. In den nachfolgenden Paketen findet die Firewall keine Portnummern mehr und lässt – wenn der Tunnelbauer Glück hat – das Fragment durch.

Der Netzwerk-Graph in Abbildung 6a zeigt, dass sich viele fragmentierte Pakete im Netz tummeln. Abbildung 6b schlüsselt auf, dass die meisten das Netz von außen erreichen. Ein Blick in die Pakete offenbart, was sich in diesem ungewöhnlichen Verkehr verbirgt.

Der Inhalt eines gewöhnlichen IP-Pakets beginnt mit dem Header der nächsthöheren Protokollschicht, zum Beispiel TCP. Netdude zeigt diesen Aufbau sehr übersichtlich (Abbildung 7a). In IP-Fragmenten ist meist kein Header mehr zu finden, nur das erste Fragment des IP-Gesamtpakets enthält einen TCP-Header oder wenigstens dessen Anfang.

Abbildung 7b zeigt den Inhalt eines späteren Fragments: In bester Ascii-Kodierung stehen dort die Worte »adduser bogus«. Die Vermutung liegt sehr nahe, dass es sich um ein Shellkommando handelt und die Shell als Hintertür auf dem Host 192.168.0.80 arbeitet.

Abbildung 7a: Den Aufbau eines TCP-Headers stellt Netdude sehr anschaulich dar. Dieses Paket beendet eine Verbindung: Das FIN-Flag (»F«) ist gesetzt.

Abbildung 7b: Dieses IP-Fragment enthält keinen TCP-Header, dafür einige Ascii-Zeichen. Vermutlich interpretiert der Empfänger den Inhalt als Shellskript.

Im realen Einsatz wird der Paketinhalt oft verschlüsselt sein. Trotzdem lohnt ein Blick in die Innereien: Unerwartete Fragmente, eigenartig verschachtelte Protokolle und ungewöhnliche Kombinationen von Flags sind gute Kandidaten für weitere Analysen, besonders wenn diese Anomalien wiederholt auftreten.

Firewall

Immer eine gute Idee ist der Einsatz einer Statefull-Firewall oder eines Application Level Gateway (Proxy). Beide führen Buch über den genauen Status einer Verbindung. Sie wissen, wann eine neue Verbindung beginnt und welche Endpunkte sie verbindet. Damit kann sie auf Wunsch jede Verbindung trennen, wenn diese länger als eine bestimmte Zeit läuft. Auch der oben genannte Trick mit SYN-Paketen, deren Acknowledgement Number die Daten übermittelt, fällt auf: Die meisten Firewalls erkennen die steigende Anzahl an SYN-Paketen als SYN-Flood-Angriff, den sie abwehren.

Gegen einfache HTTP-Tunnel wie HTTPort [3] hilft es, die »CONNECT«-Methode für alle Zielports mit Ausnahme von TCP/443 (HTTPS) zu sperren. Dummerweise braucht HTTPS die Connect-Methode, wenn die Verbindung über einen Proxy läuft. Jeden SSL-Verkehr sperren ist meist unerwünscht; ihn nur zu wenigen, vertrauenswerten Zielen zu gestatten wäre schon besser.

Noch besser ist es, einen HTTP/HTTPS-Proxy zu verwenden, der den User erst authentifiziert. Dann weiß der Admin immerhin, wer wann was versucht. HTTP-Proxys blicken recht genau ins Webprotokoll. Tools wie HTTP-Filter [25] nutzen das und lassen ausschließlich erwünschten Traffic durch. Das klappt auch mit Contentfilter-Software. Befinden sich im internen Netz Systeme, die für Viren und Würmer anfällig sind, ist zudem ein Virenscanner Pflicht.

01 # ungewöhnliche Flags verwerfen
02 iptables -A INPUT -p tcp --tcp-flags ALL FIN,URG,PSH -j DROP
03 iptables -A INPUT -p tcp --tcp-flags ALL ALL -j DROP
04 iptables -A INPUT -p tcp --tcp-flags ALL SYN,RST,ACK,FIN,URG -j DROP
05 iptables -A INPUT -p tcp --tcp-flags ALL NONE -j DROP
06 iptables -A INPUT -p tcp --tcp-flags SYN,RST SYN,RST -j DROP
07 iptables -A INPUT -p tcp --tcp-flags SYN,FIN SYN,FIN -j DROP
08 # Unerwartete Pakete verwerfen und ungültige loggen
09 iptables -A INPUT -p tcp ! --syn -m state --state NEW -jDROP
10 iptables -A INPUT -p tcp -mstate --state INVALID -m limit --limit 10/m -j LOG --log-level info
11 # SYN-Flood-Schutz
12 iptables -N syn-flood
13 iptables -A INPUT -p tcp --syn -j syn-flood
14 iptables -A syn-flood -m limit --limit 1/s --limit-burst 4 -j RETURN
15 iptables -A syn-flood -j DROP
16 # HTTP-CONNECT-Anfragen ablehnen
17 iptables -I INPUT -p tcp -d 0/0 --dport 80 -m string --string "CONNECT" -j REJECT
18 # Anzahl Verbindungen begrenzen
19 iptables -p tcp -m iplimit --iplimit-above 2 -j REJECT --reject-with tcp-reset

Die Linux-Firewall IPtables [26] implementiert einige Optionen, die beim Unterbinden von verborgenen Kanälen helfen. Sie kann beispielsweise alle Pakete verwerfen, deren Flags ungültig kombiniert sind. Die in Listing 1 (Zeilen 2 bis 7) aufgeführten TCP-Flags sollten in normalem Verkehr nie vorkommen. Diese Regeln blockieren jeden Tunnel, der die Flags zur Kommunikation missbraucht. Ungültige Flags sind ein gutes Indiz für dubiose Aktivitäten im Netz.

Normalerweise ist jedes TCP-Paket entweder ein Verbindungsaufbauwunsch (SYN-Flag gesetzt) oder es gehört zu einer bestehenden Verbindung. Da IPtables den Zustand jeder Verbindung speichert, erkennt es Pakete, die zu keiner gehören und dennoch kein SYN-Flag gesetzt haben (Zeile 9). Den umgekehrten Fall – SYN gesetzt, aber keine passende Connection – spürt Zeile 10 auf und protokolliert ihn. Ein SYN-Flood-Schutz ist in den Zeilen 12 bis 15 zu sehen. Die Kommandos legen die neue Filterkette »syn-flood« an und begrenzen darin die Anzahl an SYN-Paketen auf maximal vier neue Verbindungen pro Sekunde.

Die genannten Optionen beherrscht jede IPtables-Implementierung. Nicht immer vorhanden ist das String-Modul, mit dem IPtables zum Contentfilter wird, beispielsweise um HTTP-»CONNECT«-Anfragen zu blockieren (Zeile 18).

Verfolgungsjagd

Das IP-Limit-Modul begrenzt die Anzahl an Verbindungen, die von oder zu einem Host gehen. Es gibt dem Admin zudem die Wahl zwischen mehreren Methoden, wie die Firewall überschüssige Verbindungen trennt. Neben der Variante »tcp-reset« (Zeile 20) kennt sie »proto-unreach« oder »host-unreach«, beides sind ICMP-Nachrichten.

Trotz aller Abwehr schaffen es ausgeklügelte Tunneltechniken, jede Firewall zu überwinden. Je tiefer der Filter in die Protokolle guckt und je mehr Anomalien er erkennt, um so besser tarnen die Entwickler ihre geheimen Kanäle. Den Admins bleibt nur, den kompletten Verkehr zu protokollieren und zu analysieren – vermeintlich erlaubten und offensichtlich verbotenen. Ob sie das dürfen, ist eine Frage des Datenschutzes.

Unstrittig ist das Auswerten von Firewall-Logfiles eine Admin-Pflicht [27]. Weitere wertvolle Anhaltspunkte liefern Intrusion-Detection-Systeme (IDS) wie Snort ([28], [29]). Mit wenigen einfachen Regeln erkennen sie Anomalien, loggen deren Quelle und zeichnen ungewöhnlichen Datenverkehr auf. Sehr interessant ist das CCTDE-Projekt von Gray-World (Covert Channels and Tunnels Detection Engine, [12]). Es fungiert als Snort-Präprozessor und spezialisiert sich darauf, verborgene Kanäle aufzuspüren.

Löchriger Boden

VPNs sind Stand der Technik, kaum eine Firma kommt ohne sie aus. Selbst die meisten DSL-Anschlüssen verwenden mit PPoE (PPP over Ethernet) einen Protokollstapel, den die Erfinder von PPP wohl so nicht erwartet hatten. Admins, Netzverantwortliche und die meisten User kennen und nutzen also Tunnel. Es überrascht, wie wenigen bewusst ist, wie gut sich diese Techniken für verdeckte Kanäle eignen, die mühelos strikte Sicherheits-Policys umgehen.

Mit technischen Maßnahmen allein ist der Abwehrkampf nicht zu gewinnen. Arbeitet die Firewall auf Applikationsebene, betten die kommunikationswilligen Insider ihren Tunnel in die übertragenen Dokumente und Bilder ein. Selbst wenn ein Application Level Gateway das Protokoll und die Struktur der Daten auf RFC-Konformität prüft, bleibt die Bedeutung von Begriffen im übertragenen Text – ganz wie in vielen Spionage-Thrillern, wenn der Bösewicht harmlosen Wörtern eine neue Bedeutung beimisst.

Ohnmacht braucht sich bei den Admins dennoch nicht einzustellen. Mit den oben genannten Maßnahmen erhöhen sie immerhin die Hürde für verdeckte Kanäle. Die Tunneltechniken sorgen auch für Waffengleichheit: Sollte ein wild gewordener Admin seine Allmachtsposition schamlos ausnutzen, geben verantwortungsvoll genutzt Tunnel den Benutzern ihre Freiheit zurück. (fjl)