© lama-photography, Photocase.com

Firewalls schützen vor Angriffen von außen. Aber auch die eigenen Benutzer sind gefährlich, wenn sie absichtlich oder aus Unwissenheit Tunnel durch die Firewall öffnen. Dagegen hilft verborgene SSH-, OpenVPN- und Skype-Verbindungen anhand ihres Fingerabdrucks aufzuspüren und zu unterbinden.

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.

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

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.

Ab durch den Tunnel

Zusammen mit den Optionen »-L« oder »-R« für Port-Forwarding durchbohrt SSH die Firewall komplett: »ssh […] -R 1521:oracleserver:1521« erlaubt es beispielsweise allen Benutzern auf dem Zielhost, direkt den Oracle-Server im geschützten Firmennetz anzusprechen.

Abbildung 2: Getunnelte Pakete verwenden den Proxy-Server für den Transfer und fallen an der Firewall nicht auf. Durch den Tunnel ist es möglich, IP-Pakete so zu routen, als wäre die Firewall gar nicht vorhanden.

Da SSH eigentlich dazu gedacht ist, eine Terminalsitzung bereitzustellen, kamen schon 1996 findige Anwender auf die Idee, über die sichere SSH-Verbindung eine PPP-Session zu starten. Aus Performance-Sicht ist das zwar heikel [5], in aller Regel funktioniert die Technik aber und erlaubt IP-Pakete durch die Firewall zu tunneln. Die Architektur in Abbildung 2 verdeutlicht, dass bei entsprechendem Routing der Client im internen Netz durch den Tunnel ungeschützt im Internet steht und damit auch ein Zugriff auf das LAN möglich ist. Neuere SSH-Versionen ersparen dem Admin sogar die PPP-Session und fordern mit der Option »-w« ein Tun-Interface an (Zeile 1 in Listing 1).

SSH konfiguriert das Tunnelinterface jedoch weder auf dem lokalen noch auf dem fernen Host (Zeilen 4 bis 9). Der Ausbrecher muss die Adressen selbst setzen und das Routing einrichten, damit die Pakete durch den SSH-Tunnel laufen. Im internen Netz konfiguriert er:

ifconfig tun0 192.168.1.1
route add -net Servernetz_außen dev tun0
iptables -t nat -A POSTROUTING -i tun0 -j MASQUERADE

Im externen Netz lauten die dazu passenden Kommandos:

ifconfig tun0 192.168.1.2
route add -net Internes_Netz dev tun0

Das Masquerading am internen Interface sorgt dafür, dass die von außen eindringenden Pakete aus Sicht des internen Netzes vom internen Rechner stammen.

01 localhost# ssh -w any Zielhost
02 Last login: Sat May 17 20:22:09 2008 from andererhost
03 zielhost# ifconfig tun0
04 tun0      Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
05           POINTOPOINT NOARP MULTICAST  MTU:1500  Metric:1
06           RX packets:0 errors:0 dropped:0 overruns:0 frame:0
07           TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
08           collisions:0 txqueuelen:500
09           RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)

Spürnase

Das SSH-Protokoll macht es glücklicherweise recht einfach, die SSH-Verbindungen zu erkennen: Zu Beginn senden sich Client und Server ihre Versionsnummern im Klartext zu. Ein »telnet localhost 22« ergibt als Antwort beispielsweise »SSH-1.99-OpenSSH_4.7«. Bei einem legalen SSL-Webzugriff folgen an dieser Stelle bereits Binärdaten des SSL-Handshake. Ein IDS kann das leicht unterscheiden. Beispielsweise erkennt folgende Snort-Regel SSH-Requests anhand des Strings »SSH-« und warnt, wenn sie auf Ports ungleich 22 laufen:

alert tcp any !22 -> any !22 (msg:"BLEEDING-EDGE Covert Non-Standard SSH Port Usage"; flags:AP+;content: "SSH-";depth:8; sid:2000354; rev:1;)

