Sicherheitsrisiken aktueller WLAN-Implementierungen am Beispiel öffentlicher HotSpots

Aus Winfwiki

Name des Autors:	Florian Wolters
Titel der Arbeit:	Sicherheitsrisiken aktueller WLAN-Implementierungen am Beispiel öffentlicher HotSpots
Hochschule und Studienort:	Fachhochschule für Oekonomie & Management - Essen
Datum der Erstellung:	10.02.2009

Inhaltsverzeichnis 1 Abkürzungsverzeichnis 2 Abbildungsverzeichnis 3 Tabellenverzeichnis 4 Einleitung 5 Grundlagen HotSpots 6 Risiken bei der Benutzung öffentlicher HotSpots 6.1 Unverschlüsselte Datenübertragung 6.2 Man-in-the-middle Angriffe 6.3 Angriff durch Rechner im gleichen WLAN 7 Lösungsvorschläge zur Minimierung der Risiken 7.1 WLAN Verschlüsselung 7.2 verschlüsselte Protokolle 7.3 SSH-Tunnel 7.4 Virtuelle Private Netze 8 Ein praktisches Beispiel 8.1 Die VPN-Software 8.2 Das VPN-Gateway 8.3 Der Client 8.4 Die Kommunikation 9 Fazit 10 Fußnoten 11 Literaturverzeichnis

1 Abkürzungsverzeichnis

Abkürzung	Bedeutung
AES	Advanced Encryption Standard
AP	Access Point
CA	Certificate Authority
DHCP	Dynamic Host Configuration Protocol
DNS	Domain Name System
DSL	Digital Subscriber Line
DynDNS	Dynamisches DNS
HTTP	HyperText Transfer Protocol
HTTPS	HyperText Transfer Protocol Secure
IMAPS	Internet Message Access Protocol Secure
IP	Internet Protocol
LAN	Local Area Network
LZO	Lempel-Ziv-Oberhumer
PDA	Personal Digital Assistant
POP3S	Post Office Protocol 3 Secure
RTP	Realtime Transport Protocol
SSH	Secure Shell
SSL	Secure Socket Layer
TCP	Transmission Control Protocol
TLS	Transport Layer Security
UDP	User Datagramm Protocol
VPN	Virtual Private Network
WEP	Wired Equivalent Privacy
WLAN	Wireless LAN
WPA	Wi-Fi Protected Acesss

2 Abbildungsverzeichnis

Abbildung 1:	Schematische Darstellung des Empfangsbereich eines Access Points
Abbildung 2:	Darstellung eines HTTP Paketes
Abbildung 3:	Schematische Darstellung eines "Man-in-the-middle" Angriffs
Abbildung 4:	Logische Position einer Firewall
Abbildung 5:	Access Point mit aktivierter Verschlüsselung
Abbildung 6:	Darstellung der Kommunikation mittels verschlüsselter Protokolle
Abbildung 7:	SSH-Tunnel zwischen Nutzer und einem SSH-Server
Abbildung 8:	VPN-Tunnel zwischen Nutzer und VPN-Gateway
Abbildung 9:	Modifizierte Routingtabelle eines Clients
Abbildung 10:	Schematische Darstellung der VPN Kommunikation
Abbildung 11:	Pfad zu einem Server im Internet via VPN-Gateway

3 Tabellenverzeichnis

Tabelle 1:	Vor- und Nachteile von WLAN Verschlüsselung
Tabelle 2:	Vor- und Nachteile von verschlüsselten Protokollen
Tabelle 3:	Vor- und Nachteile von SSH-Tunneln
Tabelle 4:	Vor- und Nachteile von VPN-Tunneln

4 Einleitung

Diese Hausarbeit beschreibt mögliche Sicherheitsrisiken, die bei der Benutzung öffentlicher HotSpots und unverschlüsselter drahtloser Netzwerke (eng. Wireless Local Area Network, WLAN) im Allgemeinen auftreten können. Zunächst werden die Probleme bei Zugängen mit fehlender oder nicht hinreichender Verschlüsselung beschrieben. Danach werden mögliche Alternativen aufgezeigt, die es ermöglichen, die Risiken, die aus fehlender oder unzureichender Verschlüsselung resultieren, zu minimieren. Im Anschluss daran wird anhand eines konkreten Beispiels dargestellt, wie eine sichere Kommunikation trotz der Sicherheitsrisiken öffentlicher HotSpots möglich ist.

Die Motivation für die Behandlung dieses Themas war der Umstand, dass bei der Benutzung öffentlicher HotSpots eine gesicherte Übermittlung von vertraulichen Informationen nicht immer in vollem Umfang gewährleistet werden kann und der Autor nach Lösungsmöglichkeiten für dieses Problem suchte. Das am Ende erwähnte Beispiel beschreibt, wie der Autor das Problem löst.

5 Grundlagen HotSpots

Der Grundgedanke bei der Entwicklung drahtloser Netzwerke war es, Computer und andere netzwerkfähige Geräte an einem beliebigen Ort innerhalb des Empfangsradius eines sogenannten Zugriffspunktes (eng. Access Point, AP) mit dem Netzwerk bzw. Internet verbinden zu können, ohne an verlegte Kabel oder fest montierte Dosen gebunden zu sein. Dabei besteht sogar die Möglichkeit, sich innerhalb des Empfangsradius zu bewegen, ohne die Konnektivität zu verlieren.

Die genannten Vorteile führten zu einer schnellen und weiten Verbreitung drahtloser Netzwerke. Die nötigen Komponenten sind sehr preiswert und in allen möglichen Variationen und Preislagen verfügbar.

Gleichzeitig bergen diese Umstände allerdings Risiken, da die Ausbreitung der verwendeten Funkwellen nicht kontrollierbar ist^[1]. Das bedeutet, dass sie auch durch einen Dritten, der sich im Empfangsradius der beteiligten Stationen befindet, empfangen werden können. Dies ist aus Sicherheitssicht ein großer Nachteil, weil hier gegenüber dem Kabel kein direkter physikalischer Zugriff auf das Medium mehr nötig ist, um Zugang zum Netzwerk zu erhalten.

