Seminar: Securing Wireless Networks

Seminar: Securing Wireless Networks Seminarvortrag von Rosenberg Peter Fachhochschule Aargau Departement Technik Studiengang I Betreuender Dozent: Herr Prof. Dr. C. Nicola Windisch, 10. Dezember 2003 1/14

Abstract In this seminar, I discuss the security risks of wireless networks and give some advices on how to configure the access-point and the clients. Furthermore I describe how to solve this problem with a virtual private network (VPN) using IPSec. This includes the description of the architecture and the protocols of IPSec. A sampleinstallation of this IPSec is included, too. Inhaltsverzeichnis 1 Einleitung... 3 2 Sicherheitsrisiken... 3 3 Konfiguration... 4 3.1 Access Point... 4 3.2 Clients... 5 4 VPN mittels IPSec... 5 4.1 Aufbau von IPSec... 6 4.2 Security Association (SA)... 6 4.3 Protokolle... 7 4.4 Transport und Tunnel-Modus... 9 4.5 Beispiel-Installation... 10 4.6 Automatischer Schlüsselaustausch und Verteilung... 13 4.7 Diffie-Hellman-Algorithmus... 13 4.8 Oakley... 13 4.9 ISAKMP (Internet Security Associatin and Key Management Protokol)... 13 5 Anhang... 14 5.1 Quellen... 14 2/14

1 Einleitung Wireless LAN ist eine alternative zum herkömmlichen, kabelgebundenen LAN. Es überträgt die Daten per Funk und gibt dem Benutzer somit mehr Flexibilität, welche aber mit Nachteilen erkauft werden muss. Denn die Ausbreitung der übertragenen Daten beschränkt sich nicht mehr nur auf die verlegten Netzwerkkabel sondern dringt über die Funkwellen auch nach aussen. Ein Standard für Wireless LAN ist 802.11b, der sich wahrscheinlich als allgemeiner Standard durchsetzen wird. Er erlaubt ein Datendurchsatz von 11 Mbits und benutzt eine Frequenz von 2.4 GHz. Der Nachfolger von 802.11b ist 802.11a, der ein höherer Datendurchsatz vorsieht. Vom neuen Standard sich ebenfalls schon Geräte erhältlich, auch solche die beide Standards unterstützten (langsamer, da Umschalten Zeitaufwändig). Bezüglich Sicherheit sind beide Standards problematisch. 2 Sicherheitsrisiken Jeder Access-Point (AP) ist grundsätzlich ein Sicherheitsrisiko und sollte daher als unsicher betrachtet werden. Er sollte in jedem Fall nur die benötigte Reichweite haben (z.b. nur innerhalb des Firmengebäudes) indem er entsprechend im Gebäude positioniert wird und die Sendeleistung so angepasst wird, dass das Signal nur das gewünschte Gebiet abdeckt. Die Risiken, die berücksichtigt werden müssen sind: Einfügende Angriffe (Autorisierung ungenügend) Abfangen und Beobachten des Datenverkehrs Fehlkonfiguration (z.b. AP in Werkseinstellung) Störung Client zu Client Angriffe Ein AP, der in Werkseinstellung betrieben wird, hat in den meisten Fällen jegliche Sicherheitseinstellungen deaktiviert. Dies bedeutet, dass alle Daten unverschlüsselt und für jeden einsehbar übertragen werden, der sich innerhalb der Sendereichweite des APs befindet. Mit speziellen Antennen ist es gar möglich, aus weiter Entfernung Wireless Netze abzuhören. Die Server Set ID (SSID) als Sicherheitsinstrument einzusetzen bietet minimale Sicherheit, da diese jeweils im Klartext übertragen wird (siehe unten). Durch einfügen eines Clone-APs ist es möglich, Anmeldeinformationen der Client zu bekommen. Dies kann benutzt werden, um Logins/Passwörter abzufangen oder die SSID zu bestimmen. 3/14

