vergleich und einführung von intrusion detection systemen · intrusion detection von network...

Fachhochschule Konstanz Hochschule für Technik, Wirtschaft und Gestaltung

Vergleich und Einführung von Intrusion Detection Systemen

Adrian Müller

Konstanz, 30.09.2002

Diplomarbeit

< elektronische Version >

© 2002 Adrian Müller

FFaacchhhhoocchhsscchhuullee KKoonnssttaannzz

FFaacchhbbeerreeiicchh IInnffoorrmmaattiikk

Vergleich und Einführung von IDS 1. Einleitung

Diplomarbeit Adrian Müller Seite 2 von 102

Diplomarbeit

zur Erlangung des akademischen Grades

Diplom-Informatiker (FH)

an der

Fachhochschule Konstanz Hochschule für Technik, Wirtschaft und Gestaltung

im Fachbereich Informatik/Technische Informatik

Thema: Vergleich und Einführung von Intrusion Detection Systemen Diplomand: Adrian Müller

Darrenbaum 10 78628 Rottweil

Firma: KirchMedia GmbH & Co KGaA

Robert-Bürkle-Str. 3 85737 Ismaning

Betreuer: Professor Helmut Malz,

Fachhochschule Konstanz Dipl.-Ing. (UNI) Udo Fredel, KirchMedia GmbH & Co KGaA

Abgabetermin: 30. September 2002



Anlage 5

Ehrenwörtliche Erklärung

Hiermit erkläre ich, Adrian Müller, geboren am 27.Januar 1976 in Rottweil, ehrenwörtlich,

(1) dass ich meine Diplomarbeit mit dem Titel: „Vergleich und Einführung von Intrusion Detection Systemen„

bei KirchMedia GmbH & Co KGaA unter Anleitung von Professor Helmut Malz selbständig und ohne fremde Hilfe angefertigt habe und keine anderen als in der Abhandlung angeführten Hilfen benutzt habe;

(2) dass ich die Übernahme wörtlicher Zitate aus der Literatur sowie die

Verwendung der Gedanken anderer Autoren an den entsprechenden Stellen innerhalb der Arbeit gekennzeichnet habe.

Ich bin mir bewusst, dass eine falsche Erklärung rechtliche Folgen haben wird. Konstanz, 30.09.2002



Zusammenfassung Thema: Vergleich und Einführung von Intrusion Detection Systemen Diplomand: Adrian Müller

Darrenbaum 10 78628 Rottweil

Firma: KirchMedia GmbH & Co KGaA

Robert-Bürkle-Str. 3 85737 Ismaning

Betreuer: Professor Helmut Malz

Fachhochschule Konstanz

Dipl.-Ing. (UNI) Udo Fredel KirchMedia GmbH & Co KGaA

Abgabetermin: 30. September 2002 Schlagworte: ID-Systeme, Vergleich, Probleme, Lösungen, Einführung IDS Beschreibung: In der Diplomarbeit werden verschiedene, schon auf dem Markt befindliche Intrusion Detection Systeme auf unterschiedliche Kriterien verglichen. Es werden mögliche Einsatzarten und Einsatzorte mit ihren Vor- und Nachteilen durchleuchtet und besprochen. Auf Basis der erlangten Erkenntnisse wird ein System vorgeschlagen, das nach Abstimmung mit dem Projektleiter eingesetzt werden soll. Zu den Einsatzkriterien gehören das vorhandene Budget, die Netzwerkumgebung, die Ausstattung und Leistungsfähigkeit des Einsatz-Intrusion Detection Systems sowie die Art des Intrusion Detection Systems. Geplant ist der Einsatz mindestens eines bzw. mehrer Systeme als eine sogenannte Enterprise-Lösung. Mittels verschiedener Hilfsmittel und Tools werden die Intrusion Detection Systeme eTrust von Computer Associates, Real Secure von ISS, Snort, Tripwire und Network Intrusion Detection von Network Flight Recorder untersucht. Der Test und Betrieb dieser Systeme geschieht sowohl vor, als auch hinter der Firewall also in der demilitarisierten Zone des Unternehmens. Die Untersuchung der Systeme beinhaltet Kontrollen über Systemstabilität, Prozessor- und Hauptspeicherauslastung, Anzahl der erkannten Angriffe auf Basis simulierter Angriffe sowie die Benutzerfreundlichkeit.



Inhaltsverzeichnis 1. Einleitung................................................................................................................. 10

2. Umgebung................................................................................................................ 14

3. ID-Systeme............................................................................................................... 17

3.1 Einsatzgebiete von IDS ........................................................................................ 18

3.2 Arten von ID-Systemen ....................................................................................... 19

3.2.1 Netzwerkbasierende IDS............................................................................... 20

3.2.2 Netzknotenbasierende IDS............................................................................ 22

3.2.3 Hostbasierende IDS....................................................................................... 24

3.3 Konfiguration und Umgebung ............................................................................. 26

3.3.1 Regeln / Rules ............................................................................................... 26

3.3.2 Netzwerkbesonderheiten............................................................................... 26

3.4 Allgemeine Einsatzarten...................................................................................... 28

3.4.1 Einsatzumgebung.......................................................................................... 28

3.4.2 Administration und Management ................................................................. 30

3.5 Benachrichtigung und Alarmierung..................................................................... 32

3.5.1 e-Mail ............................................................................................................ 32

3.5.2 SNMP-Trap................................................................................................... 32

3.5.3 Popup-Fenster ............................................................................................... 32

3.5.4 Akustische Signale ........................................................................................ 33

3.5.5 Sonstige Benachrichtigung / Alarmierung.................................................... 33

3.6 Auswirkungen des Betriebssystems..................................................................... 35

4. Vergleich von Intrusion Detection Systemen .......................................................... 37

4.1 Kriterien des Vergleichs ....................................................................................... 37

4.1.1 Auslastung..................................................................................................... 37

4.1.2 Umgebung..................................................................................................... 37

4.1.3 Angriffserkennung ........................................................................................ 37

4.1.4 Alarme........................................................................................................... 39

4.1.5 Signaturen ..................................................................................................... 39

4.1.6 Art des IDS.................................................................................................... 39



Inhaltsverzeichnis 4.2 Testumgebung...................................................................................................... 40

4.2.1 Einsatzorte..................................................................................................... 40

4.2.2 Testhardware ................................................................................................. 41

4.2.3 Testwerkzeuge .............................................................................................. 41

5. Getestete Intrusion Detection Systeme .................................................................... 42

5.1 Snort mit Analyseprogramm ACID ..................................................................... 42

5.1.1 Installation..................................................................................................... 42

5.1.2 Konfiguration................................................................................................ 43


5.1.4 Betrieb ........................................................................................................... 47

5.1.5 Fazit............................................................................................................... 47

5.2 Computer Associates - eTrust.............................................................................. 49

5.2.1 Installation..................................................................................................... 49

5.2.2 Konfiguration................................................................................................ 50


5.2.4 Betrieb ........................................................................................................... 53

5.2.5 Fazit............................................................................................................... 53

5.3 Tripwire................................................................................................................ 55

5.3.1 Installation..................................................................................................... 55

5.3.2 Konfiguration................................................................................................ 55


5.3.4 Betrieb ........................................................................................................... 58

5.3.5 Fazit............................................................................................................... 59

5.4 ISS - Real Secure ................................................................................................. 60

5.4.1 Installation..................................................................................................... 60

5.4.2 Konfiguration................................................................................................ 61


5.4.4 Betrieb ........................................................................................................... 65

5.4.5 Fazit............................................................................................................... 66



Inhaltsverzeichnis 5.5 NFR – Network Intrusion Detection.................................................................... 68

5.5.1 Installation..................................................................................................... 68

5.5.2 Konfiguration................................................................................................ 69


5.5.4 Betrieb ........................................................................................................... 72

5.5.5 Fazit............................................................................................................... 72

6. Zusammenfassung.................................................................................................... 74

6.1 Erkenntnisse ......................................................................................................... 76

6.2 Aufgetretene Probleme ........................................................................................ 77

7. Einführung von Intrusion Detection Systemen........................................................ 80

8. Quellen..................................................................................................................... 83

Anhang A – IDS Vergleichslisten................................................................................ 85

Snort........................................................................................................................... 85

CA - eTust .................................................................................................................. 88

Tripwire...................................................................................................................... 92

ISS Real Secure.......................................................................................................... 95

NFR – Network Intrusion Detection........................................................................ 100



Vorwort

Das Thema „Vergleich und Einführung von Intrusion Detection Systemen“ wurde von

Herrn Dierolf, Leiter des Bereichs Zentrale Informatik und Herrn Fredel, Leiter des

Teams Netzwerk Technologie, vorgeschlagen. Aufgrund der Größe des Unternehmens

und aufgrund des Themengebietes und der Arbeitsumgebung habe ich mich für die

KirchMedia als Betreuer meiner Diplomarbeit entschieden.

Der Sinn und Zweck dieser Diplomarbeit ist das Verstärken der Sicherheit des

lokalen, internen Netzes.

Besondere Schwierigkeiten entstanden am 08.04.2002, als die KirchMedia Insolvenz

beantragte und somit die Weiterführung der Diplomarbeit ins Wanken brachte.

Ich möchte mich hier nochmals für die Mühen und Umstände, insbesondere bei Herrn

Udo Fredel, Herrn Günter Dierolf, Frau Andrea Piderit, Frau Sylvia Bachmaier, Frau

Rosemarie Weindl, Herrn Hans Püttner und dem Netzwerkteam der KirchMedia

GmbH & Co. KGaA bedanken, die mich während der Anfertigung meiner

Diplomarbeit tatkräftig unterstützt haben und stets mit Rat und Tat zur Seite standen.

Ein besonderer Dank geht natürlich noch an alle Mitarbeiter der Zentrale Informatik.

Desweiteren möchte ich mich hiermit bei meinem betreuenden Professor Herrn

Helmut Malz für sein Engagement und seine Ratschläge recht herzlich bedanken.

Ismaning, 30.September 2002

Adrian Müller



Abbildungsverzeichnis Abbildung 1 - Aufbau eines Firmennetzwerkes mit redundantem Internetzugang ....... 16

Abbildung 2 - Netzwerkbasierendes IDS ...................................................................... 20

Abbildung 3 - Netzknotenbasierendes IDS.................................................................... 22

Abbildung 4 - Hostbasierendes IDS .............................................................................. 24

Abbildung 5 - Liste der simulierten Angriffe ................................................................ 38

Abbildung 6 - Oberfläche Snort + ACID....................................................................... 45

Abbildung 7 - Details zu einem Alarm.......................................................................... 46

Abbildung 8 - Übersicht der Alarme von eTrust ........................................................... 49

Abbildung 9 - Anpassen der Regeln und Signaturen..................................................... 50

Abbildung 10 - generierter Report von Tripwire ........................................................... 57

Abbildung 11 - Hinzufügen der Sensoren zum Event-Kollektor................................... 62

Abbildung 12 - Auswahl einer Sensor-Policy ............................................................... 63

Abbildung 13 - Ansicht der Alarme nach Events .......................................................... 66

Abbildung 14 - Übersicht der Alarme des NFR Network Intrusion Detection ............. 69

Abbildung 15 - N-Code eines DoS-Angriffs ................................................................. 70

Abbildung 16 - Firewall mit Proxies ............................................................................. 78

Abbildung 17 - Standalone-NIDS in der DMZ.............................................................. 81

Abbildung 18 - Zwei NID-Systeme im Verbund ........................................................... 82



1. Einleitung

In Zeiten des e-Commerce und der wachsenden Netzwerk- und Internet-Gesellschaft

wird der Ruf nach Sicherheit immer lauter. Die Zeiten, in denen das Internet der gut

verdienenden Oberschicht vorbehalten war, sind seit langem vorbei. Mittlerweile

werden mehr als 20% aller Verträge über das Internet abgeschlossen. Dies geschieht

zumeist über e-Mail oder Online-Konferenzen. Selbst Online-Banking und

Bestellungen über das Internet gehören sozusagen zum Tagesgeschäft der Internet-

User. Jedes größere Unternehmen und jeder Dienstleister ist mittlerweile über das

Internet erreichbar, da ohne Interne tzugang ein Wettbewerbsnachteil droht. Das

Internet ist in manchen Branchen das Informationsmedium Nr.1 geworden. 50% aller

deutschen haben einen Zugang zum Internet, wobei 75% dieser Personen das Internet

regelmäßig, d.h. mehrmals Wöchentlich, nutzen.1)

Der Ausbau der Firmennetzwerke schreitet immer mehr voran. So werden LANs1,

VPNs2, Intranets und Extranets mit rasender Geschwindigkeit aufgebaut. Dies führt

vor allem zu Zeiteinsparungen, erhöhtem und verbessertem Informationsfluss sowie

zur besseren Kommunikation unter den Mitarbeitern. Um mehrere

Firmenniederlassungen miteinander verbinden zu können, wird wiederum das Internet

benutzt. Somit werden firmeninterne und somit sicherheitsrelevante Daten über das

Internet ausgetauscht und eventuell sogar unverschlüsselt zwischen den einzelnen

Niederlassungen übertragen. Die Folge ist, dass Hacker mit Hilfe von Programmen

und Scripten Firmeninterna für jedermann offen legen können und somit der

Konkurrenz einen Wettbewerbsvorteil verschaffen. Werksspionage dieser Art hat

schon vielen Unternehmen hohe Verluste und zum Teil auch den Konkurs

eingebracht.

Erst nach einer so genannten „Lernphase“ wurden die Sicherheitsrichtlinien und die

Sicherheitspolitik der Firmennetzwerke überdacht. Der Grund hierfür ist, dass ein

Zugang zum Internet anfänglich teuer war und es meist noch kein Budget für die

1) Informationen laut http://www.pcwelt.de/news/internet/18557/ 1 LAN = Local Area Network 2 VPN = Virtual Private Network



Sparte „Sicherheit“ gab. Somit war auch die Absicherung mittels eines Paketfilters

oder einer Firewall ein Luxus, da diese Komponenten sehr teuer waren, bzw. noch

sehr teuer sind.

Mittlerweile ist eine gewisse Sicherheitsstruktur- und Sensibilität in den IT-Bereichen

eines Unternehmens unumgänglich. So werden zum Beispiel Firewalls, Paketfilter und

Verschlüsselungstechniken eingesetzt, um das Sicherheitsniveau des

Datenaustausches zu erhöhen.

Bislang galt eine Firewall als das „non plus ultra“ und sozusagen als das Allheilmittel,

um ein Netzwerk sicher zu machen. Es galt die Devise: „Wer eine Firewall im Einsatz

hat, ist vor Hackern sicher“. Diese Devise gerät in der Zeit eines enorm wachsenden

Sicherheitsbedarfs, in der Sicherheitskompromittierungen auf der Tagesordnung

stehen, immer mehr ins Schwanken. Vielmehr muss nun das Sicherheitskonzept

überarbeitet werden und ein komplettes Sicherheitspaket geschnürt werden, das aus

mehreren Komponenten besteht. Ein wirksameres Sicherheitskonzept sollte somit

folgende Komponenten beinhalten:

• Paketfilter

Ein Paketfilter arbeitet auf der Schicht 3 des ISO/OSI-Modells und filtert die

ankommenden Pakete nach Quell-Adressen, Ziel-Adressen, Ports und

Paketeigenschaften. Somit kann ein Angriff auf den unteren

Protokollschichtebenen frühzeitig abgewehrt werden. Dies sind z.B. DoS3-

Angriffe wie „SYN-Flooding“ oder ähnliche.

• Application Level Gateway (Firewall)

Die eigentliche Firewall arbeitet auf den Schichten 4-7 des ISO/OSI-

Modells und kann somit Zugriffe auf Anwendungen oder Server-Dienste

einschränken. Die Firewall erkennt zusätzlich Angriffe, die ein Paketfilter

nicht erkennt, da sie Pakete des Netzwerkverkehrs speichert, untersucht und

wieder zusammensetzt. Dadurch kann sie zu einem gewissen Grad die

Inhalte von Netzwerkpaketen mit Signaturen vergleichen und somit auf

versuchte Angriffe reagieren.

3 DoS = Denial of Service



• Intrusion Detection System (IDS)

Ein Intrusion Detection System wird überwiegend zum Erkennen von

Angriffen, Portscans und Überprüfen des Netzwerkverkehrs eingesetzt. Es

gibt unterschiedliche Arten von ID-Systemen, die später genauer

beschrieben werden. Einige ID-Systeme beinhalten auch Content Security

Systeme und indirekt auch Virus Detection Systeme.

• Content Security System

Um Firmeninformationen, die nicht für jedermann gedacht sind, zu schützen

und geheim zu halten, müssen der Netzwerk- sowie der e-Mailverkehr

überwacht werden. Die Inhalte aus e-Mails und Dateien werden mit

bestimmten Wörtern verglichen, die als „nicht öffentlich zugänglich“

gekennzeichnet sind. Diese Überprüfung der e-Mails und Dateien macht das

Content Security System.

• Virus Detection System (Viruswall)

Täglich kommunizieren Mitarbeiter über e-Mail miteinander und tauschen

Informationen und Dateien aus. Diese e-Mails können von außen kommen

und Anhänge enthalten, die mit Viren befallen sind. Besonders häufig

kommen Makroviren in Microsoft Office Dokumenten vor, die sich dann

über die Weitergabe einzelner Dokumente im Unternehmen ausbreiten.

Ebenso können sich schon eingeschleppte Viren über Festplatten und

Netzlaufwerke verbreiten und Dateien zerstören. Um dieser in den letzten

Jahren ansteigenden Virenflut Einhalt zu gewähren, werden sogenannte

Viruswalls eingesetzt, die den Netzwerkverkehr und die Dateien auf Servern

und Workstations ständig überprüfen.

• Verschlüsselung des Datenverkehrs

Um sichere Verbindungen zwischen Unternehmen und Handelspartner bzw.

Außenstelle gewährleisten zu können, müssen die sicherheitsrelevanten

Daten verschlüsselt werden. Die geschieht immer stärker durch den Aufbau

von VPNs4.

4 VPN = Virtual Private Network



Hierbei werden die Daten über einen sogenannten Tunnel ausgetauscht, der

mit IPSec5 oder anderen Protokollen verschlüsselt ist.

Bei näherem Betrachten der einzelnen Sicherheitssysteme stellt sich die Frage, wieso

eine Firewall zusammen mit einem Paketfilter nicht ausreicht, Angreifer vom

Firmennetzwerk fernzuhalten. Um den Einsatz von ID-Systemen genauer spezifizieren

zu können, werden in den folgenden Kapiteln die Hintergründe und Arbeitsweisen der

verschiedenen ID-Systeme beschrieben. Hieraus geht hervor, dass eine Firewall

alleine die Sicherheit des Firmennetzwerkes nicht gewährleisten kann.

5 IPSec = IP Security

Vergleich und Einführung von IDS 2. Umgebung


2. Umgebung

Die Ausgangssituation stellt ein gesamtes Firmennetzwerk, bestehend aus einzelnen,

segmentierten Netzwerken dar. Diese Situation lässt sich in vielen größeren

Unternehmen wiederfinden, für die eine ständige Internetverbindung und die daraus

resultierende Erreichbarkeit existenzabhängig ist.

Die Segmentierung eines Netzes in mehrere Teilnetze hat mehrere Vorteile. Einerseits

können die einzelnen Unternehmensbereiche voneinander getrennt werden, was zu

einer besseren Übersicht und Struktur führt. Andererseits lassen sich dadurch

unterschiedliche Standorte unterscheiden. Jedes Stockwerk bzw. jede Abteilung hat

einen eigenen IP-Adressraum bzw. befindet sich in einem eigenen Subnet. Dies

vereinfacht die Verwaltung und den Service, der bei Strukturänderungen wie z.B. bei

einem Umzug oder bei einer Ausgliederung nötig ist.

Wie bereits erwähnt, ist die ständige Anbindung an das Internet für viele Firmen

lebenswichtig. Aus diesem Grund müssen diese Zugänge redundant ausgelegt sein und

an den Stellen, an denen dies nicht möglich ist, muss ein Single Point of Failure

geschaffen werden, der schnellstmöglich und mit geringem Aufwand überbrückt, bzw.

Instand gesetzt werden kann.

Nachfolgend wird der Aufbau eines redundanten, segmentierten Netzwerks erläutert,

der mit der nachfolgenden Abbildung überprüft werden kann. Dieser Aufbau

entspricht meist einem Standort, der über weitere Verbindungen mit den anderen

Standorten verbunden ist. Diese Verbindungen wurden wegen Übersichtlichkeit nicht

eingezeichnet und werden hier auch nicht näher besprochen.

Um einen redundanten Internetzugang zu ermöglichen, werden zwei unabhängige

POP6-Zugänge benötigt (siehe Abbildung 1 - Aufbau eines Firmennetzwerkes mit

redundantem Internetzugang), die aufgrund ihrer Standortanbindung nicht miteinander

gekoppelt sind. Diese unterschiedlichen POP können von einem oder zwei

verschiedenen Anbietern gehostet werden, wobei für das Routing das BGP 7 verwendet

wird. Eine Anbindung an zwei verschiedene Anbieter erfordert einen „Provider

6 POP = Point of Presence 7 BGP = Border Gateway Protocol (ein Routing Protokoll)



Independent Adressbereich“, d.h. der IP-Adressbereich gehört zu keinem der beiden

ISPs8, sondern er gehört der Firma selbst.

Sollte eine Leitung aus irgendeinem Grund ausfallen, so ist immer noch eine Internet-

Verbindung vorhanden, um eine Aufrechterhaltung der Kommunikationswege

