Entwicklung eines verteilten Intrusion Detection Systems für Wireless LAN

Transkript

1 Entwicklung eines verteilten Intrusion Detection Systems für Wireless LAN - Grosser Beleg - Bearbeiter: Sandro Reichert sandro.reichert@inf.tu-dresden.de Fakultät Informatik Institut für Systemarchitektur Lehrstul Rechnernetze Betreuer: Dipl.-Inform. Stephan Groß Hochschullehrer: Prof. Dr. rer. nat. habil. Dr. h. c. Alexander Schill Datum: 31. Oktober 2006

2 Aufgabenstellung Zielstellung Mit der Verbreitung von Wireless LAN haben in den letzten Jahren auch die Angriffe auf drahtlose Netze zugenommen. So sind beispielsweise die Sicherheitsmechanismen der ersten Generation vollständig gebrochen. Als Ersatz für den besagten WEP-Standard wurden mit WPA und WPA2 in der Zwischenzeit zwar sichere Alternativen geschaffen, jedoch schützen diese nur die Kommunikationsverbindung zwischen Access Point und mobiler Station. Auch können sie organisatorische Sicherheitslücken nicht verhindern. Ziel dieser Arbeit ist die Weiterentwicklung eines am Lehrstuhl Rechnernetze entwickelten Wireless Intrusion Detection Systems (IDS), das einzelne mobile Geräte schützt. Dazu soll die bestehende Implementierung zunächst untersucht und die vom Basissystem bereits zur Verfügung gestellten Mechanismen zur Vernetzung einzelner IDS-Sensoren analysiert werden. Hierauf aufbauend ist ein Mechanismus zu entwickeln, um mehrere IDS-Sensoren dynamisch miteinander zu koppeln. Eine Managerkomponente soll dabei dezentral auf jedem Gerät Informationen zu den kooperierenden Geräten verwalten. Die Implementierung ist anhand ausgesuchter Angriffsszenarios zu validieren, für die entsprechende Erkennungsroutinen zu entwickeln sind. Schwerpunkte Intrusion Detection C/C++ Programmierung Sicherheit verteilter Systeme 2

3 Inhaltsverzeichnis 1 Einleitung 6 2 Grundlagen Schutzziele grundlegende Schwachstellen in Wireless LAN Netzwerkname ESSID MAC-Adresse Sicherheit in IEEE Risiken im WLAN fehlerhafte Konfiguration von WLAN-Komponenten Anschluss nicht autorisierter Hardware Benachbarte Netze und Überlappungen der Frequenzen Angriffe Angriffscharakteristiken Angriffstechniken Network Discovery Masquerading Denial-Of-Service Man-In-The-Middle Intrusion Detection Systeme Typen von Intrusion Detection Systemen Weitere Unterscheidungsmerkmale von IDS Architektur eines IDS IDS für WLAN Motivation für ein Verteiltes Wireless IDS aktuelle Systeme Analyse Das IDS Bro Architektur von Bro Basiskonzepte von Bro Erkennung von Angriffen im WLAN Design der Kommunikationsschnittstelle Welche Events sollen ausgetauscht werden? Übertragung der Events Intrusion Detection Message Exchange Format IDMEF Anforderungen an das Nachrichtenformat Anforderungen an das IDMEF-Protokoll Anforderungen an den Inhalt der Nachrichten Blocks Extensible Exchange Protocol BEEP Intrusion Detection Exchange Protocol IDXP Das BEEP-TUNNEL-Profil Zusammenfassung IDMEF / BEEP Die Kommunikationsschnittstelle von Bro

4 3.4.1 Allgemeiner Ablauf Konfigurationsmöglichkeiten Verbindungsaufbau Austausch von Events Zusammenfassung Implementierung Analyse bisher erkennbarer Angriffe Definition der neuen Policy Adressierung auf Policy Ebene Austausch der MAC-Adressen Das Event wlan comm question Das Event wlan comm awnser Angriffswarnung durch das Netz propagieren Zusammenfassung Evaluierung Erstellen des Angreifer-Skriptes Vorbereitung des Versuchsaufbaus Installation VMware Server Installation der virtuellen Maschine Installation Bro Klonen des virtuellen Systems Durchführung Verbindungsaufbau mit Austausch der MAC-Adressen Angriff kooperativ erkennen Vorwarnung weiterer Systeme Ausblick auf weiterführende Entwicklungen Eindeutige Bestimmung des verwendeten Kanals Analyse des durch die Kommunikation entstehenden Traffic Broadcasting von Events Zusammenfassung 74 A Abkürzungsverzeichnis 75 B Quelltext-Listing Event wlan comm broadcast alert 76 Literatur 81 4

5 Abbildungsverzeichnis 1 Architektur eines Intrusion Detection Systems Möglicher Angriff von Eve auf Bob trotz des Einsatzes eines zentralen IDS-Manager Die Architektur von Bro [Neu05] Die Ereignisverarbeitung von Bro [Neu05] Die Policy-Interpretation von Bro [Neu05] Der Informationsfluss in wireless.bro Protokollebenen und Kanäle bei der Kommunikation zweier BEEP- Peers über eine BEEP-Session Manager A baut über die zwei Proxies P1 und P2 einen Tunnel zu Manager B auf Schematische Darstellung der inter-bro Kommunikation Ablauf der Setup-Phase Ablauf eines Man-In-The-Middle-Angriff Erkennung von MAC-Spoofing durch kooperierende IDS Informationsfluss bei der Erkennung eines Angriffes und der Vorwarnung weiterer Systeme Der Informationsfluss in wireless.bro

6 1 Einleitung Mit dem Streben nach mehr Individualität und Flexibilität erhöht sich die Anzahl der Nutzer mobiler Endgeräte und drahtloser Netze fortlaufend. Ein besonders großer Zuwachs ist bei Wireless LAN zu verzeichnen, sowohl im privaten, als auch im gewerblichen Bereich. Viel zu wenigen Nutzern ist hierbei bewusst, dass sie die gewonnene Flexibilität mit einer eingeschränkten oder gar verlorengegangenen Sicherheit bezahlen! Die Sicherheitsmechanismen der ersten Generation wurden vollständig gebrochen und für die aktuellen Standards WPA und WPA2 existieren ebenfalls erste Angriffsmethoden. Daher ist neben der sorgfältigen Konfiguration der Netzwerkknoten eine permanente Überwachung des Netzwerkes mit Intrusion Detection Systemen zu empfehlen. Ein WLAN kann auf zwei verschiedene Arten realisiert werden. Im Infrastruktur-Modus werden zumeist mehrere Access Points an strategisch sinnvollen Positionen fest installiert und über ein kabelgebundenes Netzwerk in die bereits bestehende Topologie integriert. Aufgrund der resultierenden lokalen Unterteilung des Netzes in Funkzellen ist es sinnvoll, ein Verteiltes Wireless IDS einzusetzen, um alle Funkzellen und Kanäle simultan zu überwachen. Im ad-hoc-modus werden vorallem mobile Geräte wie Laptops oder PDAs 1 direkt miteinander verbunden, ohne eine bestehende Infrastruktur zu benötigen. Der unbedarfte Umgang mit der Technik stellt die Entwickler von Sicherheitslösungen immer wieder vor neue Herausforderungen, um Nutzer effektiv zu schützen. Das Ziel dieser Arbeit ist eine Erweiterung für das bereits entwickelte Bro, ein open-source Intrusion Detection System für Breitbandnetze. Es wurde 2005 von Renè Neumerkel im Rahmen einer Diplomarbeit an der TU Dresden für WLAN erweitert [Neu05]. Jetzt wird untersucht, in wieweit sich die Erkennungsmöglichkeiten von Angriffen verbessern lassen, wenn mehrere mobile Geräte kooperieren. Hierzu werden in Kapitel 2 zunächst die Schwachstellen, Risiken sowie die mit ihnen verbundenen Angriffe in drahlosen Netzwerken vorgestellt. Im zweiten Teil des Kapitels wird der Leser in das Themengebiet der Intrusion Detection Systeme eingeführt. Im Anschluss daran folgt die Analyse des eingesetzten IDS Bro. Es werden die Basiskonzepte zur Erkennung von Angriffen vermittelt und die bereits integrierte Schnittstelle zur Kommunikation mit anderen Systemen genau unter die Lupe genommen. In diesem Zusammenhang erfolgt ebenfalls eine Untersuchung des Intrusion Detection Message Exchange Formates, welches einen 1 PDA steht für Personal Digital Assistent. Zu dieser Gruppe gehören kleine, portable Geräte wie digitale Terminplaner. 6

7 standardisierten Austausch von Nachrichten zwischen Intrusion Detection Systemen unterschiedlicher Anbieter ermöglicht. Mit dem erworbenen Wissen wird in Kapitel 4 eine Strategie entwickelt und umgesetzt, mit der sich die gewünschte Kooperation der mobilen Stationen umsetzen lässt. In diesem Zuge wird ein Verfahren aufgezeigt, mit dessen Hilfe sich Informationen über einen erkannten Angriff auch an Nutzer weiterleiten lassen, zu denen der Urheber dieser Vorwarnung keine direkte Verbindung aufgebaut hat. Im darauf folgenden Kapitel werden die entwickelten Methoden anhand konkreter Beispiele evaluiert. Zum Abschluss wird die Arbeit in den sie umgebenden Rahmen eingeordnet und ein Ausblick auf weiterführende Entwicklungen geworfen. 7

8 2 Grundlagen Zu Beginn werden die angestrebten Schutzziele eines allgemeinen IT-Systems kurz erläutert, gefolgt von einer Übersicht der verschiedenen Schwachstellen drahtloser Netzwerke, den damit verbundenen Risiken und den resultierenden Angriffsmöglichkeiten. Eine Einführung in das Gebiet der Intrusion Detection Systeme wird das Grundlagenkapitel abrunden. 2.1 Schutzziele Der erste Schritt bei der Entwicklung eines Schutzsystems ist eine klare Definition der Schutzziele. Im Anschluss daran wird das zu schützende System anhand dieser Definition analysiert, eine Strategie zur Umsetzung ausgearbeitet und schließlich werden die erforderlichen Schutzmaßnahmen ergriffen. Die in IT-Systemen auftretenden Bedrohungen werden üblicherweise in drei Bereiche unterteilt [Pfi00]: Vertraulichkeit: Nur Berechtigte erhalten die Informationen. Integrität: Die Informationen sind richtig, vollständig und aktuell oder aber dies ist eindeutig erkennbar nicht der Fall. Verfügbarkeit: Die Informationen sind dort und dann zugänglich, wo und wann sie von Berechtigten gebraucht werden. 2.2 grundlegende Schwachstellen in Wireless LAN Die folgenden Schwachstellen im allgemeinen WLAN Standard IEEE und dessen Erweiterungen sind für diese Arbeit sehr wichtig. Darüberhinaus existieren weitaus mehr Bedrohungen, auf die an dieser Stelle nicht weiter eingegangen wird, da es den gesetzten Rahmen sprengen würde Netzwerkname ESSID Der Netzwerkname, kurz SSID bzw. ESSID 2, wird im Normalfall von jedem Acces Point im Klartext alle 100ms im Beacon Frame, einem speziellen Management Frame, per Broadcast gesendet. Clients suchen sich anhand der ESSID den AP mit der besten Signalstärke, sowohl bei der ersten Anmeldung am Netz, als auch beim Handover zwischen zwei Funkzellen. Je nach Konfiguration des APs kann sich jeder Client mit ihm verbinden, oder nur Clients mit der selben ESSID. Den Netzwernamen zu fälschen ist ein typischer Bestandteil eines Angriffs, daher bieten manche Hersteller die Deaktivierung des ESSID-Broadcasts in 2 (Extended) Service Set IDendity: Werden mehrere Basisstationen mit der selben SSID zusammen betrieben, so wird sie als ESSID bezeichnet. 8

