Network Intrusion Detection Systeme

Transkript

1 HTW Aalen Projektarbeit Network Intrusion Detection Systeme Autor: Andreas Heißel Betreuer: Prof. Dr. Roland Hellmann Eine Projektarbeit, erstellt im Rahmen der Vorlesung Netzwerksicherheit SS2013 des Studienganges Informatik 2. Juli 2013

2 Erklärung Ich erkläre hiermit, dass ich die Ausarbeitung, Network Intrusion Detection Systeme selbstständig verfasst und keine andren Quellen und Hilfsmittel als die angegebenen benutzt habe. Die Stellen, die anderen Werken im Wortlaut oder dem Sinn nach entnommen wurden sind in jedem einzelnen Fall unter Angabe der Quelle als Entlehnung (Zitat) kenntlich gemacht. Das gleiche gilt für beigefügte Skizzen und Darstellungen. Ort, Datum: Unterschrift: i

3 Inhaltsverzeichnis Erklärung i Abbildungsverzeichnis Tabellenverzeichnis Abkürzungen iv v vi 1 Einleitung Einleitung Motivation Ziel der Arbeit Network Intrusion Detection Systeme Aktives NIDS Passives NIDS Funktion eines NIDS Erkennung von Angriffsmustern Abweichung vom Normalverhalten Protokollanalyse Erkennung durch Statistische Daten Korrelation von Ereignisdaten Aufbau von NIDS Snort Installation und erste Konfiguration Die Arbeit mit Snort Programmaufruf Snort Regeln Aufbau der Snort Regeln Beispielregel Präprozessoren Schwächen von NIDS Session Splicing Denial of Service Weitere Schwächen ii

4 Inhalt iii 5 Praktikum Lösungen Aufgabe Aufgabe Aufgabe Aufgabe Literaturverzeichnis 27

5 Abbildungsverzeichnis 2.1 Aktives NIDS Passives NIDS Mögliche Layouts für ein NIDS Aufbau einer Snort Regel Snort Beispielregel Beispielregel Session Splicing Session Splicing Aufgabe 2 Lösungsmöglichkeit Aufgabe 2 Lösungsmöglichkeit Aufgabe 3 Lösung Aufgabe 3 Lösung Aufgabe 4 Lösung iv

6 Tabellenverzeichnis 3.1 Mögliche Aktionen für Snort Regeln Sonderzeichen bei der Angabe von Quell- und Zieladresse Mögliche Rule-Options v

7 Abkürzungen NIDS IDS IDPS (D)DoS TTL MTU NIDPS Network Intrusion Detection System Intrusion Detection System Intrusion Detection and Prevention System (Distributed) Denial Of Service Time To Live Maximum Transmission Unit Network Intrusion Detection and Prevention System vi

8 Kapitel 1 Einleitung 1.1 Einleitung In diesem Kapitel wird die Motivation der Arbeit dargestellt. Darauf folgend wir das Ziel und die Gliederung der Ausarbeitung vorgestellt. 1.2 Motivation Vernetzte Computersysteme sind aus der heutigen Welt nicht mehr wegzudenken. Egal, ob nun beim Online-Shopping von der Couch oder bei der Zusammenarbeit mit Geschäftspartnern auf der ganzen Welt, es gibt kaum einen Bereich, in dem Computernetze noch keinen Einzug gehalten haben. Gerade deshalb ist es um so wichtiger diese Systeme vor Angriffen zu schützen, denn bei all den Vorteilen die eine Netzwerk-Infrastruktur mit sich bringen kann, birgt diese auch zahlreiche Gefahren für Unternehmen und Privatpersonen. Neben den etablierten Systemen wie Firewalls und Virenscanner erlauben Network Intrusion Detection Systeme das Erkennen und Abwehren von Angriffen auf das eigene Netzwerk. 1

9 Einleitung Ziel der Arbeit Das Ziel dieser Ausarbeitung ist zunächst die allgemeine Betrachtung von Network Intrusion Deteciton Systemen. Hierzu werden zunächst verschiedene NIDS-Varianten vorgestellt und deren unterschiedliche Funktions- und Arbeitsweisen betrachtet. Des Weiteren wird mit Snort ein frei Verfügbares Open-Source NIDS-System vorgestellt und an Hand einiger praktischer Beispiele die Arbeit mit diesem demonstriert. Hauptaugenmerk hierbei liegt dabei auf der Erstellung von Erkennungs-Regeln für Snort. In einem weiteren Kapitel werden daraufhin Möglichkeiten aufgezeigt, wie ein Network Intrusion Detection System umgangen werden kann und Probleme und Schwächen von Network Intrusion Detection Systemen angesprochen. Ein letztes Kapitel umfasst zudem verschiedene Übungen zum Umgang und der Arbeit mit Snort und die zugehörigen Lösungen.

10 Kapitel 2 Network Intrusion Detection Systeme Wie der Name bereits andeutet, bezeichnet man mit Network Intrusion Detection System bezeichnet ein System, welches dazu eingesetzt wird, Angriffe auf ein Netzwerk zu erkennen. Hierzu kann je nach eingesetztem System eine Alarm, etwa per oder SMS, ausgelöst und der Angriff beziehungsweise die verdächtigen Pakete zur Analyse oder gar als Beweismittel protokolliert werden. Während Firewalls den Netzwerkverkehr einfach nach festgelegten Regeln blockieren, wird bei einem NIDS der Datenstrom mitgelesen und auf bestimmte Eingenschaften hin untersucht. Auf diese Weise können Angriffe wie (D)Dos, Sniffing oder Spoofing und auch die Aktivität von Viren, Trojanern oder Botnetzen festgestellt werden.[14]. Je nach Implementierung des Systems unterscheidet man dabei zwischen aktiven- und passiven Network Intrusion Detection Systemen. 2.1 Aktives NIDS Bei einem aktiven, auch Inline genannten, Network Intrusion Detection System sitzt das NIDS in der Regel an einem Übergang zwischen zwei Netzwerksegmenten. Dies hat zur Folge, dass bei dieser Variante der gesamte Datenverkehr, der in das Netz hinein oder heraus fließt, verarbeitet werden kann, beziehungsweise durch das Intrusion Detection System verarbeitet werden muss. 3