Snort könnte über »flexresponse« die entlarvten Verbindungen automatisch per TCP-Reset unterbrechen. Auch kommerzielle Lösungen wie Checkpoints Firewall-1 bieten im Rahmen ihrer Intrusion-Prevention-Technik die Möglichkeit, SSH-Verbindungen auf nicht-SSH-Ports zu erkennen und herauszufiltern. Bei solch rabiaten Maßnahmen ist aber Vorsicht angebracht, da sie oft mehr Schaden anrichten (Denial of Service), als sie nutzen. Der Kasten “Spuren im Proxy” nennt weitere Techniken, um getarnte SSH-Verbindungen aufzuspüren.

1211747508.013 33412 192.168.1.8 TCP_/MISS 200 39175 CONNECT www.linuxmagazin./de:443 - DIRECT/80.237.227.140 -

while(<>) {
    my @parts = split(/s+/);
    print $_ if $parts[1] > 5 * 60 * 1000;
}

1211207478.319 559806 192.168.1.1 TCP_MISS/000 37915 CONNECT 130.133.160.18:443 - DIRECT/130.133.160.18 -

OpenVPN

Das VPN-Paket OpenVPN [6] baut ebenfalls verschlüsselte Verbindungen zwischen Netzen auf. Es ist als Alternative zu IPsec gedacht, verpackt die Daten aber in UDP- oder TCP-Paketen (beide Port 1194). Eigentlich eignet sich UDP besser [5], für die Proxy-Anbindung sind jedoch TCP (Option »proto tcp«) sowie der HTTPS-Port nötig (»port 443«). Version 2.1 kennt praktischerweise die Option »–port-share Host Port«: Bemerkt der Server, dass der Client kein OpenVPN-Protokoll verwendet, dann mutiert er zum Reverse-Proxy und leitet alle Daten an den angegebenen Host und Port weiter. Auf diese Weise teilen sich ein OpenVPN-Server und ein Webserver den Port.

Mit der Anweisung »http-proxy Host Port« verbindet sich der OpenVPN-Client unter Verwendung des Webproxys an den externen OpenVPN-Server. Das Ergebnis ist auch hier eine voll geroutete Verbindung, die sich zunächst der Kontrolle durch die Sicherheitsinfrastruktur entzieht. Um sich im lokalen Netz zu tarnen, kann der Client noch NAT-Regeln einbauen, die die externen IP-Adressen hinter der Adresse des Clients verstecken. Damit sehen alle von außen stammenden Pakete so aus, als würden sie dem Client entspringen.

Trennkraft

OpenVPN ist darum nicht so einfach von SSL (und dessen Nachfolger TLS) zu unterscheiden wie OpenSSH. Selbst kommerzielle Intrusion-Detection-Systeme wie etwa Bluecoat lassen OpenVPN-Verbindungen passieren. Neben den im Kasten “Spuren im Proxy” vorgestellten Methoden gibt es noch einen weiteren Ansatz: Das OpenVPN-Protokoll verwendet zwar viele SSL-Bestandteile, ist aber dennoch ein eigenes Protokoll. Bei SSL erkennt Wireshark die ersten Stufen des SSL-Handshake noch als eigene Pakete. Bei OpenVPN zeigt der Sniffer nur den Vermerk »SSL Continuation Data«.

Das erste Paket der OpenVPN-Verbindung nach dem HTTP-»CONNECT« beginnt mit der hexadezimalen Bytefolge 00, 0E und 38. Die Snort-Anweisung »content:”|00 0E 38|”; depth:3;« sucht nach diesen Werten in den ersten 3 Bytes eines Pakets. Die Ergänzung »flow:to_server,established« bestimmt einschränkend, dass Snort die Bytefolge nur in einer etablierten Datenverbindung und in der richtigen Richtung sucht. Es scheint aber keine Anweisung zu geben, die Snort dazu zwingt, nur am Anfang des Datenstroms zu suchen. Dies wäre aber nützlich, um False Positives zu vermeiden.

Messaging-Programme wie Skype, Microsoft Messenger und viele mehr erlauben ihren Anwendern neben Audio- oder Video-Telefonaten und Text-Chats auch direkte Dateitransfers. Skype und MSN sind Closed-Source-Programme und bei Skype ist sogar das Protokoll geheim und chiffriert. Was diese Programme genau versenden, ist daher nicht einsehbar.