9 der Konfiguration ihrer Geräte an. Dies ist jedoch nicht standardkonform mit IEEE und kann Störungen in einigen Geräten verursachen [Com03a]. Darüberhinaus bietet diese Maßnahme nicht den erhofften Schutz, die ESSID wird bei jedem Verbindungsaufbau im Klartext übertragen und kann so leicht ausgespäht werden MAC-Adresse Die Media Access Control Adresse ist eine weltweit eindeutige 48 Bit Adresse der Hardware. Im WLAN wird sie als Teil des Header im Klartext übertragen, weshalb sie problemlos ausgespäht und manipuliert werden kann. Sie ist daher nicht zu einer sicheren Identifikation eines WLAN-Gerätes geeignet und ist einer der Grundbausteine für viele bekannte Angriffe. Jedem Hersteller von Hardware ist ein genauer Bereich an MAC-Adressen zugeordnet, welche bei der Internet Assignet Number Authority registriert sind. Es wurden noch nicht alle möglichen Adressen vergeben Sicherheit in IEEE WEP - Wired Equivalent Privacy ist der veraltete Sicherheitsstandard. Er ist mitlerweile durch WPA, WPA2 und i ersetzt, nachdem er vollständig gebrochen wurde. Zu den Schwachstellen von WEP zählen die zu kurzen Werte für Schlüssellänge und Initialisierungsvektor sowie der lineare RC4-Algorithmus. Die mit WPA2 und IEEE i eingeführten Neuerungen machen Angriffe dennoch nicht unmöglich. Sie bieten keinen Schutz vor Flooding-Attacken (siehe 2.4.5), da die Management-Frames weiterhin unverschlüsselt übertragen werden [FMS01, Oss04, Oss05, Sch05]. 2.3 Risiken im WLAN Neben den in Kapitel 2.2 genannten Schwachstellen von IEEE stellen die Nutzer selbst häufig eine ihnen unbewusste Bedrohung für das Netzwerk dar. Die Risiken bestehen in der falschen Konfiguration der WLAN-Komponenten und dem Anschluss nicht autorisierter Hardware. Ein anderes Problem stellt die unkontrollierbare Ausbreitung der Funkwellen dar, wodurch sich z.b. Netze benachbarter Firmen überlappen können oder ein Angreifer unbemerkt von aussen mithören kann fehlerhafte Konfiguration von WLAN-Komponenten Ein grosses Sicherheitsproblem stellt die Werkseinstellung vieler Endgeräte dar, vorallem bei Routern mit integriertem Access Point. Einstöpseln und 9

10 Lossurfen wird gerade von IT-Laien im SoHo-Bereich 3 als nutzerfreundlich angesehen und dementsprechend auch von den Firmen so beworben. Was im ersten Moment so komfortabel erscheint, entpuppt sich schnell als Risiko. Die Nutzerfreundlichkeit ist nichts anderes als die Unwissenheit der Nutzer, dass sie sich mit sicherheitsrelevanten Themen beschäftigen müssen und ebenso die Nachlässigkeit der Firmen, ihre Kunden auf diese seit Jahren bekannten Risiken aufmerksam zu machen. Eine typische WLAN-Router Standardkonfiguration: ein aktivierter DHCP-Server und WEP entweder deaktiviert oder ein Schlüssel aus Nullen bzw. ausschließlich Ziffern Anschluss nicht autorisierter Hardware Ein IT-Verantwortlicher muss Zugriff auf alle Knoten im Netzwerk haben, um Sicherheitsrichtlinien durchsetzen zu können. Jedes nicht von ihm kontrollierbare Gerät stellt somit ein Sicherheitsrisiko dar, unabhängig von der Tatsache, ob es von einem Mitarbeiter oder Angreifer installiert wurde. Nicht autorisierte WLAN-Geräte werden als Rogue Access Point bezeichnet. Während man in der Vergangenheit unter dem Begriff hauptsächlich Hardware APs verstand, nimmt mittlerweile die Zahl der sogenannten Soft-APs immer mehr zu. In diese Kategorie fallen vorallem WLAN-fähige Laptops, die von Mitarbeitern an das kabelgebundene Netzwerk legal angeschlossen werden. Sind sie fehlerhaft konfiguriert (siehe 2.3.1), können sie z.b. als ungeschützer AP auftreten und gleichzeitig als Brücke zum LAN agieren. Ein Angreifer kann auf diese Weise alle Sicherheitsvorkehrungen des LAN umgehen [Kre03]. Zur Klasse der Soft-APs können darüberhinaus alle WLAN-fähigen Geräte gehören: u.a. PDAs, Barcode Scanner, Drucker und Scanner. Sie weisen alle nur sehr schwache bzw. keine eingebauten Sicherheitsmerkmale auf [Air06] Benachbarte Netze und Überlappungen der Frequenzen Durch die unkontrollierte Ausbereitung der Funkwellen entstehen Sicherheitsrisiken, die es in dem Umfang in Kabelnetzwerken nicht gibt. Da wären zunächst die Probleme mit anderen WLANs: Funkzellen nah aneinander liegender APs überlappen sich in Bürogebäuden auch über Firmengrenzen hinweg. Die Begrenzung der Reichweite durch schwächere Sendeleistungen oder Ausrichtung der Antennen führt nicht immer zum Erfolg. Für mangelhaft konfigurierte Endgeräte besteht die Gefahr, dass sie sich ungewollt mit dem WLAN eines benachbarten Unternehmens, dem WLAN eines Angreifers oder ad-hoc mit irgendeinem unbekannten WLAN verbinden. Diese Verbindungen beeinträchtigen alle in Abschnitt 2.1 genannten Schutzziele: Vertraulichkeit Integrität und Verfügbarkeit. 3 Small Office, Home Office 10

11 Um den reibungslosen Betrieb eines Funk-Netzes gewährleisten zu können, soll an dieser Stelle kurz auf das schmale ISM-Band GHz eingegangen werden. Systeme nach IEEE b, g und i bieten zwar nominell 13 Kanäle 5 an, es können aber nur drei Kanäle überlappungsfrei genutzt werden. Hinzu kommen andere Dienste wie bluetooth und Geräte wie Funk-Überwachungskameras, medizinische Apperaturen und haushaltsübliche Mikrowellen, die ebenfalls dieses ISM Band verwenden. Diese vielseitige Nutzung des Frequenzbandes und die damit verbundenen gegenseitigen Störungen sind ein nicht zu unterschätzendes Risiko für die Verfügbarkeit der einzelnen Dienste [Aru06, Kom04]. Beeinträchtigungen dieser Art werden im Normalfall nicht von einem Wireless IDS erkannt, da dieses zwar die Luftschnittstelle überwacht, aber mit den unterschiedlichen Protokollen nicht umgehen kann. 2.4 Angriffe Die grundlegenden Schwachstellen und Risiken im WLAN sind nun bekannt, jetzt werden die daraus resultierenden möglichen Angriffe vorgestellt. Zunächst werden die allgemeinen Angriffscharakteristiken erläutert, anschließend einige spezielle Angriffstechiken. Dabei soll nicht bis ins Detail gegangen werden, denn diese Arbeit baut auf die Diplomarbeit Entwicklung eines Angriffssensors für Wireless LAN von Renè Neumerkel, TU Dresden auf. Typische Bedrohungen und Angriffe werden in dieser Arbeit ausführlich beschrieben [Neu05] Angriffscharakteristiken Welches Ziel verfolgt der Angreifer? Hier reicht das Spektrum vom Erschleichen von Diensten wie Internetzugang bis hin zur Industriespionage mit dem Ausspähen sensibler Daten und der Störung des Netzwerkes. Agiert der Angreifer beobachtend oder verändernd? Ein beobachtender Angreifer hört den Netzwerkverkehr ab, ohne selbst Nachrichten einzuschleusen. Greift er allerdings zusätzlich aktiv ein, indem er Pakete verschickt, wird er als verändernder bzw. aktiver Angreifer bezeichnet. Dieses Verhalten ist vom Netzwerkbetreiber generell leichter zu bemerken als das eines beobachtenden Angreifers. 4 Industrial Scientific Medical Band, ein lizenzfreier Frequenzbereich von bis GHz 5 Angaben beziehen sich auf Deutschland, in anderen Ländern gibt es teilweise andere Regulierungen 11

12 Auf welcher Netzwerkschicht findet der Angriff statt? Die in Kabelnetzen bekannten Angriffe erfolgen meist in der Schicht 3 (Vermittlungsschicht) oder einer höhern Schicht des OSI-Referenzmodells. In Funknetzen sind eher die darunterliegenden Schichten 2 (Sicherungsschicht) und Schicht 1 (Bitübertragungsschicht) das Ziel von Angreifern Angriffstechniken Angreifern steht mittlerweile ein ganzes Arsenal an Programmen und Tools zu Verfügung, um in WLANs einzudringen. Das Grundprinzip aller Angriffe ist jedoch das selbe: zuerst werden allgemeine Informationen über das Netzwerk gesammelt und anschließend gezielt der eigentliche Angriff gestartet. In späteren Phasen folgt die Ausweitung von Rechten oder das Verwischen von Spuren. Diese Herangehensweise, sowie die Grundzüge einiger spezifischer Techniken ähneln bereits bekannten Angriffen aus dem Bereich kabelgebundener Netze. In den folgenden Abschnitten werden einige häufig verwendete Angriffstechniken, sowie Maßnahmen zu deren Erkennung durch Intrusion Detection Systeme vorgestellt. Für einen umfassenden Überblick auf weitere Angriffe wird auf die zahlreiche Literatur verwiesen [Ahl04, Aru06, Bir06, Com03a, FMS01, Oss04, Oss05, Sch05] Network Discovery Der erste Schritt eines Angreifers ist die Suche nach WLANs, die sich in seiner Empfangsreichweite befinden. Hierbei wird zwischen Passive Probing und Active Probing unterschieden. Führt ein Angreifer die Suche nicht nur stationär an einem Ort durch, sondern mit einem mobilen WLAN-Gerät und aktiviertem Netzwerkerkennungs-Tool, so wird dieser Vorgang als Wardriving bezeichnet. Beim Passive Probing werden sequentiell alle Kanäle nach Beacon-Frames (siehe 2.2.1) abgehört. Bei diesem Verfahren werden nur Pakete empfangen, daher kann es von einem IDS nicht erkannt werden. Active Probing ist das Versenden von Probe Requests auf allen Kanälen. Vorhandene APs antworten im Normalfall mit einer Probe Response, welche die ESSID, MAC-Adresse und Informationen über verfügbare Protokolle beinhaltet. Eine weitere Möglichkeit zum Sammeln von Informationen stellen aktive Netzwerkerkennungs-Tools dar, indem sie z.b. versuchen die ESSID eines Netzwerkes zu erraten. Ihr Einsatz kann durch das sehr hohe Aufkommen von Paketen mit einem falschen Netzwerknamen oder ungültigen MAC-Adressen von einem IDS erkannt werden. Mit dem Wissen über verfügbare Netzwerke lassen sich nun die verschiedensten Angriffe starten. Je nach Angriffsziel (siehe 2.4.1) kann der Angreifer u.a. 12