In nahezu jedem Hotel, Cafe oder Flughafen sind heute drahtlose Internetzugänge über öffentliche Access Points (sog. HotSpots) verfügbar^[2][3]. Diese werden häufig von großen Telekommunikationsunternehmen betrieben. Gegen Gebühr kann der Nutzer sich so drahtlosen Zugang zum Internet an verschiedenen Orten, an denen HotSpots verfügbar sind, verschaffen.

Die Nutzer öffentlicher HotSpots bieten potentiellen Angreifern verschiedene Möglichkeiten, deren Rechner anzugreifen bzw. den übertragenen Verkehr zu überwachen oder zu verändern. Das liegt daran, dass im Gegensatz zu drahtgebundenen Netzwerken jeder Zugang zum Drahtlosnetzwerk hat, der sich innerhalb des Empfangsradius des Acces Points befindet. Die Abbildung 1 veranschaulicht das schematisch.

Bei öffentlich betriebenen HotSpots ist die Verschlüsselung des drahtlosen Netzwerks in der Regel deaktiviert, weil der Betreiber seinen Nutzern einen möglichst einfachen Zugang gewähren will. Das Einschalten der Verschlüsselung würde hier zusätzlichen Aufwand bei Betreiber und Nutzer verusachen, da Ersterer den Schlüssel verteilen und Letzerer den Schlüssel auf seinem Rechner eintragen müsste. Hier könnte schon ein Tippfehler den Nutzer vom Gebrauch des HotSpots abhalten.

6 Risiken bei der Benutzung öffentlicher HotSpots

Im Folgenden werden Risiken genauer beschrieben, die der Nutzer kennen sollte, wenn er öffentliche HotSpots ohne weitere Sicherheitsvorkehrungen nutzt. Der erste Aspekt ist die Übertagung von Daten im Klartext aufgrund der üblicherweise deaktivierten Verschlüsselung des WLANs von HotSpots. Ein zweites Problem ergibt sich dadurch, dass ein Angreifer den Nutzverkehr über seinen Rechner umleiten und dabei ggf. verändern kann. Der letzte Punkt betrifft Angriffe, die ein potentieller Angreifer im gleichen Drahtlosnetzwerk gegen den Nutzer des HotSpots direkt ausführen kann.

6.1 Unverschlüsselte Datenübertragung

Das größte Problem bei der Nutzung von öffentlichen HotSpots stellt die üblicherweise nicht aktivierte Verschlüsselung der drahtlosen Verbindung dar. Das hat zur Folge, das Daten im Klartext übertragen werden, wenn der Nutzer Protokolle verwendet, die selbst keine Verschlüsselung der Nutzdaten unterstützen^[4]. Das ist der Fall wenn z.B. Webseiten per Hyper Text Transfer Protocol (HTTP) ausgeliefert werden.

Ein potentieller Angreifer, der sich im Empfangsradius des HotSpots befindet, bringt seine drahtlose Netzwerkkarte in den sog. "Monitor Modus". Das bewirkt, dass die Netzwerkkarte alle Pakete verarbeitet und nicht nur die, die an sie selbst adressiert sind. Dabei erhält sie auch solche Pakete, die das Opfer an den Access Point sendet bzw. von diesem emfpängt.

Für die Aufzeichnung der empfangenen Daten setzt der Angreifer dann ein Analysewerkzeug ein, dass den aufgezeichneten Verkehr filtern und durchsuchen kann. Dies kann z.B. Wireshark^[5] oder ein ähnliches Programm sein. Damit kann der gesamte aufgezeichnete Verkehr in einzelnen Paketen untersucht werden. Sogar eine Extraktion binärer Daten wie Bilder oder Audiosignale ist dann möglich.

Dies versetzt den Angreifer in die Lage, sämtliche Daten mitzulesen, die der Nutzer aus dem Internet empfängt oder ins Internet überträgt. Darunter können auch sensitive Daten, wie z.B. Benutzernamen, Kennwörter oder Bankdaten sein. Abbildung 2 zeigt beispielhaft ein per WLAN übertragenes HTTP Paket mit Benutzernamen und Passwort, das mit Hilfe von Wireshark aufgezeichnet wurde. Diese Daten könnte ein Angreifer mit vergleichsweise wenig Aufwand aus dem Datenstrom herausfiltern.

6.2 Man-in-the-middle Angriffe

Mit einem "Man-in-the-middle" wird eine Angriffsform bezeichnet, die zur Folge hat, dass ein Angreifer die Daten auf dem Weg von und zu einem Opfer durch seinen eigenen Rechner schleust. Er sitzt damit also zwischen Benutzer und Server. Damit hat er die Möglichkeit, die Daten auf dem Weg einzusehen und zu manipulieren bevor er sie weiterleitet^[6][7].

Um sich selbst zwischen die beiden Kommunikationspartner einzuklinken, hat der Angreifer verschiedene Möglichkeiten. Im einfachsten Fall gibt er sich gegenüber dem Opfer als Gateway zum Internet aus. Das hat zur Folge, dass das Opfer alle Daten, die es ins Internet schicken will, an den Rechner des Angreifers weitergibt. Dieser leitet sie dann ggf. manipuliert ins Internet weiter.

Solange der Angreifer keine Manipulationen an den zu übertragenden Daten vornimmt, wird das Opfer nicht merken, dass seine Daten unterwegs umgeleitet werden. Dazu müsste es weitere Schritte unternehmen, um herauszufinden, welchen Weg die Daten ins Internet nehmen. Auch wenn der Angreifer keine Manipulationen vornimmt, so hat er trotzdem die Möglichkeit, sämtliche übertragenen Daten einzusehen und zu speichern, um sie z.B. zu einem späteren Zeitpunkt mit Hilfe von Software nach sensitiven Daten zu durchsuchen. Der Angreifer hat also die volle Kontrolle über den gesamten Datenverkehr des Opfers.

