Ausarbeitung

HTW Aalen
Projektarbeit
Network Intrusion Detection Systeme
Autor:
Betreuer:
Andreas Heißel
Prof. Dr. Roland Hellmann
Eine Projektarbeit, erstellt im Rahmen der Vorlesung
Netzwerksicherheit SS2013
des Studienganges
Informatik
2. Juli 2013
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
Inhaltsverzeichnis
Erklärung
i
Abbildungsverzeichnis
iv
Tabellenverzeichnis
v
Abkürzungen
vi
1 Einleitung
1.1 Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.3 Ziel der Arbeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1
1
1
2
2 Network Intrusion Detection Systeme
2.1 Aktives NIDS . . . . . . . . . . . . . . . . . .
2.2 Passives NIDS . . . . . . . . . . . . . . . . .
2.3 Funktion eines NIDS . . . . . . . . . . . . . .
2.3.1 Erkennung von Angriffsmustern . . . .
2.3.2 Abweichung vom Normalverhalten . .
2.3.2.1 Protokollanalyse . . . . . . .
2.3.2.2 Erkennung durch Statistische
2.3.3 Korrelation von Ereignisdaten . . . . .
2.4 Aufbau von NIDS . . . . . . . . . . . . . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
Daten
. . . .
. . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
3
3
4
5
5
6
6
7
8
9
3 Snort
3.1 Installation und erste Konfiguration
3.2 Die Arbeit mit Snort . . . . . . . . .
3.2.1 Programmaufruf . . . . . . .
3.3 Snort Regeln . . . . . . . . . . . . .
3.3.1 Aufbau der Snort Regeln . .
3.3.2 Beispielregel . . . . . . . . . .
3.4 Präprozessoren . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
11
11
12
12
13
14
16
16
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
4 Schwächen von NIDS
18
4.1 Session Splicing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.2 Denial of Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
4.3 Weitere Schwächen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
ii
Inhalt
5 Praktikum
5.1 Lösungen . . .
5.1.1 Aufgabe
5.1.2 Aufgabe
5.1.3 Aufgabe
5.1.4 Aufgabe
Literaturverzeichnis
iii
.
1
2
3
4
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
22
25
25
25
26
26
27
Abbildungsverzeichnis
2.1
2.2
2.3
Aktives NIDS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Passives NIDS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Mögliche Layouts für ein NIDS . . . . . . . . . . . . . . . . . . . . . . . .
3.1
3.2
Aufbau einer Snort Regel . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Snort Beispielregel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.1
4.2
Beispielregel Session Splicing . . . . . . . . . . . . . . . . . . . . . . . . . 19
Session Splicing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
5.1
5.2
5.3
5.4
5.5
Aufgabe
Aufgabe
Aufgabe
Aufgabe
Aufgabe
2
2
3
3
4
Lösungsmöglichkeit 1
Lösungsmöglichkeit 2
Lösung 1 . . . . . . .
Lösung 2 . . . . . . .
Lösung 1 . . . . . . .
.
.
.
.
.
iv
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
4
5
9
25
25
26
26
26
Tabellenverzeichnis
3.1
3.2
3.3
Mögliche Aktionen für Snort Regeln . . . . . . . . . . . . . . . . . . . . . 14
Sonderzeichen bei der Angabe von Quell- und Zieladresse . . . . . . . . . 15
Mögliche Rule-Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
v
Abkürzungen
NIDS
Network Intrusion Detection System
IDS
Intrusion Detection System
IDPS
Intrusion Detection and Prevention System
(D)DoS
(Distributed) Denial Of Service
TTL
Time To Live
MTU
Maximum Transmission Unit
NIDPS
Network Intrusion Detection and Prevention System
vi
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
Einleitung
1.3
2
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.
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 E-Mail 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
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
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 E-Mail 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.
2.3.1
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,
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]
2.3.2
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.
2.3.2.1
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, 92-101] 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
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.
2.3.2.2
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.
Network Intrusion Deteciton Systeme
2.3.3
8
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.
Network Intrusion Deteciton Systeme
2.4
9
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
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.
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
Snort
12
sudo apt-get install snort. Nach der Installation erstellt Snort eine StandardKonfigurationsdatei 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.
3.2.1
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.
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.
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
3.3.1
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 2.9.4.6 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.
Snort
15
Zeichen
any
!
20:22
:1023
1023:
Bedeutung
Beliebige IP oder Port
Adresse oder Port negieren
Port-Bereich
’kleiner als’
’größer als’
Tabelle 3.2: Sonderzeichen bei der Angabe von Quell- und Zieladresse
10.0.1.0/24 80 -> 192.168.10.0/24 80
Folgende Zeile etwa legt fest, dass diese Regel nur auf Pakete angewandt wird, die aus
dem Subnetz 10.0.1.0/24 von Port 80 kommen und an eine Adresse im IP-Bereich
192.168.10.0/24 an Port 80 adressiert sind. Zur Festlegung des Quell- und Ziel-Adressbereiches sind verschiedene Sonderschreibweisen möglich, die es etwa ermöglichen PortBereiche 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
1.000.000 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.
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
3.3.2
Beispielregel
alert tcp !10.1.1.0/24 any -> 10.1.1.0/24 any /
(flags: SF; msg: ”SYN-FIN-Scan”; sid: 123456;)
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 10.1.1.0/24
• Seine Zieladresse liegt im Subnetz 10.1.1.0/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:
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]
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 www.evil.com enthalten. Da bei einem Aufruf einer Internetseite die
18
Schwächen von NIDS
19
alert tcp !10.1.1.0/24 any -> 10.1.1.0/24 any /
(content: ”www.evil.com”; msg: ”Aufruf von Evil.com”; sid: 123456;)
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 www.evil.com 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 www.evil.com in die zwei Teilstrings www.e 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 www.evil.com.
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.
Schwächen von NIDS
4.2
20
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.
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.
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
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:
Praktikum
24
Username
Passwort
admin
passwort123
user
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.
Praktikum
25
5.1
Lösungen
5.1.1
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
5.1.2
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: 123456;)
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: 123456;)
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.
Praktikum
26
log tcp any any -> [IP vom FTP-Server] 21 /
(content: ”admin”; msg:”FTP Login Versuch”; sid: 123456;)
Abbildung 5.3: Aufgabe 3 Lösung 1
5.1.3
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: 123456;)
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.
5.1.4
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 FINFlag im Paket mit der Sequenznummer 1.
log tcp !$HOME NET any -> $HOME NET any /
(msg:”SYN-FIN-Scan”; seq:1; flags:F; sid: 123456;)
Abbildung 5.5: Aufgabe 4 Lösung 1
Literaturverzeichnis
[1] L. Todd Heberlein Karl N. Levitt Biswanath Mukherjee.
on Detection.
Network Intrusi-
http://wenke.gtisc.gatech.edu/ids-readings/network_id.
pdf, 22.08.2011.
[2] Bloomberg. Sourcefire named to infoworld’s open source hall of fame. http://www.
bloomberg.com/apps/news?pid=newsarchive&sid=aaCpMAb3DbU0.
[3] BSI. BSI-Leitfaden zur Einführung von Intrusion-Detection-Systemen. https:
//www.bsi.bund.de/DE/Publikationen/Studien/ids02/zus_htm.html, 2010.
[4] Juniper.
Idp series intrusion detection and prevention: Application and net-
work intrusion detection - juniper networks. http://www.juniper.net/us/en/
products-services/security/idp-series/.
[5] Carsten Crantz Markus Kobe.
Seminararbeit - Intrusion Detection System.
http://www.informatik.uni-hamburg.de/RZ/lehre/18.415/seminararbeit/
8_IDS.pdf, 17.04.2003.
[6] Martin Roesch. Snort - Lightweight Intrusion Detection for Networks. http:
//www.mathcs.richmond.edu/~dszajda/classes/cs334/papers/snort.pdf,
11.08.2009.
[7] Network Security Resource. Intrusion Detection Systems. https://www.ischool.
utexas.edu/~netsec/ids.html, 07.02.2002.
[8] nmap. Timing and performance. http://nmap.org/book/man-performance.html.
[9] Ricky M. Magalhaes.
Host-Based IDS vs Network-Based IDS.
http:
//www.windowsecurity.com/articles-tutorials/intrusion_detection/
Hids_vs_Nids_Part1.html, 23.01.2013.
27
Quellen
28
[10] Snort. Snort :: Home Page. http://www.snort.org/.
[11] Chris Green Sourcefire, Martin Roesch. Snort Users Manual. Snort Manual, 2013.
[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. http://insecure.org/stf/secnet_ids/
secnet_ids.pdf, 12.04.2013.
[14] Edwin Reusch Tillmann Werner. WID-Portal - Sondervorlesung Netzsicherheit: IDS
Evasion: Eine technische Einführung. http://net.cs.uni-bonn.de/fileadmin/
events/Special/BSI/2007-07-04_Sondervorlesung_Netzsicherheit_
publication.pdf, 05.05.2009.
[15] Types of Intrusion Detection Systems. Types of Intrusion Detection Systems (IDS).
http://www.omnisecu.com/security/infrastructure-and-email-security/
types-of-intrusion-detection-systems.htm, 03.02.2011.
[16] William Stallings. Introduction to Network-Based Intrusion Detection Systems.
http://www.informit.com/articles/article.aspx?p=782118, 2007.
[17] WindowSecurity.com.
FAQ: Network Intrusion Detection Systems :: Intrusion
Detection :: White Papers.
http://www.windowsecurity.com/whitepapers/
intrusion_detection/FAQ_Network_Intrusion_Detection_Systems_.html#1.,
2013.