13 versuchen, die ggf. eingesetzte WEP- oder WPA-Verschlüsselung zu brechen, das Funknetz mit Denial-of-Service (2.4.5) Angriffen zu stören oder sich unbemerkt in eine bestehende Kommunikationsbeziehung als Man-In-The-Middle (2.4.6) einzuschleusen. Diesen Angriff sicher zu erkennen ist einer der zentralen Punkte dieser Arbeit. Da er verschiedene Angriffe miteinander kombiniert, werden zunächst die nötigen Grundlagen vorgestellt und anschließend der Man-In-The-Middle Angriff selbst analysiert Masquerading Versucht ein Nutzer seine eigene Idendität zu verschleiern, indem er eine andere Idendität vortäuscht, so spricht man von Masquerading, Impersonation oder Spoofing. Hierzu ersetzt er die eigene MAC-Adresse seiner WLAN-Hardware mit der Adresse eines autorisierten Nutzers, um z.b. die als Zugangskontrolle eingesetzen MAC-Filter eines APs zu umgehen. Eine andere Variante ist das Vortäuschen eines autorisierten Access Points, indem der Angreifer seine WLAN-Karte mit der MAC-Adresse und der ESSID eines aut. APs konfiguriert und auf einem anderen Kanal als der autorisierte AP auf eingehende Verbindungen argloser Nutzer wartet. Ein IDS kann Masquerading am Empfang von noch nicht vergebenen und daher ungültigen MAC-Aderssen erkennen (siehe 2.2.2). Angriffe mit gefälschten, gültigen Adressen sind hiervon ausgeschlossen Denial-Of-Service DoS-Angriffe richten sich generell gegen die Verfügbarkeit eines Netzes. Ihr Ziel ist es, einzelnen oder gar allen autorisierten Nutzern des Netzerks den Zugriff auf die Kommunikationsdienste zu verwehren. Eine der verbreitetsten Methoden ist das massenhafte Versenden von gefälschten Management-Frames innerhalb kürzester Zeit. Diese Technik ist auch als Flooding bekannt. DoS- Attacken werden häufig in Verbindung mit Masquerading (2.4.4) durchgeführt. Um einem Nutzer den Zugang zum Netz zu verwehren, kann ihm ein Angreifer permanent gefälschte Deauthenticate-Nachrichten oder Disassociate-Nachrichten mit der Absenderadresse des eigentlichen APs schicken. Der Client muss sich daraufhin fortlaufend erneut mit dem AP verbinden, jedoch ohne Erfolg der Angreifer trennt die Verbindung sofort wieder. Mit einem ähnlich gearteten Angriff lässt sich auch ein AP lahmlegen, indem der Angreifer massenhaft Authentication Requests bzw. Association Requests mit ständig wechselnden Absenderadressen verschickt. Der AP muss auf jede Anfrage reagieren, auch wenn die vermeindlichen Nutzer nicht autorisiert sind und ihre Verbindungsanfrage abgelehnt werden muss. Die Station ist nur noch mit der Nutzerverwaltung beschäftigt und hat keine freien Kapazitäten mehr für die eigentliche Kommunikation. 13

14 Zum Erkennen der Angriffe wird die Häufigkeit des Auftretens von Management-Frames des selben Typs untersucht. Werden in einem Zeitraum ungewöhnlich viele Nachrichten des selben Typs empfangen, so deutet dies auf einen DoS-Angriff hin Man-In-The-Middle Als Man-In-The-Middle werden Angreifer bezeichnet, die sich in eine Kommunikationsbeziehung zwischen zwei Teilnehmern transparent einschleusen, d.h. ohne dass einer der Beiden etwas bemerkt. Der Angreifer agiert somit als Gateway zwischen den Kommunikationspartnern und ist auf diese Weise in der Lage, jeglichen Datenverkehr mitzuhören und unter Umständen auch eine Verschlüsselung auf Anwendungsebene zu umgehen. Er kann einzelne Pakete aus dem Datenstrom aussondern, verändern oder neue einfügen. Weitere Formen des MITM sind Session Hijacking und Connection Hijacking. Beim Session Hijacking übernimmt der Angreifer die Rolle des Clients aus einer bereits bestehenden Kommunikationsbeziehung, indem er ihn z.b. mit einer DoS-Attacke zum Absturz bringt und seine eigene WLAN-Karte mit der MAC-Adresse des Clients konfiguriert. Jetzt ist er in der Lage, die bestehende Verbindung mit dem Access Point fortzuführen. Analog wird beim Connection Hijacking der Access Point angegriffen und durch einen eigenen AP des Angreifers ersetzt. 2.5 Intrusion Detection Systeme Intrusion Detection Systeme sind Werkzeuge zur Erkennung von Angriffen innerhalb eines IT-Systems. Ihre Spannweite reicht von einfachen, hostbasierten IDS, welche ihre Daten primär aus Logfiles beziehen, bis hin zu komplexen, netzwerkbasierten IDS, die ihre Systemumgebung in komplexen Zustandsmodellen darstellen. Nach einer allgemeinen Begriffsklärung soll der Leser in die Welt der IDS eingeführt werden. Anschließend wird das Augenmerk auf die besonderen Anforderungen an ein Wireless IDS im allgemeinen, sowie auf das in dieser Arbeit benutzte Bro im speziellen gelenkt Typen von Intrusion Detection Systemen Der Begriff Intrusion Detection System und die Funktionalität solcher Systeme ist einem stetigen Wandel unterlegen. Werkzeuge der ersten Generation waren nur mit rudimentären Erkennungsmöglichkeiten ausgestattet, sie überwachten z.b. den Zugriff auf verschiedene Systemressourcen und hatten keinerlei Schutzfunktionen. Mittlerweile geht der Trend zu Systemen, die auf Angriffe ak- 14

15 tiv mit Gegenmaßnahmen reagieren können. Die verschiedenen Hersteller lassen sich hierbei unterschiedliche Namen wie Intrusion Detection & Response System, Intrusion Prevention System oder Intrusion Protection System einfallen [Gö03a]. Diese Systeme sind meist kommerzieller Natur und werden hier nur der Vollständigkeit halber mit erwähnt. Der Focus der Arbeit liegt auf den IDS. Hostbased Intrusion Detection Systems Hostbased Intrusion Detection Systeme, kurz HIDS, waren die ersten verfügbaren Programme, welche sich lediglich auf das Verhalten des eigenen Betriebssystems konzentrierten, indem sie vorrangig Logfiles auswerteten und den Netzwerkverkehr ignorierten. Ihr Einsatz hat immer mehr an Bedeutung verloren, modernere Lösungen wie Intrusion Prevention Systeme oder Network Nodebased Intrusion Detection Systeme (s.u.) haben ihren Platz eingenommen. Networkbased Intrusion Detection Systems Networkbased Intrusion Detection Systeme (NIDS) sind dedizierte Systeme, die den kompletten Datenverkehr des angeschlossenen Netzwerksegmentes analysieren und anhand einer vorgegeben security policy mögliche Angriffe erkennen. Network Nodebased Intrusion Detection Systems Im Gegensatz dazu werden die Network Nodebased Intrusion Detection Systeme (NNIDS) direkt auf dem zu schützenden System installiert. Sie kontrollieren im Hintergrund den eigenen ein- und ausgehenden Datenverkehr und typische Parameter des Betriebssystems wie fehlgeschlagene Anmeldeversuche und Zugriffe auf Systemdateien. Ihr Vorteil gegenüber NIDS ist, dass sie ohne Einsatz neuer Hardware in eine bestehende Infrastruktur eingebettet werden können. Der Nachteil besteht in ihrer Verwundbarkeit - wird das Produktivsystem angegriffen, ist das NNIDS schlimmstenfalls ebenfalls außer Gefecht gesetzt. Inline Intrusion Detection Systems Zu dieser Klasse zählen Werkzeuge, die man als transparentes Gateway in eine bestehende Verbindung zwischen zwei Netzwerkknoten einbindet. Der Datenstrom wird durch das IIDS hindurch geleitet, unerwünschte Pakete werden herausgefiltert. Application Intrusion Detection Systems Um (Angriffs-) Ereignisse auch auf Anwendungsebene erkennen zu können, muss ein IDS die Bedeutung einer Anfrage verstehen können. Hierfür wurden Application Intrusion Detection Systeme kreiert. Sie können z.b. eine HTTP- Anfrage aus einem Paketstrom selektieren, die segmentierte Nachricht zusammensetzen, anhand von Sicherheitsrichtlilinien das Gefahrenpotential der Anfrage ermitteln und gegebenenfalls notwendige Gegenmaßnahmen einleiten. 15

16 Intrusion Prevention Systeme Unter dieser Kategorie sollen hier stellvertretend alle IDS zusammengefasst werden, die bei erkannten Angriffen aktiv und in Echtzeit in das Neztwerk eingreifen 6. Ihr Handlungsspielraum ist von Hersteller zu Hersteller sehr verschieden, er umfasst u.a. die automatische Rekonfiguration von Firewalls, das Ausschließen einzelner, potentiell gefährlicher Nutzer, oder auch die direkte Interaktion mit dem Angreifer 7 [Str03a, Str03b, Aru06] Weitere Unterscheidungsmerkmale von IDS Die in Kapitel beschriebenen Typen von Systemen werden zusätzlich anhand der Arbeitsweise ihrer Angriffserkennung, sowie ihrer Architektur unterschieden [Gö03b, Neu05]. Signaturbasierte IDS suchen in den gesammelten Daten (Auditdaten) nach typischen Angriffsmustern. Typische Suchstrategien sind das Pattern Matching oder die Protokollanalyse. Obwohl diese Art der Angriffserkennung eine sehr hohe Treffergenauigkeit hat, ist sie dennoch permanent mit dem Problem konfrontiert, dass ihre Signaturen immer aktuell gehalten werden müssen, um die immer wieder neu entwickelten Angriffsmethoden sicher zu erkennen. Anomalien-erkennende IDS verfolgen eine andere Strategie. Mit logischen oder statistischen Ansätzen wird ein Modell entwickelt, welches das normale Verhalten des Systems abbildet. Auf diese Weise können auch bisher unbekannte Angriffe entdeckt werden, der Nachteil besteht jedoch in der hohen Fehlerrate dieser Erkennungsstrategie. Abschließend soll die Granularität eines IDS betrachtet werden. Bei monolithischen IDS sind alle Komponenten (siehe Kap ) in einem einzigen Programm / System untergebracht. Ihre Sichtweise ist auf das angeschlossene Netzwerksegment beschränkt. Verteilte IDS bestehen aus mehreren Modulen, die Daten an verschiedenen Netzwerkknoten sammeln und verarbeiten. Diese geografische Verteilung ermöglicht eine umfassendere Sicht auf die Geschehnisse im zu überwachenden IT-System. Eine genauere Betrachtung verteilter IDS findet in Abschnitt statt. Das in dieser Arbeit verwendete Bro ist ein signaturbasiertes, Networkbased Intrusion Detection System. Bro kann sowohl monolithisch betrieben werden, als auch verteilt, indem mehrere Instanzen im Netzwerk installiert werden, welche Nachrichten miteinander austauschen. 6 Hier sind ebenso Intrusion Detection & Response Systeme und Intrusion Protection Systeme etc. gemeint. 7 In [Str03a] wird ein Verfahren beschrieben, bei dem einem potentiellen Angreifer ein System mit Schwachstellen vorgetäuscht wird. Nutzt er diese Schwachstelle aus, wird er als Angreifer enttarnt und sofort gesperrt. Der Vorteil dieser Variante gegenüber Honeypot-Systemen ist, dass das verwundbare System nur vorgetäuscht wird und nicht real existiert. 16

17 2.5.3 Architektur eines IDS Intrusion Detection Systeme besitzen im Allgemeinen die in 1 dargestellten vier Module: Einen oder mehrere Sensoren, welche Daten sammeln und daraus Ereignisse generieren. Je nach System werden dabei die Netzwerkschnittstelle oder systeminterne Funktionen abgehört. Einen Monitor zur Datenanalyse, welcher diese Ereignisse zusammenfasst, mit einem vorliegendem Verhaltensmodell vergleicht und bei Hinweisen auf einen Angriff entsprechende Nachrichten generiert. Die Resolver entscheiden anhand vorliegender Sicherheitsrichtlinien, in welcher Form die Ereignisse dargestellt werden. Ihre Palette reicht vom ignorieren der Nachricht über einen Eintrag in die Protokolldatei bis hin zur Benachrichtigung des Admins. Bei Intrusion Detection & Response Systemen kann auch eine Rekonfiguration der vorhandenen Sicherheitsmechnanismen erfolgen. Selbstverständlich darf ein Controller zur Steuerung, Überwachung und Wartung des IDS nicht fehlen. Abbildung 1: Architektur eines Intrusion Detection Systems IDS für WLAN Die in kabelgebundenen Netzen eingesetzten Intrusion Detection Systeme haben sich seit Jahren bewährt. In den folgenden Abschnitten wird gezeigt, weshalb diese bestehenden Systeme für den Einsatz in kabellosen Netzwerken an- 17