sicherzustellen. Die Firewalls, die über einen Switch miteinander verbunden sind, sind

ebenfalls redundant aufgebaut, um eine Hochverfügbarkeit des Zugangs und der

Sicherheit zu gewährleisten.

Diese Firewalls betreiben kein Load-Balancing um die Netzlast zu teilen, überwachen

sich aber mittels eines Heartbeats, wobei jede Firewall der anderen zu regelmäßigen

Zeitpunkten „ein Lebenszeichen“ sendet. Die Switches vor und hinter den Firewalls

sind nicht redundant ausgelegt und stellen somit einen Single Point of Failure (SPF)

dar.

Hinter dem zweiten Switch wird der Netzwerkverkehr für die demilitarisierte Zone

und das interne Netzwerk aufgespaltet. Die sogenannte demilitarisierte Zone (DMZ),

in der die für die Öffentlichkeit zugänglichen Dienste angeboten werden, ist ein

gesicherter Bereich. Diese Dienste sind unter anderem Web-Server (HTTP 9), File-

Server (FTP 10) und den für die e-Mail-Verteilung zuständigen Mail-Server (SMTP11).

Eine DMZ hat folgenden Vorteil: Falls es einem Hacker gelingen sollte,

Administrationsrechte auf einem Server zu erhalten, so hat er zwar die Möglichkeit

sich die anderen Server in der DMZ zugänglich zu machen, kommt aber aus der DMZ

nicht in das interne Netzwerk. Somit bleibt das interne Firmennetz einbruchsicher,

solange keine Server-Dienste darin nach außen angeboten werden.

Die Firewalls werden so eingesetzt, dass sie die IP-Adressen der inneren,

segmentierten Netze mit ihren eigenen IP-Adressen ersetzen. Diese Technik wird

„Masquerading“ genannt. Dies hat den Vorteil, dass die IP-Adressen der internen

Netze nicht nach außen gezeigt werden und somit keine externe Person die internen

Netzwerkadressen direkt ansprechen kann. Zusätzlich ist dies ein Schutz vor Hackern,

die versuchen mittels IP-Spoofing eine interne IP-Adresse vorzutäuschen. Beim IP-

8 ISP = Internet Service Provider 9 HTTP = Hypertext Transfer Protocol 10 FTP = File Transfer Protocol 11 SMTP = Simple Mail Transfer Protocol



Spoofing werden die ausgehenden IP-Pakete so umgeschrieben, dass anstelle der

eigenen IP-Adresse eine andere IP-Adresse verwendet wird. Diese andere IP-Adresse

ist meist eine IP-Adresse aus internen Netzen, bzw. eine interne IP-Adresse des

anzugreifenden Netzes. Durch diese Technik können Firewalls, Router oder

Paketfilter umgangen werden, da diese Komponenten die IP-Adresse überprüfen und

merken, sie kommt aus dem internen Netz. So wird das Paket ungehindert an die

Zieladresse weitergeleitet, ohne dass ein Alarm ausgelöst wurde.

Internet

Router Router

Stadt Stadt

Firewall mitPaketfilter

Firewall mitPaketfilter

Switch

Web-Server

FTP-Server

Mail-Server

PC

PCPC

PC

DMZ

Inte

rnet

Ser

vice

Pro

vide

r

Intern

et Service

Pro

vider

Inte

rnes

Fir

men

net

zwer

k

Switch Switch

Verbindungswege zum internen Netzwerk

Abbildung 1 - Aufbau eines Firmennetzwerkes mit redundantem Internetzugang

Vergleich und Einführung von IDS 3. ID-Systeme


3. ID-Systeme

ID-Systeme können auf unterschiedlichste Arten betrieben und eingesetzt werden. Aus

diesem Grund gibt es mehrere Arten von ID-Systemen, die im nächsten Abschnitt

näher beschrieben werden. Normalerweise werden ID-Systeme eingesetzt, um die

Netzwerksicherheit zu erhöhen und um gefährliche Angriffe zu erkennen, welche die

Firewall nicht erkannt hat. Es können über eine längere Zeitperiode bestimmter

Netzwerkverkehr oder sonstige Aktivitäten protokolliert werden.

In einem Netzwerk können ein oder mehrere ID-Systeme vorhanden sein. Hierbei

kann es sich um die unterschiedlichsten Arten von Systemen handeln. Es können

alleinstehende Systeme sein, oder sie können als Dienst, bzw. Prozess auf einem

bereits verwendeten System zusätzlich installiert werden. Wird nur ein einziges IDS in

einem Unternehmen eingesetzt, so spielt die Frage der zentralen Administration keine

große Rolle, denn der Informationsfluss eines Systems lässt sich durch Einstellungen

und Filterregeln einschränken. Ebenso kann das IDS über Webseiten oder SSH12

administriert werden. Kommen jedoch mehrere oder auch unterschiedliche Arten von

ID-Systeme zum Einsatz, so muss es eine zentrale Administrationsapplikation geben.

Diese Administrationsapplikation wird auch Managementkonsole genannt. Alle ID-

Systeme in einem Unternehmen werden so konfiguriert, dass sie die gesammelten

Informationen, Alarmmeldungen und Log-Files an das Managementsystem

weiterleiten. So können dann von der Managementkonsole alle ID-Systeme zentral

administriert werden. Einige dieser Managementkonsolen beinhalten die Möglichkeit,

neue ID-Systeme remote zu installieren.

Ein IDS kann ohne eine Verbindung zum Managementsystem installiert werden, so

dass es beim Auftreten eines Alarms verschiedene Möglichkeiten gibt, den

zuständigen Administrator zu informieren. Dies kann unter anderem die

Benachrichtigung per e-Mail, Pager oder SMS sein. Bei den meisten Systemen ist es

ebenfalls möglich, eine Benachrichtigung über das Netzwerk-Management-System per

SNMP13-Trap durchzuführen.

12 SSH = Secure Shell 13 SNMP = Simple Network Management Protocol



3.1 Einsatzgebiete von IDS

Die Einsatzgebiete richten sich je nach Anwendungsfall und Art des einzusetzenden

IDS. Mögliche Einsatzorte sind vor bzw. hinter einer Firewall, in einer DMZ oder im

internen Firmennetz.

Vor einer Firewall stellt das IDS einen zusätzlichen Angriffspunkt für Hacker dar,

falls es nicht als Stealth-IDS, d.h. ohne IP-Adresse oder mit speziellem Netzwerk-Tap

installiert wird. Ebenso ist die Flut an Fehlalarmen immens, so dass nicht immer

richtig entschieden werden kann, ob der erkannte Alarm auch einen möglichen

Angriffsversuch darstellt. Vor einer Firewall wird sämtlicher Netzwerkverkehr durch

das IDS geschleust, was eine sehr hohe Systemauslastung und evtl. das ungefilterte

Durchlassen von Paketen zufolge hat. Zusätzlich kommt Netzwerkverkehr, der

sowieso nicht durch die Firewall kommen würde, da die Protokolle oder Serverdienste

nicht angeboten werden. Das IDS sollte aus diesen Gründen nur für Testzwecke vor

der Firewall zum Einsatz kommen.

Hinter einer Firewall kann der nicht geblockte Verkehr vor der Weiterleitung

überprüft werden, wobei die Netzlast durch das Filtern der Firewall reduziert wurde.

Somit können zwar Angriffe auf die Firewall nicht erkannt werden, aber das IDS stellt

somit keinen potentiellen Angriffspunkt mehr dar.

Der Einsatz in einer DMZ ist sinnvoll, da der Netzwerkverkehr schon eingeschränkt

ist und der Netzwerkverkehr nur mit den Signaturen verglichen werden muss, dessen

Server in der DMZ vorhanden sind. So können, wenn kein FTP-Server in der DMZ

vorhanden ist, die Signaturen für das Erkennen von FTP-Angriffen komplett entfernt

werden, was zu einer Performancesteigerung und zu einer geringeren Fehlerrate führt.

Ein lokales, vom Internet abgeschirmtes Netz mit einem IDS auszurüsten, stellt eine

effektive Zusatzlösung dar. Das IDS kann somit zwar nicht vor externen Angriffen

schützen, wohl aber vor internen. Die Anzahl der internen Angriffe ist zwar

zurückgegangen, stellt aber immer noch ein hohes Gefährdungspotential dar, das

heutzutage immer noch vernachlässigt wird2).

2) Informationen laut: http://www.security-forum-news.de/sf/News/2002/01/04_trend.htm



3.2 Arten von ID-Systemen

Im Allgemeinen gibt es drei verschiedene Arten von Intrusion Detection Systemen.

Dies sind die Netzwerkbasierenden-, die Netzknotenbasierenden- und die

Hostbasierenden Intrusion Detection Systeme, die im nachfolgenden Abschnitt

behandelt werden. Sie unterscheiden sich in ihren Einsatzgebieten sowie an ihren

Verfahren, um Eindringlinge bzw. Angriffe zu analysieren und aufzuspüren. Bei

einigen Systemen ist ein Übergang oder die Kombination der Intrusion Detection

Systeme möglich, so dass diese nicht genau spezifiziert werden können. So kann z.B.

ein Netzwerkbasierendes Intrusion Detection System zusätzlich die Funktionalität

eines Hostbasierenden Intrusion Detection Systems vereinen, um sicherzustellen, dass

das IDS sicher ist, und keine unbefugte Person Dateien auf dem System verändert.

Dies ist eine doppelte Sicherheit, wobei dies aber selten realisiert wird.



3.2.1 Netzwerkbasierende IDS

Netzwerkbasierende Intrusion Detection Systeme (NIDS) werden entweder als

Hardwarekomponenten in 19 Zoll-Einbaugehäusen oder softwareseitig für die

Installation auf einem Rechner konzipiert. Diese Art von ID-Systemen ist wohl am

Aufwendigsten und folglich werden hohe Systemressourcen benötigt. Das

Einsatzgebiet dieses IDS ist in einem Netz als eigenständige Komponente, die den

Netzwerkverkehr des gesamten Teilnetzes mithört14.

Internet

Webserver

Firewall

Switch

FTP-Server

Mail-Server

DMZ

Netzwerkbasiertes IDS-System

Switch

Internes Netz

Netzwerkbasiertes IDS-System

Abbildung 2 - Netzwerkbasierendes IDS

Das NIDS versetzt die Netzwerkkarte in den sogenannten „promiscuous mode“, ein

Modus, bei dem die Netzwerkkarte sämtlichen Netzwerkverkehr aufnimmt, auch

wenn er nicht für den Rechner bestimmt ist, in dem die Netzwerkkarte steckt. Der

ankommende Netzwerkverkehr wird dann durch das NIDS mit verschiedenen

14 Das Mithören des Verkehrs in einem Netzwerk wird auch als „Sniffing“ (Schnüffeln) bezeichnet.



Signaturen verglichen, um potentielle Angriffe aufzudecken. Diese Signaturen

überprüfen den Verkehr auf verschiedene Protokolle, wie z.B. TCP15, UDP16, ICMP17,

verschiedene Dienste, verschiedene Flags in den Protokollen und/oder Zeichenketten

in den Netzwerkpaketen.

Um jedoch den Netzwerkverkehr auf verdächtige Zeichenketten oder potentiell

gefährliche Inhalte zu überprüfen, müssen mehrere Netzwerkpakete einer Verbindung

erfasst und zwischengespeichert werden. Um den kompletten Datenverkehr auswerten

zu können, müssen diese zwischengespeicherten Pakete zusammengesetzt und

anschließend mit den Signaturen verglichen werden.

Diese Signaturen lassen sich auf Protokolle, Protokoll-Flags und Inhalte anpassen, so

dass vorhandene Signaturen geändert oder deaktiviert und neue Signaturen nach

eigenen Kriterien erstellt werden können.

Bei Netzwerken mit hoher Auslastung und hoher Bandbreite (ab 100 Mbit/s) werden

leistungsfähige Systeme benötigt, da bei ca. 12 MByte/s die Daten

zwischengespeichert, zusammengesetzt und mit Signaturen verglichen werden

müssen. Dies setzt hohe Anforderungen an Bus-System, Peripheriegeräte und

Prozessor. Aus diesem Grund gibt es für die NIDS viele Produkte als Hardware-

Lösungen. Ebenso spielt die Anzahl der Signaturen, bzw. die Größe der

Signaturendatenbank eine große Rolle, denn der Netzwerkverkehr, bzw. die Pakete

müssen damit verglichen werden.

Problematisch wird der Einsatz von NIDS bei sogenannten „geswitchten

Netzwerken“. Die Lösung dieses Problems wird in Kapitel 3.3.2

Netzwerkbesonderheiten näher erläutert.

Eine weitere Einsatzart von NID-Systemen ist das Überwachen von Log-Files, die

Verbindungsanfragen und sonstigen Netzwerkverkehr protokollieren. Allerdings wird

diese Methode nur noch selten eingesetzt, da die Zuverlässigkeit und die Log-Details

nicht unbedingt ausreichend sind.

15 TCP = Transmission Control Protocol 16 UDP = User Datagram Protocol 17 ICMP = Internet Control Message Protocol



3.2.2 Netzknotenbasierende IDS

Netzknotenbasierende Intrusion Detection Systeme (NNIDS) stellen, aus einer

gewissen Sichtweise, sozusagen eine Kombination aus netzwerkbasierenden IDS und

hostbasierenden IDS dar. Diese Form der Intrusion Detection Systeme ist relativ neu,

so dass es bislang wenige Systeme gibt, die nach diesem Muster arbeiten.

Internet

Firewall

Switch

DMZ

Internes Netz

Switch

Netzknotenbasierendes ID

S

IDSWebserver

IDSMail-Server

IDSFTP-Server

Netzknotenbasierendes ID

SN

etzknotenbasierendes IDS

Netzknoten-Management-

Station

Abbildung 3 - Netzknotenbasierendes IDS

Genau wie beim NIDS werden die Pakete und Netzwerkströme auf Signaturen, Flags

und/oder Dienste überprüft. Es werden jedoch nur die Daten mit den Signaturen

verglichen, die ausschließlich für das System bestimmt sind, auf dem das NNIDS

läuft.

Aus diesen Gründen ist es möglich, das NNIDS als zusätzlichen Serverprozess auf

einem bereits bestehenden System zu installieren. Somit ist die möglicherweise teuere

Investition eines weiteren Systems überflüssig. Voraussetzung dafür ist aber, dass das

bereits bestehende System noch genügend Ressourcen hat, um das NNIDS aufnehmen



zu können. Dabei müssen vor allem der Netzwerkverkehr als auch die Prozessorlast

berücksichtigt werden.

Um wiederum mehrere NNIDS in den lokalen Netzen überwachen zu können, ist es

hier ebenfalls möglich, wie bei den NIDS, eine zentrale Managementkonsole zu

installieren, mit der die NNIDS-Agenten konfiguriert und überwacht werden können.

Diese über das Firmennetz verteilten Agenten können somit ihre Daten,

Alarmmeldungen und Konfigurationsdaten an die Managementkonsole liefern, bzw.

erhalten. Dadurch können neue, veränderte und sicherheitsrelevante Signaturen

innerhalb kürzester Zeit auf alle Agenten verteilt werden.

Der Einsatz dieser NNIDS hat im Gegensatz zu den NIDS den Vorteil, dass es keine

Probleme mit einem geswitchten Netzwerk gibt, da die NNID-Systeme direkt auf

Netzknoten, z.B. einem HTTP-Server mit Anbindung an einen Datenbank-Server,

sitzen und der Datenverkehr nach außen nur über eine Netzwerkkarte geschieht.

Es ist auch nicht erforderlich, die Netzwerkkarten in den „promiscuous mode“ zu

versetzen, da nur die Pakete analysiert werden, die an das netzknotenbasierende IDS

gerichtet sind. Dieses IDS wird mehr oder weniger auch als hostbasierendes IDS

angesehen, da es auf einem Host läuft und kein zusätzliches Gerät, bzw. kein

zusätzlicher Host nötig ist. Diese Klassifizierung als hostbasierendes IDS ist genau

genommen nicht richtig, da es nur bedingt die Funktionen eines HIDS erfüllt.



3.2.3 Hostbasierende IDS

Hostbasierende Intrusion Detection Systeme (HIDS) werden hauptsächlich auf

Servern eingesetzt, um Zugriffe und Angriffe festzuhalten, die nur auf bzw. gegen

dasjenige System ausgeführt werden.

Internet

Webserver mit Hostbasiertem IDS

Firewall

Switch

FTPserver mit Hostbasiertem IDS

Mail-Server mit Hostbasiertem IDS

DMZ

Abbildung 4 - Hostbasierendes IDS

Die Arbeitsweise eines HIDS beschränkt sich auf die Überwachung von Prozessen

und Diensten, wie z.B. der laufende Login-Prozess sowie die Integrität von Dateien.

Bei Windows-Systemen wird meist auch die Registrierungsdatei überwacht, die ein

großes Sicherheitsrisiko und somit einen idealen Angriffspunkt darstellt.

Bei der Installation des HIDS wird normalerweise ein Initialisierungslauf

durchgeführt, der die wichtigsten Informationen über lokale Dateien sammelt und

diese in einer Datenbank ablegt. Zu diesen Informationen gehören die Dateigröße,

Datum der Erstellung, Datum der letzten Änderung, Zugriffsrechte, Besitzer und

einige andere Informationen, abhängig vom Betriebssystem. Da sich einige der oben

genannten Informationen leicht ändern lassen, wird evtl. noch eine CRC-, MD5-,

SHA-, oder Haval-Prüfsumme generiert, die sich aufgrund des Algorithmus nicht

zurückberechnen lässt und somit eine nicht bemerkbare Veränderung der Datei quasi

unmöglich macht.



HID-Systeme, die nur Dateien und keine Prozesse bzw. Applikationen überwachen

werden FIA18 Systeme genannt.

Diese Systeme dienen nur der Überwachung der lokalen Dateien und können somit

keine Brute-Force Login-Angriffe erkennen. Ebenfalls ist der Einsatz solcher Systeme

auf FTP- oder HTTP-Servern, d.h. Server, die viele Zugriffe zu verzeichnen haben,

nicht empfehlenswert, da viel Konfigurationsarbeit geleistet werden muss und

komplette Verzeichnisse nicht eingebunden werden können, aufgrund der durch

Änderungen resultierenden Fehlalarme.

Die HIDS, die ebenfalls Prozesse und Applikationen überwachen, laufen ständig als

eigener Prozess im Hintergrund, im Gegensatz zu den FIA-Systemen, die je nach

Umfang einmal am Tag oder in der Nacht durchlaufen.

Bei der Überprüfung der Datei-Integrität werden wie beim Initialisierungslauf die

Informationen zu jeder Datei überprüft und mit den festgehaltenen Informationen in

der Datenbank verglichen. Haben sich die Eigenschaften oder die Prüfsumme einer

Datei geändert, so wird ein Alarm ausgelöst.

Im Gegensatz zu den proaktiven NID-Systemen sind HIDS reaktiv, d.h. sie reagieren

erst nachdem eine Veränderung aufgetreten ist. Diese Systeme, insbesondere die FIA-

Systeme laufen nicht in Echtzeit, um die Prozessorlast gering zu halten und die

eigentlichen Server-Dienste nicht zu verlangsamen. HIDS, die Prozesse und

Anwendungen überwachen, laufen ebenfalls nicht in Echtzeit, so dass z.B. versuchte

Brute-Force Logins erst nach einer gewissen Zeit erfasst und alarmiert werden.

18 FIA = File Integrity Assessment



3.3 Konfiguration und Umgebung

3.3.1 Regeln / Rules

Die Konfiguration der meisten ID-Systeme basiert auf definierten Rege ln, den so-

genannten Rules. Diese Regeln können verschlüsselt oder im Klartext vorhanden sein.

Im Allgemeinen können diese Regeln verändert, neue Regeln erstellt oder schon

vorhandene Regeln gelöscht oder deaktiviert werden. Einige IDS haben eigene

Notationen oder Sprachen mit denen diese Regeln erstellt werden können.

Bei den NIDS bzw. NNIDS sind Informationen, wie z.B. Quell- IP-Adresse, Ziel- IP-

Adresse, Protokoll, Quell-Port, Ziel-Port sowie mögliche Strings oder Protokoll-Flags

enthalten, welche auf Regeln überprüft werden.

Die Regeln zur Überprüfung von Dateien bei HIDS enthalten Informationen über

Zugriffe, Checksummen, usw., wobei zu jeder Datei eine eigene Regel definiert

werden kann.

Oft werden Regeln, die einen gemeinsamen Dienst, aber verschiedene Signaturen

beinhalten, in einem Regelsatz (Ruleset) für eine bessere Übersicht, zusammengefasst.

3.3.2 Netzwerkbesonderheiten

In den verschiedenen Netzwerken und bei größeren Umgebungen kann es zu

Problemen hinsichtlich NID- und NNID-Systemen kommen. Bei diesen Systemen

befindet sich die Netzwerkkarte im „promiscuous-mode“, was somit den gesamten

Netzwerkverkehr aufzeichnet, auch denjenigen, der nicht für das ID-System bestimmt

ist. Dies stellt bei kleineren Netzwerken mit Bus-Topologien kein Problem dar, denn

der Netzwerkverkehr wird auf der gesamten Leitung in alle Richtungen gesendet. Bei

einer Sterntopologie kann es vorkommen, dass der gesamte Netzwerkverkehr auf allen

Ein- und Ausgängen gesendet wird. Dies geschieht nur, wenn man nicht intelligente

Netzwerkkomponenten, wie z.B. einen Hub 19 zur Verbindung der einzelnen Hosts