6.3 Angriff durch Rechner im gleichen WLAN

Durch den Umstand, dass sich alle Rechner, die an einem drahtlosen Netzwerk angemeldet sind, in einem Netz befinden, besteht für den Nutzer außerdem ein weiteres Risiko. Ein ebenfalls im Drahtlosnetzwerk angemeldeter Angreifer könnte den Rechner des Opfers direkt angreifen^[8]. Dies kann auf Seiten des Opfers durch den konsequenten Einsatz einer leistungsfähigen Firewall abgewehrt werden. Dabei erhält der Nutzer ggf. sogar eine Information über einen möglichen Versuch eines Angriffs. Zudem sollten alle nicht benötigten Services, die per Netzwerk erreichbar sind, wie z.B. Datei- und Druckerfreigaben, tunlichst deaktiviert werden.

Da die Kommunikation in diesem Falle aber immer vom Angreifer über den Access Point zum Opfer läuft, hat auch der Betreiber eine Möglichkeit, diese Form von Angriffen zu unterbinden. Er kann den Access Point so konfigurieren, dass direkter Verkehr zwischen den Teilnehmern des WLANs nicht weiterleitet wird. Dieses Feature wird oft mit „Intra-Cell-Blocking“ bezeichnet. Wenn diese Funktion aktiviert ist, kann jeder Teilnehmer eines Drahtlosnetzwerks nur noch mit dem Access Point und dem dahinter liegenden Internet kommunizieren; nicht aber mit anderen Teilnehmern des WLANs.

Da dieses Feature aber nicht von allen Access Points unterstützt wird oder sogar deaktiviert sein könnte, sollte der Nutzer sich darauf nicht verlassen und selber mit dem Einsatz einer Firewall solche Formen von Angriffen verhindern.

Die nebenstehende Abbildung 4 zeigt die logische Position einer Firewall. Diese läuft im Normalfall als Software auf dem Rechner des Nutzers und kontrolliert sämtliche Verbindungen, die von außen zum geschützten Rechner hergestellt werden.

7 Lösungsvorschläge zur Minimierung der Risiken

7.1 WLAN Verschlüsselung

Die einfachste Möglichkeit, sich gegen das Abhören von Daten im Klartext zu schützen, stellt die Verschlüsselung der WLAN Verbindung dar. Die dazu nötige Hard- bzw. Software haben alle heutzutage erhältlichen Geräte bereits an Bord.

Für den Betreiber eines HotSpots stellt sich diese Methode allerdings eher als hinderlich dar, weil sie Nutzer und Betreiber zwingt die eingesetzten Geräte entsprechend zu konfigurieren. Dazu müsste der Betreiber seinen Nutzern den Schlüssel vorab mitteilen. Das würde auf beiden Seiten lediglich zusätzlichen Aufwand erzeugen.

Dieser Umstand und die Tatsache, dass potentielle Angreifer ohne Weiteres in Kenntnis des Schlüssels gelangen können, in dem sie sich z.B. als Kunde ausgeben, veranlasst die Betreiber u.a. dazu, diese Form der Absicherung nicht zu nutzen.

Dazu kommt, dass ein Großteil der standardisierten Verschlüsselungsmethoden für WLAN Verbindungen als unsicher gelten. Die zusammen mit dem WLAN Standard entwickelten Algorithmen Wired Equivalent Privacy 64 (WEP64) bzw. WEP128 lassen sich auch ohne Kenntnis des Schlüssels bereits innerhalb weniger Minuten knacken^[9][10][11]. Diese Varianten sollten daher aus Sicht der Sicherheit schon nicht mehr in den WLAN Geräten implementiert werden.

Auch der Nachfolger Wi-Fi Protected Access (WPA) gilt in Fachkreisen nicht mehr als sicher, weil auch dieser sich durch geschickte Berechnungen und entsprechendes Know-How knacken lässt^[12][13].

Wenn eine solche WLAN Verschlüsselung eingesetzt wird (z.B. zu Hause), dann sollte unbedingt die neueste Version WPA2 genutzt werden. Diese enthält gegenüber der Vorgängerversion wesentliche Verbesserungen und vor allem einen als sicher geltenden Verschlüsselungsalgorithmus namens Advanced Encryption Standard^[14] (AES). Zudem werden die verwendeten Schlüssel während der Dauer der Verbindung periodisch verworfen und neu berechnet.

Dieser Lösungsvorschlag bietet aber einen weiteren gravierenden Nachteil. Die Verschlüsselung bezieht sich nur auf die Verbindung zwischen Nutzer und Access Point (in Abb. 5 schematisch in rot dargestellt). Wenn ein Angreifer also physikalischen Zugang zum Access Point hat, weil dieser z.B. im Hotelflur an der Wand hängt, kann er sich hinter dem Access Point in die Kommunikation einklinken. Hier könnte er sogar sämtiche Verbindungen aller Nutzer abhören auch wenn er die Nutzer selber nicht direkt empfangen kann. Für diesen Fall wäre die Sicherheit mittels einer Verschlüsselung des WLANs also nicht ausreichend.

7.2 verschlüsselte Protokolle

Protokolle, die die Nutzdaten verschlüsseln, bieten eine weitere Möglichkeit, um den Verkehr an einem öffentlich genutzten Hotspot gegen Abhören und Modifikationen zu schützen. Gemeint sind hier Protokolle, die entweder eine Verschlüsselung direkt implementiert haben oder auf Secure Socket Layer (SSL) bzw. Transport Layer Security (TLS) aufsetzen (z.B. Hyper Text Transfer Protocol Secure (HTTPS), Post Office Protocol 3 Secure (POP3S), Internet Message Access Protocol Secure (IMAPS), etc.). Diese Protokolle erfordern auf der Seite des Client eine Software, die diese Methode der Verschlüsselung unterstützt. In der Regel stellt dies allerdings kein Problem dar. Alle aktuellen Browserversionen unterstützen beispielsweise die sichere Variante HTTPS. Ähnlich sieht es mit Emailsoftware aus.