18 gepasst oder gar komplett neu entwickelt werden müssen, um die veränderten und neuartigen Bedrohungen effektiv erkennen zu können. Das Übertragungsmedium Luft Das neue Übertragungsmedium Luft bringt einige Probelme mit sich, die in kabelgebundenen Netzwerken nicht vorhanden sind. Zu der in Kapitel beschriebenen vielfältigen Nutzung des ISM-Band 2.4 GHz kommt hinzu, dass ein WLAN nicht ohne weiteres in eindeutige Netzwerksegmente untergliedert werden kann. Es müssen simultan alle 13 Kanäle 8 überwacht werden. Eine zusätzliche Herausforderung stellt die flächendeckende Überwachnug des kompletten Luftraums dar, da an jeder nicht überwachten Stelle ein Angreifer unbemerkt in das System eindringen könnte. Einige Hersteller versuchen dieses Problem mit spezieller Hardware zu lösen, indem das IDS nicht als overlay über der IT- Infrastruktur liegt, sondern die Sensoren direkt in die Access Points integriert werden, sodass ein AP sowohl für den normalen Netzwerkverkehr, als auch für die Überwachung seines eigenen Segmentes zuständig ist [air04]. Die technischen Aspekte der mobilen Endgeräte dürfen nicht missachtet werden. Im Gegensatz zum LAN sind die Endgeräte der Clients nicht immer bekannt. Es besteht daher das Risiko, dass ein Angreifer modifizierte Hardware / Treiber einsetzt, die sich nicht standardkonform zu IEEE verhält. Ein weiteres Problem stellen die Angriffe auf den Schichten 1 (Bitübertragungsschicht) und 2 (Sicherungsschicht) des OSI-Referenzmodells dar (siehe 2.4.1). Im LAN werden diese Schichten durch die Ummantelung der Kabel häufig als ausreichend geschützt betrachtet, im WLAN sollte anfangs Wired Equivalent Privacy, besser bekannt als WEP, diese Schutzmechanismen gewährleisten. WEP ist mittlerweile vollständig gebrochen (siehe 2.2.3) und für die nachfolgenden Standards WPA und WPA2 existieren ebenfalls erste Angriffe [Ahl04, Neu05]. Aus diesen speziellen Gegebenheiten resultieren besondere Anforderungen an ein Wireless IDS. Aufgaben eines Wireless IDS Aus den in Kapitel 2 beschriebenen grundlegenden Schwachstellen (2.2), Risiken (2.3) und Angriffen (2.4) in WLANs ergeben sich zusammenfassend die folgenden Aufgaben eines Wireless IDS: Erkennung WLAN-typischer Risiken: Die fehlerhafte Konfiguration von WLAN-Komponenten wie Access Points oder Clients (siehe 2.3.1). 8 Die Anzahl ist länderspezifisch und hängt von der jeweiligen Regulierungsbehörde ab. 18

19 Der Anschluss von unautorisierter Hardware wie privaten Laptops oder PDAs (siehe 2.3.2). Das Auftreten unerwünschter Verbindungen wie ad-hoc-netze der Clients untereinander (siehe 2.3.3). Überwachung der Luftschnitstelle, d.h. alle möglichen Kanäle des genutzten Frequenzbandes. Für einen umfassenden Schutz sollte sich das IDS nicht nur auf die Protokollebene IEEE beschränken, sondern mit Hilfe von RF-Scannern auch Komplikationen mit anderen Geräten wie Haushalts-Mikrowellen erkennen (siehe 2.3.3). Gemeint ist also eine Überwachung von Schicht 1 (Bitübertragungsschicht) an aufwärts. Erkennung von Angriffen Die Erkennung von Angriffen ist selbstverständlich die primäre Aufgabe eines jeden IDS. Zusätzlich zu den in kabelgebundenen Netzen bekannten Angriffen müssen alle WLAN-spezifischen Angriffe erkannt werden (siehe 2.4). Dazu zählen neben dem Mitschneiden von Nachrichten (sniffing, eavesdropping) und Angriffen auf die Verschlüsselung (WEP, WPA etc.) auch diese bereits näher untersuchten Techniken: Masquerading - Der Angreifer täuscht eine andere Idendität vor (siehe 2.4.4). Denial-of-Service-Angriffe - Ein Eindringling stört die Verfügbarkeit des Netzes, indem er gezielt einzelne Nutzer oder Zugangspunkte angreift (siehe 2.4.5). Man-In-The-Middle-Angriffe - Der Angreifer schleust sich unbemerkt in die Kommunikation zwischen zwei Netzteilnehmern ein (siehe 2.4.6). Eine zusätzliche Erkennung der Angriffsvorbereitung (network discovery) bietet, sinnvoll eingesetzt, einen erweiterten Schutz [Aru06]. Auf die grundlegenden Features eines IDS wie die Protokollierung der erkannten Angriffe und eine Benachrichtigung des Administrators in Echtzeit soll an dieser Stelle nicht weiter eingegangen werden, diese Mechanismen sollten in jedem vernünftigen IDS integriert sein Motivation für ein Verteiltes Wireless IDS Um die in Abschnitt geforderte simultane Überwachung aller Kanäle zu ermöglichen, bietet es sich an, mehrere IDS miteinander zu vernetzen. Dabei können zwei verschiedene Strategien verfolgt werden. Zum Einen kann eine zentrale Manager-Komponente die Daten von mehreren, im System verteilten Sensoren verarbeiten, zum Anderen können mehrere Network Nodebased Intrusion Detection Systeme miteinander gekoppelt werden. 19

20 Zentraler Manager mit verteilten Sensoren Diese Architektur eignet sich besonders für den Betrieb in einer Umgebung mit fester Infrastruktur. Öffentliche HotSpots oder firmeninterne WLANs zeichnen sich durch eine vorab bekannte Netzwerkarchitektur mit einer festen Anzahl von Access Points aus, deren Hardware und Standort dem Administrator bekannt sind. Mit diesem Vorwissen werden an geeigneten Positionen die Sensoren installiert, welche ihre Daten an einen zentralen Manager schicken. Neben der Überwachung der Luftschnittstelle auf Protokollebene können zusätzliche Geräte eingesetzt werden, die den verwendeten Frequenzbereich nach Störsignalen scannen, sowie Sensoren auf Betriebssystem-Ebene, welche die Protokoll- Dateien analysieren und z.b. fehlgeschlagene Anmeldeversuche erkennen. Vorteile gegenüber einzelnen IDS: Alle gesammelten Sensor-Daten müssen nur an einem zentralen Punkt verarbeitet und archiviert werden. Auf diese Weise werden die Betriebskosten minimiert. Zur Überwachung und Wartung des IDS kann eine einzige Person eingesetzt werden. Mit dem Wissen über den genauen geografischen Standort der Sensoren kann ein Angreifer anhand seiner Signalstärke in Echtzeit lokalisiert und gegebenenfalls vom Sicherheitspersonal festgenommen werden. Beim Einsatz von einzelnen IDS könnte nur das Vorhandensein des Angreifers, nicht aber seine Position bestimmt werden. Dank der gleichzeitigen Überwachung auf Betriebssystem und Netzwerkebene lässt sich die Anzahl der false positives genannten Fehlalarme reduzieren. Beispiel: Ein Netzwerk-Sensor stellt fest, dass ein Nutzer X wiederholt versucht, sich auf einem System anzumelden. Ein syslog-sensor meldet dem Manager, dass alle Anmeldeversuche eines Nutzers Y fehlschlagen. Der Manager führt diese Informationen zusammen, stellt fest, dass X = Y ist und entscheidet auf Grund geltender Sicherheitsrichtlinien, diesen erfolglosen Angriff zu ignorieren. Bei der Analyse einens Angriffs im Nachhinein entfällt das Zusammenführen der verschiedenen IDS-Logfiles Um einen reibungslosen Betrieb des IDS zu gewährleisten, muss die Kommunikations zwischen den Sensoren und dem Manager in Echtzeit stattfinden, sowie gegen etwaige Angriffe resistent sein. Mobile selbstschützende Systeme Zum Schutz mobiler Systeme wie Laptops oder PDAs wird ein anderer Ansatz verfolgt. Die das Gerät umgebende Netzarchitektur ändert sich fortlaufend, 20

21 weshalb eine Sicherheitsarchitektur mit zentralem Manager und verteilten Sensoren nur schwer zu realisieren ist. Eine Möglichkeit besteht darin, auf jedem Knoten im Netzwerk auch auf jedem mobilen Gerät, ein IDS zu installieren. Diese IDS kommunizieren miteinander und informieren sich auf diese Weise gegenseitig über erkannte Angriffe. Um den einzelnen Systemen eine umfassendere Sicht auf ihre Umgebung zu ermöglichen, wird eine Kooperation dieser Geräte angestrebt. Dieses Verfahren ist in [Gro05] ausführlich beschrieben. Vorteile gegenüber der Architektur mit zentralem Manager Ein Wireless IDS mit zentralem Manager und verteilten Sensoren ist entweder ein dediziertes System mit eigener Infrastruktur, oder auf jedem festinstallierten AP eines bereits bestehenden Netzwerkes integriert. In beiden Architekturen sind die mobilen Endgeräte nicht mit eingebunden. Dieser Nachteil birgt Sicherheitsrisiken, welche durch das folgende Szenario verdeutlicht werden: Abbildung 2: Möglicher Angriff von Eve auf Bob trotz des Einsatzes eines zentralen IDS-Manager In einem Firmengebäude ist Bob ein Benutzer, Charlie und Dave sind ihm bekannte APs der Firma mit IDS. Bob ist autorisiert, sich mit den APs zu verbinden. Charlie sendet auf Kanal 1, Dave auf Kanal 6. Bob befindet sich nur in Reichweite von Charlie, Dave ist zu weit entfernt. Die Angreiferin Eve platziert ihren Laptop in der Nähe des Opfers Bob. Sie konfiguriert ihn als AP Dave 2 mit den Daten des realen AP Dave und stellt die Sendeleistung so ein, dass Charlie ihr Signal nicht empfangen kann. Wenn Bob nun eine Verbindung aufbauen möchte, wird der gefälschte AP Dave 2 mit einem stärkeren Signal als Charlie empfangen und Bob verbindet sich mit der Angreiferin. Charlie kann die Verbindung von Bob zu Eve nur indirekt sehen, für ihn scheint sich Bob mit dem realen Dave verbunden zu haben. Wenn Bob seine Sendeleistung automatisch anpasst, so kann seine Verbindung zu Eve von Charlie nicht bemerkt werden, obwohl das IDS der Firma den Luftraum lückenlos überwacht. 21

22 Dieses Angriffsszenario ist vermeidbar, wenn Bob ebenfalls ein IDS installiert hat, welches mit dem IDS der Firma interagiert. Beim Verbindungsaufbau zu einem AP baut Bob gleichzeitig eine Verbindung zum IDS auf und verifiziert die Verbindung, indem das firmeneigene IDS überprüft, ob der AP Charlie bzw. Dave tatsächlich eine aktive Verbindung zu Bob unterhält. Überprüfungen dieser Art sind selbstverständlich nicht auf den Verbindungsaufbau beschränkt, sie können unter anderem für alle Arten von Management-Frames benutzt werden. Im Kapitel 4.1 wird diese Kooperation noch einmal genauer untersucht aktuelle Systeme Wireless Intrusion Detection Systeme sind sowohl von kommerziellen Anbietern erhältlich, sowie auch als freie open-source Tools. Die kostenlosen Lösungen haben oft nur einen geringen Funktionsumfang, sie beschränken sich auf die Erkennung nicht autorisierter Hardware sowie einiger typischer DoS-Angriffe [Loc05]. Ihnen gegenüber stehen die teils sehr mächtigen, professionellen Lösungen der Intrusion Protection Systeme, welche neben dem Erkennen der Angriffe und Gefahren auch Maßnahmen zur Gegenwehr bereithalten. Laut Herstellerangaben bieten sie einen umfassenden Schutz [Air05, Aru06, Net06]. Ein aktueller Vergleich einiger IPS ist in [Bul05] zu finden, allgemeine Übersichten in [Com03b, Mä04]. Das um die wireless Komponente erweitere IDS Bro kann im Funktionsumfang bereits jetzt mit anderen frei erhältlichen Tools mithalten, im nächsten Kapitel wird untersucht, in wieweit sich die Erkennungsmöglichkeiten erweitern lassen, wenn man mehrere verteilte Instanzen miteinander kommunizieren lässt. 22