verwendet. Ein Hub kann sich nicht merken welcher Host an welchem Port hängt, so

dass er den Netzwerkverkehr an alle Ausgänge weiterleitet.

19 Hub = Multi Port Repeater



Um größere Netzwerke miteinander zu verbinden, und um den Netzwerkverkehr

möglichst gering zu halten, werden Switches eingesetzt. Diese Komponenten sind

intelligent und können sich merken, welcher Host an welchen Port angeschlossen ist.

Wenn nun das IDS an einen solchen Switch angeschlossen wird, so würde das IDS nur

denjenigen Verkehr untersuchen, der direkt an das IDS gerichtet ist. Um dieses

Problem zu lösen, verfügen einige Switches über ein so genanntes Port-Mirroring, mit

dem jeder einzelne Port an einen bestimmten Port weitergeleitet werden kann. Dies

erlaubt dann das Mitprotokollieren des gesamten Netzwerkverkehrs.



3.4 Allgemeine Einsatzarten

3.4.1 Einsatzumgebung

Für die verschiedenen Intrusion Detection Systeme gibt es auch die

unterschiedlichsten Einsatzarten. Bei diesen Einsatzarten ist die Installation,

Umgebung und Verteilung der Systeme gemeint.

Die wohl einfachste Art, ein einzelnes oder mehrere unabhängige Systeme

einzusetzen, ist die Installation als Standalone-IDS. Jedes alleinstehende (Standalone)

IDS bildet somit einen Single Point of Failure, was eine Administration vereinfacht

und die Übersichtlichkeit verbessert. Dabei muss ein solches System nicht wirklich

„alleinstehend“ sein im Sinne von keine Verbindung zu einem anderen System haben,

sondern es können wohl Verbindungen zu anderen Systemen bestehen. Diese

Verbindungen stellen keine Verbindungen zu einem oder mehreren Management-

Systemen, sondern Datenverbindungen dar. Genauer gesagt, Verbindungen zu SNMP-

Servern, die bei einem Alarm benachrichtigt werden, Datenbank-Servern, auf denen

die Alarmmeldungen und Informationen abgelegt werden oder SMTP-Server, die für

die Versendung von e-Mails verantwortlich sind.

Das direkte Gegenteil von Standalone-IDS sind Enterprise-IDS. Zu dieser Klasse

gehören alle IDS, die mit irgendeiner anderen Komponente des IDS, die nicht lokal

installiert ist, auf irgendeine Art kommunizieren. Zu diesen Komponenten gehören

weitere IDS, Management-Server, Administrationsoberflächen, Firewallsysteme oder

Netzwerkkomponenten. Diese Komponenten sind aufeinander abgestimmt und stellen

somit keine allgemein genützten Ressourcen dar, sondern werden nur in Verbindung

mit einem IDS eingesetzt. Ein IDS mit einem Datenbank-Server, auf dem die Daten

und Informationen abgelegt werden, stellt keine Enterprise-Lösung dar, da der

Datenbank-Server auch für andere Komponenten genutzt werden kann, die nichts mit

dem IDS zu tun haben. Wiederum kann ein Datenbank-Server auf dem IDS installiert

werden, um keinen unnötigen Netzwerkverkehr zu verursachen.

Einige Enterprise- und Standalone-IDS besitzen die Fähigkeit, Daten und

Informationen an Netzwerkkomponenten oder Firewalls zu liefern und diese auf Basis

der gelieferten Daten zu konfigurieren. Besonders bei den Enterprise-IDS besteht die



Möglichkeit der IR20; d.h. durch Angabe einiger Daten, wie z.B. Login und Passwort

ist es den ID-Systemen möglich, z.B. bei einem geeigneten CISCO-Switch eine IP-

Adresse zu blocken, bzw. einen Paketfilter aufzubauen. Einige Systeme unterstützen

die Kommunikation, bzw. den Abgleich mit dem weltweit führenden Firewallsystem

Checkpoint Firewall-1, was die IR direkt an der Firewall erlaubt. Dies stellt eine

wesentlich sicherere Methode dar, da eine IR gefährlich in Bezug auf vorgetäuschte

IP-Adressen ist. So kann es möglich sein, dass ein Angreifer bzw. Hacker eine IP-

Adresse vortäuscht, die er nicht besitzt z.B. die IP-Adresse eines Telekom Web-

Servers, und damit versucht in ein fremdes Netzwerk einzudringen. Bemerkt nun das

IDS diesen Angriff, führt es eine IR aus und blockiert die IP-Adresse des Angreifers,

was zur Folge haben kann, dass alle Verbindungsanfragen von innen, die wirklich an

die IP-Adresse des Telekom Web-Servers gerichtet sind, geblockt werden.

Dieser Angriff mit einer vorgetäuschten IP-Adresse (auch IP-Spoofing genannt), ist

eine schon länger bekannte Hackermethode, um Zugriffe auf einen Server zu

reduzieren und zu unterbinden, was für die Firma eine Nichtverfügbarkeit des Hosts

darstellt und somit einen finanziellen Schaden verursacht.

Der folgende Abschnitt bezieht sich auf die Netzwerkkarten in einem NIDS bzw.

NNIDS, die zur Überwachung des Netzwerkverkehrs und nicht als Management-

Interface genutzt werden.

Um die Angriffssicherheit der ID-Systeme zu erhöhen, ist es möglich, die

Netzwerkkarte bei NIDS und NNIDS ohne IP-Adresse zu versehen. Diese

Netzwerkkarte lässt sich durch kleine Änderungen an den Netzwerkeinstellungen

aktivieren. Das IDS hat folglich keine IP-Adresse und kann somit nicht angesprochen

werden. Versetzt man die Netzwerkkarte nun in den „promiscuous mode“, so kann der

gesamte Netzwerkverkehr aufgezeichnet werden, ohne dass das IDS über das

Netzwerk ansprechbar ist. Dies stellt einen enormen Sicherheitszuwachs dar, da ein

Angriffspunkt und zwar das IDS ausgeschaltet ist. Angreifer können so nicht merken,

dass sich ein IDS in dem Netzwerk befindet und werden somit wohl keine gezielten

Angriffe gegen das IDS fahren.

20 IR = Intrusion Response



Eine weitere Möglichkeit ist der Einsatz von speziellen Netzwerk-Taps, d.h.

modifizierte Netzwerkkabel (insbesondere Twisted-Pair), bei denen die TX21- oder

RX22-Verbindungen gekappt oder mit Kondensatoren verändert wurden. Dies dient

zum Abschirmen des IDS, so dass dies auf Netzwerkanfragen oder Broadcasts nicht

antworten kann. Wird ein Kondensator in eine Verbindung eingebaut, so werden

Antworten (IP-Pakete) auf Verbindungsanfragen vom IDS gesendet. Dieser

Netzwerkverkehr wird aber durch den Kondensator so verändert, dass er Unbrauchbar

wird. Der Switch oder Router, der diese modifizierten Pakete erhält, verwirft sie, da

Prüfsummen falsch sind oder das ganze Paket nicht gelesen werden kann. Der

Kondensator lässt aber noch genügend elektrische Signale durch, damit die aktive

Netzwerkkomponente merkt, dass ein Gerät an jenem Port hängt. Würden keine

elektrischen Signale mehr zur aktiven Netzwerkkomponente durchkommen, so würde

diese den Port abschalten.

Das IDS unter den oben genannten Installationen, bei denen die Existenz für Angreifer

nicht ersichtlich ist, wird ab sofort als Stealth-IDS, bzw. Stealth-Installation

bezeichnet.

3.4.2 Administration und Management

Um auf ID-Systeme zugreifen und diese Administrieren zu können gibt es die

Möglichkeit der lokalen und Fernadministration. Die lokale Administration, d.h. der

physikalische Zugriff kommt normalerweise nur bei Standalone-IDS zum Einsatz, bei

denen die Einrichtung einer Fernadministration zu aufwendig und zu umfangreich

wäre. Lokale Administration bedeutet einen Sicherheitszuwachs, da keine

Informationen über Netzwerke laufen, sondern direkt angezeigt werden können.

Ebenfalls kann genau überwacht werden, wer wann zuletzt auf das System zugegriffen

hat, wobei auch einfacher mehrere verschiedene Administrationsaccounts erstellt

werden können.

Bei einer Fernadministration müssen die kompletten Administrationsdaten über das

Netzwerk ausgetauscht werden, was zu eine r zusätzlichen Netzlast und einem

21 TX = Transcieve 22 RX = Receive



Sicherheitsrisiko führt. Bei einigen Enterprise-IDS können die Administrations- sowie

alle anderen Daten verschlüsselt werden, die an andere Systeme gesendet werden.

Fällt bei einem Enterprise-IDS ein beteiligtes System aus oder ist dies nicht

erreichbar, so ist die Funktionsweise des gesamten Systems nicht gewährleistet.

Um die Kommunikation zwischen den einzelnen Systemen sicher zu machen und die

Netzlast zu senken, kann eine sogenannte „Out-of-Band-, bzw. Out-Band-

Kommunikation“ eingesetzt werden. Im Gegensatz zur „In-Band-Kommunikation“

verlaufen die Administrations- und Informationsdaten über ein eigenes Netzwerk.

Dabei können diese Daten sicher und ohne Verschlüsselung übertragen und vor

Angreifern geschützt werden. Diese „Out-of-Band-Kommunikation“ wird in großen

Netzen hauptsächlich für das SNMP-Management eingesetzt. Das IDS verfügt bei

dieser Art über eine zweite Netzwerkkarte, die direkt per Crosskabel23 oder indirekt

über Netzwerkkomponenten mit den anderen IDS-Komponenten verbunden ist.

23 Crosskabel = Eine Verbindung über Twisted-Pair, bei der die TX- und RX-Leitungen gekreuzt sind



3.5 Benachrichtigung und Alarmierung

Wurde ein Angriff erkannt, so gibt es bei den unterschiedlichen IDS oft mehrere

Möglichkeiten der Alarmierung, bzw. Benachrichtigung des Administrators. Es gibt

keinen Standard dafür, aber die meisten IDS unterstützen die Benachrichtigung über e-

Mail, SNMP-Trap, Popup-Fenster oder akustische Signale. Diese Alarmierungen

werden nun genauer dargestellt.

3.5.1 e-Mail

Durch Angabe des e-Mail Servers sowie der e-Mailadresse des IDS-Administrators

können Angriffe sofort nach Auslösung des Alarms verschickt werden. Diese

Methode der Alarmierung ist jedoch nur sinnvoll, wenn wenige Alarme auftreten und

der IDS-Administrator ständig über e-Mail erreichbar ist. Diese Alarmierung findet

am häufigsten Verwendung, da über eine Mailingliste sofort mehrere Administratoren

benachrichtigt werden können. Ebenfalls kann die Benachrichtigungsadresse ohne viel

Aufwand so umgestellt werden, dass die e-Mails auch an andere Adressen versendet

werden können.

3.5.2 SNMP-Trap

Die Benachrichtigung über einen SNMP-Trap stellt bei größeren Netzwerken, in

denen bereits Netzwerk-Managementsysteme eingesetzt werden, die beste Lösung dar.

Dabei kann das IDS ständig auf Verfügbarkeit überwacht werden, und bei einem

Angriff alarmiert das IDS das Managementsystem. Aufgrund der vorhandenen SNMP-

Versionen SNMP-v1, SNMP-v2 und SNMP-v3 ist die Alarmierung über einen

SNMP-Trap nicht immer möglich, da die Versionen untereinander nicht 100%

kompatibel sind.

3.5.3 Popup-Fenster

Das ID-System NFR Network Intrusion System beinhaltet die Möglichkeit, bei einem

Alarm ein Pop-up Fenster zu öffnen, das sofort die wichtigsten Informationen eines

Alarms anzeigt. Das freie IDS Snort beinhaltet die Möglichkeit der Alarmierung über



das SMB24-Protokoll. Diese Unterstützung muss beim Erstellen des IDS mit

einkompiliert werden. Mit dieser Unterstützung ist es möglich, Nachrichten, bzw. ein

Popup-Fenster auf einem Windows System darzustellen. Dies natürlich unter der

Voraussetzung, dass die benötigten Dienste unter Windows aktiviert sind.

Die Möglichkeit der Anzeige von wichtigen Alarmen in einem oder mehreren Popup-

Fenstern besteht bei den meisten Windows basierenden IDS.

3.5.4 Akustische Signale

Die Alarmierung über akustische Signale hat wenige Vor- und viele Nachteile. Hat ein

IDS keinen eigenen Monitor, so kann die Alarmierung über einen Piepton die einzige

Möglichkeit sein, um den Administrator über einen möglichen Angriff zu informieren.

Steht das IDS in einem Rechenzentrum, das nicht ständig besetzt ist, so werden die

akustischen Signale ignoriert. Bei hoher Netzlast können viele Alarme/Fehlalarme

auftreten, so dass die akustische Alarmierung fast zu einer Belästigung wird. Bei

einigen IDS werden die akustischen Signale nicht über den Systemlautspreche r,

sondern über die Soundkarte generiert, was die Einrichtung des IDS erschwert, denn

eine Soundkarte gehört normalerweise nicht zur Standardausstattung.

3.5.5 Sonstige Benachrichtigung / Alarmierung

Je nach Ausstattung und Flexibilität des IDS gibt es weitere Möglichkeiten zur

Alarmierung, wie z.B. das Versenden einer SMS25 an ein Handy.

Die wohl häufigste Methode der Alarmierung ist die Ausgabe auf dem Bildschirm

ohne zusätzliche Benachrichtigungen. Meist wird ein neuer Alarm am oberen Ende

einer Liste neu dargestellt, so dass sofort zeitlich überprüft werden kann, welche

Alarme wann eingegangen sind. Die Administration eines IDS nimmt viel Zeit in

Anspruch, so dass der IDS-Administrator nicht ständig auf das IDS schauen kann. Das

Überprüfen des IDS geschieht aus diesem Grund durchschnittlich nur ein bis zwei Mal

am Tag, so dass alle bis zu diesem Zeitpunkt aufgetretenen Alarme untersucht und

überprüft werden. Eine ständige Alarmierung über mögliche Angriffe bzw.

24 SMB = Server Message Block 25 SMS = Short Message Service



Fehlalarmierungen würde mit der Zeit die Aufmerksamkeit des IDS-Administrators

mindern.



3.6 Auswirkungen des Betriebssystems

Wie bereits erwähnt gibt es viele verschiedene Intrusion Detection Systeme für die

verschiedensten Betriebssysteme. Je nach Sicherheitsaspekt, persönlicher Vorlieben,

Unternehmensphilosophie, Netzwerkumgebung und Serverlandschaft muss

entschieden werden, welches IDS auf welcher Plattform unter welchem

Betriebssystem eingesetzt werden soll.

Aufgrund der verschiedenen Plattformen (Intel, Alpha-RISC, HPPA-RISC, SUN-

SPARC, ...) und der darauf basierenden Betriebssysteme (Windows, Linux, HP-UX,

Solaris, ...), kann die Leistung der einzelnen IDS sehr stark variieren. Ebenfalls sind

die laufenden Prozesse und somit die noch zu vergebende Systemleistung

ausschlaggebend. Diese noch verbleibende Systemleistung ist abhängig von

Prozessorlast, verfügbarer Hauptspeicherkapazität, Festplattenplatz,

Auslagerungsdateigröße (virtueller Speicher) und Bus- sowie

Speichergeschwindigkeiten. Genauere Analysen für die Berechnung der

Systemleistung würden den Rahmen der Diplomarbeit sprengen, weshalb hier nicht

weiter darauf eingegangen wird.

Das wohl am häufigsten eingesetzte Betriebssystem für ID-Systeme stellt Windows,

insbesondere Windows NT, 2000 und XP dar. Seltener werden UNIX/Linux-

Betriebssysteme eingesetzt. Dies liegt wohl an der einfacheren Installation, dem

bekannten Look-and-Feel, sowie an den einheitlichen Schnittstellen der verschiedenen

Windows-Systeme. Bei UNIX/Linux-Systemen müssen betriebssystembedingte

Veränderungen vor der Installation durchgeführt werden, da die Systemumgebungen

der einzelnen Betriebssysteme zum Teil sehr stark variieren können.

Was die Leistung/Performance von Windows-Systemen angeht, so hinkt diese den

UNIX/Linux-Systemen zum Teil weit hinterher. Dies liegt vor allem an den vielen,

ständig laufenden Prozessen, der Benutzungsoberfläche, sowie dem immens hohen

Zugriff auf die Systemregistrierung. So wird z.B. beim Start des Internet Explorers 3.0

mehr als 1.000-mal auf die Systemregistrierung zugegriffen, was das System stark

ausbremst. UNIX/Linux-Systeme besitzen keine Systemregistrierung wie Windows-

Systeme, so dass jedes gestartete Programm seine eigenen Konfigurationen besitzt.



Was die Sicherheit bei Betriebssystemen angeht, so sind Windows-Systeme im

Gegensatz zu UNIX/Linux-Systemen viel schwerer zu sichern. Hinsichtlich Microsoft

ist es so, dass diese Firma selbst Hintertüren und versteckte Informationen in ihre

Betriebssysteme eingebaut hat. So wurde erst 1997 bekannt, dass Microsoft dem

NSA26 einen eigenen Schlüssel in die Registrierung eingebaut hat, um Benutzer und

Daten auszuspionieren.

Im Gegensatz zu Windows, können UNIX/Linux-Betriebssysteme ohne grafische

Oberfläche installiert und konfiguriert werden. Dies verringert die Prozessorlast, da

keine weiteren Berechnungen nötig sind, keine zusätzlichen Prozesse laufen und die

Informationen über die Benutzungsoberfläche nicht im Hauptspeicher abgelegt

werden müssen. Für NIDS und NNIDS sind besonders die vorhandene und freie

Hauptspeicherkapazität, sowie die Prozessorlast ausschlaggebend. Unter Anderem

können unter UNIX/Linux-Systemen durch Kernel-Anpassungen wichtige

Leistungsverbesserungen erzielt werden. Unter Windows ist es hingegen nicht

möglich den Kernel manuell zu verändern, ebenfalls kann Windows nicht ohne

Benutzungsoberfläche installiert werden.

26 NSA = National Security Agency

Vergleich und Einführung von IDS 4. Vergleich von Intrusion Detection Systemen


4. Vergleich von Intrusion Detection Systemen

4.1 Kriterien des Vergleichs

Um die verschiedenen IDS miteinander vergleichen zu können, müssen Kriterien

gefunden und die Systeme daraufhin untersucht werden. Folgende Kriterien wurden

bei den Systemen untersucht:

4.1.1 Auslastung

Hierbei ist die Netzwerk- sowie Prozessorlast gemeint. Die verschiedenen IDS können

je nach Umfang, Implementierung und laufenden Diensten diese Auslastung stark

beeinflussen. So kann z.B. ein nicht auf Geschwindigkeit optimiertes, neues IDS eine

viel höhere Prozessorlast verursachen als ein älteres IDS, das mehrfach überarbeitet

wurde, um die Leistung zu erhöhen.

Einige IDS verursachen selbst eine Netzwerklast, die dann zur eingehenden

Netzwerklast hinzu addiert werden muss. Diese zusätzliche Netzwerklast können

DNS27-Namensauflösungen sein, um den FQDN 28 zu ermitteln.

4.1.2 Umgebung

Zur Umgebung gehört das verwendete Betriebssystem, die Kompatibilität mit anderen

Anwendungen bzw. dem System sowie die allgemeine Stabilität der IDS-Software. So

ist es bei einigen IDS zu Abstürzen gekommen, die zu einer schlechten Bewertung in

dieser Kategorie führen.

4.1.3 Angriffserkennung

Um zu testen, ob ein IDS gewisse Angriffe erkennt und korrekt klassifizieren kann,

werden mittels unterschiedlicher Programme mögliche Angriffe auf das IDS simuliert.

Die verwendeten Programme werden später noch genauer erklärt. Wichtig für die

Bewertung sind primär die Erkennung eines simulierten Angriffs, die genauere

27 DNS = Domain Name Service 28 FQDN = Fully Qualified Domain Name



Klassifikation in Gruppen, Untergruppen oder die genaue Erkennung des verwendeten

Tools. Unter anderem spielt die Priorisierung, d.h. Einteilung in unterschiedliche

Angriffsklassen und Gefährlichkeit eines Angriffs eine große Rolle.

Backdoors: Finger:

Back Orifice 2000 Finger Perl

Backdoor 2 Finger user

Deep Throat

Netbus Hijacking:

Satans Backdoor TCP hijacking

SNMP Backdoor

Sub Seven HTTP:

Tini Backdoor HTTP classifieds post

HTTP cold fusion

CMD-Execution: HTTP dragon fire

FTP site exec dot-dot HTTP form mail

HTTP .bat exec HTTP guestbook

HTTP Cisco catalyst exec

PcNFS exec Scans:

rsh IP fragmentation

STATD automount exec IP protocol violation

ypupdate exec IP unknown protocol

NFS guess

Dos / DDoS: Port Scan (IP half)

e-mail expn overflow Port Scan (nmap)

e-mail helo overflow Port Scan (TCP)

finger bomb Port Scan (UDP)

FTP args Scanner Cybercop

FTP bounce Traceroute linux icmp

FTP root Traceroute linux udp

FTP site exec tar.cap Tracert ms with lookup

generic intel overflow Tracert ms without lookup

HTTP Apache DoS

HTTP IIS PHP overflow

HTTP Netscape admin overflow

IMAP authentication overflow

IMAP overflow IDS-Name:LAND (TCP) Datum:LAND (UDP)

PING Flood

Ping of Death

Smurf