Die Authentifizierung und Verschlüsselung erfolgt hierbei über Zertifikate, die von einer vertrauenswürdigen Stelle (eng. Certificate Authority, CA) unterschrieben worden sind. Anhand der Unterschrift kann der Client feststellen, ob das Zertifikat vertrauenswürdig ist und er es akzeptiert. Weiterhin kann er anhand der Zertifikate prüfen, ob die Gegenstelle tatsächlich der Server ist, der er vorgibt zu sein. Damit ist sichergestellt, dass der Nutzer wirklich mit dem richtigen Server kommuniziert und nicht mit einem Angreifer, der eine falsche Identität vortäuscht und die Daten vor der Weiterleitung manipuliert.

Bei diesen Methoden ist eine durchgängige Verschlüsselung bis zum Zielrechner gewährleistet. Daher kann der Verkehr bei Benutzung dieser Protokolle unterwegs nicht im Klartext mitgelesen werden. Ein Angreifer erhielte dann nur verschlüsselte Daten, die er ohne Kenntnis des zugehörigen Schlüssels nicht dekodieren könnte.

Die Nutzung von verschlüsselten Protokollen ist aber unter bestimmten Umständen nicht immer einsetzbar. So bieten nicht alle, der im Internet benutzten Protokolle, eine sichere Variante. Als Beispiel sei hier das Domain Name System (DNS) genannt. Das führt dazu, dass selbst bei Abrufen einer Seite mittels HTTPS erkannt werden kann, welche Adresse der Benutzer aufruft, weil die DNS Abfrage des Domainnamens im Klartext erfolgte. So ist es einem Angreifer unter Umständen möglich, dem Opfer gefälschte Antworten unterzuschieben und es damit z.B. auf eine falsche Webseite umzulenken.

Außerdem erfordert diese Form der Kommunikation eine gewisse Reserve an Rechenleistung auf dem Client, weil die Verschlüsselung mit Zertifikaten die Berechnung von komplizierten mathematischen Formeln voraussetzt. Das kann insbesondere für leistungsschwache oder kleine Rechner wie z.B. Personal Digital Assistant (PDA) nachteilig sein.

7.3 SSH-Tunnel

Eine weitere Variante, die für eine sichere Übertragung von Daten sorgen kann, stellen Tunnel mittels Secure Shell (SSH) dar. Das SSH Protokoll ist eigentlich eine Möglichkeit, um auf einem entfernten Server ein Terminal zu erhalten, damit man auf diesem arbeiten kann. Die Übertragung erfolgt hierbei verschlüsselt. Diese Verschlüsselung ist nach aktuellen Erkenntnissen als sicher einzustufen.

Für die Nutzung dieser Methode ist allerdings ein Server nötig, der über das Internet erreicht werden kann. Dies kann ein gemieteter Server oder ein Rechner sein, der über den Router am heimischen Internetzugang angeschlossen ist. Außerdem benötigt der Nutzer für den Aufbau des Tunnels ein Programm (z.B. puTTY^[15]).

Bei dieser Art der Kommunikation wird eine SSH Verbindung zum SSH-Server hergestellt. Das kann mittels sicherer Passwörter oder Zertifikaten geschehen. Innerhalb dieser Verbindung lassen sich weitere Nutzdaten übermitteln. Dafür kann die SSH Client Software sich wie ein Proxy Server verhalten, der die Daten auf dem Rechner des Nutzers entgegennimmt. Die Nutzdaten werden dann durch den Tunnel an den Server weitergegeben, der sie wieder aus dem Tunnel extrahiert und an das eigentliche Ziel weiterleitet.

Auf dem gesamten Weg zwischen Client und Server werden die Daten hier verschlüsselt transportiert. Dies bietet Schutz gegen Abhören und Manipulation innerhalb des WLANs des HotSpots sowie im Netzwerk des Betreibers hinter dem HotSpot.

Der größte Nachteil dieser Variante liegt allerdings darin, dass jede Software auf dem Client Rechner so konfiguriert werden muss, dass sie die Daten nicht direkt ins Internet übermittelt, sondern diese an die lokale SSH Client Software weitergeben soll. Das hat zur Folge, dass der Nutzer hier relativ viel Konfigurationsaufwand hat, weil er diese Parameter jedes Mal wieder umstellen muss, wenn er z.B. seinen Rechner zu Hause im Heimnetz nutzen will.

Weiterhin ist mit dieser Methode nicht jedes im Internet verwendete Protokoll tunnelbar. So bereiten Protokolle, die das Transport Control Protocol (TCP) als Transportprotokoll verwenden in der Regel keine Schwierigkeiten. Darunter fallen z.B. HTTP oder POP3. Insbesondere aber Protokolle, die auf User Datagram Protocol (UDP) basieren, lassen sich mit dieser Methode nicht tunneln. Dies sind z.B. DNS oder das Realtime Transport Protocol (RTP).

7.4 Virtuelle Private Netze

Eine weitere Variante zur Absicherung des Verkehrs bei der Nutzung eines öffentlichen HotSpots stellt die Kommunikation mittels eines Virtuellen Privaten Netzwerks (eng. Virtual Private Network, VPN) dar. VPNs dienen dazu, private Daten über ein potentiell unsicheres Medium sicher zu übertragen^[16]. Für die Nutzung stellt eine VPN Software auf dem Rechner des Nutzers eine Verbindung zu einem VPN-Server bzw. VPN-Gateway her. Diese Verbindung wird mittels Zertifikaten verschlüsselt. Durch ausreichend große Zertifikate wird hier ein Angriff durch Durchprobieren aller Möglichkeiten praktisch ausgeschlossen. Durch den sog. VPN-Tunnel wird der Verkehr dann durchgeleitet. Der VPN-Tunnel ist eine logische Verbindung zwischen dem Client und dem Gateway (in Abbildung 8 rot dargestellt). Am VPN-Gateway kann der Verkehr dann entweder ins Internet oder das dahinter angeschlossene Netzwerk geleitet werden.