23 3 Analyse Zunächst wird das dieser Arbeit zugrundeliegende Intrusion Detection System Bro analysiert. Neben dem grundlegenden Aufbau wird auf die Mechanismen zur Erstellung und Verarbeitung von Ereignissen eingegangen. Zusätzlich werden die in [Neu05] entwickelten Mechanismen zur Erkennung von Angriffen im WLAN mit Bro erläutert. Anschließend kommen eigene Gedanken zum Konzept einer Kommunikationsschnittstelle zum Tragen. Hierbei werden ebenso die bereits existierenden Konzepte der Intrusion Detection Working Group vorgestellt, welche sich mit dem standardisierten Austausch von Nachrichten zwischen verschiedenen IDS beschäftigt. Abschließend wird das in Bro bereits integrierte Kommunikationsinterface untersucht. Es werden sowohl die vom Nutzer konfigurierbaren Abläufe in den Policy Skripts, als auch die im Kern enthaltenen Methoden genau vorgestellt. Aus den gewonnenen Erkenntnissen wird in Kapitel 4 ein Verfahren vorgestellt, mit dem sich mehrere Instanzen von Bro miteinander koppeln lassen, um kooperativ Angriffe zu erkennen. 3.1 Das IDS Bro Bro ist ein auf Unix basierendes, open-source Intrusion Detection System. Um Angriffe auf ein System in Echtzeit zu erkennen, untersucht es den Netzwerkverkehr auf den Schichten 3 bis 7 des OSI-Referenzmodells. Hierzu wird es an das zu schützende Netzwerk mit einer Network Trap angeschlossen, welche an einem zentralen Punkt dieses Netzes den gesamten Paketstrom dupliziert und an das von Bro überwachte Netzwerk-Interface weiterleitet. Das IDS ist für andere Knoten im Netz nicht sichtbar und kann nur angesprochen werden, wenn es zusätzlich über ein weiteres Interface in das IT-System integriert ist. Eine Grundkonzept von Bro ist die eindeutige Trennung der Methoden zur Generierung von allgemeinen Ereignissen und der Definition von Sicherheitsrichtlinien, welche der Nutzer an seine Bedürfnisse am eigenen Standort anpassen kann. Die bei der Analyse des Netzwerkverkehrs erzeugten Ereignisse sind daher neutral, sie werden erst im nächsten Schritt anhand einer nutzerspezifischen Security Policy bewertet. Zum Erstellen der Sicherheitsrichtlinien haben die Entwickler von Bro eine eigene Skriptsprache entwickelt. In dieser werden spezielle Event Handler definiert, um die auf Netzwerkebene generierten Ereignisse zu verarbeiten. Einem Administrator stehen somit vielfältige Möglichkeiten wie die Protokollierung der auftretenden Aktivitäten oder das Auslösen selbst definierter Ereignisse zur Verfügung. 23

24 Bro ist ursprünglich für den Einsatz in Breitbandnetzen entwickelt. Im Rahmen einer Diplomarbeit wurde ein Patch entwickelt, der die Analyse von WLAN- Frames nach IEEE ermöglicht. Die in jener Arbeit vorgestellte Analyse des IDS sowie die Implementierung der neuen Funktionalität wird an dieser Stelle zusammengefasst. Dem geneigten Leser seien die Kapitel 3 und 4 in [Neu05], sowie das Benutzerhandbuch [PRT04] und das Referenzhandbuch [PT04] von Bro empfohlen. Die folgenden Abschnitte beschreiben das bereits gepatchte Bro in der Version Architektur von Bro Die grundlegende Architektur von Bro ist in Abbildung 3 veranschaulicht. Das IDS besteht im Kern aus den Komponenten Network Analysis, Event Engine und Policy Script Interpreter. Darauf setzen die Policy Skripts des Policy Layers auf, welche die Sicherheitsrichtlinien des Standorts enthalten. Abbildung 3: Die Architektur von Bro [Neu05]. Beim Start des Systems werden alle zuvor definierten Event Handler in der Event Engine registriert. Sobald bestimmte Netzwerkaktivitäten zu verzeichnen sind, generiert der Network Analysis genannte Sensor hieraus Ereignisse und leitet sie zur genaueren Untersuchung an die Event Engine weiter. Zum Analysieren des Traffic werden zwei Strategien benutzt. Mit Hilfe von Protocol Analyzern werden die auf verschiedenen Schichten eingesetzen Protokolle wie TCP, UDP, ICMP und verschiedene Protokolle der Anwendungsschicht untersucht. Im Gegensatz dazu untersucht die Signature Engine den Paketstrom nach speziellen Signaturen, die auf Angriffe hinweisen. 24

25 Die Event Engine ruft die entsprechenden Event Handler zur weiteren Verarbeitung auf. Während der Bearbeitung eines Ereignisses werden neue Ereignisse zunächst in einer Warteschlange gesammelt. Der Policy Script Interpreter bildet die in den Skripten enthaltenen Anweisungen auf entsprechende C++ Klassen ab, welche ihrerseits die Sicherheitsrichtlinien in die Tat umsetzen und z.b. einen Eintrag ins Logfile schreiben. Die Komponente Peer Communication ist eine Schnittestelle, mit der sich eine Kommunikation zwischen mehreren Instanzen von Bro realisieren lässt. Sie wird ebenfalls von der Programmierschnittstelle brocolli benutzt, welche die Kommunikation zwischen Bro und externen Programmen ermöglicht. Eine ausführliche Beschreibung der inter-bro Kommunikation folgt in Abschnitt Basiskonzepte von Bro Generierung von Ereignissen Um auf den Netzwerkverkehr zuzugreifen, bedient sich Bro der C-Bibliothek libpcap. Diese greift über einen Paketfilter im Kernel auf den Treiber der Netzwerkkarte zu. Alternativ kann auch eine Datei als Paketquelle zur Offline- Analyse benutzt werden. Im Kern von Bro bildet die Klasse PktSrc die Schnittstelle zu libpcap. Sie nimmt die Pakete der jeweiligen Netzwerkverbindungen entgegen und übergibt IEEE Pakete an die Klasse NetSessions, WLAN-Frames werden an die Klasse WlanSessions weitergereicht. In NetSessions werden die Protokoll-Header der OSI-Schichten 1 und 2 entfernt und der IP-Header auf das verwendete Transportprotokoll untersucht. Anschließend werden die Pakete zu bestehenden Kommunikationsbeziehungen zugeordnet und schließlich in Abhängigkeit des Transportprotokolls in Unterklassen der Klasse Connection verarbeitet. Hier erfolgt der Hauptteil der Verarbeitung des Datenstroms die protokollabhängige Analyse der Pakete. In der Klasse WlanSessions werden zunächst die Header der Frames untersucht. Dabei wird als erstes festgestellt, um welchen Frame-Typ es sich handelt. Möglich sind Control-, Management und Data-Frame. Control-Frames dienen der Zugriffssteuerung auf das Übertragungsmedium Luft, Managament-Frames regeln den Ablauf der Kommunikation zwischen zwei Stationen, mit ihnen werden neue Verbindungen auf- und abgebaut oder fortgeführt. Die Übertragung von Nutzdaten erfolgt schließlich in den Data-Frames. Zu den weiteren Aufgaben der Klasse gehört das Zerlegen der Frame-Header in seine Bestandteile und die Analyse des Frame-Body der Management-Frames, da dieser wichtige Informationen für die Erkennung von Angriffen beinhaltet. Anschließend werden entsprechende Ereignisse generiert. 25

26 Verarbeitung von Ereignissen Die Grundvoraussetzung für die Verarbeitung von Ereignissen bilden die Event Handler. Sie enthalten Anweisungen, welche bei ihrem Aufruf durch ein Ereignis ausgeführt werden. In der Installation von Bro sind bereits Handler für typische Erkennungsaufgaben enthalten. Diese werden vom Nutzer an die spezifischen Gegebenheiten am Standort angepasst, sowie bei Bedarf um eigene Handler ergänzt. Jedem Ereignis kann eine beliebige Anzahl an Event Handlern zugeordnet werden. Abschließend legt der Nutzer in einer speziellen Konfigurationsdatei fest, welche der vorhandenen Handler beim Start des Systems geladen werden sollen. Die Verarbeitung der Ereignisse ist in zwei Phasen unterteilt. Bro Start Zuerst werden alle aktivierten Policy Scripte eingelesen. Anschließend werden die in den Skripten enthaltenen Event Handler in der Event Registry erfasst. Dieses Verzeichnis ermöglicht im folgenden Verlauf einen schnellen Zugriff auf den entsprechenden Handler. Wie bereits in Abschnitt erwähnt, liest der Policy Script Interpreter die Skripte ein, und bildet sie auf entsprechende C++ Klassen ab. Event Generation für jedes Ereignis Wird zur Laufzeit vom Sensor ein bestimmtes Ereignis generiert, so werden die für die Verarbeitung zuständigen Event Handler in der Event Registry nachgeschlagen und den Ereignis zugewiesen. Danach wird das Ereignis eine Warteschlange eingereiht und verweilt dort, bis es vom Event Manager aufgerufen wird. Er ruft alle zugewiesenen Event Handler sequentiell auf und übergibt sie dem Policy Script Interpreter, der die in den Handlern enthaltenen Anweisungen ausführt. Die eben beschriebenen Abläufe werden in Abbildung 4 veranschaulicht. Abbildung 4: Die Ereignisverarbeitung von Bro [Neu05]. 26

27 Definition und Modifikation von Policies Nach der Installation von Bro befinden sich die mitgelieferten Policy Skripte im Unterverzeichnis policy. Beim Start von Bro wird zunächst die Datei bro.init eingelesen, welche über spezielle include-befehle weitere benötigte Standard- Skripte lädt. Zusätzlich werden die Dateien host.bro und local.site.bro aus dem Verzeichnis site geladen. In diesen beiden Dateien kann der Nutzer die Sicherheitspolitik an seine Bedürfnisse anpassen, indem er etwa zusätzliche Policy Skripte lädt und über bereitgestellte Variablen das Verhalten der Standard-Skripte beeinflusst. Im folgenden Abschnitt wird der Zusammenhang zwischen Policy-Skripten und Bro erläutert. Interpretation der Policies Der Policy Interpreter stellt das Bindeglied zwischen der vom Anwender beeinflussbaren Sicherheitspolitik und dem Kern von Bro dar. Er beinhaltet die zur Definition der verwendeten Skriptsprache nötige Grammatik mit den entsprechenden Terminalsymbolen, sowie einen Parser und einen Interpreter. Mit Hilfe dieser Werkzeuge werden die in den Policy Skripten enthaltenen Datentypen, Werte, Bezeichner und Attribute auf ihnen entsprechende C++- Klassen abgebildet. Zudem werden Klassen für die Darstellung von Ausdrücken, Anweisungen, Funktionen und Event Hanndlern bereitgestellt. Abschließend steht die Klasse Scope zur Darstellung der Gültigkeitsbereiche der eben genannten Komponenten zur Verfügung. Analog zu den zwei Phasen bei der Ereignisverarbeitung ist in Abbildung 5 die Interpretation der Policy Skripte dargestellt. Bro Start Beim Einlesen der aktivierten Policy-Skripte werden für alle Definitionen von Typen, Variablen und Funktionen Objekte der ihnen entsprechenden Klassen erzeugt und entsprechend ihrem Gültigkeitsbereich gespeichert. Die Event Handler registriert der Interpreter in einer Instanz der Klasse EventRegistry. Laufzeit Wird ein Event Handler aufgerufen, so werden die enthaltenen Anweisungen und Funktionsaufrufe durch den Interpreter ausgeführt. Er benutzt den Aufruf-Stack ein Objekt der Klasse Frame, modifiziert den Zustand der Objekte im Scope. 27