Stacheldraht DoS

SYN-Flood

TFN

TFN2000

Trinoo Deamon

Trinoo Master

UDP Bomb

Abbildung 5 - Liste der simulierten Angriffe



4.1.4 Alarme

Hierbei ist nicht die Angriffserkennung, sondern die Behandlung bzw. Abhandlung

von Alarmen gemeint. So muss die Anzahl und Häufigkeit der Fehlalarme (False-

Positives) analysiert und überwacht werden sowie das Festhalten/Abspeichern der

Alarme. Besonders wichtig ist die Darstellung der Alarme sowie deren

Informationsgehalt. Werden also zusätzliche Informationen über gesetzte TCP-Flags,

Hex-Dumps o.ä. abgespeichert und angezeigt, so hilft dies Fehlalarme zu

identifizieren.

4.1.5 Signaturen

Hier wird untersucht, wie viele Signaturen mitgeliefert werden und welche Signaturen

nach einer Standardinstallation aktiv sind. Die Flexibilität, d.h. Anpassbarkeit der

Regeln, das Erstellen von neuen Regeln und Ändern von vorhandenen Regeln, spielt

ebenso eine Rolle wie die Aktualisierung von Regeln über Medien wie z.B. das

Internet oder über Disketten/CD-Updates.

4.1.6 Art des IDS

Hier muss zwischen HIDS, NIDS und NNIDS unterschieden werden, da ein HIDS

nicht mit einem NIDS oder NNIDS verglichen werden kann. Ebenso ist der gedachte

Einsatz als Standalone- oder Enterprise IDS zu untersuchen und zu überprüfen.



4.2 Testumgebung

Auf Basis der Testumgebung werden die verschiedenen Systeme getestet und

untersucht. Diese Testumgebung ist von folgenden Faktoren abhängig:

4.2.1 Einsatzorte

Die verschiedenen Systeme wurden hauptsächlich vor der Firewall, also direkt im

Internet eingesetzt. Nur zu Beginn des Vergleichs wurde das erste IDS im internen

Netzwerk bzw. Intranet eingesetzt, da noch unklar war, ob das IDS vor der Firewall

oder in der DMZ eingesetzt werden sollte.

Der Einsatz vor der Firewall hat sowohl Vor- als auch Nachteile. So werden alle

Angriffe gegen das Netzwerk ungefiltert durch das IDS erfasst. Wird das IDS nicht im

Stealth-Modus installiert, so stellt das IDS einen weiteren externen Angriffspunkt dar.

Ebenfalls wird die Anzahl der Fehlalarme immens, da die meisten Angriffe, wie z.B.

Portscans oder virenverseuchte e-Mails direkt von der Firewall geblockt werden.

Der Einsatz hinter der Firewall, also in der DMZ kann das Problem zur Folge haben,

dass die von außen kommenden IP-Adressen über NAT29 oder über Proxies mit der

IP-Adresse der Firewall ersetzt werden. So kann dann zwar ein Angriff erkannt, aber

die genauere Herkunft bzw. die IP-Adresse des Angreifers nicht ermittelt werden. Bei

Netzwerken mit einer hohen Anzahl an Zugriffen, kann das IDS Fehlalarme in Bezug

auf Portscans liefern. Das IDS registriert eine hohe Anzahl an Verbindungsanfragen,

die genau von einer einzigen IP-Adresse kommen und klassifiziert diese IP-Adresse

als Ausgangspunkt eines Portscans. Abhilfe kann das Verändern der Einstellungen auf

transparentes Proxying schaffen, bei dem die IP-Adressen der Anfragen nicht durch

die IP-Adresse der Firewall ersetzt werden. Eine weitere Möglichkeit besteht durch

den Einsatz eines weiteren IDS vor der Firewall, wodurch die registrierten Angriffe

mit dem IDS in der DMZ verglichen und ausgewertet werden können.

29 NAT = Network Address Translation



4.2.2 Testhardware

Als Testumgebung wurden zwei verschiedene Systeme verwendet. Zum einen das ID-

System, das zu bewerten war und für das Simulieren von Angriffen ein

Angriffsrechner, der direkt mit dem Internet verbunden war und nicht von der Firewall

geschützt wurde. Beide Rechner enthielten Pentium-Prozessoren und 128 bzw.

256MB Hauptspeicher. Das Angriffssystem wurde unter Windows 2000 und Linux

betrieben, da die meisten Angriffswerkzeuge unter diesen Betriebssystemen liefen.

4.2.3 Testwerkzeuge

Als Testwerkzeuge dienten zum Großteil Programme, die zur Netzwerk-Absicherung

bzw. Überprüfung eingesetzt werden. Diese Programme waren Port-

/Netzwerkscanner, mit denen man Systeme oder ganze Netzwerke untersuchen und

testen kann. Ein System kann nach offenen Ports und laufenden Diensten überprüft

werden, wobei manche Werkzeuge sogar noch Einzelheiten über den laufenden Dienst

herausfinden können.

Ein weiteres Tool, das noch neu und unbekannt ist und mit dem die Tests durchgeführt

wurden, nennt sich IDS Informer. Dieses Programm wurde speziell für die

Überprüfung von ID-Systemen entwickelt und kann über 100 verschiedene Angriffe

simulieren. Die verschiedenen Angriffe, mit denen jedes IDS überprüft wurde sind in

Abbildung 5 - Liste der simulierten Angriffe dargestellt.

Bevor das Tool IDS Informer verfügbar war, wurden die Angriffe mit richtigen

Hackertools, wie z.B. Nukern und DoS-Tools ausgeführt, wobei abwechselnd das

IDS-System (so fern es eine IP-Adresse hatte) und das komplette Netzwerk

angegriffen wurden.

Vergleich und Einführung von IDS 5. Getestete Intrusion Detection Systeme


5. Getestete Intrusion Detection Systeme

5.1 Snort mit Analyseprogramm ACID

Das zuerst getestete IDS „Snort“ ist für fast alle Betriebssysteme, wie z.B. Windows,

Linux und UNIX verfügbar. Es wurde unter der GNU General Public License

veröffentlicht und ist somit frei verfügbar. Das Programm wird ständig

weiterentwickelt, so dass nach einigen Wochen eine neue Version erhältlich ist.

Zusätzlich zum Programm müssen aktuelle Regelsätze installiert werden, die fast

täglich aktualisiert werden. So dauert es oft nur eine geringe Zeit, bis Regeln zur

Erkennung eines neuen Sicherheitslochs verfügbar sind und eingesetzt werden

können. Durch die Verbreitung von Snort gibt es Organisationen, die eigene

Regelsätze erstellen und diese der Öffentlichkeit bereitstellen. Einen direkten Support

bei Problemen gibt es nicht, jedoch besteht ein Snort-Forum, in dem Probleme und

Lösungen diskutiert werden, so dass man dort fast immer auf Hilfe zählen kann. In

diesem Forum sind auch die Entwickler von Snort vertreten, so dass beim Auftreten

eines Bugs diese benachrichtigt und um Hilfe gefragt werden können.

Snort selbst ist eine Applikation, die normalerweise im Hintergrund läuft und keine

Daten ausgibt, d.h. keine Benutzungsoberfläche hat. Aus diesem Grund wird die

Zusatzapplikation ACID30 hier mitbesprochen, die die grafische Darstellung und

Auswertung übernimmt.

5.1.1 Installation

Für die Installation von Snort steht die aktuelle oder eine Beta-Version zur Verfügung.

Dasselbe gilt für die Regelsätze, diese können aber nicht miteinander gemischt

werden, da sich bei einem Versionswechsel auch die Regelsätze ändern.

Snort, als auch die Regelsätze können als komprimierte tar-Archive von der

Internetseite http://www.snort.org heruntergeladen und entpackt werden. Die

Installation verläuft wie bei fast allen Linux/UNIX-Applikationen über Makefiles und

Konfigurationsskripte. Der Verlauf der Installation ist normalerweise problemlos,

30 ACID = Analysis Console for Intrusion Databases



wenn alle benötigten Bibliotheken und abhängigen Pakete vorhanden sind. Je nach

Einsatzgebiet können Optionen wie z.B. Datenbankunterstützung, Unterstützung von

SNMP-Traps, Benachrichtigung per SMB oder Intrusion Response angegeben werden,

die dann verfügbar sind und eingesetzt werden können. Um eine Verbindung zum

Analyseprogramm ACID herzustellen, muss Snort mit Datenbankunterstützung

eingerichtet werden, was eine Relationale Datenbank voraussetzt. Diese Datenbank

kann auf einem anderen System installiert werden, das eine Verbindung mit dem IDS

hat. Je nach gewünschter Sicherheit müssen Benutzer und Gruppe erstellt werden,

unter denen das IDS läuft. Ebenfalls müssen Sicherheitsanpassungen an Datenbank

und Betriebssystem vorgenommen werden, um einen hohen Sicherheitsstandard zu

gewährleisten. Durch die Konfiguration als Stealth-IDS wird einem potentiellen

Eindringling keine Angriffsmöglichkeit gegeben, so dass ein spezielles System-

Hardening nicht nötig ist.

5.1.2 Konfiguration

Die Konfiguration von Snort erfolgt über die einzige Konfigurationsdatei snort.conf.

In dieser Datei können die Einstellungen für Netzwerk, Portscan-Preprozessor,

verwendete Regelsätze, Datenbankverbindung und andere Dienste vorgenommen

werden. Durch Optionen beim Aufruf kann Snort als Paketlogger, Paketsniffer oder

Intrusion Detection System gestartet werden. Aufgrund des Vergleichs von Intrusion

Detection Systemen wird hier nur der Einsatz mit den Optionen für den Start als IDS

besprochen.

Snort beinhaltet seit der Version 1.8.7 die Möglichkeit der Paketdefragmentierung.

Diese Unterstützung bietet die Erkennung von Angriffen, bei der der Angreifer mittels

Paketzerstückelung versucht, die Angriffssignaturen zu verstecken. Der

Paketfragmentierungsangriff ist eine neue Technik, die erst seit einigen Monaten von

Hackern verwendet wird, um Angriffe vor ID-Systemen zu verstecken.

Erhält das IDS Daten, so werden diese zwischengespeichert und mit einer

Signatur/Regel eines Regelsatzes verglichen. Snort bietet Regelsätze für Web-, FTP-,

SMTP- und viele andere Angriffe, wobei die Signaturen/Regeln einzeln oder der

ganze Regelsatz deaktiviert werden können.

Beispiel für den Aufbau einer Regel bei Snort im Regelsatz DDoS:



alert tcp $EXTERNAL_NET any -> $HOME_NET 27665 (msg:"DDOS Trin00 Attacker to

Master default password";flags: A+; content:"gOrave"; classtype:attempted-

dos; sid:234; rev:1;)

Erklärungen zum Aufbau:

Alert bedeutet die Alarmierung, unter der die Regel geloggt wird – dies ist meist

alert oder log. Danach folgt das Protokoll (TCP, UDP, ICPM, …). Gefolgt von der

externen IP-Adresse kommt der Quellport, d.h. der Port, auf dem der Client eine

Verbindung zum Server herstellt. Der Pfeil gibt die Richtung des Datenverkehrs an, in

diesem Falle vom Client zum Server. Danach folgt die IP-Adresse des Servers, gefolgt

vom Zielport auf dem Server. Die Nachricht (msg) dient der genaueren Beschreibung

für den Administrator. Als nächstes werden die TCP-Flags überprüft, in diesem Falle

muss zumindest das Acknowledge-Flag gesetzt sein, wobei zusätzliche TCP-Flags

auch erlaubt sind. Die gesuchte Signatur ist in diesem Falle ein Passwort, das aus dem

String „g0rave“ besteht. Signaturen können bei Snort Strings, URI31s,

Hexadezimalwerte oder bestimmte TCP-Flaganordnungen sein. Zur besseren

Einordnung verschiedener Angriffe, die zur gleichen Gruppe gehören, wird eine

Klassifizierung vorgenommen. Der Wert hinter sid bezieht sich auf eine Message-

Map, in der nochmals Informationen zu einem oder mehreren Angriffen abgelegt sind.

Zum Schluss wird noch eine Angabe über die aktuelle Revision der Regel

festgehalten, um bei einem Update sicherzustellen, dass die aktuelle Version

verwendet wird.

Aufgrund der vielen Fehlalarme, mit denen ein IDS zu kämpfen hat, können bei Snort

schnell und einfach einzelne Regeln oder Regelsätze deaktiviert werden. Dies ist

besonders nach der Standardinstallation nötig, da nicht alle Regelsätze benötigt

werden und eine manuelle Anpassung, wie bei jedem anderen IDS, geschehen muss.

So werden z.B. keine Regeln für die Erkennung von Angriffen gegen IIS32-Server

benötigt, wenn keine IIS-Server im Unternehmen eingesetzt werden. Die

Deaktivierung dieser Regeln hat die Vorteile, dass Angriffe auf IIS-Server ignoriert,

31 URI = Uniform Resource Identifier 32 IIS = Internet Information Server (Webserver von Microsoft)



Fehlalarme durch die Überprüfung auf diese Regeln vermieden werden und das IDS

die Daten auf weniger Regeln überprüfen muss und somit schneller wird.


Wurde ein möglicher Angriff von Snort erkannt, so wird die ausgelöste Regel mit

sämtlichen, zur Verfügung stehenden Informationen in der Datenbank zur

Speicherung abgelegt. Aufgrund einer ständigen Aktualisierung der Oberfläche

(Abbildung 6 - Oberfläche Snort + ACID) wird immer die neueste Anzahl der Alarme

angezeigt.

Abbildung 6 - Oberfläche Snort + ACID

Durch Navigation über die Oberfläche können nähere Details über einen potentiellen

Angriff überprüft werden. Aus den gespeicherten Alarmen (siehe Abbildung 7 -

Details zu einem Alarm) können Informationen über Protokolleigenschaften und



übermittelte Daten verfolgt werden, damit überprüft werden kann, ob es sich bei dem

ausgelösten Alarm um einen tatsächlichen Alarm, oder einen Fehlalarm handelt.

Abbildung 7 - Details zu einem Alarm

Auf Basis der Standardinstallation mit geringfügigen Anpassungen, wurden Angriffe

mit dem Programm IDS Informer simuliert, was zu folgenden Ergebnissen führte:

Anzahl erkannte Angriffe Angriffstyp Anzahl simulierte Angriffe

absolut relativ in %

Backdoor 8 2 25 %

CMD-Execution 7 4 57,14 %

DoS / DDoS 25 12 48 %



Finger 2 2 100 %

Protocol Hijacking 1 0 0 %

HTTP 5 4 80 %

Scans 13 12 92,31 %

Gesamt 61 36 59,02 %

Auf Basis dieser Ergebnisse lässt sich sagen, dass nicht alle erkannten Angriffe genau

klassifiziert, sondern nur allgemein erkannt wurden. D.h. ein Portscan wurde z.B.

nicht genau als „Scanner Cybercop“ gemeldet, sondern nur als „Portscan“. Diese

genaue Klassifizierung kann durch manuelles Nachbearbeiten der Regeln teilweise

behoben werden, wobei die Frage besteht, ob dies wirklich nötig ist, da eigentlich nur

wichtig ist, dass ein Portscan gegen das Netzwerk ausgeführt wurde.

5.1.4 Betrieb

Entgegen allen Erwartungen, was die theoretische Netzlast von 155 MBit/s betrifft,

werden im Durchschnitt weniger als 5 MBit/s in das Internet übertragen. Diese

Netzlast scheint gering zu sein, aber wenn es auf den Tag berechnet wird, so sind das

innerhalb von 24 Stunden ungefähr 54 Gbyte. Im Verhältnis zu dieser Last, beträgt die

durchschnittliche Prozessorauslastung bei Snort nur ca. 10%, wobei der

Hauptspeicher, in dem die Daten zwischengespeichert werden, von 128MB ständig

mit ca. 96 % belegt ist.

Die Betriebssystemkompatibilität ist bei Snort sehr gut, so dass nie ein Absturz aus

Systemgründen aufgetreten ist. Jedoch wurde bei der Testversion ein Bug erkennbar,

als der DoS-Angriff „Ping of Death“ simuliert wurde. Nach mehrfachem Ausführen

dieses Angriffs starb der Prozess Snort, so dass das IDS ausser Gefecht gesetzt wurde.

Dieser Bug wurde in der nächsten Version behoben.

5.1.5 Fazit

Snort erkennt im Vergleich zu anderen getesteten IDS weniger Angriffe und kann die

erkannten Angriffe nicht so gut klassifizieren, aber es ist im Bezug auf das Erkennen

von Portscans ungeschlagen. In die Erstellung von Regeln findet man sich schnell ein

und kann schon früh eigene Regeln erstellen oder vorhandene Regeln ändern. Im



Gegensatz zu anderen IDS muss zwar Snort nach Regeländerungen neu gestartet

werden, aber die Regeln liegen lokal auf dem Rechner, so dass diese nicht an andere

Systeme übertragen werden müssen. Die Anpassbarkeit für die Angriffserkennung ist

aufgrund der Flexibilität und des hohen Potentials der Regeln sehr hoch und weit

entwickelt. Für ein frei verfügbares IDS liefert Snort einige Besonderheiten, die für

die Verfolgung und Aufklärung von Angriffen unumgänglich und essentiell wichtig

sind, wie z.B. die Datenpakete als Hexdump, die den Alarm ausgelöst haben.

Insbesondere glänzt Snort wie schon erwähnt bei der Erkennung von Portscans, wobei

der Zeitfaktor in Verbindung mit der Anzahl an Verbindungsanfragen so variiert

werden kann, dass nur größere Portscans gemeldet werden. Ohne großen Aufwand

lässt sich der Portscan-Preprozessor abschalten oder die IP-Adresse ignorieren, die

ständig Fehlalarme produzieren, die von Snort als Portscans klassifiziert werden. In

Verbindung mit einem Logging in eine Datenbank und der Analyseoberfläche ACID

stellt Snort ein fast vollständiges IDS für den täglichen Gebrauch dar. Weitere

Programme, wie z.B. für das Aktualisieren der Regeln oder für die Alarmauswertung

stehen im Internet bereit. Diese Programme gehören nicht standardmäßig zu Snort,

werden aber auch im Snort-Forum diskutiert und ausgetauscht.



5.2 Computer Associates - eTrust

Das Intrusion Detection System eTrust von Computer Associates ist ein

netzwerkbasierendes IDS. Es kann als Standalone System oder als Agent bzw.

Managementkonsole installiert werden, um mit den anderen IDS-Komponenten zu

kommunizieren. Dieses System ist nur unter Windows verfügbar. Als Testversion

wurde die aus dem Internet heruntergeladene Demoversion 1.5.0.73 unter Windows

2000 verwendet (siehe Abbildung 8 - Übersicht der Alarme von eTrust).

Abbildung 8 - Übersicht der Alarme von eTrust

5.2.1 Installation

Die Installation des Systems geschieht, wie mittlerweile für Windows-Programme

üblich, mit dem Installationstool InstallShield. Dies sollte eigentlich ohne größere

Probleme vonstatten gehen, wobei nach der Installation sogenannte Workspaces

angelegt werden. Alle erfassten Daten und Alarme werden nicht wie üblich in



Datenbanken abgelegt, sondern in diesen Workspaces, die nach Belieben gewechselt

oder neue angelegt werden können.

5.2.2 Konfiguration

Die Standardkonfiguration nach der Installation protokolliert den gesamten

Netzwerkverkehr, was zu einer hohen Auslastung des Systems führt. Nach einer

gewissen Zeit reicht der Hauptspeicher für das Zwischenspeichern von Daten nicht

mehr aus, so dass das IDS eine Warnmeldung ausgibt.

Alle Regelsätze und Regeln sind nach der Installation aktiviert, so dass diese

individuell geändert werden müssen. Es ist keine Hauptskalierung auf eine

vorhandene Systemumgebung (z.B. Windows-Systeme) möglich, bei der ein gewisser

Umgebungs- und Sicherheitstyp gewählt werden kann.

Die Oberfläche zur Konfiguration der Regeln und Regelsätze wurde von Checkpoint

gekauft und ist mit der Konfigurationsoberfläche für die Firewall-1 identisch (siehe

Abbildung 9 - Anpassen der Regeln und Signaturen).

Abbildung 9 - Anpassen der Regeln und Signaturen



Hierbei können die Regeln nach Quelle, Ziel, Diensttyp, auszuführende Aktion und

zeitlicher Gültigkeit der Regel eingestellt, verändert oder neue Regeln hinzugefügt

werden. Das Verändern und Erstellen vorhandener und neuer Regeln geschieht intuitiv

und gestaltet sich durch die übersichtlich gehaltene Oberfläche einfach. Die

auszuführenden Aktionen beinhalten unter anderem Intrusion Response-Techniken,

um einen gefährlichen Datenstrom direkt durch das IDS oder eine Firewall von CA zu

blocken.

Für jede Regel können individuelle Signaturen, kombiniert mit regulären Ausdrücken

erstellt werden. Dieses hohe Anpassungspotential hilft bei der Verringerung von

Fehlalarmen, den sogenannten False Positives. Zusätzlich können bestimmte

Ausnahmefälle definiert werden, in denen die Regel nicht greift.

Die Regeln für die Alarmierung von verdächtig wirkenden paket- und

statistikbasierten Netzwerkaktivitäten lassen sich nicht verändern, obwohl dies genau

bei diesen Regeln erforderlich ist. Denn genau hier treten die meisten Fehlalarme auf.

Die Möglichkeit, viele Regeln verändern zu können steigert den

Konfigurationsaufwand ins Unermessliche, was zur Folge haben kann, dass kaum