Mit Hilfe dieser Variante können üblicherweise alle Protokolle sicher übertragen werden, die auf IP basieren, wenn sie durch den Tunnel geleitet werden. Durch die VPN-Software wird ein virtuelles Netzwerkgerät im System angelegt, das in das Routing eingebunden werden kann. In der Regel bietet VPN-Software Möglichkeiten, das Routing so zu modifizieren, dass sämtlicher Verkehr durch den sicheren VPN-Tunnel läuft. Das beugt dem sog. "Split-Tunneling"^[17] vor.

Wird ein solches VPN von einem öffentlichen HotSpot aus genutzt, bietet es Schutz für die übertragenen Daten gegen Abhören und Modifizieren. Der Schutz ist dabei bereits auf der WLAN-Strecke gegeben. Weiterhin ist es einem Angreifer auch hier nicht möglich, den Verkehr hinter dem Access Point im Klartext abzugreifen.

Diese Variante stellt allerdings auch einige Anforderungen an Client und Server. Zunächst muss auf beiden Rechnern eine entsprechende VPN-Software installiert und als Client bzw. Server eingerichtet werden. Solche VPN Server werden mittlerweile auch durch einige HotSpot-Betreiber zur Nutzung angeboten^[18].

Außerdem ist bei dieser Möglichkeit weitaus mehr Aufwand für die Konfiguration notwendig als bei den drei bereits genannten Varianten. So müssen hier entsprechende Zertifikate generiert werden. Zusätzlich ist ein tiefer Eingriff in das Betriebssystem nötig, um die Schnittstelle für den Tunnel anzulegen und das Routing so zu modifizieren, dass die Nutzdaten immer durch den VPN-Tunnel geleitet werden.

Für einen potentiellen Angreifer, der den Verkehr im drahtlosen Netzwerk oder hinter dem Access Point abhört, sind dann nur noch die Quelladresse des Nutzers sowie die Zieladresse des VPN-Gateways sichtbar. Ein Mithören bzw. Dekodieren der Nutzlast ist nicht mehr möglich.

8 Ein praktisches Beispiel

Für dieses Beispiel wird die Variante VPN genutzt, die den Verkehr mittels einer VPN-Software gegen Abhören und Modifizieren absichert. Als VPN-Software wird hier OpenVPN^[19] auf dem Client sowie dem VPN-Gateway verwendet.

Der Nutzer sei mittels eines Notebooks an einem öffentlichen HotSpot angemeldet. Da heutzutage die Internetzugänge meist als Pauschalangebote vermarktet werden, ist eine dauerhafte Internetverbindung kostengünstig möglich. Aus diesem Grunde dient als VPN-Gateway ein Router am heimischen DSL-Anschluss. Dieser ist, wie der Rechner des Nutzers, mit einer entsprechenden Version von OpenVPN ausgestattet.

Damit die Verbindung zum VPN-Gateway trotz dynamisch wechselnder IP-Adressen hergestellt werden kann, wird auf dem Router eine DynDNS Software genutzt, die über diesen Dienst über einen Hostnamen die jeweils aktuelle öffentliche IP-Adresse des Routers bekannt macht^[20].

8.1 Die VPN-Software

Die hier eingesetzte Software OpenVPN ist im Internet frei verfügbar. Es exisitieren verschiedene Versionen für die gängigen Betriebssysteme Microsoft Windows, Linux und MacOS. Eine Installation ist mit wenigen Schritten erledigt^[21] und es existieren sogar Werkzeuge für grafische Oberflächen^[22].

Die Software nutzt für die Verschlüsselung der Verbindungen die ebenfalls frei verfügbare SSL Bibliothek OpenSSL^[23]. OpenVPN gehört damit zur Klasse der sog. SSL-VPNs^[24][25].

Weiterhin kann die Software mit einer frei verfügbaren Version der Lempel-Ziv-Oberhumer (LZO) Bibliothek^[26] erweitert werden, so dass sie eine transparente Komprimierung der Nutzdaten durchführt. Dies ist vor allem für schmalbandige Zugänge empfehlenswert, um den Datendurchsatz zu steigern. Zu beachten ist dabei jedoch, dass dies auch auf dem VPN-Gateway zusätzliche Prozessorlast erzeugt.

Für die Authentisierung können wahlweise Zertifikate oder sog. Preshared Keys genutzt werden. Letzteres sind im Prinzip Passwörter, die auf dem Client sowie dem VPN-Gateway bekannt sein müssen. Diese Variante hat allerdings den Nachteil, dass aus dem verschlüsselten Verkehr u.U. der Schlüssel zurückgewonnen werden kann, da dieser während der Verbindung nicht erneuert wird.

Abhilfe schafft hier eine Authentisierung mit Zertifikaten. Bei dieser Methode werden während der bestehenden Verbindung laufend neue Schlüssel berechnet und verwendet, was die Möglichkeiten, den Schlüssel innerhalb einer akzeptablen Zeit zu rekonstruieren, deutlich einschränkt.

8.2 Das VPN-Gateway

Im Heimnetzwerk des Nutzers wird ein Router verwendet, der VPN Verbindungen mit OpenVPN unterstützt. Hier kann z.B. das Modell WRT54^[27] von Linksys^[28] verwendet werden. Auf diesem Gerät kann der Nutzer eine eigens dafür entwickelte Linux Distribution (OpenWRT^[29]) installieren, die für die nachfolgenden Konfigurationen als Grundlage dient. Für das System ist ein OpenVPN Softwarepaket verfügbar, dessen Installation^[30] auch die dafür nötigen Kernelmodule automatisch mit einrichtet. Außerdem wird eine Version der LZO Bibliothek mit installiert, die für die Komprimierung zum Einsatz kommt.