11 Network Intrusion Deteciton Systeme 4 Abbildung 2.1: Aktives NIDS Die Implementierung eines aktiven NIDS erfolgt entweder durch ein eigenständiges Netzwerkgerät oder in dem man etwa eine Firewall oder einen Switch mit einem Network Intrusion Detection System kombiniert [16]. Da bei einem aktiven NIDS der durchfließende Verkehr direkt verarbeitet wird, kann mit diesem System bei einem möglichen Angriffsfall nicht nur ein Alarm ausgelöst, sondern auch aktiv in die Datenübertragung eingegriffen werden. Je nach eingesetztem NIDS können auf diese Weise etwa verdächtige Pakete abgewiesen, der Payload, also die eigentlichen Nutzdaten der Pakete bearbeitet oder Regeln der Firewall verändert werden. Bei einem System, dass in einem Angriffsfall aktiv in den Datenverkehr eingreift handelt es sich jedoch genau genommen nicht mehr um ein NIDS, in diesem Fall spricht man in der Regel von einem Network Intrusion Detection and Prevention System (NIDPS). Ein Nachteil eines aktiven Network Intrusion Deteciton Systemes zeigt sich jedoch, wenn die Netzwerklast die Kapazität des NIDS überstigt. In diesem Fall lässt das Network Intruison Detection System den Verkehr in der Regel ungeprüft passieren lässt, um die Netzwerk-Kommunikation nicht zu beeinträchtigen und kann in diesem Moment keinen Schutz mehr bieten, was ein möglichen Angriffsvektor darstellt. Mehr zu diesem Thema finden Sie im Abschnitt 4.2. Solche aktiven NID-Systeme sind oftmals als Komplettlösung, bestehend aus spezieller Hardware und der dazugehörigen Software, erhältlich. Als Beispiel wäre hier etwa die IDP-Serie der Firma Juniper zu erwähnen [4]. 2.2 Passives NIDS Die zweite Möglichkeit, ein NIDS zu betreiben ist im passiven Modus. Hierbei verarbeitet das Network Intrusion Detection System den Verkehr nicht direkt, sondern untersucht nur eine Kopie des anfallenden Datenstromes. Im einfachsten Fall besteht diese Implementierung aus einem gewöhnlichen Host, dessen Netzwerkinterface im sogenannten

12 Network Intrusion Deteciton Systeme 5 Promiscious Mode Netzwerkverkehr mitschneidet und einer NIDS-Software die die Datenpakete nach bestimmten Regeln verarbeitet. Siehe hierzu Abbildung 2.2. Da nur eine Kopie des Datenverkehres bearbeitet wird, kann im Gegensatz zu aktiven Systemen bei einem passiven System bei einem möglichen Angriff nicht aktiv eingegriffen werden. Hier wird in der Regel lediglich ein Alarm, etwa in Form einer Meldung auf dem Bildschirm oder einer ausgelöst und der potentiell gefährliche Verkehr in eine Log-Datei geschrieben. Gerade in großen Netzwerken mit hohem Datenaufkommen kann ein passives im Vergleich zu einem aktiven NIDS einen Performance-Vorteil bedeuten, da der Datenverkehr kein extra Verarbeitungsschritt durchlaufen muss. [16] Abbildung 2.2: Passives NIDS 2.3 Funktion eines NIDS Es gibt verschiedene Möglichkeiten, auf die ein Network Intrusion Detection System ungewollten Verkehr erkennen kann. Hierzu unterscheidet man zwischen der Erkennung von Angriffsmustern, der Erkennung auf Grund von Abweichung des Normalverhaltens und der Erkennung von Angriffen auf Grund Korrelation von Ereignisdaten Erkennung von Angriffsmustern Die am weitesten verbreitete Funktionsweise ist die Erkennung von Angriffsmustern, auch Pattern Matching genannt. Hierbei wird der Datenstrom einfach mit Verhaltensmustern bekannter Angriffe abgeglichen. Für die Erkennung der Angriffe können hierbei alle Details des TCP-Verkehres, wie etwa gesetzte Flags, der Payload oder auch der TTL-Wert eines Paketes, verwendet werden. Auf diese Weise kann etwa gezielt nach Paketen gesucht werden, bei denen sowohl das SYN als auch das FIN Flag gesetzt ist,

