Die vielfach belegte Binsenweisheit sagt: Zwei Drittel aller IT-Angriffe stammen von internen Rechnern ([1], [2]), sei es böse Absicht des Benutzers oder ein versehentlich eingeschleppter Trojaner. Klar ist, dass in dieser Situation eine ernstzunehmende Firewall auch den nach draußen gerichteten Verkehr überwachen muss. Kaum ein Browser findet aus einem Firmennetz direkten Zugang zu öffentlichen Webservern, meist klemmt sich ein Proxy mitsamt Contentfilter und Virenscanner dazwischen und wacht über den Datenverkehr.
Dieser Schutz droht zu scheitern, wenn Benutzer oder Programme die Firewall von innen durchtunneln, nur um ihren Lieblingsdienst zu erreichen, und dabei munter Kollateralschaden anrichten. Den Tunnel nutzen Angreifer gern auch in der Gegenrichtung, um ins LAN einzudringen. Ein früherer Artikel im Linux-Magazin [3] zeigte, welche raffinierten Tricks sich Tunnelbauer ausdenken.
Glücklicherweise bleibt die Mehrheit der Möchtegern-Ausbrecher bei simplen Techniken, die zwar herkömmliche Firewalls täuschen, sich mit etwas Zusatzaufwand dennoch automatisch enttarnen lassen. Der Aufwand lohnt doppelt, da er die akute Gefahr bannt und zudem Admins und IT-Leitern verrät, welche Benutzer gegen die Regeln verstoßen.
Ausgangssituation
Ein typisches Proxy-geschütztes Netzwerk skizziert Abbildung 1. Die innere Firewall erlaubt lediglich Verbindungen von den Clients an den Proxy in der DMZ, die äußere Firewall lässt nur Verbindungen vom Proxy ins Internet zu. Das entspricht der vom BSI empfohlenen P-A-P-Architektur (Paketfilter, Application Level Gateway, Paketfilter). Der Proxy gestattet üblicherweise »CONNECT«-Requests nur für den Zugriff auf SSL-verschlüsselte Webserver und erlaubt daher nur den Zielport 443. Vor dem Webproxy (beispielsweise Squid) durchsucht ein Virenscanner den Verkehr. Auf demselben Rechner läuft zusätzlich noch Snort als IDS (Intrusion Detection System). Die beiden Firewalls sind nach BSI-Empfehlung von unterschiedlichen Herstellern und beherrschen Stateful Filtering.
Abbildung 1: Viele Firmen und Admins vertrauen auf eine mehrstufige Firewallkonfiguration, um Verbindungen zur Außenwelt nur durch einen Proxy zu erlauben, der in der DMZ steht.
Diese Konfiguration ist bereits deutlich aufwändiger als die meisten Firewalls in kleinen und mittelständischen Unternehmen. Trotzdem gelingt es mit einfachen Mitteln, aus diesem Netz auszubrechen und geroutete Rückverbindungen zu ermöglichen, etwa mit OpenSSH, OpenVPN oder Instant-Messaging-Programmen bis hin zu Skype. Sie unterwandern die Firewall und kommunizieren zu allem Überfluss verschlüsselt, sodass auch das IDS nichts erkennt.
SSH
Die Secure Shell ist der De-facto-Standard für Remote-Zugriffe auf Kommandozeilenebene. Neben der originären Aufgabe, einen Shellprompt auf einem entfernten System zu erlangen oder dort Befehle auszuführen, erlaubt es SSH per Port-Forwarding, TCP-Verbindungen vom Client zum Server oder in der anderen Richtung zu tunneln.
Für den Fall, dass die Firewall einen Proxy erzwingt, haben die Entwickler die SSH-Option »ProxyCommand Skript« erfunden. Sie steht entweder in der Datei »~/.ssh/config« oder als »-o "ProxyCommand Skript"« im SSH-Aufruf. Das angegebene Skript übernimmt den Verbindungsaufbau zum Proxy (siehe Kasten "SSL-Requests und Proxys") und übergibt den Dateideskriptor der Netzwerkverbindung an den SSH-Prozess.
Mark Suter hat ein passendes Skript geschrieben [4]. Es nutzt die Connect-Methode des Proxys, um SSH zu verbinden. Da der Proxy nur anhand der Portnummer ermittelt, welches Protokoll er durchverbindet, genügt es in der Regel, den SSH-Server auf Port 443 zu betreiben, um den Proxy auszutricksen.
|
Wenn sie nach einer Webseite fragen, schicken Webbrowser einem Webproxy normalerweise die gewünschte HTTP-Methode, die vollständige URL sowie eine ganze Reihe von Header-Feldern. Bei HTTPS-Requests funktioniert das nicht, da schon die URL verschlüsselt zum Webserver gehen soll. Sie kann vertrauliche Daten enthalten, etwa »GET«-Parameter auf CGI-Seiten. Daher beginnt der Dialog zwischen Browser und Webserver normalerweise mit der HTTP-Methode »CONNECT«:
CONNECT www.linux-magazin.de:443 HTTP/1.0
Host: www.linux-magazin.de
User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv:1.8.1.11) Gecko/20071127 Firefox/2.0.0.14
HTTP/1.0 200 Connection established
Der Client sagt dem Proxy also nur, zu welchem Server an welchem Port er eine Verbindung wünscht, und er teilt seine Browser-Kennung mit. Nach diesem Dialog reicht der Proxy die Daten zwischen Client und Server nur noch durch, ohne sie weiter zu untersuchen, da die Verbindung Ende-zu-Ende-verschlüsselt ist.
Nach Ende der Verbindung schreibt der Proxy in das Logfile, wie lange sie gedauert hat und wie viele Daten er transferiert hat.
|
Im Skript sind die IP-Adresse oder der Hostname sowie der Port des Webproxys einzutragen. Verlangt der Proxy eine Authentifizierung, dann nimmt das Skript auch Username und Passwort auf. Im Aufruf »ssh -o "ProxyCommand ssh-https-tunnel.pl %h %p" User@Zielhost« ersetzt SSH die Platzhalter »%h« und »%p« durch Host und Port des Zielrechners.