Damit die Herstellung einer Verbindung aus dem Internet klappt, muss die Firewall eine Regel enthalten, die den OpenVPN Verkehr aus dem Internet zulässt. Diese könnte z.B. wie folgt aussehen:

iptables -I INPUT -i ppp0 -p tcp -m tcp --dport 443 -j ACCEPT

Damit ist TCP Verkehr über Port 443, der über die Schnittstelle zum Internet (ppp0) hereinkommt, zugelassen. Der OpenVPN Prozess wird mittels Konfigurationsanweisung dazu gebracht, auf diesem Port Verbindungen entgegenzunehmen. Die Zeilen in der Konfiguration des Gateways sehen so aus:

proto tcp
port 443

Für die Verschlüsselung mit Zertifikaten müssen einige Pfade zu Dateien mit Zertifikaten von Server und CA^[31] angegeben werden:

ca ca.crt
cert server.crt
key server.key
dh dh1024.pem

Der zu verwendende Verschlüsselungsalgorithmus wird ebenfalls konfiguriert. Dabei stehen dem Nutzer verschiedene zur Auswahl. In diesem Fall wird eine 256 Bit AES^[32] Verschlüsselung gewählt.

cipher AES-256-CBC

Außerdem ist der Server dafür zuständig, den Clients IP-Adressen für ihre virtuellen Tunnel Schnittstellen zuzuweisen. Er kann dafür in einem Pool entsprechende Adressen verwalten. Der Pool wird mit der folgenden Zeile konfiguriert. Der Server selbst bekommt dabei immer die erste verfügbare Adresse aus dem Pool.

server 172.16.0.0 255.255.255.0

Schließlich kann der Server noch Konfigurationsdirektiven an seine Clients verteilen, die diese bei Verbindungsaufbau entsprechend auferlegt bekommen. Um das Split-Tunneling zu vermeiden, können die Clients gezwungen werden, all ihren Verkehr durch den Tunnel zu leiten. Außerdem bekommen sie die Adresse eines DNS Servers per Dynamic Host Configuration Protocol (DHCP) mitgeteilt.

push "redirect-gateway"
push "dhcp-option DNS 172.16.0.1"

Und für die Aktivierung der LZO Kompression wird die folgende Anweisung in die Konfiguration eingetragen:

comp-lzo

Damit ist die Konfiguration auf Seiten des Servers komplett und OpenVPN kann gestartet werden. Es wird dann auf dem angegebenen Port auf Verbindungen seiner Clients warten.

8.3 Der Client

Auf dem Rechner des Nutzers kommt ebenfalls eine Version von OpenVPN zum Einsatz. Hier können alle von OpenVPN unterstützen Betriebssysteme eingesetzt werden. Für Linux Betriebssysteme wird außerdem die LZO Bibliothek benötigt, damit der Client die Kompression nutzen kann.

Die Firewall auf dem Rechner des Nutzers muss üblicherweise nicht angepasst werden. Diese erlauben in der Regel ausgehende Verbindungen in der Standard Konfiguration. Da in diesem Fall die Verbindung vom Client zum VPN-Gateway aufgebaut wird, bedarf es hier keiner weiteren Regeln. Hier sollte aber streng darauf geachtet werden, dass keine Services des Rechners über das (WLAN-)Netzwerk genutzt werden können, um einem direkten Angriff vorzubeugen.

Die clientseitige Konfiguration ist sehr ähnlich zu der des VPN-Gateways. Es gibt allerdings einige Unterschiede, die von der Server Konfiguration abweichen. So ist in der Konfiguration zunächst ein Eintrag zu finden, der den OpenVPN Prozess anweist, als Client zu fungieren:

client

Analog zur Angabe des Ports und des Protokolls sind auch hier Angaben über das zu verwendende Protokoll sowie zur Adresse und Port des VPN-Gateways zu machen:

proto tcp
remote vpngateway.dyndns.org 443

Die Zeilen mit den Angaben zu Zertifikaten sind genauso aufgebaut wie die entsprechenden Zeilen in der Konfiguration des VPN-Gateways; allerdings mit dem Unterschied, dass hier ein eigenes Zertifikat für den Client verwendet werden muss.

ca ca.crt
cert client.crt
key client.key

Damit der Client mit dem VPN-Gateway verschlüsselt kommunizieren kann, müssen auf beiden Seiten die gleichen Parameter zum verwendenten Verschlüsselungsalgorithmus gemacht werden:

cipher AES-256-CBC

Und auch die Aktivierung der LZO Komprimierung erfolgt gemäß der VPN-Gateway Konfiguration:

comp-lzo

Schließlich kann der Client angewiesen werden, das Server Zertifikat zu überprüfen, um auszuschließen, dass sich ein potentieller Angreifer als VPN-Gateway ausgibt und versucht, dadurch den verschlüsselten Verkehr umzuleiten. Diese Anweisung in der Konfiguration lautet:

ns-cert-type server

Nachdem der Nutzer sich ggf. am HotSpot angemeldet hat, um den Internetzugang freizuschalten, kann er die VPN Verbindung zum Gateway aufbauen. Er wird dabei eine IP-Adresse aus dem Pool des VPN-Gateways erhalten und gemäß den "push"-Direktiven der Gateway Konfiguration den vorgegebenen DNS-Server nutzen und seinen gesamten Verker durch den Tunnel leiten.

8.4 Die Kommunikation

Nachdem erfolgreich eine VPN Verbindung zum VPN-Gateway hergestellt wurde, wird der Nutzdatenverkehr durch den Tunnel geleitet. Als Beispiel ist eine modifizierte Routing Tabelle in Abbildung 9 dargestellt.

Der OpenVPN Prozess legt bei Verbindungsaufbau eine statische Route zur öffentlichen Adresse des VPN-Gateways (im Beispiel 217.236.80.1) an, die über das ursprüngliche Default Gateway (hier: 10.130.185.222) läuft. Diese ist in Abbildung 9 grün hervorgehoben. Die vorhandene Default Route wird gelöscht und durch eine Default Route ersetzt, die auf die Tunneladresse des VPN-Gateways (hier: 10.96.0.5) zeigt. Diese Route ist in Abbildung 9 rot gekennzeichnet. Außerdem wird die Adresse des zu verwendenden DNS-Servers auf die Adresse geändert, die das VPN-Gateway vorgibt.