13 Network Intrusion Deteciton Systeme 6 da diese Eigenschaft charakteristisch für einen sogenannten SYN-FIN-Netzwerkscan ist und bei normalen Datenverkehr nicht auftaucht. Der Vorteil dieser Methode ist, dass sie einfach zu implementieren und auch zu verstehen ist, da einfach nur für jeden Angriff eine passende Signatur erstellt werden muss. Ein solches System kann in der Regel auch einfach vom Nutzer erweitert und angepasst werden in dem eigene Regeln hinzugefügt werden. Zusätzlich bieten die meisten Hersteller von NIDS-Systemen in regelmäßigen Abständen Signaturen für neue Angriffe an, sodass die Konfiguration des Systemes nicht ausschließlich in den Händen des Endnutzers liegt. Die Kehrseite dieser Methode ist es, dass eine große Anzahl an Regeln notwendig sind um einen ausreichenden Schutz zu gewährleisten, da wirklich nur Angriffe erkannt werden können, deren Signatur implementiert ist. Gleichzeitig kann dieses System bei der Verwendung von unscharfen Regeln jedoch auch zu vielen Fehlalarmen führen was wiederum einen hohen Wartungsaufwand mit sich bringt. [12, 15] Abweichung vom Normalverhalten Im Gegensatz zur Erkennung von Angriffsmustern liegt diesem Ansatz kein fester Regelsatz vor. Dieser Herangehensweise liegt die Annahme zu Grunde, dass Angriffe und unerwünschtes Verhalten durch eine Abweichung vom Normalverhalten eines Systemes erkennbar sind. Ziel ist es daher, durch verschiedene Methoden Abweichungen von einem zuvor festgelegten Normalverhalten zu erkennen Protokollanalyse Der Protokollanalyse liegt das Normalverhalten zu Grunde, welches in den Spezifikationen der überwachten Protokolle festgelegt wurde. Bei der Erkennung von Angriffen macht man sich zu Nutze, dass viele Angriffe auf Computernetze von diesem Normalverhalten abweichen. Beispiele hierfür sind etwa absichtlich falsch gesetzte Flags die Beispielsweise bei einem Stealth- oder XMas-Scan [12, ] eingesetzt werden, oder ungewöhnliche Paketgrößen. Da nur die festgelegten Spezifikationen eingetragen werden müssen ist ein System zur Protokollanalyse einfach zu implementieren und zu pflegen. Gleichzeitig weißt es eine sehr gute Performance auf, da im Gegensatz zum Pattern Matching nur eine geringe Anzahl an Regeln abgearbeitet werden müssen. Jedoch schützt

14 Network Intrusion Deteciton Systeme 7 auch dieses System nicht vollständig vor Angriffen. Angriffe, die etwa auf Fehlern oder Unschärfe der Protokollspezifikationen beruhen werden durch eine Protokollanalyse nicht erfasst Erkennung durch Statistische Daten Eine weitere Möglichkeit Angriffe auf ein Netzwerk zu erkennen basiert auf der Auswertung von Statistischen Daten. Auch in diesem Fall liegt die Annahme zu Grunde, dass sich ein System im Falle eines Angriffes von einem Normalsystem unterscheidet. Um nun einen Angriff zu erkennen werden möglichst viele statistische Daten gesammelt. Mögliche Werte sind hierbei etwa die durchschnittliche CPU-Last, die Zugriffszeit auf ein bestimmtes System oder die Häufigkeit von fehlgeschlagenen Anmeldungen. Erkennt nun das System eine Abweichung von diesen Standard-Werten so wird ein Angriff auf das System angenommen. Der Nachteil dieser Methode ist, dass er für jedes System komplett individuell konfiguriert werden muss und daher sehr Fehlerträchtig ist. Es gibt jedoch verschiedene Ansätze durch die die Leistung eines auf statistischen Daten basierenden NIDS verbessert werden kann. Hierzu zählen zum Beispiel der Einsatz von Honeypots und und künstlicher Intelligenz. Mit Honeypot bezeichnet man einen Rechner in einem Netzwerk, der sozusagen als Falle für einen Angreifer dient. Im Falle eines NIDS wird hierzu in der Regel ein Rechner verwendet auf dem keine Programme oder Dienste laufen. Auf diese Weise kann man davon ausgehen, dass jegliche Aktivität die auf diesem System zu beobachten ist eine ungewollte und somit ein potentieller Angriff ist. Nachteil an dieser Methode ist jedoch, dass ein Honeypot je nach Standort im Netzwerk unter Umständen nicht alle Angriffe registrieren kann und gleichzeitig muss ein Angriff auf einen Honeypot auch nicht unbedingt einen Angriff auf ein Produktivsystem bedeuten. Ziel bei der Verwendung von künstlicher Intelligenz ist die Erstellung eines Systems, welches selbstständig lernt welches Verhalten normal und welches böse ist und die Regeln und das Verhalten des Network Intrusion Detectin Systemes selbstständig anpasst. Da solche Systeme auf dem heutigen Stand der Technik jedoch noch sehr Fehleranfällig sind findet diese Technik hauptsächlich in der Forschung eine Anwendung.

15 Network Intrusion Deteciton Systeme Korrelation von Ereignisdaten Die bisher beschriebenen Technologien, mit Ausnahme der Erkennung an Hand von Statistischen Daten, betrachten bei der Untersuchung den Verkehr Paket für Paket und entscheiden dann an Hand eines einzigen Paketes, ob dieses teil eines Angriffes ist oder nicht. Zwar lassen sich auf diese Weise viele Angriffe zuverlässig erkennen, doch es gibt auch Angriffe die genau diesen Umstand ausnutzen um unentdeckt zu bleiben. So lässt sich etwa der Netzwerkscanner nmap etwa in einem sogenannten paranoiden Modus betreiben [8] in dem nur alle 15 Minuten ein Port gescannt wird. Um auch solchen Angriffen auf die Schliche zu kommen setzen manche Systeme auf die Korrelation von Ereignisdaten. Dabei wird der Datenverkehr nicht nur untersucht sondern auch über längere Zeit gespeichert, sodass auch zeitlich auseinanderliegende Ereignisse miteinander in Verbindung gebracht werden können. So ist etwa ein versuchter Verbindungsaufbau an einem bestimmten Port für sich betrachtet kein außergewöhnliches oder gar unbedingt gefährliches Ereignis. Sieht man jedoch über längere Zeit, dass von der gleichen IP nacheinander Verbindungen zu allen Ports aufgebaut werden, so lässt das auf einen Netzwerkscan schließen. Auch diese Methode ist jedoch nicht ohne Nachteile. So muss bedacht werden dass vor allem in größeren Unternehmen sehr großer Datenverkehr anfällt was in einer sehr großen Datenmenge resultiert, die gespeichert und verarbeitet werden muss. Zudem kann es bei der Speicherung der Daten Konflikte mit dem Datenschutz geben.