Fehlalarme auftreten.

Zusätzlich zu den verschiedenen bereitgestellten Aktionen ist es möglich, diese

miteinander zu kombinieren. Bei einem Alarm können so z.B. ein SNMP-Trap, eine

Alarmmeldung und eine Blockregel gleichzeitig ausgeführt werden.

eTrust beinhaltet die Möglichkeit des Abgleichs mit anderen CA-Produkten und

erkennt deren Einsatz im Netzwerk. Ebenso können Informationen an CISCO-Router

oder andere Systeme geliefert werden, die zur Intrusion Response genutzt werden

können. Die Möglichkeit der akustischen Benachrichtigung ist vorhanden, aber es

bleibt zu Überlegen, ob ein ID-System standardmäßig über eine Soundkarte verfügen

sollte. Dieser Einsatz wurde bereits in Kapitel 3.5.4 Akustische Signale besprochen.


eTrust produzierte ausgelöst durch ständige DNS-Lookups von IP-Adressen selbst so

viel Netzwerkverkehr, dass dies in Verbindung mit dem eingehenden

Netzwerkverkehr das System komplett auslastete. Dies hatte zwingend sowohl die

Zwischenlagerung als auch die gleichzeitige Überprüfung und Zusammensetzung sehr



vieler Daten im Hauptspeicher zur Folge. Das Erkennen von Angriffen wurde so bis

zu mehreren Minuten verzögert. In diesem Fall kann nicht mehr von einem „Echtzeit

Intrusion Detection System“ gesprochen werden. Diese Eigenschaft ist aber bei einem

NIDS essentiell wichtig, da evtl. Gegenmaßnahmen während des Angriffs eingeleitet

werden müssen.

Aufgrund der vielen mitgelieferten Regeln und Regelsätze ist bei der

Standardkonfiguration die Anzahl der Fehlalarme sehr hoch. Es werden auch viele

unwichtige Meldungen, wie z.B. ICMP-ECHO Request (Ping) oder NSLookup (DNS-

Anfragen) mitprotokolliert und angezeigt. Zu den einzelnen Alarmen können die dazu

passenden Meldungen, Informationen und Definitionen angezeigt werden, die aber

meist schlecht beschrieben und nicht aussagekräftig sind.

Die Angriffserkennung der mit IDS Informer simulierten Angriffe ist weitaus höher

als bei Snort:

Anzahl erkannte Angriffe Angriffstyp Anzahl simulierte Angriffe absolut relativ in %

Backdoor 8 5 62,5 %


DoS / DDoS 25 14 56 %

Finger 2 1 50 %


HTTP 5 4 80 %

Scans 13 10 76,92 %

Gesamt 61 38 62,30 %

Zu den generierten Alarmmeldungen können Kurzinformationen angezeigt werden,

um den Angriff besser klassifizieren zu können. Der integrierte Virenscanner hilft bei

der Entschärfung und Erkennung von e-Mailviren. Die Virusdefinitionen können

durch die integrierte Updatemöglichkeit manuell oder automatisch heruntergeladen

und installiert werden.



5.2.4 Betrieb

eTrust arbeitet im Gegensatz zu den meisten anderen IDS mit sogenannten

Workspaces. Diese können beliebig oder automatisch nach einer gewissen Zeit

gewechselt werden, und je nach Bedarf können beliebig viele neue angelegt werden.

Die Arbeit mit den vielen verschiedenen Workspaces bringt Verwirrung, so dass es oft

schwer ist, die richtige auszusuchen, um die Daten zu bewerten. Aufgrund der vielen

mitgeloggten Informationen zu den einzelnen Alarmen steigt der Festplattenplatz

stetig an, so dass es nur eine Frage der Zeit ist, bis die Festplattenkapazität nicht mehr

ausreicht.

Durch die hohe Prozessor-, Hauptspeicher- und Festplattenlast kommt es öfters zu

Abstürzen der Software. Dieses Problem ist bekannt, so dass Computer Associates

einen zusätzlichen Prozess installiert, der das IDS-Programm überwacht. Stürzt das

IDS-Programm ab, so wird es automatisch wieder gestartet. Das Problem dieses

Prozesses liegt darin, dass das IDS-Programm nach dem Neustart in den Pause-

Zustand geht und nicht aktiv ist. Entgegen allen Erwartungen sind nach einem

Neustart des Programms noch alle bis zum Zeitpunkt des Absturzes geloggten Daten

vorhanden.

Um Daten aus den Workspaces betrachten zu können, und um das System nicht

deaktivieren zu müssen gibt es einen View-Modus. Sowohl im View- als auch im

Logging-Modus können die erfassten Meldungen und Statistiken nach Herkunft, Ziel

oder Netzwerkdiensten angezeigt werden. Aus diesen vorhandenen Informationen

lassen sich automatisch, d.h. zu gewissen Zeitpunkten, oder manuell Reports

generieren und Statistiken auswerten.

5.2.5 Fazit

Aufgrund der hohen Netzwerk-, Festplatten- und Hauptspeicherlast kommt das

System schnell an seine Grenzen obwohl die eingehende Netzwerklast bei

durchschnittlichen 3Mbit/s noch relativ gering ist.

Die Kompatibilität mit dem Betriebssystem sowie die darunter leidende, allgemeine

Stabilität des Programms ist unzureichend und für ein IDS im täglichen Einsatz nicht

tragbar. Innerhalb einer Testwoche stürzte das System mehr als 10-mal ab bzw. das



Programm hängte sich manchmal auf, so dass es neu gestartet werden musste. Diese

Situation wurde vom zusätzlich laufenden Prozess nicht erkannt und das System blieb

in einem Deadlock-Zustand stehen.

Die Resultate bei der Erkennung der verschiedenen Angriffe sind sehr gut, da es aber

keine Priorisierung der Alarme gibt, fällt die Suche und Auswertung nach relevanten

Alarmen aufwendig aus.

Unter den vielen registrierten Alarmmeldungen befinden sich ständig sehr viele

Fehlalarme. Der Informationsgehalt einer Alarmmeldung ist für die Erkennung und

Klassifizierung von Fehlalarmen unumgänglich. Da aber nicht genügend

Informationen zu einem Alarm festgehalten werden, ist dies unter Umständen nicht

möglich.

Wie schon erwähnt, ist die Anzahl der mitgelieferten Signaturen sehr groß. Es können

viele verschiedene Netzwerkdienste sehr genau überwacht werden, was eTrust zu

einem sehr guten Content Security System (siehe 1. Einleitung-Content Security

System) macht.

Die integrierten Updatemöglichkeiten für Virusdefinitionen sowie der IDS-Regelsätze

stellen ein einfaches und leicht bedienbares Tool dar, was aber auch einen möglichen

Angriffspunkt darstellt.



5.3 Tripwire

Das Host Intrusion Detection System Tripwire ist ein sogenanntes File Integrity

Assessment Intrusion Detection System. Dies bedeutet, dass es im Gegensatz zu

anderen HIDS nur Dateien auf Integrität – also Unverändertheit überprüft. Es

überwacht keine Prozesse, Anwendungen oder Hauptspeicherinformationen.

Die kostenlose Version von Tripwire ist nur für Linux- /UNIX-Derivate vorhanden und

enthält keine Administrations- bzw. Konfigurationsoberfläche. Diese Oberflächen

werden bei der kommerziellen Version mitgeliefert, sind aber nicht separat erhältlich.

Die nachfolgenden Erkenntnisse basieren auf der kostenlos zum Download bereit

gestellten Version 2.3.1-2 von Tripwire.

5.3.1 Installation

Wie für fast alle Linux-/UNIX-Applikationen wird ein so genanntes Tarball, also eine

komprimierte Datei, die eine Verzeichnisstruktur enthält, bereitgestellt. Es gibt keine

verschiedenen Versionen für die verschiedenen Linux-/UNIX-Distributionen, da die

Installation für alle Systeme gleich verläuft und sich nur die Konfigurationsdateien

verändern. Vor der Kompilierung muss in einer Konfigurationsdatei das

Betriebssystem angegeben werden, damit die benötigten Kompilierungsoptionen

verwendet werden. Während des Erstellens der vier benötigten Anwendungen werden

zwei Passwörter abgefragt, die für die Verschlüsselung der Konfigurationsdateien

sowie der Datenbank benötigt werden.

5.3.2 Konfiguration

In der vorhandenen Konfigurationsdatei für die allgemeinen Einstellungen können

Informationen zum Betriebssystem sowie e-Mailadressen für die Benachrichtigung

angegeben werden.

Die Konfigurationsdatei für die Erstellung der Integritätsdatenbank, im folgenden

Datenbankkonfigurationsdatei genannt, enthält Listen von Dateien, die überwacht

werden sollen und Regeldefinitionen wobei schon vorhandene Regeln genutzt,

verändert und erweitert werden können. Ebenfalls können Variablen für eine bessere

Übersicht und eine einfachere Handhabung deklariert werden.



In der Datenbankkonfigurationsdatei werden alle Dateien, die überwacht werden

sollen, eingetragen wobei jede Zeile die direkte Pfadangabe der Datei mit den zu

überwachenden Dateiattributen enthält.

Diese Datenbankkonfigurationsdatei kann für die unterschiedlichsten Linux-/UNIX-

Distributionen aus dem Internet heruntergeladen und verwendet werden. Das Problem

liegt darin, dass diese Datei aus dem Internet noch an das bestehende System

angepasst werden muss. So kann es vorkommen, dass in der Konfigurationsdatei

Einträge zu Programmen vorhanden sind, die auf dem aktuellen System nicht

installiert bzw. vorhanden sind. Dies würde bei mehrfachem Auftreten solcher Fälle

zu vielen Alarmmeldungen führen. Es ist auch der umgekehrte Fall möglich, so dass

auf dem System zusätzliche Programme installiert wurden, die nicht zur Überwachung

in die Datenbankkonfigurationsdatei aufgenommen wurden und somit angreifbar sind

ohne einen Alarm auszulösen. Aus diesem Grund wurde zur Aufnahme aller

ausführbaren Dateien aus den Linux-/UNIX-Verzeichnissen /bin, /usr/bin,

/usr/local/bin, /sbin und /usr/sbin ein Skript geschrieben, um sicherzustellen, dass alle

Dateien in diesen vorhandenen Verzeichnissen in der Konfigurationsdatei enthalten

sind.

Wie bereits erwähnt werden zu jedem Eintrag in der Konfigurationsdatei, d.h. zu jeder

Datei, die Dateiattribute eingetragen, die überprüft werden sollen. Tripwire kann

insgesamt 18 verschiedene Dateiattribute unterscheiden, die überprüft werden sollen.

Diese Dateiattribute können beliebig miteinander kombiniert werden. Zu diesen

gehören unter anderem: Erstellungszeit; Tag der letzen Änderung; Tag des letzten

Zugriffs; Zugriffsrechte; Größe der Datei auf dem Datenträger; Anzahl der belegten

Blöcke auf dem Datenträger; CRC32-, MD5-, Haval oder SHA-Checksummen.

Aufgrund der vielen verschiedenen Dateien unter diesen Betriebssystemen, gibt es

noch zusätzliche Erweiterungen. So können z.B. Log-Files mit der Option –l

überwacht werden, die das Anwachsen der Datei erlauben und automatisch neue Log-

Dateien in die Datenbank aufnehmen.

Zur besseren und übersichtlicheren Strukturierung der Konfigurationsdatei können

einzelne Sektionen mit unterschiedlichen Beschreibungen erstellt werden. Diese

Sektionen können mit einem Wert zwischen 1 und 1.000.000 priorisiert werden, wobei

1 die niedrigste Priorität bedeutet.



Wurden alle Einstellungen vorgenommen, kann ein erster Initialisierungslauf gestartet

werden. Dabei werden alle nötigen Dateiattribute für die zu überprüfenden Dateien

festgehalten und in der Datenbank abgelegt. Damit später diese Datenbank nicht

verändert werden kann, wird diese nach Abschluss des Initialisierungslaufs

verschlüsselt.

Nach dem Initialisierungslauf wird der erste Report erstellt und per e-Mail verschickt

(siehe Abbildung 10 - generierter Report von Tripwire).

Abbildung 10 - generierter Report von Tripwire

Mit diesem generierten Report kann überprüft werden, ob Fehler aufgetreten sind, die

noch behoben werden müssen.




Tripwire ist im Gegensatz zu Echtzeit-HIDS reaktiv, d.h. erst nachdem ein Angriff

festgestellt wurde, wird ein Alarm ausgegeben. Wie bereits erwähnt ist Tripwire kein

Echtzeit-IDS, sondern es wird nur zu gewissen Zeiten, meist über einen „Cron-Job“

ausgeführt. Aufgrund der Tatsache, dass Tripwire keine Prozesse und Programme

überwacht, ist es auch nicht nötig das System als Echtzeit-HIDS zu implementieren,

zumal die Prozessor- und Festplattenlast immens wäre.

Wurde eine Veränderung von einem oder mehreren Dateiattributen bei einer Datei

festgestellt, so wird über den generierten e-Mailreport eine Warnmeldung mitgeliefert,

in der genauer beschrieben wird, welche Datei sich wie geändert hat. In Abhängigkeit

zu den in der Konfigurationsdatei angegebenen Optionen wird mit der Datei

weiterverfahren, so dass z.B. eine neue Datei, die unter eine gewisse Sektion fällt

einfach in die Datenbank mit aufgenommen wird. Andererseits kann es ebenso sein,

dass eine Datei die geändert wurde und bei einem früheren Report gemeldet wurde

wieder in den darauf folgenden Reports auftaucht, so lange bis die Änderungen

manuell in die Datenbank übernommen wurden. Dies kann auf längere Zeit störend

sein, lässt sich aber mit den richtig gesetzten Optionen verhindern.

5.3.4 Betrieb

Der Datenbankabgleich wird immer zu gleichen Zeiten durchgeführt, folglich ist zu

den anderen Betriebszeiten des Systems nichts von Tripwire zu merken ist.

Wird jedoch der Abgleich durchgeführt, steigt die Prozessor- und

Festplattenauslastung stark an, gleichzeitig sinkt die Leistung des Systems stark ab.

Die Laufzeit dieses Abgleichs ist von der Anzahl der Einträge und den damit

verbundenen Optionen in der Konfigurationsdatei abhängig. Aus diesen Gründen

sollte der Abgleich zu Zeiten geschehen, in denen nicht allzu viel Systemleistung

benötigt wird.

Je nach Einsatz der Dienste, die hauptsächlich auf dem System laufen muss die IDS-

Anwendung angepasst werden, es kann also nur in den seltensten Fällen eine

Standardkonfiguration benutzt werden. Dieser Umstand erfordert ein hohes Maß an

Zeitaufwand, die jeder Installation von Tripwire gewidmet werden muss.



Eine Überprüfung des HIDS mittels IDS Informer war nicht möglich, da ein FIA-IDS

nicht über das Netzwerk angegriffen werden kann. Es wurden lediglich Tests durch

Verändern von Dateien, Zugriffsrechten usw. durchgeführt, die ein sehr

überzeugendes Ergebnis lieferten.

5.3.5 Fazit

Tripwire wurde als zusätzliches HIDS zu Snort installiert, um das System gegen

Angriffe schützen zu können. Die aus dem Internet heruntergeladene

Konfigurationsdatei für Mandrake Linux 8.1 konnte nur zum kleinen Teil genutzt

werden, da einige Programme, die in der Konfigurationsdatei vorhanden waren nicht

auf dem System installiert waren. Ebenfalls mussten Programme, die auf dem System

vorhanden waren, zusätzlich in die Konfiguration aufgenommen werden. Ein

manuelles Überprüfen auf die Präsenz jedes Programms in der Konfiguration, hätte

bei über 2000 Einträgen sehr viel Zeit gekostet. Aus diesem Grund wurde ein eigenes

Programm entwickelt, das einen Großteil des Aufwands ersparte.

Problematisch wurde das Einbinden der Snort-Verzeichnisse, da Snort ständig neue

Dateien und Ordner anlegt und sich somit ständig Änderungen ergeben. So kann es

sein, dass ein Tripwire-Report mehrere hundert Einträge über neue oder veränderte

Dateien enthält, die nicht alle überprüft werden können.



5.4 ISS - Real Secure

Real Secure von ISS ist ein komplettes Enterprise-System, das seinesgleichen sucht.

Es besteht aus Netzwerk-Sensoren (NIDS), Server-Sensoren (HIDS) und Workgroup-

Managern. Die eigentlichen Angriffserkennungskomponenten sind die Sensoren, die

ihre Alarme an Event-Kollektoren senden. Jeder Sensor kann seine Daten an einen

oder mehrere Event-Kollektoren liefern. Diese Event-Kollektoren können von

mehreren Management-Konsolen, den Workgroup-Managern abgefragt werden.

Die Netzwerk- und Server-Sensoren gibt es für mehrere verschiedene

Betriebssysteme, wie z.B. Windows, Linux und UNIX. Dies erlaubt die Installation

von Server-Sensoren innerhalb der DMZ auf einem Server, der Dienste wie z.B. einen

Web-Server anbietet. Diese Dienste laufen oft aus Sicherheitsgründen auf UNIX- und

nicht auf Windows-Systemen.

5.4.1 Installation

Aus Zeit- und Aufwandsgründen wurden der Netzwerk- und der Server-Sensor unter

Windows 2000 installiert. Da nur ein Testsystem vorhanden war, wurden beide

Sensoren sowie der Event-Kollektor und der Workgroup-Manager auf einem Rechner

installiert. Zur Speicherung der Daten wurde auf dem System zusätzlich ein Microsoft

SQL-Server installiert, in dem der Event-Kollektor seine Daten ablegt.

Die Installation erfolgt wie mittlerweile unter Windows üblich mittels einer

InstallShield-Installation und sollte keine Probleme bereiten. Durch die möglichen

Einstellungen sowie die Angaben zur Verbindung zwischen den Sensoren und dem

Event-Kollektor, ist es nötig die Installationsanleitung aus dem Internet

herunterzuladen und zu verwenden. Während der Installation der Sensoren kann ein

System-Hardening vorgenommen werden und die Unterstützung für die

Verschlüsselung des Datenverkehrs vom Sensor zum Event-Kollektor eingestellt

werden. Zusätzlich können sogenannte Key-Distributoren eingestellt werden, die für

die Schlüsselaufbewahrung und Verteilung eingesetzt werden können.

Werden Netzwerk- und Server-Sensor auf demselben System installiert, so warnt der

Installationsagent, dass beim Server-Sensor die Netzwerkunterstützung abgeschaltet

wird.



Die Installation der Systeme beinhaltet das automatische Anlegen von Diensten und

Benutzern und verbietet die Angabe von leeren Passwörtern, was die Sicherheit des

Systems stark erhöht.

5.4.2 Konfiguration

Um die Systemleistung bei der Installation aller IDS-Dienste auf einem System zu

optimieren wird keine Verschlüsselung zwischen dem Datenaustausch eingesetzt.

Diese Ver- und Entschlüsselung würde nur unnötige Prozessorlast verursachen, da

sowohl der Agent als auch der Event-Kollektor auf demselben Rechner sitzen und der

Datenaustausch lokal von statten geht.

Für das Logging in die Datenbank wird nicht unbedingt ein Microsoft SQL-Server

benötigt, es kann auch eine vereinfachte Datenbank, die MSDE33 installiert werden.

Um den Event-Kollektor mit den Sensoren zu verbinden, muss dieser zuerst installiert

und die Sensoren danach mit dem Deployment-Wizard verbunden werden (siehe

Abbildung 11 - Hinzufügen der Sensoren zum Event-Kollektor).

33 MSDE = Microsoft SQL Server Desktop Engine



Abbildung 11 - Hinzufügen der Sensoren zum Event-Kollektor

Ein Sensor kann somit seine Daten an mehrere Event-Kollektoren liefern. Die Event-

Kollektoren können ebenfalls von mehreren Management-Konsolen abgefragt werden.

Nach der Installation aller Komponenten können die Regelsätze angepasst werden, da

die Standardregelsätze fast alle möglichen Angriffe und verdächtigen

Netzwerkverkehr alarmieren. Zur genaueren Konfiguration können von den schon

mitgelieferten und vordefinierten Vorlagen eigene Einstellungen abgeleitet werden.

Diese mitgelieferten Vorlagen (auch Policies genannt) beinhalten Konfigurationen für

Windows- und UNIX-Umgebungen, sowie solche für den Einsatz vor der Firewall

oder in der DMZ (siehe Abbildung 12 - Auswahl einer Sensor-Policy).



Abbildung 12 - Auswahl einer Sensor-Policy

Die Veränderung der einzelnen Regelsätze und Regeln ist einfach gehalten, was das

Anpassungspotential erheblich beeinträchtigt. So sind nur eine gewisse Anzahl an

vordefinierten Aktionen einstellbar, wie z.B. das Anzeigen und Loggen eines Alarms.

Die Signaturen lassen sich zum Teil nicht ändern, so dass nicht gegen Fehlalarme

Angegangen werden kann, ohne die Regel zu deaktivieren. Diese Aktionen sind für

jede Regel individuell einstellbar, wobei zu jeder Regel ebenfalls eine der Prioritäten

niedrig, mittel oder hoch eingestellt werden kann. Zu einigen Regeln können

erweiterte Einstellungen vorgenommen werden, die das Ignorieren gewisser

Zeichenfolgen erlauben, um die Anzahl der Fehlalarme zu verringern. Ein weiterer

Vorteil ist die Möglichkeit der Ereignisfilterung, so kann ein Zeitraum definiert

werden, indem das wiederholte Auftreten desselben Ereignisses nicht als neuer Alarm