Das hat zur Folge, dass sämtliche Namensauflösungen via DNS durch den Tunnel zum VPN-Gateway geleitet werden und durch das VPN-Gateway aufgelöst werden. Die neue Default Route veranlasst den Rechner des Nutzers sämtlichen Verkehr, den er erzeugt ebenfalls durch den Tunnel zu leiten (in Abbildung 10 in rot dargestellt). Der Verkehr wird dann auf der Seite des VPN-Gateways (hier: 10.96.0.1) ins Internet weitergeleitet (grüne Markierung in Abbildung 10). Eine Überprüfung des Pfades mittels "tracepath" zeigt, dass der Pfad für IP Pakete erst zum VPN-Gateway führt und von dort ins Internet weitergeht (s. grüner Kasten in Abb. 11).

Da herkömmliche Router für den Einsatz zu Hause in der Regel die Absenderadresse von Paketen, die ins Internet geleitet werden, durch ihre eigene öffentlich zugewiesene ersetzen, landen auch die Antworten auf die Anfragen des Nutzers beim VPN-Gateway. Dieses entscheidet aufgrund seiner Routingtabelle, dass diese Antworten wieder durch den Tunnel zurück zum Nutzer geleitet werden müssen.

Durch diese VPN Verbindung kann ein potentieller Angreifer, der sich im Empfangsbereich des WLANs des HotSpots befindet, den Verkehr des Nutzers nicht mehr im Klartext mitlesen. Auch ein Abhören der Kommunikation bzw. zwangsweise Nutzung eines Proxy Servers hinter dem Access Point z.B. durch den Betreiber wird wirkungsvoll verhindert, da der Nutzverkehr bis zum VPN-Gateway nur verschlüsselt transportiert wird. Dies bedeutet zwar, einen Umweg über das VPN-Gateway zu nehmen, allerdings wird dies durch den Gewinn an Sicherheit in jedem Fall aufgewogen.

Ein weiterer Vorteil dieser Variante ist, dass hier ohne weiteren Aufwand Geräte im Haus des Nutzers erreicht werden können, die an das heimische Netzwerk angeschlossen sind. Dies können z.B. Netzwerkfestplatten sein, auf deren Daten der Nutzer von unterwegs zugreifen möchte.

9 Fazit

Um seinen Verkehr an einem öffentlichen HotSpot möglichst sicher zu übertragen, muss der Nutzer selbst entsprechende Maßnahmen ergreifen, um sich gegen Abhören und Manipulation zu schützen. Der Betreiber aktiviert hier in der Regel keine Mechanismen, weil dies immer auch die Nutzbarkeit einschränkt bzw. den Aufwand für ihn erhöht.

Die Möglichkeit, sichere Protokolle wie HTTPS einzusetzen scheitert daran, dass parallel ebenfalls benötigte Protokolle keine Sicherheitsmechanismen integrieren. Auch die Variante mit SSH-Tunneln stellt keine praktikable Lösung dar, weil hier der Aufwand für die Konfiguration in keinem Verhältnis zum Nutzen steht.

Der Weg, den Verkehr mittels eines VPN zu sichern, erfordert zwar einigen Konfigurationsaufwand und das Vorhandensein einer erreichbaren Gegenstelle, bietet dafür aber die Möglichkeit, den Verkehr nahezu vollständig gegen Abhören und Manipulation zu sichern.

Als nachteilig erweisen sich hier lediglich die geringe Bandbreite, mit der der heimische Internetanschluss zumindest im Upstream angebunden ist sowie die zusätzliche Prozessorlast, die auf Client und Gateway erzeugt wird, wobei letzteres für heutige Computersysteme kein Problem mehr darstellen sollte. Außerdem bedeutet die Einrichtung eines VPN für den Nutzer einigen Konfigurationsaufwand, damit er die VPN Lösung nutzen kann. Ist diese allerdings einmal konfiguriert, lösst sie sich bequem nutzen.

Die Verwendung von TCP Protokoll und Port 443 für den VPN-Tunnel hat einen weiteren großen Vorteil: Diese Form der Kommunikation funktioniert in vielen Fällen auch dann, wenn die Nutzer von HotSpots durch technische Maßnahmen gezwungen werden einen Proxy Server zu passieren oder alle anderen Ports gesperrt sind. Das kommt daher, dass OpenVPN auf SSL basiert, das auch bei der HTTPS Kommunikantion (ebenfalls über TCP Port 443) Anwendung findet. Daher können weder Betreiber noch Proxy Server den Verkehr von herkömmlichem HTTPS Verkehr unterscheiden. Das hat zur Folge, dass Webseiten, die der Proxy eigentlich sperren sollte, trotzdem erreichbar sind oder Protokolle, deren Kommunikation mit Hilfe von Portsperren unterbunden werden sollte, ebenfalls funktionieren. Das liegt daran, dass der Verkehr per SSL verschlüsselt übertragen und erst auf der Gegenseite am VPN-Gateway ins Internet gelangt.

Trotz der genannten Nachteile wird die Lösung mittels VPN durch den Autor tagtäglich angewendet und hat sich in vielen Fällen bewährt.

Die Lösung der Sicherheitprobleme mittles eines VPN wird beim Autor außerdem für das heimische WLAN genutzt. Dazu wird das Drahtlosnetzwerk mit einem entsprechenden WLAN Router physikalisch vom eigentlichen Netzwerk getrennt. Der Access Point des Routers ist so konfiguriert, dass er lediglich verschlüsselten VPN Verkehr entgegen nimmt und weiterleitet. Sämtlicher anderer Verkehr wird durch die Firewall schlicht verworfen. Das hat den Vorteil, dass die Verschlüsselung mittels VPN deutlich sicherer ist als eine Verschlüsselung des WLANs mit den herkömmlichen Algorithmen wie z.B. WEP oder WPA. Auch hier ist ein Abhören von außen praktisch nicht möglich, da sämtliche Protokolle per VPN zum WLAN Router getunnelt werden.