16 Network Intrusion Deteciton Systeme Aufbau von NIDS Je nach gewünschtem Einsatzgebiet gibt es unterschiedliche Möglichkeiten ein Intrusion Detection System in einem Netzwerk zu installieren. Abbildung 2.3 zeigt ein schematisches Netzwerk wobei die Kameras mögliche Standorte für NID-Systeme darstellen. Abbildung 2.3: Mögliche Layouts für ein NIDS Installiert man ein NIDS an Position eins, also zwischen Firewall und Internet, so kann dieses System alle Angriffe auf ein Netzwerk erkennen, auch diejenigen, die eigentlich von der Firewall abgewehrt werden. An Hand dieser Daten kann man etwa überprüfen, ob eine Firewall ausreichend konfiguriert ist. Ein Network Intrusion Deteciton System an dieser Position muss jedoch auch am meisten Traffic verarbeiten, muss also entsprechend performant sein. Da dieses System vor der Firewall sitzt, werden hier auch entsprechend viele Angriffe registriert was den höchsten Verwaltungsaufwand bedeutet. Ein System an Position zwei hingegen sieht nur den Verkehr, der von der Firewall nicht geblockt wurde also tatsächlich ins Netzwerk gelangen ist. Ein NIDS an dieser Stelle eignet sich besonders gut um zu prüfen, wie zuverlässig die Firewall arbeitet. Wird an dieser Position ein aktives Network Intrusion Detection System installiert, so kann dies genutzt werden um Angriffe, die nicht von der Firewall geblockt, wurden zu verarbeiten. Da dieses Network Intrusion Detection System nur noch die Angriffe erkennt, die nicht bereits von der Firewall blockiert wurden, treten an dieser Stelle weniger Alarme auf. Es ist mit einem Network Intrusion Deteciton System jedoch auch möglich, wie an Punkt drei gezeigt, nur einzelne Netzsektoren zu überwachen. Werden nur wichtige Systeme wie etwa Server überwacht wird der Verwaltungsaufwand gering gehalten. Diesen Vorteil

17 Network Intrusion Deteciton Systeme 10 erkauft man sich jedoch mit der Tatsache, dass Angriffe auf andere Netzwerksektoren unerkannt bleiben. Bei den hier vorgestellten Implementierungsmöglichkeiten handelt es sich natürlich ausschließlich um Beispiele. So können NIDS-System je nach Bedarf beliebig im Netzwerk platziert und auch mehrere Systeme miteinander kombiniert werden. Bei der Wahl des Standortes gilt es letztendlich im Einzelfall abzuwägen, welche Informationen man mit einem NIDS erhalten möchte.

18 Kapitel 3 Snort Snort ist eines der bekanntesten Open Source Network Intrusion Detecion Systeme. Es wurde ursprünglich von Martin Roesch entwickelt und bereits im Jahre 1988 in einer ersten Version veröffentlicht. In der Zwischenzeit wird Snort durch das von Martin Roesch gegründete Unternehmen Sourcefire vertrieben und ist sowohl als Version für die Betriebssysteme Windows, Linux als auch Mac erhältlich und bereits mehrere Millionen mal heruntergeladen worden. Im Jahre 2009 wurde die Software von InfoWorld sogar als ëine der besten Open Source Softwares aller Zeitenïn die Open Source Hall of Fame gewählt. [2] Das Unternehmen Sourcefire kümmert sich jedoch nicht nur um die stetige Weiterentwicklung der eigentlichen Software. Mit dem sogenannten Vulnerability Research Team beschäftigt Sourcefire mehrere Mitarbeiter, die laufend Signaturen für neue Angriffe erstellen, die in Kombination mit den eigenen Regeln genutzt werden können. Während Snort an sich kostenlos erhältlich ist, stehen diese offiziellen Regeln zahlenden Kunden jedoch früher zur Verfügung als den nicht zahlenden Anwendern. 3.1 Installation und erste Konfiguration Die Installationsdaten für Snort können ganz einfach auf der Homepage von Snort heruntergeladen werden[10]. Unter Linux kann Snort natürlich auch einfach über den entsprechenden Paketmanager installiert werden, unter Debian etwa mit dem Befehl 11

19 Snort 12 sudo apt-get install snort. Nach der Installation erstellt Snort eine Standard- Konfigurationsdatei namens Snort.conf, die sich im Verzeichnis /etc/snort befindet. Zudem wird im Verzeichnis /etc/snort/rules ein Satz an Standard-Regeln erstellt, der bereits zahlreiche Angriffe durch bestimmte Trojaner und Viren, Sniffing und ähnliches erkennt. Sowohl die Regeln als auch die Datei Snort.conf kann oder besser gesagt sollte natürlich an die eigenen Bedürfnisse angepasst werden. Die Konfigurationsdatei snort.conf erlaubt es zahlreiche Einstellungen vorzunehmen. Neben der Möglichkeit Regeln direkt anzugeben oder per Pfad einzubinden können auch Variablen, etwa für die IP-Range des eigenen Netzes, angegeben oder Präprozessoren konfiguriert werden. 3.2 Die Arbeit mit Snort Im folgenden Abschnitt wird die Arbeit mit Snort beschrieben. Alle verwendeten Befehle beziehen sich dabei auf das Betriebssystem Debian Squeeze Programmaufruf Je nach gewünschter Funktionalität kann Snort auf verschiedene Weisen gestartet werden: Im Sniffing Modus, im Logging Modus und im sogenannten NIDS Modus. Der Aufruf erfolgt einfach über eine Konsole mit dem Parameter des gewünschten Modus. Sniffing Modus Der Sniffing Mode wird über den Parameter -v aufgerufen. In diesem Modus arbeitet Snort einfach als Paketsniffer, vergleichbar etwa mit TCPDump oder Wireshark und gibt die TCP-Header auf der Konsole aus [11]. Will man für eine genauere Analyse zusätzlich die Paketdaten sehen, so gelingt dies über einen Aufruf mit dem Parameter -vd.