gewertet wird.

Ein großer Nachteil von Real Secure wird durch einen Systemneustart sichtbar, so

sind nach diesem alle vorher erkannten Alarme nicht mehr sichtbar und nur noch in

der Datenbank vorhanden.




Real Secure hat bei der Erkennung der mit IDS Informer simulierten Angriffe von

allen IDS am besten abgeschlossen. Über 70% aller Angriffe wurden erkannt und

richtig klassifiziert:

Anzahl erkannte Angriffe Angriffstyp Anzahl simulierte Angriffe

absolut relativ in %

Backdoor 8 8 100 %


DoS / DDoS 25 16 64 %

Finger 2 1 50 %


HTTP 5 3 60 %

Scans 13 11 84,62 %

Gesamt 61 45 73,77 %

Diese Ergebnisse müssen mit Hinblick auf die Tatsache beobachtet werden, dass Real

Secure nur diejenigen Angriffe richtig erkannt hat, die auch direkt an das IDS

gerichtet waren. Die Anzahl der erkannten Angriffe gegen das gesamte Subnetz bzw.

gegen Systeme in der DMZ fällt wesentlich geringer aus, da IDS Informer nur direkt

gegen IP-Adressen eingesetzt werden kann. Dieses Verhalten wurde bei allen

getesteten ID-Systemen festgestellt, so dass Real Secure hier keine Ausnahme

darstellt.

Ein Nachteil, der mittlerweile bei mehreren ID-Systemen, unter anderem auch Real

Secure, festgestellt wurde, ist die Tatsache, dass keine Hex-Dumps mitgeloggt und

abgespeichert werden. Real Secure beinhaltet die Möglichkeit, Alarme mit Hex-

Dumps abzuspeichern, stellt aber selbst keine Software zur Verfügung, die das

Überprüfen der Hex-Dumps erlaubt. Eine Software, die die Möglichkeit bietet, Real

Secure Hex-Dumps anzuschauen kann von einer anderen Firma erworben werden.



Bei der Erkennung von Portscans liegt Real Secure nur knapp hinter Snort, dafür kann

Real Secure die verschiedenen Portscans in Prioritäten unterteilen, so hat z.B. ein

UDP-Scan die höchste Priorität, wohingegen ein TCP-Scan nur mittlere Priorität hat.

Zusätzlich zu den Features eines ID-Systems bietet Real Secure sogenannte virtuelle

Dienste an, die sonst nur ein Honeypod 34anbietet. Diese virtuellen Dienste sind z.B.

Web-Server, FTP-Server oder Mail-Server. Überprüft ein Angreifer diese Dienste, so

wird er herausfinden, dass er versucht ein ID-System zu hacken. Dies kann dem

Angreifer dienlich sein, da er versuchen kann das ID-System außer Gefecht zu setzen.

Andererseits kann es auch eine abschreckende Wirkung auf den Angreifer ausüben.

Aus diesem Grund ist es unverständlich, dass Real Secure diese virtuellen Dienste

anbietet, stellen sie potentielle Sicherheitslücken dar.

5.4.4 Betrieb

Die erkannten Angriffe werden als Baumstruktur nach Quell-, Zieladresse und

Informationen dargestellt, wobei in eine der drei Ansichten Quelle, Ziel oder Event

gewechselt werden kann (siehe Abbildung 13 - Ansicht der Alarme nach Events).

34 Honeypod = Anbieten von virtuellen Diensten, um einem Angreifer ein laufendes System

vorzugaukeln, wobei alles simuliert wird. Dies wird verwendet, um Informationen über einen

Eindringling zu erhalten und Angreifer vom eigentlichen System fernzuhalten.



Abbildung 13 - Ansicht der Alarme nach Events

Die Informationen enthalten Einzelheiten über den Angriff, die Angriffsart sowie

Details für die Klassifizierung von Fehlalarmen. Die zu einem Angriff abgelegten

Informationen können mit einem Mausklick in FQDN aufgelöst werden. Dies

geschieht nicht standardmäßig, um keine unnötigen Systemressourcen zu

beanspruchen, die das System ausbremsen könnten. Ebenfalls wird dadurch keine

zusätzliche Netzlast produziert, da eine Namensauflösung bei Bedarf ausreicht. Diese

Ressourceneinsparungen erlauben dem System bei höherer Netzlast die Überprüfung

und Alarmierung noch in Echtzeit durchzuführen, was von einem NIDS erwartet wird.

5.4.5 Fazit

Die Auslastung, insbesondere die Netz- und Prozessorlast fällt bei Real Secure

besonders auf, da es das einzige unter Windows getestete IDS ist, das mit den

anfallenden Informationen gut und ohne Überlastung zurecht kommt. Abstürze gab es



so gut wie keine, was eine ausgezeichnete Kompatibilität mit dem darunter liegenden

System wiederspiegelt.

Wie bereits erwähnt hat Real Secure von allen gestesteten IDS die meisten Angriffe

erkannt und korrekt klassifiziert. Ebenfalls ist eine Priorisierung der Alarme

vorhanden, die nach Belieben verändert werden kann. Die Unterteilung in drei

unterschiedliche Prioritäten ist ausreichend und dient der besseren Übersicht.

Während der praktischen Arbeit mit ID-Systemen wurde klar, dass jedes NIDS und

NNIDS mit vielen Fehlalarmen zu kämpfen hat. Diese lassen sich leichter

identifizieren, je mehr Informationen zu einem Angriff vorhanden sind. So sind Hex-

Dumps unerlässlich, was Real Secure zwar unterstützt, diese können aber nicht mit

Real Secure selbst betrachtet werden. Informationen zu den einzelnen Alarmen mit

Beschreibung der möglichen Ursache eines Fehlalarms erleichtern das Erforschen der

Meldung.

Die Anzahl der mitgelieferten Signaturen ist, wie an den Ergebnissen zu sehen ist,

ausreichend. Manchmal wäre es schön, einige Signaturen verändern oder anpassen zu

können, was aber den Verwaltungs- und Konfigurationsaufwand erheblich steigern

würde.

Die negativste Erfahrung mit Real Secure war das versuchte Update der einzelnen

Sensoren auf die aktuellste Version über die integrierte Updatemöglichkeit. Danach

wurden nicht mehr alle Sensoren vom Event-Kollektor erkannt, so dass der Versuch

unternommen wurde, Real Secure neu zu installieren. Selbst danach wurden einige

Sensoren nicht mehr gefunden, das komplette Betriebssystem musste neu installiert

werden.

Um Real Secure als Enterprise-IDS laufen zu lassen, wird eine Management-Konsole

unter Windows benötigt, da diese nur für dieses Betriebssystem vorhanden ist.



5.5 NFR – Network Intrusion Detection

Das NIDS Network Intrusion Detection von Network Flight Recorder (NFR-NID) war

lange Zeit das führende ID-System auf dem Markt. Dies liegt wohl an dem

einzigartigen Sicherheitskonzept, dass das IDS unsichtbar und gegen Angriffe absolut

sicher macht.

Der Name Network Intrusion Detection ist etwas irreführend, da es ein NIDS und

HIDS gibt. Wird nur das NIDS installiert, so reicht zur Administration eine Windows-

Applikation, wobei zur Administration beider IDS ein weiteres System, der Central

Management Server nötig ist. Alle drei Systeme (NIDS, HIDS, Central Mangement

Server) laufen unter verschiedenen Betriebssystemen, so dass jede Software auf einem

eigenen System installiert werden muss.

5.5.1 Installation

Von einer Installation des NIDS kann man nicht sprechen, da die Software auf einer

CD geliefert und nicht auf der Festplatte installiert wird. Das auf OpenBSD basierende

System wird von der CD betrieben, welches von sich aus schon eine gewisse

Sicherheit mitbringt. Auf der Festplatte werden lediglich die gesammelten

Informationen und Alarme abgelegt, weshalb diese vor dem Einsatz gelöscht wird.

Die vorgenommenen Konfigurationen werden auf einer Diskette abgelegt, die

schreibgeschützt werden kann. Da das NIDS im Stealth-Modus betrieben wird, wird

eine zweite Netzwerkkarte für die Administration benötigt. Die Administration über

ein eigenes Netzwerk wird wie schon erwähnt „out-of-band bzw. out-band

Management“ genannt, um die Systemleistung zu verbessern und die Netzlast zu

senken.

Das Administration-Interface35, das für die Konfiguration des NIDS benötigt wird

musste von der NFR-Webseite heruntergeladen werden. Ebenfalls musste die

Dokumentation zur Installation und Konfiguration heruntergeladen werden, da diese

Dokumente nicht auf den mitgelieferten CDs vorhanden waren.

35 Administration-Interface = Benutzungsoberfläche zur Administration des IDS (Definition laut NFR)



Die Installation des heruntergeladenen Administration-Interface unter Windows sollte

mittels InstallShield-Installation problemlos verlaufen. Aus zeitlichen und

umgebungsbedingten Gründen konnte das HIDS sowie der Central Management

Server nicht installiert werden, denn eine Administration mehrerer IDS kann wie

schon erwähnt nur mit dem Central Management Server geschehen. Dieser hätte ein

weiteres System benötigt, das aber nicht vorhanden war und nicht hätte besorgt

werden können.

5.5.2 Konfiguration

Eine direkte Konfiguration des NIDS am System ist nicht möglich, es können zwar

IP-Adresse und Administrator-Passwort festgelegt, Regeln aber nicht verändert

werden. Für diese Administration ist das Administration-Interface auf einem

Windows-System nötig. Die Oberfläche ist übersichtlich und sehr einfach gehalten, so

dass die wenigen einstellbaren Optionen schnell erreicht werden können (siehe

Abbildung 14 - Übersicht der Alarme des NFR Network Intrusion Detection).

Abbildung 14 - Übersicht der Alarme des NFR Network Intrusion Detection



Die erkannten Ereignisse können in einer der drei vordefinierten Listen, oder in einer

eigenen, neu erstellten Liste abgelegt werden. Um stets die neuesten Alarme

darzustellen, können die älteren, schon überprüften Alarme ausgeblendet werden.

Alarme können gruppenweise in einer Baumstruktur oder in ihrer zeitlichen Abfolge

dargestellt werden.

Die wichtigeren Ereignisse werden in einer Popup-Liste abgelegt, wobei diese Liste

beim Auftreten eines neuen Alarms sofort in den Vordergrund springt. Die

Einordnung eines häufig auftretenden Alarms in diese Liste kann sehr lästig sein und

die Arbeit bzw. Administration stark behindern.

Will man bestimmte Regeln verändern, so kann dies nicht über eine schöne

Oberfläche gemacht werden, sondern es muss der Quellcode der Regel editiert

werden. Dieser Regel-Quellcode, auch N-Code genannt, ist eine Eigenentwicklung

von NFR, der an die Programmiersprache C angelehnt ist (siehe Abbildung 15 - N-

Code eines DoS-Angriffs).

Abbildung 15 - N-Code eines DoS-Angriffs



Die Komplexität und die Mächtigkeit dieser Sprache ist immens, so dass nur durch

täglichen Umgang dieser Code verstanden und verändert werden kann. Eine kurze

Einarbeitung ist somit nicht möglich, weshalb die Regeln während der Testphase nicht

verändert wurden. Die veränderten Regeln und Systemeinstellungen werden bei

Bedarf über das Administration-Interface an das IDS über das Netzwerk verteilt.

Ein Update der IDS-Engine ist nur durch Auswechslung der CD möglich, da wie

schon erwähnt das ganze System auf der CD verbleibt und nicht installiert wird.


Zur Angriffserkennung können die Daten in Echtzeit auf dem NIDS-Sensor

mitgelesen werden, was aber aufgrund der kurzen Aktualisierungszeiten nicht effektiv

und übersichtlich ist. Aus diesem Grund können die Alarme über das Administration-

Interface angezeigt und überprüft werden.

NFR-NID wird im Stealth-Modus installiert, was sich nicht umgehen lässt. Somit

konnte es nicht direkt mit IDS Informer angegriffen werden, wodurch auch keine

Aussagen über die Resultate der Angriffserkennung möglich sind.

Es wurden viele Verletzungen im Bezug auf HTTP-Verkehr festgestellt, welche

standardmäßig durch ein Popup-Fenster angezeigt wurden. Diese Anzeigeart behindert

das Arbeiten durch ein in den Vordergrund drängendes Fenster, so dass bei mehreren

Alarmen dieser Art innerhalb 5 Minuten diese Alarmierung störend ist. Abhilfe schafft

das Ändern der Alarmierung eines Alarms, was aber nicht ganz einfach ist. So reicht

es nicht aus, die Alarm-Konfiguration zu ändern, es muss zusätzlich die

Gruppenalarmierungsart modifiziert werden.

Es können nur ganze Pakete deaktiviert werden, einzelne Regeln werden durch

Einstellen keiner Alarmierungsart deaktiviert.

Die Portscan-Engine erkennt zwar Portscans, stellt aber nur insoweit die IP-Adressen

der gescannten Systeme dar, wie Platz im Alarmierungsfenster vorhanden ist.

Desweiteren wird weder die Angabe der IP-Adresse des Angreifers, noch Nummern

der gescannten Ports gemacht. Durch diese wenigen Angaben kann ein Portscan nur

zur Kenntnis genommen und nicht näher untersucht werden.



Erkannte Angriffe gegen ein System werden nur durch Angabe der Quell- und Ziel-IP-

Adresse alarmiert, wobei zu dem erkannten Alarm eine allgemeine Beschreibung

mitgeliefert wird. Dieser kann ohne zusätzliche Informationen wahrgenommen, aber

nicht auf einen Fehlalarm überprüft werden.

5.5.4 Betrieb

Wie bei fast allen anderen ID-Systemen gibt es Filterregeln, um nach bestimmten

Alarmen suchen zu können. Die Suchangaben können fein eingestellt werden, um eine

bestmögliche Trefferauswahl zu garantieren.

Um das System mehreren Administratoren zugänglich zu machen, können

verschiedene Administrator-Accounts mit unterschiedlichen Rechten angelegt werden.

Der Sensor kann in Echtzeit auf Systemressourcen und Auslastung überprüft werden,

welche er in gewissen Zeitabständen an das Administration-Interface liefert von dem

diese Informationen ebenfalls abgerufen werden können. Diese Informationen sind

sehr wichtig, da ständig überprüft werden kann, wieviele Pakete aufgrund der

Auslastung weggeworfen wurden.

Die Softwareversion des NFR-NID enthält genaue Restriktionen der zu verwendenden

Hardware, da die Anforderungen relativ hoch sind. Aus diesem Grund gibt es das

NFR-NID auch als Hardwarekomponente, die jedoch nicht getestet werden konnte.

Während der Testphase war das System immer stark ausgelastet, was an der

Hauptspeichernutzung und der Anzahl der verworfenen Pakete ersichtlich war. Die

Prozessorlast lag durchschnittlich bei ca. 10%, wobei die Hauptspeichernutzung meist

bei 98%-99% lag.

Die gelegentlichen Abstürze können möglicherweise durch die starke Auslastung oder

die Inkompatibilität einiger Komponenten des Testsystems verursacht worden sein,

dies konnte aber nicht bewiesen werden. Positiv muss aber berücksichtigt werden,

dass nach einem Absturz das System neu gebootet wurde und ein lauffähiger Zustand

erreicht wurde, in dem das System seine Arbeit fortsetzte.

5.5.5 Fazit

Ein großes Problem machte die Beschaffung der Software, da das Produkt als einziges

nicht über das Internet beziehbar war. So dauerte es über 2 Monate bis eine selbst



gebrannte Version der Software ankam. Diese CDs enthielten nur die Systeme und

keine Beschreibungen oder sonstigen Tools, so dass diese durch zufälliges Suchen und

Finden im Internet nachträglich heruntergeladen wurden. Unter anderem musste auch

die Administrationsoberfläche aus dem Internet bezogen werden. Durch undeutliche

Informationen zur Verwendung der Administrationsoberfläche in der Dokumentation

musste der e-Mailsupport von NFR in Anspruch genommen werden. Diese

Supportanfrage wurde aber erst nach über 5 Tagen beantwortet, so dass die technische

Unterstützung von NFR für eine Firma inakzeptabel ist.

Das Administration-Interface lässt sich aufgrund seiner kleinen Größe über eine

Diskette von jedem Windows-System aus verwenden, ist aber aufgrund des veralteten

Look-and-Feels optisch nicht ansprechend. Die Anzahl der veränderbaren Optionen

sowie die dargestellten Ereignisse sind trotz einer geringen Anzahl unübersichtlich.

Abschließend lässt sich sagen, dass das einstmals führende IDS den Anschluss an den

Stand der Technik verschlafen hat. Die Administrationsoberfläche ist optisch nicht

mehr ansprechend und die Vorgänge zum Ändern von Einstellungen nicht intuitiv, so

dass unter Umständen lange danach gesucht werden muss. Die Veränderung von

Regeln können nur geschulte Administratoren vornehmen, die sich mit N-Code

auskennen.

Vergleich und Einführung von IDS 6. Zusammenfassung


6. Zusammenfassung

Entgegen allen Erwartungen vor den Tests der ID-Systeme, wurde das NIDS von

Network Flight Recorder nicht als bestes System bewertet. Dieses System war früher

Marktführer und setzte die Standards. Mittlerweile hat es wohl den Anschluss an den

heutigen Standard verloren und kann mit den aktuellen, auf dem Markt verfügbaren

Produkten nicht mehr mithalten. Die nötige Verwendung von drei verschiedenen

Betriebssystemen, um ein Enterprise-System aufzusetzen bringt zwar einen

Sicherheitsvorteil, aber auch zusätzliche und zum Teil unnötige Kosten mit, da ein

Administrator sich auf allen Systemen auskennen muss.

Auf Basis der getesteten Systeme hat Real Secure von ISS am besten abgeschnitten,

was Systemleistung, Stabilität, Benutzerfreundlichkeit und Anpassungsfähigkeit

angeht. Die intelligente Aufteilung nach Sensoren, Event-Kollektoren und

Management-Konsolen ist ausgereift und bringt durch die Verschlüsselung des

Datenverkehrs die benötigte Sicherheit. Die verschiedenen Sensoren gibt es für viele

unterschiedliche Betriebssysteme, was ein universelles Einsetzen erlaubt. Durch die

unter Windows verfügbare Management-Konsole werden kostspielige Schulungen der

Administratoren hinfällig, da die Benutzung intuitiv, relativ einfach und doch

umfangreich ist.

Das einzige nicht in einer Enterprise-Umgebung getestete Standalone-HIDS war

Tripwire. Dies wurde unter Mandrake Linux 8.1 getestet, da es nur unter Linux-

/UNIX-Systemen verfügbar ist wobei nur die kostenlose, freie Version überprüft

wurde. Tripwire ist ein File Integrity Assessment Intrusion Detection System, das nur

Dateien auf Integritätsverletzungen überprüft. So können versuchte Brute-Force-

Login-Angriffe nicht festgestellt und alarmiert werden. Die Konfiguration von

Tripwire ist zeitaufwendig aber relativ einfach. Sobald das System steht, liefert es gute

und meist ausführliche Informationen. Die Überwachung von Prozessen und

Anwendungen ist für HIDS aber unumgänglich, da die Installation eines Root-Kits

unter Tripwire eventuell nicht erkannt werden kann und so das HIDS wirkungslos

macht.

eTrust von Computer Associates war das erste unter Windows getestete IDS. Der erste

Eindruck war durch die grafische Umgebung, der intuitiven Navigation und das



einfache Verändern einzelner Regeln geprägt. Der Umfang der mitgelieferten Regeln

ist so umfangreich, dass das System eher für ein Content-Security System und nicht

für ein IDS gehalten werden kann. Durch die umständliche Speicherung der Daten in

Workspaces wird unnötiger Festplattenplatz verschwendet. Die ständig laufenden

DNS-Anfragen produzieren so viel zusätzlichen Netzwerkverkehr, dass das System

die anfallenden Daten nicht mehr verarbeiten kann und Netzwerkpakete verwirft. Die

Instabilität ist der schwerwiegendste Grund, warum dieses System für den

Dauereinsatz ungeeignet ist. So ist eTrust nie mehr als 3 Tage ununterbrochen, d.h.

ohne einen Absturz durchgelaufen.

Das einzig freie NIDS Snort ist für Windows, Linux- und UNIX-Systeme verfügbar.

Der Installations- und Konfigurationsaufwand dieses Systems ist mit Abstand am

größten. Aber nach diesen Vorgängen gehört Snort zu den besten getesteten ID-

Systemen überhaupt, da es ständig weiterentwickelt wird, sehr anpassungsfähig und

überaus schnell ist. Zur Datenauswertung werden zusätzliche Programme benötigt, die

nicht von Snort bereitgestellt werden, im Internet aber kostenlos verfügbar sind. Die

Anpassbarkeit der vorhandenen Regeln ist hoch, so dass beim Auftreten neuer

Sicherheitslücken innerhalb kürzester Zeit eigene Regeln erstellt werden können.



6.1 Erkenntnisse

Die gesammelten Erfahrungen während des Vergleichs der Systeme hat deutlich

gemacht, dass ID-Systeme trotz der schon langen Verfügbarkeit noch nicht weit genug

fortgeschritten und entwickelt sind. So sind bei allen getesteten Systemen viele

Fehlalarme aufgetreten, die eigentlich nicht vorkommen sollten. Im Bereich der

Intrusion Response sind diese Fehlalarme bedrohlich, da dem Benutzer, der den

Fehlalarm unabsichtlich produziert hat, die Verbindung getrennt und evtl. der Zugang