28 Abbildung 5: Die Policy-Interpretation von Bro [Neu05] Erkennung von Angriffen im WLAN Nachdem die allgemeine Funktionalität von Bro nun bekannt ist, folgt eine Einführung in die spezielle Aufgabe, Angriffe auf IEEE Netze zu erkennen. Ein erster Unterschied zu Angriffen auf kabelgebundene Netzwerke ist bereits aus den Sektionen und bekannt: Im WLAN sind besonders die Schichten 1 und 2 des OSI-Referenzmodells gefährdet. Aus diesem Grund wurde in [Neu05] die neue Policy wireless.bro erstellt. Die Policy ist in die Bereiche Rogue AP Detection, Connection Handling, Flood Detection, Broadcast DoS Detection und IEEE Management Events gegliedert. Darüberhinaus dienen mehrere allgemeine Funktionen zur Initialisierung und Erkennung der Frame-Typen. Für lokale Anpassungen stehen die Variablen trusted ap, flooding timeout und known ap thresh zur Verfügung, auf die später im Detail eingegangen wird. Zur Benutzung der Policy wird eine WLAN-Karte im Monitor-Mode benötigt, welche alle empfangenen Frames über den Treiber und Paketfilter im Kernel und die Bibliothek libpcap an Bro weiterleitet. Im folgenden werden die einzelnen Bereiche von wireless.bro genauer unter die Lupe genommen. Konfiguration und Initialisierung Zuerst sollten die Variablen trusted ap in der Datei host.bro belegt werden. trusted ap ist ein Set von Access Points, in das alle dem Nutzer als vertrauenswürdig bekannten APs eingetragen werden, jeweils mit ihrer MAC-Adresse, 28

29 dem Netzwerknamen SSID und dem eingestellten Kanal. Erfolgt kein Eintrag, so betrachtet Bro im weiteren Verlauf alle APs in Reichweite als potentiell gefährlich. Beim Start von Bro werden automatisch die Event Handler für das Ereignis bro init aufgerufen. Im hier betrachteten Fall werden die bereits in trusted ap gespeicherten Access Points zusätzlich in die Tabellen trusted ap ssid und trusted ap sa übernommen. Dies ermöglicht im weiteren Programmverlauf einen deutlich schnelleren Zugriff. Ausserdem wird das Event wlan check flooding aufgerufen. Flood Detection Zur Erkennung von Flooding-Angriffen wird die Häufigkeit der Management- Frames in einem Zeitfenster betrachtet. Die Dauer dieses Zeitfensters ist in der Variablen flooding timeout angegeben, die Schwellwerte zum Auslösen eines Alarms in der Tabelle flood thresholds. In der Standardkonfiguration wird somit fortlaufend alle 10 Sekunden die Zahl der empfangenen Frames eines Typs mit dem jeweiligen Schwellwert verglichen. Hierfür ist das Event wlan check flooding zuständig. Bei einem erkannten Angriff wird eine entsprechende Meldung auf der Konsole ausgegeben. IEEE Management Events Jedes von der Netzwerkkarte empfangene Management-Frame löst ein korrespondierends Event aus. Auf der Grundlage dieser Events ist die komplette Erkennung von Angriffen aufgebaut. Die Pakete werden vorhandenen Verbindungen zugeordnet und in flood counters gezählt. wlan beacon In einem Beacon-Frame teilt ein AP allen Stationen in seiner Reichweite unter anderem seinen Netzwerknamen und Kanal mit. Das Event wird zur Erkennung neuer Access Points und Flooding-Angriffen benutzt. wlan probe resp Die Antwort eines APs, wenn eine Station Informationen vom AP anfordert. Das Event wird ebenfalls zur Erkennung neuer Access Points und Flooding-Angriffen benutzt. wlan auth Authenication-Frames werden zwischen zwei Stationen bei der Authentfizierung ausgetauscht. Ihr Auftreten wird in die Erkennung von Flooding-Angriffen einbezogen. wlan assoc req Eine Station sendet ein Association Request an den AP, wenn sie den Aufbau einer Verbindung wünscht. Das Event wird zur Erkennung von Flooding-Angriffen benutzt. wlan assoc resp Dies ist die Antwort eines AP auf die Verbindungsanfrage des Clients. Dieses Event löst das Event wlan new connection aus, welches die bekannten Verbindungen managt. 29

30 wlan reassoc req In Analogie zum Association Request sendet eine Station ein Re-Association Request, wenn sie erneut eine Verbindung zu einem AP wünscht, zu dem sie bereits verbunden war. Das Event wird ebenfalls zur Erkennung von Flooding-Angriffen benutzt. wlan reassoc resp Genauso verhält es sich beim Re-Association Response. Dies ist die Antwort des AP auf ein empfangenes Re-Association Request. Daher wird gleichfalls das Event wlan new connection aufgerufen. wlan disassoc, wlan deauth Disassociation- und Deauthentication Frames können immer von beiden Partner der Verbindung gesendet werden. Im Unterschied zu den meisten anderen Management-Frames stellen sie keine Anfrage an den Partner dar, sondern lediglich eine Information über das Ende der aktiven Verbindung. Der AP kann hier sogar alle mit ihm verbundenen Stationen auf einmal trennen, indem er als Empfänger die Broadcastadresse FF:FF:FF:FF:FF:FF angibt. Die beiden Events lösen beim Vorhandensein einer Broadcast-Adresse die entsprechenden Events wlan broadcast disassoc bzw. wlan broadcast deauth aus, andernfalls wlan end connection. Selbstverständlich werden sie ebenfalls zur Erkennung von Flooding-Angriffen herbeigezogen. Rogue AP Detection Das Event wlan new access point ist der Erkennung nicht autorisierter Access Points gewidmet. Es wird bei jedem empfangenen Frame vom Typ Beacon oder Probe Response ausgelöst. Alle bekannten APs werden im Set known ap set gespeichert, unabhängig von ihrer Klassifizierung als vertrauenswürdig oder potentiell gefährlich. Sollte die Anzahl bekannter APs einen Schwellwert überschreiten, so wird eine Warnung ausgegeben, das ein potentieller Angriff mit dem Tool FakeAP vorliegt, welches massenhaft gefälschte Beacon-Frames mit wechselnden Absenderadressen verschickt und es so autorisierten Nutzer erschwert, sich mit einen realen AP zu verbinden. Nach dieser initialen Prüfung wird der neue AP mit den Kenndaten der vertrauenswürdigen APs verglichen. Stimmen MAC-Adresse, Kanal und SSID überein, handelt es sich um einen legalen AP. Sollte mindestens einer der Parameter verschieden sein, wurde ein Rogue AP erkannt. Je nach Einordnung wird er anschließend in einer Tabelle gespeichert und eine entsprechende Meldung ausgegeben. Beim Rogue AP wird zusätzlich noch zwischen MAC-Spoofing, SSID-Spoofing oder einer Kombination der Beiden unterschieden. Connection Handling Bei jedem Auf- und Abbau sowie Wiederaufbau einer Verbindung, werden die Events wlan new connection und wlan end connection aufgerufen. Sie speichern in der Tabelle connections jeweils die MAC-Adressen der Kommunikationspartner und den verwendeten Kanal. 30

31 Wird eine neue Verbindung aufgebaut, so wird diese in connections eingetragen und anhand der bereits getätigten Klassifizierung des AP eine Meldung ausgegeben, ob sich die Station mit einem Trusted, Rogue oder unbekanntem 9 AP verbunden hat. Ist für die Station bereits ein Eintrag in der Tabelle connections vorhanden, so handelt es sich um ein re-connect. In diesem Fall muss zusätzlich geprüft werden, ob es sich bei der neuen Verbindung um den selben AP und Kanal handelt, wie in der bereits bekannten Verbindung in connections. Sollten die Werte differieren, so scheint sich die Station gleichzeitig mit zwei verschiedenen Access Points zu verbinden. Diese Beobachtung impliziert das Vorhandensein eines Man-in-the-Middle Angriffs und wird entsprechend auf dem Terminal ausgegeben! Broadcast DoS Detection Abschließend seien die Events wlan broadcast disassoc / wlan broadcast deauth beschrieben. Sie werden genau dann aufgerufen, wenn Disassociation- und Deauthentication Frames mit Broadcast-Adressen als Zieladresse empfangen werden. Diese werden von Angreifern mit gefälschten Absender-Adressen verschickt, um so autorisierten Nutzern den Zugang zum WLAN erschweren oder gar vollständig zu unterbinden. Beide Events geben entsprechende Alarm-Meldungen aus. Auf die Analyse von Bro folgen im nächsten Abschnitt Überlegungen, wie eine Kommunikationsschnittstelle zur Kopplung mehrerer Instanzen von Bro am besten zu realisieren ist. In Abbildung 6, sind die Abläufe der Policy nocheinmal veranschaulicht. Eine Vergrößerung der Abbildung befindet sich im Anhang auf Seite 77. Abbildung 6: Der Informationsfluss in wireless.bro. 9 Dieser Fall tritt ein, wenn der AP erst direkt vor dem Senden eines (Re-)Association Response in Reichweite des eigenen Systems gekommen ist, sodass er noch nicht analysiert wurde. 31

32 3.2 Design der Kommunikationsschnittstelle Das Ziel dieser Arbeit ist, durch kooperierende Geräte die Erkennung von Angriffen zu verbessern. Im vorangegangen Abschnitt wurden bereits die Erkennungsmöglichkeiten eines einzelnen Systems vorgestellt, nun stellt sich die Frage, in welcher Weise sich die Erkennungsleistung einer einzelnen Station verbessern lässt, wenn sie mit anderen Stationen kommuniziert. Es sind zwei grundlegende Entscheidungen für das Design zu treffen. Die erste bezieht sich auf den Inhalt der Nachrichten und spezifiziert, welche Events untereinander ausgetauscht werden sollen. Die zweite ist die Auswahl einer geeigneten Art der Nachrichtenübertragung Welche Events sollen ausgetauscht werden? Die einfachste Möglichkeit scheint zunächst, alle lokal ausgelösten Events an die Kommunikationspartner zu senden. Diese Variante entspricht dem Verhalten eines Sensors, der alles an den zentralen Manager weiterleitet. In der Praxis ist dieser Ansatz jedoch probematisch, der entstehende Traffik steht in keinem Verhältnis zum Nutzen. So würden unter anderem alle Events vom Typ wlan beacon ausgetauscht - bei einem Beacon-Interval von 100 Millisekunden sind das pro Sekunde bereits 10 auszutauschende Events pro AP und Client. Desweiteren geht diese Variante nicht auf die lokalen Sicherheitsrichtlinien der Stationen ein. Wie in Abschnitt beschrieben, legt jeder Nutzer vor dem Start fest, welche Policy Skripte und somit welche Event Handler geladen werden. Betrachtet man zwei Kommunikationspartner Alice und Bob, wobei Alice alle in Bro enthaltenen Skripte lädt, Bob hingegen nur wireless.bro, so wird klar, das Alice das Netz unnötig mit Nachrichten an Bob belastet. Sie informiert Bob über alle auftretenden Events, für Bob sind jedoch nur die in wireless.bro enthaltenen WLAN-Events interessant, alle weiteren werden verworfen. Aus dem Szenario wird deutlich, das es sinnvoller ist, nur ausgewählte Events an den Partner zu übertragen. Events als abonnierte Liste Ein anderer Ansatz ist somit das Erstellen einer abonnierten Liste. Alice und Bob tauschen beim Aufbau der Verbindung untereinander Listen aus, in denen sie dem Partner mitteilen, über welche Events sie informiert werden möchten. Auf diese Weise werden nur Events übertragen, die für die Empfänger auch interessant sind. Das folgende Beispiel veranschaulicht diese Liste: Es wird davon ausgegangen, dass sich die IDS Alice und Bob untereinander kennen und vertrauen. Die Umsetzung dieser Voraussetzungen soll an dieser Stelle nicht weiter betrachtet werden. 32