20 Snort 13 Loggin Modus Eine weitere Möglichkeit für einen Aufruf von Snort ist der sogenannte Logging Modus. Hierbei werden alle Daten die Snort auf dem angegebenen Interface sieht in ein angegebenes Logging-Verzeichnis geschrieben. Für einen Aufruf des Logging Modus muss man zusätzlich zu den gewünschten Parametern des Sniffing Modus noch mit -l ein Verzeichnis angeben. Ein Beispielaufruf wäre also snort -vd -l./log In diesem Beispiel würden alle Pakete im Verzeichnis./log gespeichert werden. NIDS Modus Der dritte Modus ist der sogenannte NIDS Modus in dem Snort den Verkehr an Hand von festgelegten Regeln verarbeitet. Für den Aufruf des NIDS Modus wird beim Aufruf mit dem Parameter -c eine Konfigurationsdatei angegeben in der die entsprechenden Regeln und Einstellungen festgelegt sind. Mit dem Aufruf snort -c snort.conf wird Snort also mit den in der Datei snort.conf festgelegten Einstellungen im NIDS Modus gestartet. 3.3 Snort Regeln Der Elementare Bestandteil von Snort sind die Regeln. Wird Snort im NIDS Modus gestartet, so verarbeitet das Programm den untersuchten Verkehr Paket für Paket und überprüft dabei, ob eine der angegebenen Regeln auf das aktuelle Paket zutrifft. Ist dies der Fall, so wird das Paket wie in der Regel festgelegt verarbeitet und eine eventuell definierte Aktion ausgeführt. Die einzelnen Regeln werden dabei von oben nach unten durchgearbeitet - für ein Paket wird nur die erste gefundene Regel angewandt.

21 Snort 14 Name alert log pass activate dynamic Aktion Meldung wird ausgelöst und Paket geloggt Paket wird nur aufgezeichnet Paket wird nicht verarbeitet Löst Alert aus und aktiviert dynamische Regel Regel inaktiv bis sie durch ein Acivate-Event aktiviert wurde Tabelle 3.1: Mögliche Aktionen für Snort Regeln Aufbau der Snort Regeln Jede Snort Regel besteht aus zwei grundlegenden Teilen, dem sogenannten Header und den Options. Der Header setzt sich weiterhin aus demaktions Feld, dem Protokol Feld und dem Quell und Zieladressen Feld zusammen. Abbildung 3.1: Aufbau einer Snort Regel Im Aktions Feld muss zuerst angegeben werden, welche Aktion bei einem Paketfund ausgeführt werden soll. Hierbei sind die in Tabelle 3.1 aufgeführten Werte möglich. Wird Snort als aktives Network Intrusion Detection System betrieben ist es zudem möglich, weitere Aktionen wie zum Beispiel drop, reject oder sdrop anzugeben, wodurch ein Paket verworfen, abgelehnt beziehungsweise verworfen wird, ohne dass ein Eintrag in das Log-File geschrieben wird. Im nächsten Feld, dem Protokoll Feld wird das Protokoll angegeben, nach dem gesucht wird. In der aktuellen Version stehen hierfür die Protokolle TCP, UDP, ICMP oder IP zur Verfügung. Im Quell- und Ziel-Adressfeld des Headers wird der IP-Adressbereich und der Port für die Pakete festgelegt, auf die die Regel gilt. Hierzu können zum einen einzelne IP-Adressen oder mit Hilfe der sogenannten CIDR-Notation ganze Subnetze angegeben werden. Zwischen den beiden IP Adressen beziehungsweise Adress-Bereichen gibt ein Pfeil, symbolisiert durch -> die Flussrichtung der zu untersuchenden Pakete an.

22 Snort 15 Zeichen Bedeutung any Beliebige IP oder Port! Adresse oder Port negieren 20:22 Port-Bereich :1023 kleiner als 1023: größer als Tabelle 3.2: Sonderzeichen bei der Angabe von Quell- und Zieladresse / > /24 80 Folgende Zeile etwa legt fest, dass diese Regel nur auf Pakete angewandt wird, die aus dem Subnetz /24 von Port 80 kommen und an eine Adresse im IP-Bereich /24 an Port 80 adressiert sind. Zur Festlegung des Quell- und Ziel-Adressbereiches sind verschiedene Sonderschreibweisen möglich, die es etwa ermöglichen Port- Bereiche anzugeben. Siehe hierzu Tabelle 3.2 In den Regel Optionen können weitere Merkmale angegeben werden, nach denen die Pakete untersucht werden. Hierzu stehen nahezu alle Felder eines Datenpaketes zur Verfügung. Bei einem TCP Paket kann etwa nach gesetzten Control-Flags Ausschau gehalten oder der Payload nach bestimmten Strings durchsucht werden. Eine kleine Auswahl an möglichen Optionen findet sich in der Tabelle 3.3. Hierbei handelt es sich jedoch längst nicht um alle möglichen Optionen, eine vollständige Liste finden Sie im Snort Manual [11]. Zwei wichtige Options die gesondert erwähnt werden sollten sind msg und sid. Mit msg legen Sie eine Nachricht fest, die im Logfile über dem aufgezeichneten Paket angezeigt wird und kann somit veranschaulichen auf Grund welcher Regel das Paket geloggt wurde. Bei sid handelt es sich um eine eindeutige ID die jeder Regel zugeordnet werden muss. Bei der Vergabe der SIDs sollte jedoch beachtet werden, dass die Zahlen zwischen 1 und für Regeln reserviert sind, die von Snort mitgeliefert werden. Zudem muss jeder Regel eine eindeutige SID zugeordnet werden, fehlt bei einer Regel die SID so gibt Snort eine Fehlermeldung aus und lässt sich nicht starten.