verweigert wird. Für die Erkennung von Fehlalarmen ist viel praktische Erfahrung

nötig, die erst durch den Umgang mit ID-Systemen erlernt werden kann. Hex-Dumps

(Inhalte von Netzwerkpaketen) sind für das Untersuchen eines Alarms sehr wichtig,

um Fehlalarme zu erkennen und die Ursachen untersuchen zu können. Durch die

alleinige Angabe der Quell-, Ziel-IP-Adresse und des Alarms können vorhandene

Ereignisse nicht hinreichend überprüft und ihnen auch nicht entgegengewirkt werden,

sondern hier sind tiefergehende Infos (z.B. Hex-Dumps) nötig.

Jedes der getesteten Systeme hat seine Stärken und Schwächen, so dass es kein

System gibt, das alle Angriffe erkennt, stabil ist und zudem kaum Fehlalarme meldet.

Als professionelle Gesamtlösung kann eigentlich nur Real Secure von ISS

vorgeschlagen werden. Das System stellt den heutigen „Stand der Technik“ dar, das

für zukünftige ID-Systeme als Vorbild dienen sollte.



6.2 Aufgetretene Probleme

Während der Testphasen sind einige unvorhergesehene Probleme aufgetreten, die

untersucht und gelöst werden mussten.

Zuallererst musste eine Möglichkeit gefunden werden, um den eingehenden und

ausgehenden Netzwerkverkehr in einem segmentierten, mit Switches unterteilten

Netzwerk zu untersuchen. Durch den schon vorhandenen Einsatz von CISCO-

Switches war es möglich, ein Port-Mirroring bzw. Port-Spanning einzurichten, bei

dem der gesamte Netzwerkverkehr aller benutzten Ports auf einen anderen Port

kopiert wird.

Um die Sicherheit des Netzwerkes nicht zu unterwandern, mussten Möglichkeiten für

das Absichern des IDS gefunden werden. Die erste Möglichkeit war das Einrichten

eines Paketfilters bei den unter Linux getesteten IDS. Diese Einstellungen waren sehr

restriktiv, so dass die Präsenz eines IDS von außen nicht festgestellt werden konnte.

Später wurde die Installation des IDS im Stealth-Modus vorgenommen, bei dem die

Netzwerkkarte keine IP-Adresse erhält und somit nicht direkt angesprochen werden

kann. Unter Windows waren diese Sicherheitsmaßnahmen nicht durchführbar, so dass

nur das Abschalten von gefährlichen Diensten möglich war, um das Angreifen des

Systems zu erschweren.

Das bisher schwerste und nicht einfach zu lösende Problem besteht beim Einsatz des

IDS in der DMZ. Wird eine Verbindungsanfrage aus dem Internet an einen Web-

Server in der DMZ gestellt, so nimmt die Firewall die Anfrage an und stellt selbst

diese Anfrage über einen internen Proxy-Server an den Web-Server. Der Webserver

antwortet der Firewall und diese übermittelt dann die empfangenen Daten an den

Rechner im Internet. Für den Web-Server sieht es so aus, als ob alle

Verbindungsanfragen von der internen Netzwerkkarte der Firewall kommen. Wird das

IDS in der DMZ betrieben, so enthalten alle bestehenden Verbindungen und

Verbindungsanfragen IP-Adressen aus dem privaten IP-Adressraum der DMZ, die

nach außen nicht sichtbar sind (siehe Abbildung 16 - Firewall mit Proxies).



Web-Server192.168.0.80

FTP-Server192.168.0.21

Mail-Server192.168.0.25

HTTP FTP SMTP

HTTP-Proxy FTP-Proxy SMTP-Proxy19

2.16

8.0.

80 <- 19

2.16

8.0.

1

192.

168.

0.21

<- 19

2.16

8.0.

1

192.

168.

0.25

<- 19

2.16

8.0.

1

192.

100.

100.

1:80

<-

Inte

rnet

192.100.100.1:21 <

- Internet

192.

100.

100.

1:25

<- In

tern

et

Internet

Firewall mit ProxysExterne IP: 192.100.100.1Interne IP: 192.168.0.1

Abbildung 16 - Firewall mit Proxies

Wird nun ein möglicher Angriff erkannt, so kann die Herkunft nicht bestimmt werden,

da die interne IP-Adresse der Firewall verwendet wurde. Der mögliche Angriff kann

somit nicht nachverfolgt werden, es kann nur festgestellt werden, dass ein versuchter

Angriff erfolgt ist. Abhilfe dieses Problems bietet das Einstellen der Proxy-Agenten

auf ein transparentes Proxying, wobei die IP-Adresse, mit denen die Anfrage gestellt

wurde nicht durch die IP-Adresse der Firewall ersetzt wird, sondern weitergeleitet



wird. Eine weitere Möglichkeit ist der Einsatz eines weiteren IDS vor der Firewall.

Durch eine Kopplung der beiden IDS können mögliche Angriffsversuche verglichen

und die IP-Adresse des Angreifers herausgefiltert werden. Dies kann durch einfaches

Vergleichen der geloggten Daten beider IDS geschehen.

Vergleich und Einführung von IDS 7. Einführung von Intrusion Detection Systemen


7. Einführung von Intrusion Detection Systemen

Aufgrund der aktuellen wirtschaftlichen Lage der KirchMedia GmbH & Co. KGaA

und wegen des besten Preis-Leistungsverhältnisses wurde als Einsatz-IDS Snort in

Verbindung mit ACID vereinbart.

Um einen gewissen Sicherheitsstandard beizubehalten und keinen weiteren

Angriffspunkt zu liefern, erfolgt die Konfiguration im Stealth-Modus, also ohne IP-

Adresse. Die Administration und Überwachung des Systems geschieht lokal, so dass

keine weiteren Netzwerkverbindungen notwendig sind. Die MySQL-Datenbank, in

der alle Alarmmeldungen abgelegt werden läuft lokal, wodurch auch nur ein lokaler

Zugriff möglich ist. Die Darstellung der Alarme über ACID erfolgt auch lokal über

einen Apache-Web-Server.

Als Einsatzgebiete wurden die Positionen vor der Firewall sowie in der DMZ

untersucht. Wie schon in Kapitel 3.1 Einsatzgebiete von IDS besprochen, gibt es zu

jeder Umgebung Vor- und Nachteile, wobei vorerst der Einsatz in der DMZ festgelegt

wurde. Innerhalb kürzester Zeit kann durch Umpatchen der Netzwerkverbindungen

das IDS vor die Firewall positioniert werden. Das Verändern der Proxies auf ein

transparentes Proxying ist aus Sicherheitsgründen nicht möglich, Angriffe können also

vorerst nur erkannt aber nicht externen IP-Adressen zugeordnet werden können.

Abbildung 17 - Standalone-NIDS in der DMZ zeigt die aktuelle Einsatzumgebung, in

der das IDS positioniert wurde.

Um eine bessere Überwachung zu gewährleisten und um die Angriffe externen IP-

Adressen zuordnen zu können, kann ein weiteres NIDS vor der Firewall positioniert

werden. Dieses NIDS kann dann über eine zweite Netzwerkkarte die Daten über eine

Datenbankverbindung an das NIDS in der DMZ liefern, was zu einem Single Point of

Administration führen würde. Über manuelle Abgleiche könnten dann Angriffe

verfolgt und klassifiziert werden (siehe Abbildung 18 - Zwei NID-Systeme im

Verbund). Durch die Konfiguration beider NIDS im Stealth-Modus wäre auch kein

Bypass (das Umgehen) der Firewall möglich.



Internet

Firewall

WEB-Server

FTP-Server

Computer

Computer

DMZ

Firmen-Netz

Switch

Switch

Netzwerk IDSSnort

Switch

Netzwerkverbindungen

Verbindung mit dem Sniffer-Interface des IDS

Abbildung 17 - Standalone-NIDS in der DMZ



Internet

Firewall

Netzwerk IDSSnort 1

WEB-Server

FTP-Server

Computer

Computer

DMZ

Firmen-Netz

Switch

Switch

Netzwerk IDSSnort 2

Switch

Netzwerkverbindungen

Datenverbindung zwischen den beiden IDS

Verbindung mit dem Sniffer-Interface des IDS

Abbildung 18 - Zwei NID-Systeme im Verbund

Vergleich und Einführung von IDS 8. Quellen


8. Quellen