Beim MSN-Client bestimmt der Benutzer per Konfiguration, ob das Programm einen Proxy verwendet. Skype versucht unter Windows und Mac OS X zuerst eine direkte Verbindung und danach den systemweit eingestellten Proxy. Die Linux-Version von Skype hat eine eigene Proxy-Option.

Skype

In ihrem Paper [7] analysieren Philippe Biondi und Fabrice Descleaux, wie Skype funktioniert und was sich bei einer direkten Skype-Verbindung abspielt. Die lesenswerte Analyse zeigt, welche Anstrengungen der Hersteller unternimmt, um sowohl den Code als auch das Protokoll zu verschleiern. Leider stammt das Paper aus dem Jahr 2006 und die Skype-Entwicklungsabteilung hat mittlerweile nachgelegt, um von Intrusion-Detection-Systemen unentdeckt zu bleiben. Bei der oberflächlichen Analyse mit Wireshark sieht auch alles unauffällig aus, auf ein SSL-Client-Hello des internen Clients folgt das Server-Hello der Gegenseite.

Aufgefallen

Im Server-Hello ist jedoch etwas zu beobachten. Abbildung 3 zeigt, dass die Zertifikate fehlen, die ein echter SSL-Server präsentieren würde. Dies würde neben den im Kasten “Spuren im Proxy” vorgeschlagenen Methoden einem IDS einen einfachen Anhaltspunkt bieten. Vermutlich werden die Skype-Entwickler aber nachziehen, sobald die ersten Sicherheitssysteme den Ansatz nutzen.

Abbildung 3: Bei der Antwort eines Skype-Peers über einen Proxy fehlen die Zertifikate. Bei regulärem SSL-Traffic sendet mindestens der Server sein X.509-Zertifikat an den Client, bei beidseitiger Authentifizierung verfährt der Client ebenso.

Der zu Snort gehörende Regelsatz »p2p.rules« enthält daher eine Regel, die den Start eines Skype-Clients anhand eines anderen Kriteriums erkennt: Der Client probiert immer zuerst eine direkte Verbindung, bevor er sich an den Proxy wagt. Um das zu erkennen, muss Snort Verbindungsversuche über das Default-Gateway aufspüren.

MSN

Microsoft-Messenger-Verbindungen sind wesentlich einfacher zu erkennen als Skype. Der Client gibt sich durch den »UserAgent«-String zu erkennen und abgesehen von der Anmeldung sind gute Teile der Zugriffe sogar unverschlüsselt, wie Abbildung 4 zeigt. Zum Blocken ist es also hinreichend, den User-Agent am Proxy zu sperren. In Squid genügt hierzu eine Browser-ACL:

acl MSN browser -i MSMSGS
http_access deny MSN

IPS-Produkte, beispielsweise die Checkpoint Firewall-1, erlauben es in ihren Smart-Defense-Einstellungen sogar, einzelne Funktionen zu sperren oder freizugeben. Damit ist es möglich, Chat und Telefonie zu erlauben, aber Dateitransfers zu sperren.

Dass Instant-Messaging-Clients und Skype nach Kräften versuchen sich der Kontrolle durch eine Firewall zu entziehen, ist im ersten Moment zwar verständlich, stört die Rolle einer Firewall als zentrales Sicherheitsinstrument aber nachhaltig. Zudem öffnen auch OpenVPN oder die VPN-Clients von Juniper und Checkpoint bei Bedarf eine Verbindung via SSL über einen Proxy. Damit können Anwender und Anwendungen die Firewall mit einfachen Mitteln unterhöhlen.

Abbildung 4: Bei der Verbindung über einen Proxy gibt sich ausgerechnet der MSN-Client kooperativ: Er sendet eine eigene User-Agent-Kennung und verzichtet darauf, sein Protokoll zu verschleiern.

Löcher stopfen

Die anfangs vorgestellte Firewall-Konfiguration ist zwar recht aufwändig, gegen Tunnel durch den Proxy bleibt sie dennoch machtlos. Dem Admin bleibt nur, die Logfiles kritisch zu durchforsten und sein IDS in Stellung zu bringen. (fjl)