23 Snort 16 Option flag content dsize ttl fragbits Auswirkung Gesetzte TCP-Flags String im Payload Größe des Payloads TTL-Wert Gesetzte Fragbits Tabelle 3.3: Mögliche Rule-Options Beispielregel alert tcp! /24 any -> /24 any / (flags: SF; msg: SYN-FIN-Scan ; sid: ;) Abbildung 3.2: Snort Beispielregel In Figur 5.1 ist eine Beispielregel für Snort zu sehen. Diese Regel löst einen Alert mit der Nachricht SYN-FIN-Scan aus, wenn folgende Eigenschaften zutreffen: Es handelt sich um ein TCP Paket Das Paket stammt nicht aus dem Subnetz /24 Seine Zieladresse liegt im Subnetz /24 Quell- und Ziel-Port sind beliebig Es sind die TCP-Flags S und F gesetzt 3.4 Präprozessoren Der Funktionsumfang von Snort lässt sich mit Hilfe verschiedener Präprozessoren um zusätzliche Funktionen erweitern. Bei Präprozessoren handelt es sich um optionale Pakete die die Datenpakete vor der eigentlichen Überprüfung an Hand der Regeln verarbeiten. So kann der Verkehr etwa zusätzlich auf bestimmte Angriffsmuster untersucht oder im Folgenden genauer und effektiver analysiert werden. Den Präprozessoren ist es dabei sowohl möglich einzelne Pakete zu analysieren als auch etwa den Payload zu verändern. Zur Nutzung der Präprozessoren werden diese einfach in der Snort Konfigurationsdatei mit dem Aufruf preprocessor [name]: [option] mit den gewünschten Optionen aufgerufen. Bekannte Präprozessoren sind etwa:

24 Snort 17 Stream5 Mit diesem Präprozessor kann TCP Verkehr defragmentiert werden. Wie in Kapitel 4.1 gezeigt wird, kann die Fragmentierung von TCP Paketen dazu genutzt werden um NIDS-Systeme zu umgehen. Durch die Defragmentierung des Verkehres lassen sich die verschleierten Angriffe dennoch erkennen. Arpspoof Dieser Präprozessor dient zur Erkennung von Arp-Spoofing Angriffen sfportscan Der Präprozessor sfportscan ermöglicht es TCP- UDP- und IP-Portscans zu entdecken. Reputation Mit diesem Präprozessor können IP-Adressen auf eine White- oder Blacklist gesetzt werden und dadurch der Zugriff limitiert werden. Wie auch bei den Regel Optionen sei an dieser Stelle gesagt, dass es sich hierbei nur um einen kleinen Auszug der verfügbaren Präprozessoren handelt. Eine umfangreiche Liste finden Sie ebenfalls in der Dokumentation von Snort. [11]

25 Kapitel 4 Schwächen von NIDS Wie bei allen Sicherheitssystemen im Bereich der IT, bietet auch ein Network Intrusion Detection System keinen vollständigen Schutz vor Angriffen auf das überwachte System. Wie bereits in Kapitel 2.3 angesprochen weißen Network Intrusion Detection je nach Implementierung verschiedene, charakteristische Schwächen auf, die von einem Angreifer für seine Zwecke ausgenutzt werden können. Im Folgenden werden mehrere mögliche Angriffsszenarien dargestellt die solche Schwächen nutzen um das System zu umgehen. 4.1 Session Splicing Eine Möglichkeit einen Angriff auf ein Netzwerk auszuführen, der von einem Network Intrusion Deteciton System unerkannt bleibt, ist das sogenannte Session Splicing. Grundlage hierfür ist, dass das Payload-Feld eines TCP-Paketes keine feste Größe hat, sondern sich über die sogenannte Maximum Transmission Unit festlegen lässt. Die MTU gibt an, wie groß ein TCP-Frame maximal sein darf - ist die zu übertragende Datenmenge zu groß für ein einzelnes Paket, so wird sie auf mehrere Pakete aufgeteilt. Da Snort in der Standard-Einstellung den Datenverkehr Paket für Paket bearbeitet und somit keine Informationen über vorhergegangene Pakete zur Verfügung stehen, kann dieser Umstand dazu ausgenutzt werden um auf einfache Weise einen Angriff unbemerkt an einem Network Intrusion Detection System vorbei zu schleusen. Die in Abbildung 4.1 dargestellte Regel durchsucht den Datenverkehr nach Paketen, die den String enthalten. Da bei einem Aufruf einer Internetseite die 18