IDS Group Test Report (Edition 2, Dez. 2001, Edition 3, Juli 2003) The NSS-Group [http://www.nss.co.uk/ids/index.htm]

Intrusion Detection: Tripwire für Linux

c’t magazin für computer technik, Ausgabe 11 vom 21.5.2002

NT-Registry Monitor beim Starten des Internet Explorers 3.0 http://www.inigraphics.net/ini-sc/mswin/awfnttip/kap5.htm

FAQ: Network Intrusion Detection Systems

http://www.robertgraham.com/pubs/network-intrusion-detection.html

Firewall kontra Intrusion-Detection

http://www.bluemerlin-security.de/Berichtfirewallids.php3

Network Monitoring for Intrusion Detection http://online.securityfocus.com/infocus/1220

BSI-Studie: Intrusion Detection Systeme

http://www.bsi.bund.de/literat/studien/ids/doc0000.htm

eTrust - Computer Associates http://www3.ca.com/Solutions/Solution.asp?ID=271

Real Secure - Internet Security Systems

http://www.iss.net/products_services/enterprise_protection/rsnetwork/index.php

Network Intrusion Detection – Network Flight Recorder

http://www.nfr.com/products/NID/

Tripwire http://sourceforge.net/projects/tripwire/

Snort - The Open Source Network Intrusion Detection System

http://www.snort.org/

Snort-User Mailing List http://sourceforge.net/mailarchive/forum.php?forum=snort-users

CISCO - The Science of Intrusion Detection System Attack Identification

http://www.cisco.com/warp/public/cc/pd/sqsw/sqidsz/prodlit/idssa_wp.htm

TOOLS - INTRUSION DETECTION SYSTEM (IDS) TESTING http://www.ideahamster.org/tools/ids.shtml

BLADE-Software - IDS Informer™ 3.1

http://www.blade-software.com/ids%20informer.htm

Vergleich und Einführung von IDS 8. Quellen


Packetstorm Security

http://packetstormsecurity.nl/

Intersect Alliance http://www.intersectalliance.com/projects/index.html

Security Focus Online

http://online.securityfocus.com/

Common Vulnerabilities and Exposures (CVE)

http://cve.mitre.org/

Attrition.org Security - Denial of Service Database http://www.attrition.org/security/denial/

System Fingerprinting

http://www.spirit.com/Network/net0900.html

New Order - the resource for people to help avoid being hacked, security and

exploiting related files and links

http://neworder.box.sk/

CERT® Coordination Center

http://www.cert.org

WHITEHATS Security http://www.whitehats.com/

Vergleich und Einführung von IDS Anhang A – IDS Vergleichslisten


Anhang A – IDS Vergleichslisten

Snort

Name des IDS Snort The Open Source Network Intrusion Detection System

Hersteller Open Source Project

Preis ca. - kostenlos -

Art des IDS

Betriebssystem Linux, UNIX, MacOS X-Server, Win32

Plattformverfügbarkeit

Bewertungsversion Version 1.8.5 - Source Code

Bewertung Agent auf Mandrake-Linux 8.1 - i586

Installation

Installationsmedium Komprimiertes TAR-Archiv (Quellcode)

Verlauf Installation der benötigten LIBS, Kompilierung von Snort problemlos, manuelles

Anlegen von Verzeichnissen, Kopieren von Konfigurationsfiles

Einbinden von Datenbank und Windows-Messaging möglich

Konfiguration

Allgemeines Konfigurationsfiles gut kommentiert

Anpassung Änderungen aufgrund der Komplexität evtl. zeitaufwendig

Skalierbarkeit gut skalierbar, viele verschiedene Optionen, Erweiterung durch Plug-Ins

Signaturen

Mitgelieferte Sign. ca. 25 verschiedene Signaturen mit insgesamt ca. 3200 versch. Regeln

Veränderung d. Sign. einfacher Aufbau der Regeln, die verändert und erweitert werden können

Update d. Sign. mittels eigenem Shell-Skript. Änderungen müssen wieder neu gemacht werden

Übersichtlichkeit sehr unübersichtlich, wobei die Log-Files mit Zeitaufwand gelesen

werden können



Erkennung von Intrusions

zeitl. Verzögerung keine, Real-Time Detection, evtl.Ausgabe des Verkehrs auf dem Bildschirm

Darstellung Eintrag in das alert-Logfile, keine sonstige Darstellung oder Alarmierung

Alarmierung durch zusätzl. Programme mittels e-Mail oder Windows-Pop-up-Meldungen

Log-Files

Art der Speicherung Alarmmeldungen, Portscans und Alarmpakete werden jeweils extra gespeichert

Details in Log-Files Angabe von srcip, destip, Angriff, Port, URL zu genaueren Details des Angriffs

Archivierung keine; Manuell über selbst geschriebene Shell-Skripte und Cron-Tab

Übersichtlichkeit sehr unübersichtlich, wobei die Log-Files mit Zeitaufwand gelesen

werden können

Sonstiges

Prozessorlast im Daemon-Mode 10-80%, Durchschn. ca. 30% beim Einsatz vor der Firewall

Priorisierung d. Intrus. 3 Priorisierungsstufen

Gesamteindruck eher etwas für Bastler und Linux-User, die etwas Shell programmieren können

Bemerkungen Nach der Installation (mit Libraries) mussten die vielen Optionen

eingestellt werden um Snort nach eigenen Vorstellungen laufen zu lassen.

Ebenso mussten im Config- File die Rules auskommentiert werden, die nicht

genutzt werden sollten. Nach einigen überflüssigen Meldungen

mussten die Rule-Files überprüft und z.T. auskommentiert werden

Installation

Bemerkungen keine Managementkonsole vorhanden

Fazit Die Log-Files können mittels SnortSnarf, einem Log-Aufbereitungstool,

in HTML- Seiten konvertiert werden, was zur grafischen Darstellung

der Ereignisse dient. Mit Swatch lassen sich die Alarmmeldungen per

e-Mail versenden. Dabei wird einfach das Log-File überwacht und bei einer

Änderung eine e-Mail geschrieben

Negativ:

kein Support, nur News-Groups Skripte für Backup oder Aktualisierung der Regeln müssen selber geschrieben bzw. aus dem

Internet runtergeladen werden Automatischer Start von Snort muss durch selbst geschriebene Skripte eingerichtet werden.

Neu downgeloadete Rules müssen wieder durchgegangen werden, weil die gemachten Änderungen verloren gehen

Portscan-Kriterien können nicht genauer definiert werden

Datenanbindung loggt die Portscans bei ACID nicht in die Datenbank



Positiv:

Insgesamt übersichtlich Regeln werden nach Angriffspunkt klassifiziert und unterteilt, z.B. Web-IIS (Microsoft Internet Information Server)

Komprimierte Abspeicherung des Datentransfers

Komprimiertes Datenformat kann auch von anderen Programmen gelesen werden, da tcpdump-Format

Unterstützung bei der Benachrichtigung eines Alarms mittels SNMP-Trap, Mail oder Windows-Pop-Up-Message

Datenbankanbindung (z.B. MySQL) zur besseren Auswertung

ACID und Demarc-Personal-Edition sind frei verfügbar und somit gibt es viele Leute, die sich damit auskennen.

Anzahl der Alarme gering Anzahl der Fehlalarme akzeptabel



CA - eTust

Name des IDS eTrust

Hersteller Computer Associated

Preis ca. ab 3.300 US$

Art des IDS

Betriebssystem Windows NT / 2000 / XP


Bewertungsversion Build 1.5.0.73 - DEMO

Bewertung als Standalone IDS

Installation

Installationsmedium Internet Download Trial Version als komprimierte EXE

Verlauf InstallShield Installation ohne Probleme

Konfiguration

Allgemeines Standardkonfiguration protokolliert gesamten Netzwerkverkehr

Anpassung sehr hohes Anpassungspotential

Skalierbarkeit alle Regeln müssen individuell geändert werden, keine

Hauptskalierung möglich

Übersichtlichkeit Gewöhnungsbedürftig, da es viele Optionen und Unteroptionen gibt

Signaturen

Mitgelieferte Sign. Viele Signaturen, die alles protokollieren können und

viele Fehlalarme produzieren

Veränderung d. Sign. Einfach, nachdem man sich eingearbeitet hat

Update d. Sign. Einfach, über Internet bzw. Update-Agent. Vollautomatisch

Übersichtlichkeit Sehr übersichtlich, vordefinierte Regeln gut verständlich




zeitl. Verzögerung je nach Prozessorauslastung und Netzwerkverkehr bis zu mehreren Minuten

Darstellung z.T. Individuell anpassbar, z.T. unnötige Infos (nach Client, Server), z.T.

nur TCP/IP

Alarmierung z.T. Individuell Anpassbar, Unterscheidung nach Alarm

und Sicherheitsverletzung

Log-Files

Art der Speicherung mehrere Workspaces, die gewechselt werden können

Details in Log-Files alle, die protokolliert wurden

Archivierung Unkomprimiert in Datenbank-ähnlichem Format

Übersichtlichkeit sehr gut, da es einen View -Modus gibt, der die Workspaces darstellt

Sonstiges

Alarmierung normalerweise nicht auffallend, oft mit Sound

Prozessorlast z.T. sehr hoch, mit Warnmeldung über Auslastung des Systems

Priorisierung d. Intrus. keine Priorisierung, auch nicht möglich

Gesamteindruck befriedigend, ideal für Windows-User mit wenig Einarbeitungszeit

Bemerkungen zu viele Abstürze, Verzögerung der Alarme, zu hohe Auslastung, zu viele

falsche Alarme, Auswertung und Zwischenspeicherung des gesamten

Netzwerkverkehrs, aus diesen Gründen eher ideal als Content Security

System mit IDS-Zusätzen

Fazit

Bemerkungen

Resultat eTrust ist für den permanenten und täglichen Einsatz weniger geeignet, da

es zu viele Abstürze gibt. Die Auslastung ist ebenfalls zu hoch, so dass ein

Ausfall nur eine Frage der Zeit ist. Das Loggen benötigt zu viel Festplattenplatz

und somit wird irgendwann der Platz ausgehen, was auch

zu einem Absturz führen wird (hypoth.).

Allgemeines:

e-Mail-Benachrichtigung an alle geloggten e-Mail-Sender und Empfänger möglich

Verschiedene Workspaces mit individuellen Rules und Konfigurationen

Automatisches Löschen von Log-Files nach einer gewissen Anzahl von Tagen

Anzeige der Statistiken nach Server, Workstations oder Netzwerkdienste

Automatisches Erkennen von CA-Produkten und eTrust ID-Agenten bzw. Programmen im Netzwerk

Zu Alarmmeldungen können Kurzinformationen angezeigt werden

Vordefinierte Sicherheitsbestimmungen werden bei Verletzung angezeigt und es kann direkt gehandelt werden

Integrierte Intrusion Response-Möglichkeiten individuell definierbar

Es gibt vordefinierte Regeln, um einen versuchten Einbruch festzustellen



Content-Inspektionsregeln um Netzwerkverkehr nach gefährlichen Inhalten zu untersuchen

Erkennung von "merkwürdigen Netzwerk-Aktivitäten", z.B. Port Scans oder Root-Logins

URL-Monitor, der Zugriffe auf nicht arbeitsrelevante Webseiten loggt und evtl. verbietet

Generierung von Reports über fast alle Ereignisse, Server, Workstations, Protokolle

Generierung der Reports automatisch oder "von Hand". Reports meist als Diagramme generiert

Automatisches Update von Virendatenbank, URL-Kontrollisten und IDS-Regeln möglich

Virenerkennung im IDS Für jeden Benutzer des IDS können eigene Regeln erstellt werden, was er darf und nicht darf.

Negativ: Statistic Based Rules können nicht geloggt werden.

Für die unterschiedlichen Rules können nicht alle verschiedenen Aktivitäten ausgewählt werden

Verwirrend sind die verschiedenen Workspaces, bzw. Speichern und Umschalten

Absturz ohne Fehlermeldung beim Anklicken eines Log-Eintrags unter Rules.

Automatischer Neustart des Programms nach Absturz nach ca. 15 Sekunden. Programm traced nicht

weiter, sondern bleibt im pause-status Bei Suspicious Activity Detection Rules können keine eigenen Regeln definiert werden

Standardalarmierung mit Sound schlecht, da ein IDS normalerweise keinen Sound benötigt

Häufige Abstürze, bzw. Programm bleibt hängen und muss abgeschossen werden

Hoher Festplattenplatz wird für die Workspaces benötigt

Hohe Prozessorauslastung

Unklare Alarmmeldungen bzw. schlechte und nicht aussagekräftige Definitionen

Zu viele Alarme/Fehlalarme, auch bei Einschränkung der Signaturen / Regeln

Bei der Deinstallation bleiben laufende und lauffähige Dienste übrig, die nicht deinstalliert werden können, z.B.

Registrierungsassistent Positiv:

Trotz Absturz des Programms sind die Daten noch vorhanden

Warnmeldung, dass das Programm die anfallenden Daten nicht mehr verarbeiten kann

Erstellung eigener Rules einfach und intuitiv

FTP- und HTTP-Transfers können individuell angeschaut werden

e-Mails können mitgelesen werden

Viele Möglichkeiten zum Benachrichtigen des Administrator

Kuchendiagramm über die Anteile der Dienste am Netzwerkverkehr schön

Monitor/Block/Alert Rules, Dienste wie HTTP, FTP oder IMAP werden hauptsächlich geloggt

Viele verschiedene Aktionen in Kombination miteinander möglich: z.B. Log, Block, Define Blocking Rules,

Alert Message, Windows NT Event Log, Run, Email, Fax, Sound, Append to File, SNMP-Trap, Pager, Export

Log File, OPSEC, User Defined, Archive Log File, Export to Telemate, Notify by Syslog, Export to Web

Trends, CISCO Router Configuration, NT Message, eTrust Audit Message, Unicenter Message, eTrust Firewall Rule

Auflistung der einzelnen Dienste, als Unterpunkte die geloggten Ereignisse

Auflistung nach Dienste, Clients, Servern oder Regeln möglich

Intrusion Attempt Detection Rules: Angabe von Client, Server, Typ (z.B. Telnet mit gewissen Signaturen), Aktion und

zeitlicher Abgrenzung, wann die Regel aktiv ist

View -Modus um eine Workspace zu Betrachten.

Content Inspection Rules: Angabe von Client, Server, Typ (HTML, News oder FTP-Data), Aktion und zeitl.

Abgrenzung

Verwaltung und Erstellung von Regeln hat gleiche Oberfläche wie Checkpoint Firewall



Suspicious Network Activity Detection Rules: packetbasiert oder statistikbasiert: Hier können die

vordefinierten Angriffe nur ein bzw. ausgeschaltet und die Aktionen verändert werden. Die Statistic Based

Rules können nicht geloggt werden

IDS läuft auch im Background-Modus. Administrator muss nicht im IDS angemeldet sein

Bei zu hoher Auslastung werden die Daten zwischengespeichert, so dass diese nach dem Pausieren des Systems

noch zu Ende überprüft werden können

Automatischer Neustart nach ein paar Minuten



Tripwire

Name des IDS Tripwire

Hersteller Tripwire Inc.

Preis ca. - kostenlos - bzw. $6,995

Art des IDS

Betriebssystem Linux / UNIX


Bewertungsversion Tripwire 2.3.1-2 non-commercial

Bewertung HIDS

Installation

Installationsmedium Tarball Source-Code

Verlauf Standardinstallation für Linux vorkonfiguriert

Konfiguration

Allgemeines Vorkonfigurierte Policys können über das Internet für verschiedene

Betriebssysteme erstellt werden

Anpassung Sehr gut, aber sehr aufwendig

Skalierbarkeit Sehr gut, da es viele Optionen gibt

Übersichtlichkeit Gut, alle Konfig-Files befinden sich in einem Verzeichnis

Signaturen

Mitgelieferte Sign. Standardmäßig für verschiedene Linux - und UNIX-Distributionen

Veränderung d. Sign. Notwendig und umständlich bei manueller Veränderung

Update d. Sign. unnötig, nur bei Neuinstallation von Programmen

Übersichtlichkeit Unübersichtlich aufgrund der sehr langen Listen, einzelne

Einträge sind übersichtlich




zeitl. Verzögerung Sehr groß, da Abgleich durch cron-jobs zeitlich gesteuert

Darstellung Über e-Mailnachrichten, Aufbau wie Log-Files

Alarmierung Keine Alarmierung ausser durch generierte e-Mails nach jedem cron-job

Log-Files

Art der Speicherung keine Log-Files - Ablegen der Standardkonfiguration in einer

verschlüsselten DB

Details in Log-Files -----

Archivierung keine Archivierung, Datenbank wird bei einem Update neu erstellt

Übersichtlichkeit nur Konfigurationsfile ist lesbar.

Sonstiges

Alarmierung keine weiteren Möglichkeiten der Alarmierung ausser durch e-Mail

Prozessorlast gering bzw. mittel, wenn Abgleich/Überprüfung gestartet wird

Priorisierung d. Intrus. Einteilung in unterschiedlich schwerwiegende Verletzungen

Gesamteindruck gut, aber großer Konfigurationsaufwand bei der Erstinstallation

Bemerkungen gutes File Integrity Assessment-IDS mit vielen möglichen Optionen

für verschiedene Dateien. Eigene Optionen können generiert werden.

Standardkonfigurationen für Linux / UNIX-Distributionen können aus

dem Internet heruntergeladen werden

Installation

normales Entpacken des Archivs

Kompilierung und Installation nach Angabe der OS-Plattform mittels Makefile

Erstellung von Schlüssel für die Verschlüsselung der Konfigurationsdateien und der Datenbank

Positiv:

Es können eigene Regeln aus den Einzelregeln erstellt werden

Unterstützung von 18 verschiedenen Dateiattributen

Viele schon vordefinierte Variablen

Einteilung in 1000000 verschieden schwerwiegende Sicherheitsverletzungen

Sehr sicher durch verschiedene Verschlüsselungen

Abgleich der Datenbank nach Änderung möglich, ohne die ganze Datenbank neu erstellen zu müssen.

Neue Dateien werden automatisch in die Liste der zu überprüfenden oder zu ignorierenden Dateien aufgenommen



Negativ:

selbst angepasste Regelsätze passen nicht zu einer angepassten Installation einer Distribution

generierte Reports z.T. sehr unübersichtlich

keine Echtzeiterkennung von Angriffen

Alarmierung nur über e-Mail möglich

Problem: sehr viele Sicherheitsverletzungen bei einem Systembackup



ISS Real Secure

Name des IDS Real Secure Network Sensor & Workgroup Manager

Hersteller ISS

Preis ca. Network Sensor: $8,995* per sensor, Host Sensor: $8,995* per sensor

Art des IDS

Betriebssystem Windows NT SP6 / 2000 SP1, Solaris (SPARC), RedHat-Linux, HP-UX 11,

AIX 4.3


Bewertungsversion jeweils Version 6.5, Update auf Version 7.0 wieder deinstalliert

Bewertung Network Sensor mit Workgroup Manager

Installation



Konfiguration

Allgemeines Standardkonfiguration protokolliert gesamten Netzwerkverkehr

Anpassung hohe Anpassungsfähigkeit

Skalierbarkeit durch schon vorgegebene, nicht änderbare Standard-Policies, von der neue,

veränderbare Policies abgeleitet werden können

Übersichtlichkeit sehr übersichtlich durch Baumstrukturen

Signaturen

Mitgelieferte Sign. Viele Signaturen, von denen eigene Rulesets abgeleitet werden müssen

Veränderung d. Sign. Einfach, aber z.T. eingeschränkt

Update d. Sign. Über Updates des Sensors

Übersichtlichkeit Sehr übersichtlich durch Baumstruktur




zeitl. Verzögerung keine zeitl. Verzögerung -> RealTime-Detection

Darstellung Standarddarstellung nach Prioritäten, keine Hex-Dumps

Alarmierung Individuell anpassbar, Unterscheidung nach Alarm und Sicherheitsverletzung

Log-Files

Art der Speicherung alle Alarme werden in einer MS-SQL-Datenbank abgelegt

Details in Log-Files Unbekannt, da die Datenbank nicht nach einem Event durchsucht

werden kann

dazu werden Programme anderer Hersteller benötigt

Archivierung entspricht Archivierung der MS-SQL-Datenbank

Übersichtlichkeit einzelne oder mehrere gleiche Events werden genau dargestellt

Sonstiges

Alarmierung nach Priorität durch den Namen der Signatur

Prozessorlast gering, ohne Problem der maximalen Auslastung

Priorisierung d. Intrus. 3 verschiedene Priorisierungen: niedrig, mittel und hoch

Gesamteindruck sehr gut, da keine Abstürze und Real-Time-IDS

Bemerkungen Es fehlt die Darstellung der Hex-Dumps zur genaueren Überprüfung des

Netzwerkverkehrs. Einige Fehlalarme, System erkennt standardmäßig keine

Portscans, die mehrere Hosts im gleichen Subnetz betreffen.

Installation:

RealSecureNetworkSensor 6.5 - Installshield Installation ohne Probleme

Erstellung eines Public-Private-Keys für Administration, wenn erforderlich und gewünscht

Unterstützung von verschiedenen Key -Distributoren

Hardening des Netzwerk-Sensors (Optional abschaltbar)

RealSecureUtilities 6.5 - Installshield Installation ohne Probleme

Zum Abgleich, Verteilung und Kopieren von Schlüsseln

RealSecureWorkgroupManager 6.5 - Installshield Installation abgebrochen, da MSDE benötigt wird,

fortsetzung problemlos Warnmeldung, dass Netzwerk-Sensor und Management-Konsole nicht auf dem gleichen Host installiert werden

sollte

MSDE-2000 (Microsoft SQL Server Desktop Engine) wird benötigt

Hardening des Workgroup-Managers

Viele Sicherheitseinstellungen, Verschlüsselungen, Verbot von "leeren" Passwörtern, Automatisches Anlegen von

Usern, Installieren von Diensten



Automatische Installation von Microsoft SQL-Server auf der Management-Station

Workgroup-Manager besteht aus: Console-Services, Event Collector Services, Asset Database und Enterprise

Database

Die Reportgenerierung auf Basis der MSDE (Microsoft Database-Desktop Engine) schlug immer fehl, mit der Fehler-

meldung, dass eine DLL einen Fehler verursacht hat. Auch ein Update der DLLs hat nichts gebracht

Konfiguration: Installation und Konfiguration sollten mit den Installations-HowTos durchgeführt werden um einen besseren

Überblick zu erhalten, welche Optionen benötigt werden und wie der Deployment-Wizard funktioniert, da nicht alles

intuitiv ist und evtl. nachgelesen werden muss

Aufgrund der Installation aller Komponenten auf einem PC kam es zu Problemen mit der Verschlüsselung zwischen

der Managementkonsole und den Sensoren. Diese Verbindung wird normalerweise mit generierten Key-Files

nach der Public / Private-Methode verschlüsselt

Der Serversensor muss, bei Installation auf dem gleichen PC wie ein Netzwerksensor ohne Netzwerkunterstützung

installiert werden. Ebenfalls sollte keine Verschlüsselung zwischen den Verbindungen bestehen, da sonst der

Prozessor zusätzliche Rechenzeit für die Ver- und Entschlüsselung verbraucht.

Name des IDS Real Secure Network Sensor & Workgroup Manager

Hersteller ISS

Preis ca. $8,995* per Sensor

Art des IDS

Betriebssystem Windows NT SP6 / 2000 SP1, Solaris (SPARC), RedHat-Linux, HP-UX 11,

AIX 4.3

Plattformverfügbark

eit

Bewertungsversion jeweils Version 6.5, Update auf Version 7.0 wieder deinstalliert

Bewertung Server Sensor mit Workgroup Manager

Installation





Konfiguration

Allgemeines Standardkonfiguration protokolliert nur wenige Veränderungen

Anpassung hohe Anpassungsfähigkeit

Skalierbarkeit durch schon vorgegebene, nicht änderbare Standard-Policies, von der neue,

veränderbare Policies abgeleitet werden können

Übersichtlichkeit sehr übersichtlich durch Baumstrukturen

Signaturen

Mitgelieferte Sign. Viele Signaturen, von denen eigene Rulesets abgeleitet werden müssen

Veränderung d. Sign. Einfach, aber z.T. eingeschränkt

Update d. Sign. Über Updates des Sensors

Übersichtlichkeit Sehr übersichtlich durch Baumstruktur und Oberbegriffe


zeitl. Verzögerung keine Real-Time-Erkennung, dadurch zeitl. Verzögerung von ein paar

Sekunden

Darstellung Standarddarstellung nach Prioritäten, keine Hex-Dumps

Alarmierung Individuell anpassbar, Unterscheidung nach Alarm und Sicherheitsverletzung

Log-Files

Art der Speicherung alle Alarme werden in einer MS-SQL-Datenbank abgelegt

Details in Log-Files Unbekannt, da die Datenbank nicht nach einem Event durchsucht werden kann

dazu werden Programme anderer Hersteller benötigt

Archivierung entspricht Archivierung der MS-SQL-Datenbank

Übersichtlichkeit einzelne oder mehrere gleiche Events werden genau dargestellt

Sonstiges

Alarmierung nach Priorität durch den Namen der Signatur

Prozessorlast gering, ohne Problem der maximalen Auslastung

Priorisierung d. Intrus. 3 verschiedene Priorisierungen: niedrig, mittel und hoch

Gesamteindruck gut, da keine Abstürze. Keine Real-Time-Alarmierung

Bemerkungen Angriffe auf HIDS sind kaum erfolgt. Es wurden nur Login-Versuche und

Registry-Änderungen als Alarme angezeigt. Andere Alarme wurden lokal nicht

provoziert.



Negativ: Nach Update durch die integrierte Updatemöglichkeit wurden die Sensoren nur noch z.T. erkannt und beendeten

sich von selbst. Nach Neuinstallation von ISS-RealSecure wurden keine Sensoren und Event-Collektoren

mehr gefunden.

Aus diesem Grund musste Win2K neu installiert werden.

Nach jedem Neustart werden die vorhandenen Alarme komplett gelöscht und sind nur noch in der Datenbank

zur Auswertung vorhanden

Genauere Analysen des Angriffs sind nicht möglich, da keine Hex-Dumps standardmäßig vorhanden sind. Diese

können zwar eingestellt werden, aber es fehlen die Programme um diese Dumps anzuschauen. Diese können

von einer anderen Firma erworben werden.

Auf der Management-Konsole muss ein Microsoft SQL-Server installiert werden. Dies setzt ein Windows-Rechner

als Management-Konsole voraus. Microsoft SQL-Server auf der Management-Konsole stellt ein Angriffspunkt dar.

Genaue Aktions- und Maßnahmendefinition für einzelne Regeln sehr umständlich

Viele Fehlalarme, besonders bei HTTP-Anfragen durch Alarm-Strings in der URL

Hardening des Betriebssystems nur minimal - gefährliche Dienste wie der Windows-Server-Dienst werden nicht

abgeschalten und es wird auch nicht darauf hingewiesen.

Gezielte Angriffe auf das Netzwerk werden nur dann genau bemerkt, wenn das IDS ebenfalls angegriffen wird.

UDP-Scans werden standardmäßig mit hoher Priorität und TCP-Portscans mit mittlerer Priorität alarmiert.

Signaturen können normalerwiese nicht verändert werden

Positiv: Bei den einzelnen Regeln können so genannte Wiederholungsraten eingestellt werden, wenn z.B. innerhalb von 5

Min. mehrmals die gleiche Regel zutreffen würde, wird der Alarm nur einmal dargestellt, bis der Timer abgelaufen ist.

Unterteilung in hohe, mittlere und niedrige Prioritäten

Das IDS stellt virtuelle Dienste zur Verfügung um Angreifer besser erkennen und abschrecken zu können

Auflistung aller verschiedenen Events, die während der laufenden Zeit der Konsole aufgetreten sind

Anzeige der Events als Baumstruktur.

Anzeige der Alarme nach Quellen, Zielen und Events

Aufspaltung der einzelnen Komponenten nach Sensor, Management-Konsole und Event-Kollektor

Ein Sensor kann seine Alarme an mehrere Event-Kollektoren weiterleiten.

Die Management-Konsole kann mehrere Sensoren und Event-Kollektoren abrufen

Es können für manche Signaturen gewisse Ausnahmen definiert werden.

Gute Dokumentation zu Installation der einzelnen Komponenten

Ausführliche Beschreibung jedes einzelnen Alarms mit Angabe von Fehlalarm-Möglichkeiten (False-Positives)

Geringe Netzlast, da die IP-Adressen nicht in DNS-Namen umgewandelt werden

Bei Bedarf können die IP-Adressen eines Alarms mit einem Mausklick in DNS-Namen aufgelöst werden.

Aufgrund der geringen Netzlast müssen keine Netzwerkstreams zwischengespeichert werden, was ein Real-Time-

Alerting zur Folge hat



NFR – Network Intrusion Detection

Name des IDS NFR - Network Intrusion Detection

Hersteller Network Flight Recorder

Preis ca. $12,500

Art des IDS

Betriebssystem Proprietär / OpenBSD


Bewertungsversion NID - 100 Version 5.2

Bewertung NIDS

Installation

Installationsmedium Eval-CD

Verlauf Ohne Probleme, System bleibt auf der CD, Daten werden auf die HDD

geschrieben

Konfiguration

Allgemeines nur durch Administration-Interface (AI) von einem anderen Rechner aus

möglich

Anpassung geringe Anpassungsfähigkeit über die AI

Skalierbarkeit nur eine Policy, die verändert werden kann

Übersichtlichkeit Nicht ganz übersichtlich, trotz Baumstruktur

Signaturen

Mitgelieferte Sign. Viele Signaturen, die in Gruppen eingeteilt sind

Veränderung d. Sign. nicht möglich, nur das Logging kann verändert bzw. ausgeschaltet werden

Update d. Sign. durch neue CD - Signaturen sind auf CD abgelegt

Übersichtlichkeit trotz geringer Anpassungsfähigkeit nicht besonders übersichtlich




zeitl. Verzögerung auf dem IDS - keine, auf dem AI Verzögerung bis zur nächsten

Aktualisierung

Darstellung als nicht gelesener Alarm in einer Liste oder als Eintrag im Pop-up Fenster

Alarmierung Pop-up Fenster und Piep-Ton (wenn Soundkarte vorhanden)

Log-Files

Art der Speicherung auf der Ferstplatte

Details in Log-Files gering, nur Source-Adresse, Destination-Adresse und Art des A larms

Archivierung keine Archivierung möglich

Übersichtlichkeit unbekannt

Sonstiges

Alarmierung durch POP-Ups auf der AI, SNMP Traps und e-Mails

Prozessorlast mittel, dafür ist die Hauptspeicherauslastung sehr hoch bei 128 MB RAM

Priorisierung d.

Intrus. mittelmäßig, nach Listen, die selbst angelegt werden können

Gesamteindruck schlecht, veraltetes Aussehen und nicht mehr Stand der Technik

Bemerkungen

Installation:

NIDS - Neuinstallation erfordert komplette Repartitionierung, da ein proprietäres OS mitgeliefert wird (auf OpenBSD

basierend) Installation eines Central Management Servers möglich (2. System wird benötigt).

Verfügbare Plattformen für den Central Management Server: Linux und Solaris

Mindestens 2 eigenständige Systeme notwendig: 1 NIDS mit proprietärem und verädertem OpenBSD, sowie ein

Windows System (NT oder 2000) auf dem das Administration-Interface installiert wird. Evtl. wird ein 3. System

(Linux oder Solaris) als Central Management Server benötigt, falls mehrere NID-Systeme installiert werden.

Im NID-System werden 2 Netzwerkkarten benötigt: 1 für das "outbound" Management und 1 als Sniffing-Interface

Im Lieferumfang besteht aus 3 CDs, wobei 1 CD für das NIDS, 1 CD für das HIDS und 1 CD für den Central

Management Server vorgesehen sind.

Das HIDS ist nur für Windows verfügbar.

Das Administration-Interface ist nur für Windows (NT oder 2000) verfügbar und muss manuell heruntergeladen

werden

Es wurde keine Dokumentation mitgeliefert und es wurden keine Internet-Adressen angegeben, auf denen

Installationshilfen angeboten wurden. Durch Zufall wurde mit Hilfe einer Suchmaschine ein PDF-Dokument

"Getting started" gefunden

Ebenfalls wurde mit einer Suchmaschine der Link zum Download des Administration-Interface gefunden.

Installation des Administrations-Interface mittels Install-Shield installation Problemlos unter Windows 2000

Installation des NIDS durch die Bootfähige CD ohne Probleme - das System befindet sich auf der CD, nur die Daten

werden auf der Festplatte abgelegt.



Positiv: Hohes Sicherheitspotential OS auf CD, die schreibgeschützt ist Konfiguration wird auf Diskette abgelegt, die schreibgeschützt werden kann

Selbständiger Reboot und Neustart nach Absturz

Echtzeiterkennung der Alarme auf dem NIDS

Genaue Anzeige über CPU-Auslastung, RAM, HDD, sowie Packets Received und Packets Dropped

2 verschiedene Darstellungsarten der Alarme

Darstellung nach gelesenen / ungelesenen Nachrichten

Pop-up Fenster bei wichtigen Alarmen

Eigener Programmiercode: N-Code Änderungen der Regeln über das Administration-Interface, Upload ohne Neustart des IDS möglich

Administration-Interface passt auf Diskette und kann auf jedem Windows NT/2000/XP-Rechner gestartet werden

Scan-Netzwerkkarte hat keine IP-Adresse

Negativ: Keine Administrationsmöglichkeiten beim NIDS-Sensor

Bei einem Update des Sensors muss die komplette CD ersetzt werden.

3 verschiedene Betriebssysteme für Sensor, Central Management Server und Administration Interface nötig

Keine Informationen über einen Alarm ausser Src-IP, Dest-IP und Name des Angriffs

Keine Informationen über angegriffene Ports bei einem Portscan

Darstellung der Alarme verwirrend Zu wenige Informationen über Angriffe

Nur auf geringe Anzahl an unterschiedlichen Hardwarekomponenten ausgelegt

Nicht "State of the Art", d.h. veraltetes Look-and-Feel

Administration-Interface nicht umfangreich und optisch nicht ansprechend gehalten

IDS kann über das normale Netzwerk nicht angesprochen werden, d.h. es wird eine zweite Netzwerkkarte benötigt

Keine Auswahl zwischen In-band und Out-of-Band-Management, d.h. nur Out-of-Band-Management möglich

Plötzliche, ungeklärte Abstürze Alarme sind bei der Ausgabe auf dem IDS-System verwirrend und eigentlich unleserlich

Zu schlechtes Preis-Leistungsverhältnis, für den einstmals Spitzenreiter der ID-Systeme

vergleich und einführung von intrusion detection systemen · intrusion detection von network...

Documents