33 Bob startet sein System und liest die aktivierten Policies ein. Nun startet auch Alice und liest ebenfalls ihre Skripte ein. Als nächstes fragt sie den Status aller ihr bekannten Bro s auf geeignete Weise ab und erhält von Bob eine positive Rückantwort. Alice schickt an Bob eine Liste mit Ereignissen, über die sie informiert werden möchte. Bob aktualisiert zur Laufzeit seine Event Registry und schickt eine eigene Liste an Alice zurück. Alice aktualisiert ebenfalls ihre Event Registry. Von nunan informieren sich die Beiden gegenseitig, wenn lokal ein entsprechendes Event ausgelöst wird. Wird die Verbindung getrennt, entfernen sie die vom Partner registrierten Events. Dem aufmerksamen Leser mag an dieser Stelle folgendes Problem aufgefallen sein: Im vorangegangenen Beispiel wird davon ausgegangen, das Bob nur die Policy wireless.bro lädt, Alice hingegen alle verfügbaren. Demzufolge sendet Sie in ihrer Liste an Bob auch Ereignisse, die von seinem geladenen Skript nicht behandelt werden. Daher werden Alice nicht alle gewünschten Ereignisse mitgeteilt, sondern nur die Schnittmenge aus ihrer Anfrage und den von Bob bereitgestellten. Aus diesem Grund müssen die kooperierenden Systeme zusätzlich eine weitere Liste austauschen, in der die tatsächlich registrierten Events aufgeführt sind. Die erste Designentscheidung ist mit der Wahl einer abonnierten Liste getroffen. Jetzt wird geklärt, auf welche Art und Weise der Austausch der Events stattfinden soll Übertragung der Events Bro wird für die Verwendung in Breitbandnetzen entwickelt und beherrscht den TCP/IP-Protokollstapel, der im WLAN ebenfalls eine starke Verbreitung hat. Die Verwendung dieser Protokolle bietet sich daher an. Zur gegenseitigen Authentifizierung der Intrusion Detection Systeme, sowie zur sicheren 10 Übertragung der Nachrichten bietet sich das Sicherheitsprotokoll SSL/TLS 11 an. Es ist ebenfalls weit verbreitet und als open-source Paket verfügbar [Ope]. Nach diesen eigenen Überlegungen wird im nächsten Abschnitt der aktuelle Forschungsstand der Intrusion Detection Working Group vorgestellt. Sie befasst sich mit dem Standard für den Austausch von Nachrichten zwischen Intrusion Detection Systemen. 3.3 Intrusion Detection Message Exchange Format IDMEF Das Intrusion Detection Message Exchange Format soll die Kommunikation zwischen den Sensoren und der Manager-Komponente eines IDS / IPS, sowie 10 Im Sinne von Kapitel SSL: Secure Sockets Layer, TLS: Transport Layer Security, ein Sicherheitsprotokoll der Transportschicht, welches auf das Transmission Control Protocol TCP aufsetzt [DR06]. 33

34 zwischen verschiedenen Intrusion Detection and Response Systemen untereinander standardisieren. Auf diese Weise können Produkte unterschiedlicher Hersteller miteinander kombiniert werden, um die jeweiligen Vorzüge der einzelnen Systeme zu einem System mit einer höher entwickelten Angriffserkennung zu vereinen. Ebenso wird ermöglicht, die Ereignis-Daten der verschiedenen Systeme in einer einzigen, zentralen Datenbank zu speichern und Meldungen auf einem einheitlichen User Interface auszugeben. Nicht zuletzt ermöglicht ein standardisiertes Format verschiedenen Personengruppen wie Nutzern, Herstellern oder Gerichten einen einfacheren Austausch an gesammelten Angriffsdaten und vermindert die Missverständnisse in ihrer Interpretation durch Personen mit unterschiedlichen Vorkenntnissen. Der aktuelle 16. Entwurf [DCF06] der Intrusion Detection Working Group IDWG hat den Status eines Internet-Draft und kann daher noch nicht als Referenz zur Implementation betrachtet werden. Dennoch sollen die interessanten Konzepte an dieser Stelle vorgestellt werden. Zunächst werden die allgemeinen Anforderugen an das IDMEF sowie dessen Transportprotokoll beschrieben [WE02], anschließend das bereits vorhandene Kommunikationsprotokoll BEEP [Ros01b] und das darauf aufbauende Intrusion Detectction Exchange Protocol IDXP [FMW02], welches zum Austausch von IDMEF-Nachrichten benutzt wird Anforderungen an das Nachrichtenformat Jedem Anwender soll es ermöglicht werden, sich die Nachrichten in seiner gewünschten Sprache / Zeichensatz anzeigen zu lassen. Diese Trennung von Nachrichtentyp und Anzeigesprache kann durch eine eindeutige Bezeichnung der Ereignisse numeric event identifier genannt erreicht werden. Nicht jeder IDS-Manager benötigt alle Daten, die ihm seine Sensoren oder andere IDS zur Verfügung stellen. Eine leichte Filterung bzw. Zusammenfassung der Nachrichten ist zwingend nötig. Zur klaren Trennung zwischen Semantik der Nachrichten und ihrer Übertragungsmechanismen soll das Nachrichtenformat unabhängig vom Kommunikationsprotokoll eingesetzt werden können, die Verwendung des Intrusion Detection Exchange Protocol IDXP wird allerdings empfohlen Anforderungen an das IDMEF-Protokoll Um in aktuellen IP-Umgebungen arbeiten zu können, muss das Transportprotokoll sowohl IPv4, als auch IPv6 unterstüten. Eine zuverlässige Übertragung der Nachricht vom Sender zum Empfänger muss gewährleistet sein. Dazu sind eventuell bestehende Firewalls ohne Rekonfiguration zu überbrücken. 34

35 Jeder Sender muss eindeutig authentifizierbar sein. Der Übertragungskanal muss die Vertraulichkeit und Integrität (siehe 2.1) der Nachrichten erhalten. Die Wahl der Verschlüsselungsmethode 12 muss dem Administrator die Möglichkeit bieten, ein in seinem Land zulässiges Verfahren zu wählen. Das Protokoll muss gegen DoS-Attacken 13 resistent sein und die Duplikation von Nachrichten erkennen Anforderungen an den Inhalt der Nachrichten Die verschiedenen Typen von IDS (siehe 2.5.1) geben unterschiedliche Arten von Meldungen aus. Für die Kommunikation untereinander ist hingegen wichtig, was ein IDS festgestellt hat, nicht wie das Ereignis bemerkt wurde. Um alle Arten von IDS zu unterstützen, wird das Schema für den Nachrichteninhalt in Pflichtfelder und Kann-Felder untergliedert. Pflichtfelder, die in jeder Nachricht vom IDS ausgefüllt werden müssen: Jedes Ereignis muss einen eindeutigen Bezeichner haben, um Missverständnisse und Fehlinterpretationen zu vermeiden 14. Diese bereits als numeric event identifier beschriebenen Bezeichner sind in einer global bekannten, standardisierten Liste registriert. Anhand des Bezeichner können dem IT-Verantwortichen sofort Hintergrundinformationen sowie Gegenmaßnahmen zu typischen Angriffen zur Verfügung gestellt werden. Handelt es sich um ein typisches (Angriffs-) Ereignis, so müssen die möglichen Auswirkungen auf den Zielrechner mit angegeben werden. Die Quelle und das Ziel des Ereignisses müssen klar erkennbar sein, sofern sie ermittelt werden können. Bei Ereignissen im Netzwerk sind das z.b. die IP- und MAC-Adresse, aber auch Ereignisse auf Betriebssystem- und Anwendungs-Ebene sollen identifizierbar sein. Hat das IDS, welches das Ereignis meldet, bereits eine Reaktion ausgelöst, muss diese auch übermittelt werden. Jede Nachricht muss mit einem Zeitstempel versehen sein. Dieser soll unabhängig von der Zeitzone des Senders sein und muss über das Jahr 2038 hinaus verwendbar sein. Genauigkeit und Granularität der Zeitangabe sollten nicht vom IDMEF vorgegeben werden. Natürlich dürfen auch Informationen zum IDS wie Idendität und geografische Position nicht fehlen. 12 sowohl Konzelation als auch Authentikation 13 Denial-of-Service 14 Beispiel: Das Ereignis Erkennung eines Rouge AP (siehe 2.3.2) muss immer den gleichen Bezeichner haben. 35

36 Kann-Felder: Ein optionales Feld, in dem der Sender die Alarmierungsschwelle zum Ereignis mit angeben kann. Neben den Feldern mit vordefiniertem Schema muss ein variables Feld zur Verfügung stehen, in dem alle Daten gespeichert werden können, die nicht in das eben beschriebene Raster hineinpassen. Eine XML-Schema dieses Datenmodells ist Bestandteil des IDMEF internetdraft 16 [DCF06] Blocks Extensible Exchange Protocol BEEP Das Blocks Extensible Exchange Protocol bildet die Grundlage für das im folgenden beschriebene Intrusion Detection Exchange Protokoll. BEEP ist ein verbindungsorientiertes, asynchrones Protokoll-Framework der Anwendungsschicht und setzt auf das weit verbreitete Transportprotokoll TCP auf [Ros01b, Ros01a]. Es spezifiziert den Austausch von Nachrichten zwischen zwei BEEP-Peers genannten Komunikationspartnern. Der Datentransfer wird über Kanäle vollzogen, wobei mittels Profilen die Syntax und die Semantik der Nachricht festgelegt sind. Bisher entwickelte Profile sind bei der Internet Assigned Number Authority (IANA) registriert. Es gibt u.a. die speziellen Profile Transport Layer Security und Simple Authentication & Security Layer für eine gesicherte Verbindung. Der Kanal Null ist für das Kanalmanagement reserviert, über ihn handeln die BEEP-Peers die Kanäle zur Kommunikation, sowie das zu verwendende Profil aus. Es wird pro Kanal genau ein Profil benutzt, unterschiedliche Kanäle können jedoch verschiedene Profile haben. Jeder BEEP-fähige Client sollte laut Standard eine gleichzeitige Kommunikation über mindestens 257 der insgesamt 2 31 zur Verfügung stehenden Kanäle unterstützen. Alle Nachrichten werden in der Regel in einem einzigen Frame übertragen. Header und Trailer bestehen generell aus druckbaren ASCII-Zeichen, die Kodierung der Nutzdaten ist im Header festgelegt es können sowohl Texte, als auch binäre Daten transferiert werden. Ein Vorteil von BEEP gegenüber anderen Protokollen ist der modulare Aufbau. Typische Protokoll-Bestandteile wie Authentikation, Konzelation, Kompression und Fehlerbehandlung sind als Module verfügbar und müssen nicht für jede Anwendung neu implementiert werden Intrusion Detection Exchange Protocol IDXP Das Intrusion Detection Exchange Protocol wurde von der IDWG entwickelt, um den Austausch von Daten zwischen den Modulen eines IDS / IPS bzw. 36

37 Abbildung 7: Protokollebenen und Kanäle bei der Kommunikation zweier BEEP-Peers über eine BEEP-Session. zwischen verschiedenen Systemen untereinander zu standardisieren. Die Spezifikation liegt derzeit als Internet-Draft in der Version 7 vor [FMW02], sie ist seit April 2003 abgelaufen und bisher weder erneuert, noch als RFC veröffentlicht worden. Das IDXP ist ein spezielles Profil des Blocks Extensible Exchange Protocol (siehe 3.3.4) und somit ebenfalls ein verbindungsorientiertes Protokoll der Anwendungsschicht. Es wird wie jedes andere BEEP-Profil beim Aufbau eines Kanals gewählt. Der Fokus im Entwurf liegt auf dem Austausch von IDMEF- Nachrichten zwischen Sensor und Manager eines IDS, darüber hinaus eignet sich das IDXP auch zur Kommunikation zwischen verschiedenen IDS /IPS Managern und zum Transport von Texten sowie Binärdaten. Eine Auswahl des Datentyps erfolgt über den MIME Content Type im Header der Nachricht. Zur Verfügung stehen text/xml für XML-strukturierte IDMEF-Nachrichten, text/- plain für unstrukturierten Text, sowie application/octett-stream für binäre Daten. Arbeitsweise des IDXP Es kommunizieren generell genau zwei IDXP-Peers miteinander über eine einzelne BEEP-Session, ein Peer kann jedoch mehrere Sessions zu jeweils verschiedenen Peers aufbauen. Dabei sind klassische n-m - Beziehungen möglich: 1-n Manager mit 1-m Sensoren, sowie 1-n Manager mit 1-m anderen Managern. Pro Session stehen maximal 2 31 Kanäle zur Verfügung. 37