Bei Verwendung von WEP (Verschlüsselung der Datenpakete) besteht ein Risiko, dass die Schlüssel geknackt werden. Weiter werden die Service-Informationen inklusive SSID trotz aktiviertem WEP im Klartext übertragen. Wireless-Clients haben die Möglichkeit, direkt miteinander zu kommunizieren ohne den AP zu verwenden. Dies bedeutet aber auch, dass diese ebenfalls von anderen Clients geschützt werden müssen. Insbesondere gegen DoS-Angriffe (Denial of Service) oder gegen Zugriff auf das Dateisystem bei unbedachten Freigaben. Eine Möglichkeit das Wireless-Netz zu stören besteht darin, dass das Netz mit einem 2.4 GHz-Signal überflutet wird, was die Kommunikation zum erliegen bringt. Dabei beseht aber kein Risiko, dass Daten in die Hände von Angreifern gelangen könnten. Es können auch eine unabsichtliche Störungen auftreten, da andere Technologien wie Bluetooth oder schnurlose Telefone auf derselben Frequenz arbeiten. 3 Konfiguration 3.1 Access Point Bei der Inbetriebnahme eines neuen APs, ist es unbedingt erforderlich, ihn bezüglich Sicherheit zu konfigurieren, da die Werkseinstellungen meist ungenügend sind. Die voreingestellten SSID s sind bekannt, daher muss eine Eigene gewählt werden. Weiter ist es bei vielen APs möglich, eine Sicherheitseinstellung zu aktivieren, die es erzwingt, dass AP und Client dieselbe SSID haben müssen. Standardmässig wird die SSID per Broadcast über das Wireless-Netz verschickt. Dies muss geg. auch deaktiviert werden. Da die SSID aber im Klartext übertragen wird, kann sie leicht abgefangen werden, sie bietet also nur ein minimaler Schutz vor Angreifern. Natürlich ist auch eine bruteforce -Attacke möglich, dabei werden viele SSID s durchprobiert. Als weiteres Sicherheitsinstrument stellen die APs Wired Equivalent Privacy (WEP) zur Verfügung. Doch der Name verspricht zuviel, denn von gleicher Sicherheit wie bei Kabelnetzen kann keine Rede sein. Indem WEP aktiviert und erzwungen wird, kann eine gewisse Sicherheit erreicht werden. Dabei ist zu beachten, dass unbedingt die Default-Schlüssel geändert werden müssen. Wie bereits oben erwähnt, können die Schlüssel geknackt werden, denn dies kann mit dem Empfangen von einigen Millionen Paketen erfolgen, welches bei stark Frequentiertem Netzwerk in 15 min. möglich ist (siehe http://www.iss.net/wireless/wlan_faq.php). Der Grund liegt darin, dass die Keys nicht bei jeder Session neu generiert werden. Als Nachfolger von WEP wurde WPA (Wi-Fi Protected Access) definiert, das die genanten Nachteile beseitigt. Neue Geräte werden vermehrt mit diesem Sicherheitsstandard ausgerüstet. Die Zugriffsmöglichkeiten zur Konfiguration des APs müssen geschützt bzw. das Default-Passwort muss geändert werden (auf einschlägigen Seiten veröffentlicht). Meist werden mehrere Interfaces angeboten wie SNMP, Serial, Web, Telnet die alle als Angriffspunkte zu betrachten sind. Weiter ist der SNMP-Client (Simple Network Management Protocol), der auf vielen APs läuft bei einigen Herstellern ungenügend 4/14

oder gar nicht geschützt. Es sollte geprüft werden, ob ein entsprechendes Update der Firmware möglich ist. Wie bereits oben erwähnt, sollte der AP so konfiguriert werden, dass die Sendeleistung nur das gewünschte Gebiet abdeckt und z.b. ausserhalb des Firmengebäudes nicht mehr empfangbar ist. Ein günstiger Standort ist dabei natürlich wichtig. 3.2 Clients Auf den an den AP angeschlossenen Clients werden ebenfalls sensible Informationen für das Wireless-Netzwerk gespeichert, insbesondere bezüglich Identifizierung und Kommunikation mit dem AP. Einige Hersteller speichern die WEP-Schlüssel in der Firmware und in der Windows-Registry und zwar verschlüsselt oder auch unverschlüsselt. Letzteres ist gefährlich, da der Schlüssel leicht erhältlich ist falls der Client schlecht konfiguriert ist. Jeder Wireless-Client muss gegen Angriffe einzeln geschützt werden, da Client zu Client-Verbindungen möglich sind. Die laufenden TCP/IP-Services müssen gut konfiguriert sein müssen, um ein Missbrauch zu verhindern. Dazu gehört auch die Datei und Druckerfreigabe, die möglichst restriktiv eingesetzt werden sollen. Wie auf fest vernetzten Computern gehört auch auf Wireless-Clients eine aktuelle Antivirus- Software, da sich neuartige Würmer schnell über das Netzwerk verbreiten können. 4 VPN mittels IPSec Die meisten der oben beschriebenen Konfigurationsmöglichkeiten, die im Wireless Networks Standard 802.11b spezifiziert sind, haben grosse Nachteile. Ein anderer Ansatz ist ein Virtual Private Network (VPN), bei dem die gesamte Kommunikation über das Wireless Netzwerk verschlüsselt wird. Dies geschieht dadurch, dass alle Daten (mit Ausnahme des Headers) in einem tiefen Layer verschlüsselt werden. Dies ist transparent zu den Anwenderprogrammen, diese müssen also nicht verändert werden. Eine Implementation die dies bietet ist IPSec, welches zudem im neuen IP-Protokol IPv6 obligatorisch vorhanden sein muss. 5/14

4.1 Aufbau von IPSec Folgende Darstellung verdeutlicht den Aufbau des IPSec : Die Architektur besteht aus dem Konzept und den Sicherheitsanforderungen und definiert weiter die Protokolle und Algorithmen, die in diesem Standard definiert sind. Das DOI (Document of Interpretation) verbindet die einzelnen Dokumente logisch, damit sie ein Ganzes bilden. 4.2 Security Association (SA) Das Security Association, kurz SA ermöglicht eine verschlüsselte Verbindung zwischen einem Sender und einem Empfänger. Mit einem SA ist aber nur die Verschlüsselung in eine Richtung möglich. Soll in beide Richtungen verschlüsselt werden, werden zwei SA s benötigt. 6/14

Die SA s können mittels Authentication Header (AH) oder Encapsulating Security Payload (ESP) übertragen werden, aber nicht mit beiden gleichzeitig. Das Security Association besteht aus: Security Parameter Index (SPI), welches zur Identifikation des SA s benutzt wird Der Zieladresse Dem Typ des Sicherheitsprotokolls 4.3 Protokolle Von IPSec werden die beiden Protokolle Authentication Header und Encapsulating Security Payload unterstützt. AH garantiert die Integrität des Packets (man kann überprüfen ob es geändert wurde) und erledigt die Authentikation (sicherstellen, dass vom richtigen Sender). Header-Aufbau von AH 7/14

ESP dagegen verschlüsselt die eigentlichen Daten und kann optional auch eine Authentifizierung durch führen. Header-Aufbau von ESP 8/14

4.4 Transport und Tunnel-Modus Bei VPN s unterscheidet man zwischen dem Transport- und dem Tunnel-Modus. Beim Transport-Modus werden nur die eigentlichen Daten (Payload) verschlüsselt, nicht aber der Header. Dieser kann nicht verschlüsselt werden, da das Netzwerk sonst nicht mehr erkennen kann, wohin das Packet zu schicken ist. Im Tunnelmodus besteht sozusagen ein Tunnel zwischen zwei geschützten Netzen (z.b. von zwei Geschäftsstellen einer Firma), über den die Daten verschlüsselt verschickt werden können. Ein Packet wird dabei von einem Host im internen Netz zum eigenen Gateway unverschlüsselt übertragen. Dort werden die Daten sowie der Header verschlüsselt und ein neuer Header generiert, der als Empfängeradresse die Adresse des Gateways des Zielnetzes erhält. Bei diesem Gateway wird werden die Daten und der Header dann entschlüsselt. Der entschlüsselte Header enthält dann wieder die ursprüngliche Zieladresse damit das Packet dem Zielhost zugestellt werden kann. 9/14

4.5 Beispiel-Installation Um die Installation auszuprobieren, verwendete ich IPSec auf einem Laborrechner der FH. Dazu installierte ich Suse Linux 9.0 und ergänzte die Hardwareaussattung mit einer zweiten Netzwerkkarte, um diesen PC als Wireless-Gateway zu benutzen. Das Programm FreeS/WAN (IPSec) ist in der Suse-Distribution bereits integriert, man kann es im Package-Manager auswählen und installieren lassen. Auch der Kernel der Distribution beinhaltet bereits die nötigen Änderungen damit IPSec ausgeführt werden kann. Es gibt die Möglichkeit, die Keys manuell oder automatisch mittels Oakley oder ISAKMP auszutauschen. Bei manueller Verteilung muss man nach der Installation von IPSec für jeden beteiligten Host ein neuen Hostkey generieren und den publickey in ein separates File speichern. Bei der Kommunikation über IPSec sind immer zwei Hosts beteiligt. Von diesen muss einer mit left und der andere mit right bezeichnet werden. Dies muss man beim der Extraktion des Public-Keys angeben. Eine IPSec-Kommunikation kann nur zwischen zwei Hosts aufgebaut werden, bei denen der eine den Public-Key right verwendet und der andere den Public-Key left. Die Seite (left/right) des Wireless-Gateways muss daher auf left oder right festgelegt werden und alle Clients entsprechend anders. Ich gehe hier davon aus, dass der Gateway auf right gesetzt wird. Löschen des files /etc/ipsec.secrets mit: rm /etc/ipsec.secrets Neuer Key generieren: ipsec newhostkey output /etc/ipsec.secrets Public-Key extrahieren: entweder mit right (hier Gateway): ipsec show-hostkey --right > pubgateway.txt oder mit left (hier Clients): ipsec show-hostkey --left > pubthishost.txt Die Einstellungsoptionen von IPSec befinden sich im File /etc/ipsec.conf. Dieses erstellte ich auf dem Gateway neu mit folgendem Inhalt: config setup interfaces="ipsec0=eth1" klipsdebug=none plutodebug=none plutoload=%search 10/14

plutostart=%search uniqueids=yes conn %default keyingtries=0 authby=rsasig left=%any right=192.168.0.1 rightsubnet=0.0.0.0/0 rightid=@secgw rightrsasigkey=0saqotialhd/xu81mt3f1ti0j9i9q/y+qui9btqagcwiwflrdbj+qo78fnuumlrlkhvmeomo1rgvzkf ZMUtnYHR5Hvmp/vN40NwIc0GLXo2FMrK3on6K7ipJ3TRZaiRmxN8rLtV7WF7rNJL7xW8wBAmQtNbOpujMkyWlvX yy8fhxo/3estgy3627iag8j7gv+hyouyvwpsqalnn3qh73/nlqlrumpkx8wrjeljjf6uqwifsaobfkmjwf4 ucwrewe58igxwc0hw/xbwukd3lnsf8vujcjo1ubjuo/1riqdtmiqbgh0fearclhsarmdrl5jzr0tnz9uzgz JNvWDxnrBMqUXAomM7lRroOVg4ChK2M2nm3i7R conn client1 leftid=@wireless1 leftrsasigkey=0saqpel7y0xlnz+rkhbwu4rdjule4r/9+h65hjvon22rmatyvvluxa9p18k3wkk UUYJErd0MZJl8nHOnR6M0OyEUX1JqtXRqxXalC/zhR3+AZpX9fnuocUNAojllwDZbHI4J2AI6Uj+VZxaRmu 5fI4dZVw8QMg1HdRLKj3UYejjbNAfMSRnzCs2T5pWqZMT6JLUhpjQKi+sg7Xy2/FqH8N9btX1gMFa3vQzyq I9Psxp9t9mEpCw9VlqP0r8d/8XIafzYA+05E8qqI7EeG5O0Jd+P85nxZxDxCA+oIZO3m0LNAevADw75kt0x avyy7u1oncbz7fsgt5rh0b1jgemools+0c4vfc0o63gs60lqqad2hlllb9 auto=add Wichtige Parameter: Für jeden Wireless-Client muss in diesem File ein Abschnitt conn xxx eingetragen werden mit dem Public-Key des Clients (z.b. per Flashcard verteilen) und dessen id. Auf jedem Wireless-Client muss IPSec ebenfalls installiert werden. Das File /etc/ipsec.conf hat dort folgenden Inhalt: config setup interfaces=%defaultroute klipsdebug=none plutodebug=none plutoload=%search plutostart=%search uniqueids=yes conn %default keyingtries=0 authby=rsasig conn client left=%defaultroute leftid=@wireless1 leftrsasigkey=0saqpel7y0xlnz+rkhbwu4rdjule4r/9+h65hjvon22rmatyvvluxa9p18k3wkk UUYJErd0MZJl8nHOnR6M0OyEUX1JqtXRqxXalC/zhR3+AZpX9fnuocUNAojllwDZbHI4J2AI6Uj+VZxaRmu 5fI4dZVw8QMg1HdRLKj3UYejjbNAfMSRnzCs2T5pWqZMT6JLUhpjQKi+sg7Xy2/FqH8N9btX1gMFa3vQzyq I9Psxp9t9mEpCw9VlqP0r8d/8XIafzYA+05E8qqI7EeG5O0Jd+P85nxZxDxCA+oIZO3m0LNAevADw75kt0x avyy7u1oncbz7fsgt5rh0b1jgemools+0c4vfc0o63gs60lqqad2hlllb9 right=192.168.0.1 rightsubnet=0.0.0.0/0 rightid=@secgw rightrsasigkey=0saqotialhd/xu81mt3f1ti0j9i9q/y+qui9btqagcwiwflrdbj+qo78fnuuml RlkhvMeomO1RgVZkfZMUtnYHR5Hvmp/vN40NwIc0GLXo2FMrK3on6K7ipJ3TRZaiRmxN8rLtV7WF7rNJL7x W8wBAmQtNbOpujMkyWlvXyy8fhXo/3eSTGY3627iag8j7gV+hyOUYVwPSQaLnN3qH73/nlqlRumpkX8wrje LjJf6uqWifsaoBfkmjwF4uCWreWe58iGXwc0hw/xBWUKd3lNSF8VuJcjo1ubjuo/1rIqDTmiqBgh0feaRCl HSARmdrL5JZr0Tnz9UzGZJNvWDxnrBMqUXAomM7lRroOVg4ChK2M2nm3i7R auto=start Die beiden Netzwerk-Interface konfigurierte ich so, dass der Access-Point an eth1 angeschlossen wurde (feste IP: 192.168.0.1) und eth0 am Internet (feste IP-Adresse des Laborrechners, könnte auch DHCP sein). Weiter installierte ich einen DHCP- Server und vergab damit die IP-Adressen auf dem Wireless-Netz. 11/14

Mit folgenden Befehlen kann man IPSec steuern: IPSec starten: /etc/rc.d/ipsec start IPSec stoppen : /etc/rc.d/ipsec stop Konfiguration client starten: ipsec auto --up client Mehr Fehler-Output generiert der add-befehl: ipsec auto --add client Damit die Anfragen von Wireless-Clients überhaupt weitergeleitet werden, muss man das IP-forwarding einschalten. EIF=eth0 IPTABLES=/usr/sbin/iptables IPSec erstellt neben den anderen Netzwerk-Interfaces ein weiteres mit dem Namen ipsec0 (weitere ipsec1 etc.). Wenn die Kommunikation über dieses Interface abgewickelt wird, dann und nur dann werden die Daten verschlüsselt übertragen. Es ist da- her wichtig, dass man auf dem Gateway iptables so konfiguriert, dass nur diese Packete zusammen mit denen von IPSec erlaubt sind und die anderen vernichtet werden. Damit kann erzwungen werden, dass nur Clients die IPSec mit einem gültigen Schlüssel verwenden über den Gateway geroutet werden. Diese Bedingungen werden mit folgendem Script erreicht: echo "1" > /proc/sys/net/ipv4/ip_forward echo "1" > /proc/sys/net/ipv4/ip_dynaddr $IPTABLES -F $IPTABLES -t nat -F $IPTABLES -X $IPTABLES -t nat -X # NAT and FORWARD $IPTABLES -t nat -A POSTROUTING -o $EIF -j MASQUERADE $IPTABLES -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT $IPTABLES -A FORWARD -i ipsec+ -j ACCEPT $IPTABLES -A FORWARD -i! ipsec+ -j LOG --log-prefix "Not IPSEC: " $IPTABLES -A INPUT -i ipsec+ -j ACCEPT $IPTABLES -A OUTPUT -o ipsec+ -j ACCEPT # IPSEC $IPTABLES -A INPUT -p UDP --sport 500 --dport 500 -j ACCEPT $IPTABLES -A INPUT -p 50 -j ACCEPT $IPTABLES -A INPUT -p tcp --destination-port 22 -j ACCEPT #ssh $IPTABLES -A INPUT -j LOG --log-prefix "INPUT DROP: " $IPTABLES -A OUTPUT -p UDP --sport 500 --dport 500 -j ACCEPT $IPTABLES -A OUTPUT -p 50 -j ACCEPT $IPTABLES -A OUTPUT -p tcp --destination-port 22 -j ACCEPT #ssh $IPTABLES -A OUTPUT -j LOG --log-prefix "OUTPUT DROP: " # lockdown! $IPTABLES -P INPUT DROP $IPTABLES -P OUTPUT DROP $IPTABLES -P FORWARD DROP #iptables -A INPUT -j LOG --log-prefix "eth0-drop INPUT: " #iptables -A INPUT -i eth0 -j DROP #iptables -A OUTPUT -j LOG --log-prefix "eth0-drop OUTPUT: " 12/14

#iptables -A OUTPUT -o eth0 -j DROP Testen kann man die IPSec-Verbindung mittels dem ping-befehl und dem Parameter I (Interface): ping -I ipsec0 <ipadresse> 4.6 Automatischer Schlüsselaustausch und Verteilung Die manuelle Schlüsselverteilung ist aber nur für kleinere Wireless-Netze geeignet, die nicht viele AP s und Benutzer aufweisen. Denn bei dieser Variante müssen alle Public-Keys der Benutzer auf allen Gateways hinter den AP s gespeichert sein. Denn nur so können die Clients den AP wechseln und haben wieder Zugriff aufs Netzwerk. IPSec ermöglicht neben der manuellen Schlüsselverteilung das Schlüsselmanagement mittels zwei verschiedener Protokolle zu automatisieren. 4.7 Diffie-Hellman-Algorithmus Der Diffie-Hellman-Algorithmus ermöglicht das Austauschen eines symmetrischen Schlüsseln zwischen zwei Teilnehmern und zwar ohne physischen Kontakt und über eine unsichere Leitung. Dazu werden zwei globale Parameter benötigt, die nicht nur beiden Teilnehmern bekannt sein müssen, sondern auch öffentlich sein können. 4.8 Oakley Das Oakley-Protokoll ist eine Erweiterung des Diffie-Hellman Algorithmus. Diffie- den schwerwiegenden Nachteil, dass er ein man in-the-middle Hellman hat aber Angriff nicht ausschliessen kann. Dieser Nachteil ist in Oakley eliminiert. Weiter hat Oakley einen Schutz gegen blockierende Angriffe 1 mittels Cookies und lässt Gruppen zu, so dass die globalen Parameter, die beiden Partnern bekannt sein müssen durch die Gruppe definiert werden. 4.9 ISAKMP (Internet Security Association and Key Management Protokol) Dieses Protokoll definiert Verfahren und Packet-Formate, um eine Security Association (SA) aufzubauen, auszutauschen etc. Dies beinhaltet Formate für den Aus- tausch von Key- und Authentikations-Daten, wobei ISAKMP unabhängig von Schlüsselaustauschprotokollen oder Verschlüsselungsalgorithmen ist. Es werden die verschiedenste Zertifikate unterstützt. 1 Ein blockierender Angriff erfolgt, indem viele Packete schickt werden, die eine Schlüssel- Generierung nach Diffie-Hellman auslösen. Da diese Generierung sehr rechenintensiv ist, wird er Server dadurch stark belastet. 13/14

5 Anhang 5.1 Quellen William Stallings, Cryptography and Network Security: Principle and Practice 3rd ed. Prentice Hall, 2002, http://williamstallings.com/ FAQ über Wireless-Sicherheit: http://www.iss.net/wireless/wlan_faq.php IPSec: http://www.freeswan.org/ FAQ über WPA: http://www.54g.org/wpa_faq.html 14/14