VPNs stellen also im Allgemeinen gute Lösungsmöglichkeiten bereit, um diverse Sicherheitsprobleme aus dem Weg zu räumen. Leider ist ihre Konfiguration nicht trivial, was u.a. dazu führt, dass sie bei Durchschnittsnutzern selten Verwendung finden.

10 Fußnoten

1. ↑ Vgl. Rech (2008): Wireless LANs, S. 427
2. ↑ Vgl. z.B. http://www.t-mobile.de/hotspot/locator/0,10620,15520-_,00.html
3. ↑ Vgl. Rech (2008): Wireless LANs, S. 58 ff.
4. ↑ Vgl. IT-Grundschutz-Kataloge, Abschnitt G5.139, S. 895
5. ↑ Vgl. http://www.wireshark.org
6. ↑ Vgl. Rech (2008): Wireless LANs, S. 428 ff.
7. ↑ Vgl. IT-Grundschutz-Kataloge, Abschnitt G5.143, S. 899 f.
8. ↑ Vgl. IT-Grundschutz-Kataloge, Abschnitt G5.138, S. 893 f.
9. ↑ Vgl. Hofherr (2005): WLAN Sicherheit , S. 60 ff.
10. ↑ Vgl. Rütten: "Todesstoß für WEP", S. 56
11. ↑ Vgl. Schmidt: "Der WEP-Wall bricht", S. 182
12. ↑ Vgl. Hofherr (2005): WLAN Sicherheit S. 129 ff.
13. ↑ Vgl. Bachfeld: "Angriff auf WPA", S. 54
14. ↑ Vgl. Wilke (2004): Der Algorithmus des "Advanced Encryption Standard"
15. ↑ Vgl. http://www.chiark.greenend.org.uk/~sgtatham/putty/
16. ↑ Vgl. Lipp (2006): VPN Virtuelle Private Netze, S. 17 ff.
17. ↑ Vgl. Lipp (2006): VPN Virtuelle Private Netze, S. 393
18. ↑ Vgl. http://www.t-mobile.de/hotspot/0,12498,17896-_,00.html
19. ↑ Vgl. http://www.openvpn.net
20. ↑ Vgl. http://www.dyndns.com/services/dns/dyndns/
21. ↑ Vgl. http://openvpn.net/howto.html#install
22. ↑ Vgl. http://openvpn.net/index.php/documentation/graphical-user-interface.html
23. ↑ Vgl. http://www.openssl.org
24. ↑ Vgl. Bauer; Liebscher; Thielking-Riechert (2006): OpenVPN Grundlagen, Konfiguration, Praxis, S. 13
25. ↑ Vgl. Lipp (2006): VPN Virtuelle Private Netze, S. 257 ff.
26. ↑ Vgl. http://www.oberhumer.com/opensource/lzo/#introduction
27. ↑ Vgl. http://www-de.linksys.com/servlet/Satellite?c=L_Product_C2&childpagename=DE%2FLayout&cid=1149822675981&pagename=Linksys%2FCommon%2FVisitorWrapper&lid=7598117595B02
28. ↑ Vgl. http://www.linksys.de/
29. ↑ Vgl. http://www.openwrt.org/
30. ↑ Vgl. http://wiki.openwrt.org/OpenVPNHowTo
31. ↑ Vgl. Bauer; Liebscher; Thielking-Riechert (2006): OpenVPN Grundlagen, Konfiguration, Praxis, S. 55 ff.
32. ↑ Vgl. http://csrc.nist.gov/publications/fips/fips197/fips-197.pdf

11 Literaturverzeichnis

[1] Bauer, Johannes; Liebscher, Albrecht; Thielking-Riechert, Klaus: OpenVPN - Grundlagen, Konfiguration, Praxis, dpunkt.verlag GmbH Heidelberg 2006 ISBN 3-89864-396-4

[2] Bachfeld, Daniel: Artikel "Angriff auf WPA", in c't magazin für computer technik, Heft Nr. 25 / 2008, S. 54, ISSN 0724-8679

[3] ohne Verfasserangaben: IT-Grundschutz-Kataloge, 10. Ergänzungslieferung, Bundesamt für Sicherheit in der Informationstechnik, 2008, http://www.bsi.bund.de/gshb/deutsch/download/it-grundschutz-kataloge_2008_EL10_de.pdf (10.02.2009 12:17)

[4] Hofherr, Matthias: WLAN-Sicherheit - Professionelle Absicherung von 802.11-Netzen, Heise Zeitschriften Verlag GmbH & Co KG, Hannover 2005 ISBN 3-936931-25-9

[5] Lipp, Manfred: VPN - Virtuelle Private Netzwerke, Addison-Wesley Verlag München 2006 ISBN 3-8273-2252-9

[6] Rech, Jörg: Wireless LANs - 802.11-WLAN-Technologie und praktische Umsetzung im Detail, 3. aktualisierte und erweiterte Ausgabe, Heise Zeitschriften Verlag GmbH & Co KG Hannover 2008 ISBN 3-936931-04-6

[7] Rütten, Christiane: Artikel "Todesstoß für WEP", in c't magazin für computer technik, Heft Nr. 09 / 2007, S. 56, ISSN 0724-8679

[8] Schmidt, Michael: Artikel "Der WEP-Wall bricht", in c't magazin für computer technik, Heft Nr. 10 / 2005, S. 182, ISSN 0724-8679

[9] Wilkin, Christian: Der Algorithmus des "Advanced Encryption Standard", Trier, 2004, http://www.realtec.de/privat/files/AES_Krypto_Seminar.pdf (08.02.2009 11:22)