38 Für eine erfolgreiche Kommunikation steht die Initialisierung einer BEEP- Session an erster Stelle. Dabei gibt es folgende Rollenverteilung: Der die Verbindung aufbauende Peer wird als Initiator I bezeichnet, der auf eingehende Verbindungen wartende Peer ist der Listener L. Nachdem der Initiator seinen Verbindungswunsch an den Listener gesendet hat, signalisieren beide ihre Bereitschaft, indem sie auf Kanal Null eine greeting Nachricht schicken. Der Listener gibt in dieser Nachricht zusätzlich die von ihm unterstützten Profile bekannt. Als nächstes folgt der Aufbau des Kommunikationskanals mit dem IDXP- Profil. In der Regel baut der Initiator den Kanal auf und agiert als Client, der Listener übernimmt die Rolle des Server er stellt die gewünschten Daten bereit. Nach erfolgreicher Bestätigung des eingerichteten Kanals bleibt dieser über einen langen Zeitraum bestehen, auch wenn zwischenzeitlich keine Nachrichten über ihn ausgetauscht werden. Auf diese Weise wird der große Managament- Overhead vermieden, der entstünde, wenn für jeden zu übertragenden Frame erneut ein Kanal auf- und abgebaut werden müsste. Das nachfolgende Listing zeigt einen erfolgreichen Kanalaufbau. Alice sendet an Bob auf dem Kanal Null ihren Wunsch, den Kanal eins mit dem Profil IDXP aufzubauen. Sie möchte in der Kommunikationsbeziehung als Client agieren. Die Rolle, sowie der Uniform Resource Identifier des Teilnehmers müssen im greeting enthalten sein. Bob quittiert den Erhalt der greeting-nachricht mit einem ok und sendet eine eigene greeting-nachricht mit seinem URI, sowie der Rolle Server. Nachdem Alice das greeting bestätigt hat, ist der Kanal aufgebaut. Die Rollen der Peers sind bis zum Abbau des Kanals fest vergeben. Der Vollständigkeit halber seien die Zahlen der jeweils erste Zeile eines Frames noch erklärt. Es handelt sich in dieser Reihenfolge um die Kanalnummer, die Nachrichtennummer, die Sequenznummer und die Größe der Nutzdaten. I : MSG I : Content Type : t e x t /xml I : I : <s t a r t number= 1 > I : <p r o f i l e u r i = http : / / iana. org / beep / t r a n s i e n t /idwg/ idxp > I : <![CDATA[ <IDXP Greeting u r i = http : / / example. com/ a l i c e I : r o l e = c l i e n t /> ]] > I : </ p r o f i l e > I : </s t a r t > I : END L : RPY L : Content Type : t e x t /xml L : L : <p r o f i l e u r i = http : / / iana. org / beep / t r a n s i e n t /idwg/ idxp > L : <![CDATA[ <ok /> ]] > L : </ p r o f i l e > L : END 38

39 L : MSG L : Content Type : t e x t /xml L : L : <IDXP Greeting u r i = http : / / example. com/bob r o l e = s e r v e r /> L : END I : RPY I : Content Type : t e x t /xml I : I : <ok /> I : END Die parallele Verwendung mehrerer Kanäle erleichtert die Einteilung der Daten in verschiedene Kategorien wie Netzwerk-Ereignisse, Host-basierte Ereignisse und sonstige Ereignisse. Die Einordnung von Ereignissen anhand ihrer Alarmierungsschwelle ist ebenso möglich ein Manager kann so sicherheitskritische Meldungen bevorzugt auswerten und ggf. eher empfangene aber weniger gefährliche Nachrichten zu einem späteren Zeitpunkt bearbeiten. Dieses Vertauschen der Reihenfolge wird nicht zuletzt durch das asynchrone Übertragungsverhalten des IDXP ermöglicht. Zum Aufbau eines gesicherten Kanals werden zuerst alle Kanäle einer bestehenden BEEP-Session inklusive des Management-Kanals geschlossen. Anschließend werden die Sicherheitsprofile TLS / SASL ausgehandelt. Letztendlich wird eine neue Session eingeleitet, welche auf der vereinbarten Sicherheitsschicht aufsetzt. Mit dem bisher beschriebenen Verfahren lässt sich die Kommunikation nur in begrenztem Rahmen bewerkstelligen jede Firewall zwischen den Nutzern müsste extra konfiguriert werden, um die Verbindung nicht zu unterbrechen. Dieses Manko wird durch das BEEP-TUNNEL-Profil beseitigt, welches nun an dieser Stelle nachgereicht werden soll Das BEEP-TUNNEL-Profil Das BEEP-TUNNEL-Profil ist ein Mechanismus, um BEEP-Sessions über eine Kette von Proxies aufzubauen [New03]. Das Verfahren wird primär zu Überbrückung von Firewalls genutzt. Auf jedem Firewall-System wird ein BEEPfähiger Client installiert, welcher im späteren Tunnel als transparenter Proxy agiert. Die Nachricht zum Aufbau des Tunnels hat eine zwiebelschalenartige Struktur: die Adresse von Proxy 1, dem ersten Punkt der Route, bildet das äußerste Element, eine Ebene tiefer steht die Adresse des nächsten Punktes usw. Das innerste Element ist das leere Tunnel-Element. Empfängt ein Client eine Tunnel-Nachricht, entfernt er das äußerste Element und schickt den Rest dieser Nachricht an den nächsten Adressat. Diese Prozedur wird solange fortgesetzt, 39

40 bis nur noch das leere Tunnel-Element vorhanden ist, womit das Endziel (Listener) der Verbindung erreicht ist. Abbildung 8 soll den Prozeß einmal ausführlich darstellen: Abbildung 8: Manager A baut über die zwei Proxies P1 und P2 einen Tunnel zu Manager B auf. A sendet eine Verbindungsanfrage an P1, anschließend tauschen die beiden greeting-nachrichten untereinander aus und schließlich sendet A folgendes Tunnel-Element [1]: <tunnel fqdn = proxy2. example. com port = 1234 > <tunnel fqdn = f i n a l. example. com port = 5678 > <tunnel/> </tunnel > </tunnel > P1 entfernt das äußerste Element der Tunnel-Nachricht, liest die Adresse von P2 aus dem nächsten Element aus, sendet eine Verbindungsanfrage an P2, sie tauschen greeting-nachrichten aus und P1 sendet den Rest der Tunnel-Nachricht [2] an P2: <tunnel fqdn = f i n a l. example. com port = 5678 > <tunnel/> </tunnel > P2 verfährt analog zu P1 und sendet an den Manager B die verbleibende, leere Tunnel-Nachricht [3]: <tunnel/> 40

41 B erkennt an der leeren Tunnel-Nachricht, dass er das Ziel des Tunnels ist und stimmt dem Aufbau zu Sobald die Proxies das ok weitergeleitet haben [4][5], ist der Tunnel aufgebaut. Alle nachfolgenden Frames werden von P1 und P2 sofort transparent weitergeleitet. Im Anschluss daran können A und B die greeting-nachrichten austauschen und ein Sicherheitsprofil aushandeln. Die Verwendung eines Sicherheitsmechanismus wird generell empfohlen, da die Proxies per Definition als nicht vertrauenswürdig gelten Zusammenfassung IDMEF / BEEP Die in den Abschnitten bis gestellten Anforderungen an das Nachrichtenformat sowie dessen Übertragungsprotokoll, werden durch das IDMEF und BEEP mit den zugehörigen Profilen allesamt erfüllt. Das IDMEF ist dennoch kaum verbreitet, da es sich weiterhin in Entwicklung befindet. Für das IDS snort gibt es bereits ein IDMEF-Plugin [Sno], bei Bro steht der IDMEF-Support auf der To-Do-Liste, wobei die Entwickler derzeit auf eine Weiterentwicklung des Formates warten. Für das Protokoll BEEP existieren einige Implementierungen in C, Java, Tcl, Phyton und Ruby, ausführliche Informationen sind unter Beepcore [BC2] zu finden. Mit dem in den Abschnitten 3.2 und 3.3 erworbenen Wissen wird jetzt die bereits in Bro integrierte Kommunikationsschnittstelle untersucht. 3.4 Die Kommunikationsschnittstelle von Bro Die Schnittstelle wurde erstmals in Bro 0.8a48 integriert, mit dem Ziel, Events zwischen zwei Instanzen von Bro auszutauschen [Broa]. Sie unterliegt einer stetigen Weiterentwicklung, sodass die in diesem Abschnitt getätigten Aussagen zunächst nur auf Bro in der aktuellen stable-version 1.1 zutreffen. Die für die vorliegende Arbeit ursprünglich benutzte Version 0.9 verwendet die Version 4 des Kommunikationsprotokolls und ist nicht mit der aktuellen Version 5 kompatibel. Derzeit existiert keine Dokumentation der Schnittstelle in den Handbüchern und der Quellcode selbst enthält nur spärliche Informationen. Das in den folgenden Unterabschnitten vermittelte Wissen wurde größtenteils durch eine ausführliche Analyse des Quelltextes erworben. Eine Kommunikation ist sowohl mit anderen Bro-Knoten möglich, als auch mit externen Programmen über die mitgelieferte Bibliothek brocolli [Kre06]. In beiden Fällen werden sogenannte Remote Events ausgetauscht. In Anlehnung an die standortspezifische Anpassung der Sicherheitsrichtlinien erfolgt die 41

42 komplette Steuerung der Kommunikation ebenfalls in den Policy Skripten. Die benötigten Skripte liegen im Verzeichnis policy, Anpassungen werden in der bereits bekannten Datei host.bro im Verzeichnis site vorgenommen. Im nächsten Abschnitt werden die allgemeinen Abläufe der Kommunikation erläutert, anschließend werden die lokalen Anpassungsmöglichkeiten der Policies genauer beleuchtet. Darauf aufbauend wird das Zusammenspiel der in den Aufbau einer Verbindung involvierten Prozesse im Kern und in den Skripten genauer beleuchtet. Eine Zusammenfassung der gewonnenen Kenntnisse rundet das Kapitel ab Allgemeiner Ablauf Der allgemeine Ablauf der Kommunikation ist in Abbildung 9 dargestellt. Die Knoten Alice und Bob kommunizieren miteinander über eine TCP/IP Verbindung, wobei intern jeweils zwei Bro-Prozesse laufen. Der Elternprozess Parent tauscht sich mit seinem Kindprozess Child über eine Pipe aus. Während der Parent die bekannte Funktionalität des IDS realisiert, ist der Child-Prozess ausschließlich mit der Socket-Kommunikation beauftragt. Er unterhält sämtliche Verbindungen zu entfernten Clients und wird vom Parent gesteuert. Die zur Steuerung benötigten Methoden werden auf Seite des Elternprozesses von der Klasse RemoteSerializer bereitgestellt. Im Child-Prozess sind die von der Klasse SocketComm bereitgestellten Methoden sowohl für die Kommunikation über die Pipe, als auch zu entfernten Knoten verantwortlich. Abbildung 9: Schematische Darstellung der inter-bro Kommunikation. Events, die Alice bei Bob angefordert hat, werden zuerst an den Child-Prozess von Bob geschickt, dann über die bestehende Netzwerkverbindung an Alice übertragen, und dort wieder durch die Pipe an den Elternprozess weitergereicht. Die Details dieser Prozedur werden im Abschnitt behandelt, zunächst wird der hierfür nötige Aufbau der Kommunikationsverbindung sowie dessen Konfiguration beschrieben. 42