26 Schwächen von NIDS 19 alert tcp! /24 any -> /24 any / (content: ; msg: Aufruf von Evil.com ; sid: ;) Abbildung 4.1: Beispielregel Session Splicing aufgerufene Adresse an den Client übertragen werden muss, würde die dargestellte Snort Regel im Normalfall bei einem Aufruf der Internetseite einen Alert auslösen. Wird die MTU der zu übertragenden Pakete jetzt jedoch soweit verringert, dass die Adresse nicht mehr als zusammenhängender String übertragen werden kann sonder aufgeteilt werden muss, so schlägt das NIDS nicht mehr an. Abbildung 4.2: Session Splicing Abbildung 4.2 zeigt etwa einen Fall, in dem der String in die zwei Teilstrings und vil.com zerlegt wurde. Für das Network Intrusion Detection System trifft für keinen der beiden Teilstrings die Regel 4.1 zu. Der Client, für den die Pakete bestimmt sind, setzt diese jedoch wieder zusammen und erhält damit unbemerkt NIDS die Adresse Diese Methode der Umgehung von NIDS kann auf verschiedene Weisen modifiziert werden. Da jedes TCP Paket eine eindeutige Sequenz Nummer enthält, an Hand deren der Empfänger den TCP-Verkehr in der richtigen Reihenfolge zusammen setzen kann ist es dem Angreifer möglich, die Pakete in vertauschter Reihenfolge zu verschicken. Wie bereits angedeutet kann diese Art der Verschleierung durch den Einsatz eines Präprozessors verhindert werden. Wird etwa der Präprozessor Stream5 eingesetzt, so werden fragmentierte Pakete vor der Untersuchung durch die Regeln wie auf dem Client zusammengesetzt wodurch der Angriffsversuch erkannt werden kann.

27 Schwächen von NIDS Denial of Service Eine weitere, wenn auch nicht so unauffällige Methode, ein Network Intrusion Detection System zu umgehen ist ein sogenannter Denial of Service Angriff. Bei einem Denial of Service Angriff wird das System soweit ausgelastet, dass es seine eigentliche Tätigkeit, in diesem Fall das Überprüfen des Datenverkehres, nicht mehr ausführen kann. Um den Netzwerkverkehr nicht zu blockieren sind die meisten NID-System standardmäßig so konfiguriert, dass der Verkehr bei zu hoher Last nicht mehr überprüft wird. Ein Angreifer kann nun ein Netzwerk etwa mit Verbindungsanfragen oder vermeintlichen Angriffen fluten, bis das NIDS überlastet ist und den weiteren Verkehr und somit auch den eigentlichen Angriff passieren lässt. Ein Denial of Service Angriff kann jedoch nicht nur durch einen Angreifer ausgelöst werden sondern auch das Resultat einer unsorgfältigen Implementierung sein. Muss ein NIDS mehr Verkehr verarbeiten, als die Hardware verkraften kann so kann es auch bei normalem Datenverkehr ohne Eingriff eines Angreifers zu einem Ausfall des Systems und damit zu unerkannten Angriffen kommen. 4.3 Weitere Schwächen Wie bereits beschrieben hängt die Sicherheit eines NIDS Systems vor allem von der Qualität der eingesetzten Regeln ab. Sind die Regeln zu strikt, werden unter Umständen nicht alle Angriffe erkannt, sind die Regeln zu unscharf können viele Fehlalarme auftreten, was die Arbeit mit dem System erschwert. Werden tatsächliche Angriffe auf Grund von zu vielen Fehlalarmen übersehen, wird auch die Sicherheit des Netzwerkes beeinträchtigt. Da ein passives System die einzelnen Angriffe nur protokolliert müssen hier die ausgegebenen Alerts von Hand überprüft und im einzelnen entschieden werden, ob es sich tatsächlich um einen Angriff handelt oder nicht und wie weiter verfahren werden soll. Hierzu kommt, dass es oftmals umfangreiche Kenntnisse der Netzwerk-Protokolle benötigt, um einen tatsächlichen Angriff von einem Fehlalarm zu unterscheiden, was die Wartung eines Network Intrusion Detection Systemes sehr kompliziert und zeitaufwändig macht.

28 Schwächen von NIDS 21 Um einen ausreichenden Schutz für das überwachte System bieten zu können, sollte ein Network Intrusion Detecion System niemals alleine, sondern ausschließlich in Kombination mit anderen Sicherheits-Systemen wie etwa Virenscanner und Firewalls verwendet werden.

29 Kapitel 5 Praktikum Für die folgenden Übungsaufgaben stehen zwei VMs zur Verfügung: Kali Angreifer Benutzername: root Passwort: toor Netzwerk: Host Only Debian NIDS-Host Benutzername: user Passwort: user Root Passwort: toor Netzwerk: Host Only Installierte Programme: Snort, ProFTPD Beide VMs müssen sich im gleichen Subnetz befinden. Dies kann über die Befehle ifconfig und ifconfig eth0 [ip] sichergestellt werden. Auf dem Desktop der Debian-VM befindet sich zudem das Handbuch von Snort im PDF Format 22

30 Praktikum 23 Aufgabe 1: Snort starten Die erste Aufgabe besteht darin, sich mit Snort vertraut zu machen. Beantworten Sie dazu folgende Fragen: Wie wird Snort gestartet? Wie wird Snort in den einzelnen Modi gestartet? (Logging, NIDS) Wo befindet sich die Beispielkonfiguration snort.conf? Aufgabe 2: Google.de In der folgenden Aufgabe soll Snort dazu eingesetzt werden, beim Aufruf von bestimmten Seiten Alarm zu schlagen. Erstellen Sie eine Regel, die beim Aufruf der Seite Google.de einen Alert auslöst. Legen Sie dazu eine neue Konfigurationsdatei an und starten Sie Snort mit dieser. Für diesen Test muss die VM auf Bridge oder NAT eingestellt werden. Überprüfen Sie an Hand der gespeicherten Alert-Meldungen, ob die Regel ausgeführt wurde Zusatzaufgabe: Das Logfile snort.log.[nummer] kann mit Snort betrachtet werden Welche Nachteile kann es haben, wenn hier einfach mit der Option content auf einen String geprüft wird? Aufgabe 3: FTP In Aufgabe drei wird Snort für die Überwachung eines FTP-Servers eingesetzt. Dazu läuft auf der Debian-VM ein ProFTPD-Server, der zum Testen verwendet werden kann. Angelegte Nutzer sind:

31 Praktikum 24 Username admin user Passwort passwort123 user Erstellen Sie eine Regel, die einen Verbindungsversuch mit dem Benutzernamen admin loggt Erstellen Sie eine Regel, die bei einem Fehlgeschlagenen Anmeldeversuch einen Alert auslöst Testen Sie auch hier an Hand des Log-Files und der gespeicherten Alert-Meldungen, ob Ihren Regeln richtig angewendet wurden. Aufgabe 4: Netzwerk-Scan erkennen Die Letzte Aufgabe besteht darin, einen Port-Scan zu erkennen. Erstellen Sie eine Regel, die einen sogenannten FIN-Scan erkennt und lassen Sie einen Alert ausgeben. Der Scan kann mit dem Kommando nmap -sf [IP] ausgeführt werden.

32 Praktikum Lösungen Aufgabe 1 Snort kann in verschiedenen Modi gestartet werden: Sniffing Modus snort -v Logging Modus snort -l./logfile NIDS Modus snort -c snort.conf Die Beispielkonfigurationsdatei befindet sich an unter folgendem Pfadetc/snort/snort.conf Aufgabe 2 Diese Aufgabe kann auf mehrere Wege gelöst werden. Eine Möglichkeit ist, in den übermittelten Paketen nach dem String google.de zu suchen. alert tcp any any -> any any / (content: google.de ; msg: Aufruf von Google.de ; sid: ;) Abbildung 5.1: Aufgabe 2 Lösungsmöglichkeit 1 Diese Regel ist zwar einfach, und löst bei einem Aufruf von Google einen Alarm aus, wird jedoch auch getriggert, wenn etwa auf einer anderen Seite nach dem String google.de gesucht wird und dieser unverschlüsselt übertragen wird. Sauberer aber auch aufwändiger wäre deshalb etwa die IPs von Google anzugeben (msg: Aufruf von Google ; sid: ;) Abbildung 5.2: Aufgabe 2 Lösungsmöglichkeit 2 Hierbei muss jedoch beachtet werden, dass Google mehrere IPs besitzt, die alle eingetragen werden müssen um eine sichere Regel zu schreiben.

33 Praktikum 26 log tcp any any -> [IP vom FTP-Server] 21 / (content: admin ; msg: FTP Login Versuch ; sid: ;) Abbildung 5.3: Aufgabe 3 Lösung Aufgabe 3 Um einen Anmeldeversuch an einem FTP-Server mit dem Account admin Aufzuzeichnen bietet es sich an, nach dem String admin Ausschau zu halten. Um einen fehlgeschlagenen Login-Versuch zu erkennen, empfiehlt es sich die FTP-Fehlercodes auszunutzen. Schlägt ein login fehl, so sendet der FTP-Server eine Antwort mit dem Fehlercode 530. log tcp [IP vom FTP-Server] 21 -> $HOME NET any / (content: 530 ; msg: Fehlgeschlagener FTP-Login ; sid: ;) Abbildung 5.4: Aufgabe 3 Lösung 2 Hierbei ist zu beachten, dass dies eine Antwort vom FTP-Server ist, also eingehende Pakete zu untersuchen sind Aufgabe 4 Ein SYN-FIN-Scan ist ein Scan, bei dem die SYN-ACK-Sequenz Sofort mittels eines gesetzten FIN-Flags abgebrochen wird. Charakteristisch ist daher ein gesetztes FIN- Flag im Paket mit der Sequenznummer 1. log tcp!$home NET any -> $HOME NET any / (msg: SYN-FIN-Scan ; seq:1; flags:f; sid: ;) Abbildung 5.5: Aufgabe 4 Lösung 1

34 Literaturverzeichnis [1] L. Todd Heberlein Karl N. Levitt Biswanath Mukherjee. Network Intrusion Detection. pdf, [2] Bloomberg. Sourcefire named to infoworld s open source hall of fame. bloomberg.com/apps/news?pid=newsarchive&sid=aacpmab3dbu0. [3] BSI. BSI-Leitfaden zur Einführung von Intrusion-Detection-Systemen. https: // [4] Juniper. Idp series intrusion detection and prevention: Application and network intrusion detection - juniper networks. products-services/security/idp-series/. [5] Carsten Crantz Markus Kobe. Seminararbeit - Intrusion Detection System. 8_IDS.pdf, [6] Martin Roesch. Snort - Lightweight Intrusion Detection for Networks. http: // [7] Network Security Resource. Intrusion Detection Systems. utexas.edu/~netsec/ids.html, [8] nmap. Timing and performance. [9] Ricky M. Magalhaes. Host-Based IDS vs Network-Based IDS. http: // Hids_vs_Nids_Part1.html,

35 Quellen 28 [10] Snort. Snort :: Home Page. [11] Chris Green Sourcefire, Martin Roesch. Snort Users Manual. Snort Manual, [12] Stephen Northcutt and Judy Nocak. Network Intrusion Detection. New Riders Pub., Indianapolis and Ind, 3 edition, 2002, c2003. [13] Timothy N. Newsham Thomas H. Ptacek. Insertion, Evasion and Denial of Service: Eluding Network Intrusion Detection. secnet_ids.pdf, [14] Edwin Reusch Tillmann Werner. WID-Portal - Sondervorlesung Netzsicherheit: IDS Evasion: Eine technische Einführung. events/special/bsi/ _sondervorlesung_netzsicherheit_ publication.pdf, [15] Types of Intrusion Detection Systems. Types of Intrusion Detection Systems (IDS). types-of-intrusion-detection-systems.htm, [16] William Stallings. Introduction to Network-Based Intrusion Detection Systems [17] WindowSecurity.com. FAQ: Network Intrusion Detection Systems :: Intrusion Detection :: White Papers. intrusion_detection/faq_network_intrusion_detection_systems_.html#1., 2013.