Grundlagen, Forderungen und Marktübersicht von IDS und RDS

„Grundlagen, Forderungen und Marktübersicht für Intrusion Detection Systeme (IDS) und Intrusion Response Systeme (IRS)“

Hrsgbr:

debis IT Security Services Rabinstraße 8 D-53111 Bonn

Autoren:

Dr. Josef von Helden, Dr. Stefan Karsch IDS-10-03 1.4 19.10.98

Dok-Ref: Version: Datum:

 1997, debis IT Security Services, jvh/sk Weitergabe sowie Vervielfältigung dieser Unterlage und Verwertung ihres Inhalts sind nicht gestattet, soweit nicht ausdrücklich zugestanden. Zuwiderhandlung verpflichtet zu Schadenersatz. Alle Rechte vorbehalten.

Grundlagen, Forderungen und Marktübersicht für Intrusion Detection Systeme (IDS) und Intrusion Response Systeme (IRS)

Inhaltsverzeichnis

Inhaltsverzeichnis 1.

2.

Einleitung

1

1.1

Änderungen im IT-Umfeld

1

1.2

Internet Zugang

2

1.3

Wechsel der Bedrohungsquelle

3

1.4

Zur Entwicklung des Gebiets „Intrusion Detection“

4

1.5

Gliederung

7

Intrusion Detection und Intrusion Response - Grundlagen

8

2.1

Übersicht

8

2.2

Automatische Erkennung von Angriffen mittels Intrusion Detection

9

2.2.1

Grundlegende Begriffe

9

2.2.2

Datensammlung

10

2.2.3

Datenanalyse

11

2.2.4

Mißbrauchserkennung

11

2.2.5

Anomalieerkennung

11

2.2.6

Ergebnisdarstellung

12

2.3

2.4

12.07.2000

Angriffe auf Computer und Netze

13

2.3.1

Angriffsplanung

16

2.3.2

Angriffe auf unterer Ebene

21

2.3.3

Angriffe auf mittlerer Ebene

31

2.3.4

Angriffe auf hoher Ebene (Anwendungsebene)

36

2.3.5

Angriffe auf das Authentisierungssystem

38

2.3.6

Import von kompromittierendem Code

39

2.3.7

Probleme im Zusammenhang mit dem Word-WideWeb (WWW)

40

Kategorisierung von Angriffen bezüglich ihrer Erkennbarkeit

45

2.4.1

Ziele

46

2.4.2

Erkennungstechniken

46

2.4.3

Auswirkung und Nutzen

49

debis IT Security Services

Seite i

Grundlagen, Forderungen und Marktübersicht für Intrusion Detection Systeme (IDS) und Intrusion Response Systeme (IRS)

2.5

Das Erkennen von Angriffen auf Rechner und Rechnernetze

50

2.5.1

Angriffsplanung

51

2.5.2

Angriffe auf unterer Protokollebene

53

2.5.3

Angriffe auf mittlerer Ebene (Dienstebene)

57

2.5.4

Angriffe auf hoher Ebene (Applikationsebene)

59

2.5.5

Angriffe auf das Authentisierungssystem

59

2.5.6

Einfuhr von Code mit Schadensfunktionalität (malicious code)

60

Probleme beim Einsatz von WWW-spezifischer Software

61

Zusammenfassung

62

2.5.7 2.5.8 2.6

2.7

2.8

3.

Inhaltsverzeichnis

Der praktische Einsatz von ID-Systemen

71

2.6.1

Voraussetzungen für Anomalieerkennung

73

2.6.2

Voraussetzungen für Mißbrauchserkennung

74

2.6.3

Voraussetzungen für einen hybriden Einsatz von Mißbrauchs- und Anomalieerkennung

75

2.6.4

Aufwand vs. Sicherheit

76

2.6.5

Rechtliche Aspekte der Intrusion Detection

78

Intrusion Response — Automatische Gegenmaßnahmen bei Angriffen

81

2.7.1

IR-Ziele

82

2.7.2

Maßnahmen

82

Effektivität von ID und IR Systemen

86

2.8.1

Wie erfolgreich ist die aktuelle ID/IR Technik?

87

2.8.2

ID Trends

88

2.8.3

IR Trends

89

2.8.4

Maximierung der Anti-Intrusions Effektivität

89

Produkt-/Projektstudie

91

3.1

Methode

91

3.2

Klassifikationskriterien für ID-Systeme

92

12.07.2000

debis IT Security Services

Seite ii

Grundlagen, Forderungen und Marktübersicht für Intrusion Detection Systeme (IDS) und Intrusion Response Systeme (IRS)

4.

5.

Inhaltsverzeichnis

3.3

EMERALD

100

3.4

DIDS

104

3.5

GrIDS

108

3.6

LogSurfer

111

3.7

RealSecure

114

3.8

Stalker

117

3.9

NetRanger

121

3.10

NetStalker

124

3.11

NIDES

127

3.12

StakeOut

130

3.13

AID

134

3.14

IDES

137

3.15

Kane Security Monitor

141

3.16

OmniGuard Intruder Alert

144

3.17

PDAT (Protocol Data Analysis Tool)

148

3.18

Übersicht: Lizenzgebühren and Verfügbarkeit

151

3.19

Übersicht: Hauptmerkmale der ID-Systeme

152

Anforderungskatalog an ein ID-System

154

4.1

Ziel

154

4.2

Ein Prototyp für eine ID-Funktionalitätsklasse

154

4.2.1

Sicherheitsaudit

155

4.2.2

Wartungsunterstützung

161

4.2.3

Identifizierung und Authentifizierung

164

4.2.4

Schutz der Sicherheitsfunktionen

164

4.2.5

Vertraulichkeit (Privacy)

166

4.3

Vertrauenswürdigkeit (Assurance)

166

4.4

Bemerkungen

168

Anforderungskatalog für ein Intrusion Response System (IRS)

169

5.1

169

12.07.2000

Ziel debis IT Security Services

Seite iii

Grundlagen, Forderungen und Marktübersicht für Intrusion Detection Systeme (IDS) und Intrusion Response Systeme (IRS)

5.2

5.3 6.

Ein Prototyp für eine IRS Funktionalitätsklasse

169

5.2.1

Sicherheitsaudit

169

5.2.2

Wartungsunterstützung

170

5.2.3

Schutz der Sicherheitsfunktionen

170

5.2.4

Verfügbarkeit der Dienste

171

Vertrauenswürdigkeit

173

Literaturverzeichnis

12.07.2000

Inhaltsverzeichnis

174

debis IT Security Services

Seite iv

Grundlagen, Forderungen und Marktübersicht für Intrusion Detection Systeme (IDS) und Intrusion Response Systeme (IRS)

Einleitung

1. Einleitung Das sich in den letzten Jahren stark verändernde IT-Umfeld erfordert in zunehmendem Maße die Berücksichtigung des Aspekts der Systemsicherheit. Hierbei ist neben dem Schutz eines internen Firmennetzes (Intranet, LAN etc.) vor Angriffen aus dem externen Netz (Internet) auch der Schutz von Angriffen aus dem internen Netz von immer stärker werdendem Interesse. Neben Firewall-Lösungen, die in den letzten Jahren zur obligatorischen Komponente einer Netzanbindung geworden sind, finden Intrusion Detection Systeme (IDS) immer weitere Verbreitung. Im Gegensatz zu Firewall-Systemen, deren Funktionsweise, Produktreife und Zusatzkomponenten in der Standardliteratur ausführlich diskutiert wurden, existiert zu IDSystemen kaum herstellerunabhängige Literatur. Das Ziel der vorliegenden Studie ist es, eine Übersicht über das Gebiet der ID-Systeme zu geben und einen Anforderungskatalog für die Entwicklung und den Einsatz solcher Systeme zu erarbeiten. Die Studie ermöglicht es dem Leser, folgende Fragen zu beantworten: •

Welche Angriffe werden gegen Rechner oder Rechnernetze gefahren?

•

Welche grundlegenden Techniken gibt es, Angriffe zu erkennen? Wie können die gängigen Angriffe erkannt werden? Gibt es Angriffe, die sich nur schwer oder überhaupt nicht erkennen lassen?

•

Welches sind die zum Zeitpunkt der Erstellung der Studie am häufigsten verwendeten ID-Systeme? Worin liegen ihre Stärken? Wie teuer ist der Einsatz solcher Systeme?

•

Was sind die Anforderungen an ein modernes ID-System, welches den Stand der Technik widerspiegelt?

Das vorliegende Kapitel gibt eine Einführung in das Thema Intrusion Detection (ID). Das Ziel der Einführung ist es, eine Übersicht über die Entwicklung des noch relativ jungen Gebiets zu geben. Daneben werden auch die in kommerziellen Produkten und Forschungsprototypen verwendeten ID-Techniken beschrieben.

1.1 Änderungen im IT-Umfeld Im IT-Umfeld hat in den letzten zehn Jahren ein Wechsel vom isolierten Arbeitsbereich hin zum an das Internet angebundenen Arbeitsplatz stattgefunden. Damit verbunden fand auch ein Wechsel vom zentral gewarteten Großrechner hin zum vom Benutzer administrierten Desktop PC statt. Diese Änderungen stellen neue Anforderungen an das mögliche Bedrohungsprofil des IT-Umfelds dar. Der Einsatz objektorientierter Techniken, die ohne größere Umstände die schnelle Ausführung von übermittelten Programmen oder Dokumenten auf vielen Zielsystemen ermöglichen, eröffnet ein neues Feld für die Verteilung 12.07.2000

debis IT Security Services

Seite 1

Grundlagen, Forderungen und Marktübersicht für Intrusion Detection Systeme (IDS) und Intrusion Response Systeme (IRS)

Einleitung

böswilliger Software. Durch Installation und Betrieb solcher Software entsteht eine Rechnerumgebung, die anfälliger gegenüber Angriffsversuchen ist und die standardmäßig wenig Schutz gegen unerwünschte Aktivität bietet. Mit den ständig wechselnden Techniken und dem immer größer werdenden ökonomischen Druck, werden Standardanwendungen (COTS-Produkte, commercial-off-the-shelf) immer häufiger auch in den Bereichen installiert, die sich vormals proprietärer Lösungen bedienten. Dies soll auf der einen Seite den Entwicklungsaufwand und die Wartungskosten reduzieren und auf der anderen Seite die Kompatibilität mit firmenexternen Produkten sichern. Der normale Käuferbereich ist jedoch im allgemeinen wenig sicherheitsorientiert und auch unerfahren mit sicheren Produkten. Kommerzielle Entwickler zeigten daher wenig Bereitschaft, sich Grundlagenwissen für die Entwicklung sicherer Produkte anzueignen. Die mangelnde Beachtung von Sicherheitsaspekten seitens der Softwarehersteller führte zusammen mit der genauen Kenntnis von Angreifern über Soft- und HardwareEigenschaften zur erfolgreichen Kompromittierung von Rechnersystemen. Trotz moderner Software-Entwicklungswerkzeuge und –Methoden führt die steigende Komplexität und der Druck des Markts auf die Softwarehersteller zu einer zu hohen Fehlerquote und Instabilität der produzierten Software. Die Testparadigmen und die Qualitätssicherungsmaßnahmen wurden dahingehend verändert, daß es nunmehr durchaus üblich ist, Alpha-Versionen einer Software auf den Markt zu bringen, die Fehlersuche den Benutzern zu überlassen und die Fehler erst dann zu beseitigen, wenn sie von den Benutzern gemeldet werden. Benutzer haben immer geringere Erwartungen an das fehlerfreie Verhalten von Software. Dies gilt insbesondere für Software, die aus dem Internet verfügbar ist. Viele Programme werden als sogenannte Teaseware oder Shareware angeboten und Internet-Nutzer zögern nicht, diese Software lokal zu starten. Es ist festzustellen, daß die Anzahl der globalen Quellen (Internetsites) für Software weiterhin zunimmt.

1.2 Internet Zugang Der freie Zugang zum Internet ist zu einem Muß für die meisten Rechnerarbeitsplätze geworden. Dabei entstand eine starke Diskrepanz zwischen einer Infrastruktur, die nicht im Hinblick auf Sicherheitsaspekte entworfen wurde, und den von dieser Infrastruktur angebotenen und unterstützen Diensten. Seit jedoch große Banken Teile ihres Zahlungsverkehrs und Electronic Commerce über das Internet abwickeln, richtet sich nun das Augenmerk verstärkt auf den Bereich der Internet-Sicherheit. In diesem Zusammenhang werden auch immer mehr Schwächen der verwendeten Techniken bekannt. Der Zugang zu Ressourcen und das Herunterladen von Software aus dem World Wide Web mittels Browsern wie Netscape Navigator oder Microsoft Internet Explorer ist vielfach auch am Arbeitsplatz zu ein Muß geworden. Ein Grund für die Notwendigkeit eines solchen Zugriffs auf das Internet ist die Fülle von Multimediaobjekten, die über das Internet verfügbar 12.07.2000

debis IT Security Services

Seite 2

Grundlagen, Forderungen und Marktübersicht für Intrusion Detection Systeme (IDS) und Intrusion Response Systeme (IRS)

Einleitung

sind. Um solche Objekte darstellen zu können, wird zusätzliche Software benötigt. Um in den Besitz dieser Software zu gelangen, ist häufig eine explizite Anfrage des Benutzers nötig; manchmal wird die Software sogar automatisch sofort nach dem Laden des entsprechenden Objekts ebenfalls aus dem Internet heruntergeladen. Die meisten Benutzer akzeptieren die Notwendigkeit, ständig über die neuesten BrowserPlug-Ins verfügen zu müssen. Dabei stellt das undifferenzierte Laden von Software aus dem Internet ein großes Sicherheitsrisiko dar. Die heruntergeladene Software erhält meistens dieselben Zugriffsrechte wie der Benutzer, der diesen Vorgang initiiert hat, und stellt so eine gute Möglichkeit dar, trojanische Pferde zu installieren1. Neben dem manuellen Herunterladen von Software erlauben Techniken wie Java-Script oder ActiveX das automatische und für den Benutzer vollkommen unsichtbare Herunterladen von Software. Die starke Verbreitung von Makroviren zeigt die Gefährlichkeit von Skriptsprachen, die sämtliche Betriebssystemfunktionen nutzen können. Da diese Sprachen von der Bedienbarkeit eher zu den höheren Programmiersprachen zählen, wird die Erstellung von trojanischen Pferden etc. erleichtert. Außerdem lassen sich solche Programme relativ leicht auf unterschiedliche Betriebssysteme portieren.

1.3 Wechsel der Bedrohungsquelle Parallel zu den sich ändernden Paradigmen der Arbeitsprozesse ist auch die Umgebung, von der die Bedrohungen ausgehen, einem Wechsel unterworfen, der zu immer gefährlicher werdenden Angriffen führt. Die Cracker-Gemeinde wächst ständig weiter und die Effektivität der Angriffe steigt mit ihr. Cracker richten ihre Aufmerksamkeit nunmehr auf Java, PCs und Standardanwendungen. Sie sind in bezug auf die Publikation ihrer Ergebnisse sehr großzügig. Die geschickten Cracker erweitern ihre Techniken, die ungeschickten benutzen Angriffsskripte. Durch den immer günstiger werdenden Zugang zum Internet und die immer preiswerter werdende Hardware, werden unerfahrene Benutzer Teil der Informationsgesellschaft. Viele von ihnen sind außerstande, die Funktionsweise der von ihnen benutzten Werkzeuge zu verstehen und können die technischen Folgen ihrer Handlungen sehr schwer abschätzen. Das Entwickeln bzw. Entdecken von Angriffen ist ein sehr dynamisches Gebiet. Kaum ein Tag vergeht, ohne daß neue Schwachstellen in IT-Systemen bekannt werden. Information zu Angriffen verbreitet sich schnell. Angriffe werden aufgezeichnet und können so leicht

1

Ein zum Zeitpunkt der Erstellung des Dokuments populärer Fall ist das Einschleusen von Trojanischen Pferden mittels der Software „T-Online Power Tools“. Diese installierte ein trojanisches Pferd, welches die Übermittlung von codierten Paßwörtern an den Angreifer veranlaßte. Die schwache Verschlüsselung dieser Paßwörter führte dazu, daß die Benutzerkonten kompromittiert wurden und den betroffenen Nutzern hätte finanzieller Schaden zugefügt werden können (vgl. [Luckhardt, 1998]).

12.07.2000

debis IT Security Services

Seite 3

Grundlagen, Forderungen und Marktübersicht für Intrusion Detection Systeme (IDS) und Intrusion Response Systeme (IRS)

Einleitung

wiederholt abgespielt werden. Darüber hinaus nimmt die Anzahl der möglichen Angriffsziele ständig zu. Die Analyse von über einer halben Million Sicherheitsalarmen, die vom ID-System NetRanger mittels des NetSolve ProWatch Secure Monitoring zwischen Mai und September 1997 gemeldet wurden [Wheelgroup Corp. ‘97] gibt eine gute Übersicht über aktuelle Angriffstrends. Jeder Kunde hat auf seinem System mindestens einen schwereren Angriff sowie ein monatliches Scanning nach Diensten und andere Ausspähversuche feststellen können. Am oberen Ende der Analyse fanden sich Benutzer, deren Systeme sich monatlich durchschnittlich fünf schweren Angriffen ausgesetzt sahen; diese Benutzer betrieben Anwendungen aus dem Bereich Electronic Commerce. Die meisten Angriffe kamen jedoch nicht von Universitäten oder Unternehmen mit festem eigenem Adreßbereich, sondern verliefen über ISPs (Internet Service Provider), die ihren Benutzern dynamische IP-Adressen zuteilen. Desweiteren war eine Korrelation zwischen der Anzahl der Angriffe in einem Zeitraum und der Diskussion über Angriffe mit anschließender Bereitstellung von Angriffsskripten erkennbar. Die Cracker beherrschen die rasche Verteilung von Angriffsinformation über das Internet sehr gut. Gefundene Systemschwächen werden schnell veröffentlicht und Informationen gut organisiert über das Usenet, Mailing-Listen und Web-Sites weitergereicht. Ein weiter zunehmender Trend ist die Verbreitung von Programmen zur automatischen Ausführung von Angriffen, welche unerfahrenen Crackern das Durchführen von Angriffen als Trittbrettfahrer erlauben. Innerhalb weniger Minuten können solche Programme oder Skripten heruntergeladen und als Angriffswerkzeug benutzt werden. Der von Mitnick 1994 durchgeführte Angriff aus Shimomuras Rechnersystem benötigte nur ein paar Minuten für das Abtasten des Zielsystems und das anschließende Starten eines Skriptangriffs [CMAD III ‘95]. Das erfolgreiche Erkennen eines solchen Angriffs benötigt daher Echtzeiteigenschaften.

1.4 Zur Entwicklung des Gebiets „Intrusion Detection“ Intrusion Detection (ID) ist ein relativ junges Teilgebiet aus dem IT-Sicherheitsbereich, welches das Ziel hat, Methoden zur Erkennung von Angriffen auf Rechnersystemen zu entwickeln. Ein ID-System (IDS) wird in Analogie zu einer Alarmanlage gesehen. Gelingt es beispielsweise einem Angreifer trotz des Firewallschutzmechanismus, ein Virenprogramm zu installieren und auch zu aktivieren, so soll das IDS einen Alarm auslösen und den zuständigen Sicherheitsbeauftragten (System Security Officer, SSO) mittels E-Mail, Pager etc. informieren. Der SSO kann dann das IDS nach genaueren Information zu dem Angriff befragen, um so geeignete Gegenmaßnahmen zu treffen. Im schlimmsten Fall kann er sich dazu entscheiden, das System herunterzufahren. Die ersten ID-Systeme untersuchten lediglich die vom Betriebssystem erzeugten Protokolldaten (Auditdaten) im Hinblick auf mögliche Angriffe. Die während des normalen Systembetriebs anfallende Auditdatenmenge kann jedoch sehr schnell groß und somit 12.07.2000

debis IT Security Services

Seite 4

Grundlagen, Forderungen und Marktübersicht für Intrusion Detection Systeme (IDS) und Intrusion Response Systeme (IRS)

Einleitung

unhandlich werden. Es gibt zwei Möglichkeiten mit solchen unhandlichen Datenmengen umzugehen: •

Verbesserung des Auditmechanismus, so daß dieser nur relevante Handlungen protokolliert.

•

Bereitstellung von Werkzeugen, die es dem SSO gestatten, sich auf die relevanten Ereignisse zu konzentrieren.

Werkzeuge zur automatischen Analyse von Auditdaten wurden sowohl von Forschern im Bereich Rechnersicherheit als auch von Systemadministratoren als proprietäre Lösungen entworfen. Die Effektivität dieser Werkzeuge war jedoch eher gering. Der Hauptansatz war dabei der Versuch, die uninteressanten Ereignisse herauszufiltern und es dem SSO so zu ermöglichen, die Auditdatenrestmenge manuell zu verarbeiten. Das hieraus entstandene Forschungsgebiet „Intrusion Detection“ versuchte diese Ansätze zu erweitern, indem man in den Auditdaten nach bekannten Angriffsmustern und Evidenz für anomales Benutzerverhalten zu suchen begann. ID war anfangs kaum mehr als der Versuch, die großen Auditdatenmenge eines Mainframes auf ein handhabbares und trotzdem aussagekräftiges Niveau zu reduzieren. Administratoren stellten sich die Frage, ob außer dem Löschen kompletter Dateiverzeichnisstrukturen mehr Indizien auf einen Eindringling hinweisen. Sicherheitskriterien, Zertifizierungs- und Akkreditierungmaßnahmen beschrieben weitgehende Anforderungen an den Auditmechanismus in den eingesetzten Systemen, machten allerdings lediglich eine begrenzte Unterscheidung zwischen der klassischen Protokollierung des Betriebsmittelverbrauchs und dem Sicherheitsaudit. Darüber hinaus boten sie kaum Hilfe bei der Verarbeitung der entstehenden voluminösen – und im allgemeinen bedeutungslosen – Auditdatenmenge. Obwohl die Entwicklung von ID-Systemen während des letzten Jahrzehnts einen enormen Fortschritt gemacht hat, hat dieses Forschungsfeld noch immer nicht den Einzug in Lehrbücher über IT-Sicherheit gefunden. Moderne Bücher, wie beispielsweise [Pfleeger, 1997] behandeln keine im Rahmen von ID entwickelten Techniken, obwohl sie kürzere Abschnitte über das Gebiet als solches beinhalten. Der Grund dafür ist, daß viele IDTechniken eher einfach gehalten sind und der Erfolg eines Systems meist entscheidend von der Wahl der richtigen Parameter ist. In dieser Hinsicht ähneln viele ID-Systeme frühen Expertensystemen (wie z.B. MYCIN). Dazu kommt, daß ID-Systeme Eigenschaften benötigen, die nicht im direkten Zusammenhang mit der Entdeckung von Angriffen stehen. So ist es beispielsweise sehr wichtig, die Integrität der IDS-Konfigurationsdaten oder auch die Echtheit einer Alarmmeldung zu garantieren. Ein gut funktionierendes IDS darf sich daher nicht auf die Fähigkeit beschränken, Angriffe zu erkennen. Zur Entdeckung von Angriffen gibt es zwei Hauptunterscheidungsmerkmale. Um festzustellen, ob ein bestimmter Systemzustand angriffstypisch ist, kann dieser Zustand in Abhängigkeit von den Folgezuständen oder auch isoliert analysiert werden. Erhält ein System beispielsweise 10 MB E-Mail pro Minute, so kann dies – isoliert betrachtet – als Angriffszustand gewertet werden und es wird ein Alarm ausgelöst. Alternativ dazu können aber auch die Vorgängerzustände betrachtet werden. Falls ein Benutzer beispielsweise 12.07.2000

debis IT Security Services

Seite 5

Grundlagen, Forderungen und Marktübersicht für Intrusion Detection Systeme (IDS) und Intrusion Response Systeme (IRS)

Einleitung

einen Fragebogen an viele Internetnutzer verschickt hat und diese Fragebögen nun ausgefüllt zurückkommen, so gibt es unter Umständen gar keinen Grund die, E-Mail-Flut als Angriff zu bewerten. Es kann daher zwischen Techniken unterschieden werden, die eine Zustandsmenge (Zustandsübergangsmethode) oder lediglich einen isolierten Zustand (Einzelzustandsmethode) berücksichtigen. Das zweite Merkmal ist die Einbeziehung von Wahrscheinlichkeiten. Die Einbeziehung von Wahrscheinlichkeiten erlaubt eine Feineinstellung der Zustandsübergangsmethode als auch der Einzelzustandsmethode. So kann beispielsweise die Wahrscheinlichkeit, daß 10 MB EMail innerhalb einer Stunde ankommt, p betragen. Das IDS löst nun einen Alarm aus, falls p > P für eine fest vorzugebendes P gilt, d.h. falls der tatsächliche Zustand so unwahrscheinlich ist, daß er einen gewissen Schwellenwert überschreitet. Kombiniert man die Einbeziehung von Wahrscheinlichkeiten mit der Zustandsübergangsmethode, so erhält man bedingte Wahrscheinlichkeiten. Kombiniert man sie mit der Einzelzustandsmethode, erhält man unbedingte Wahrscheinlichkeiten.

Emerald

zustandsbasiert Zustandsübergänge (z.B. Markov Ketten)

P≥0 Nides

zustandslos

PDAT

DIDS IDES

String matching

LogSurfer

zuständsbasiert

AID

Analyse von Zustandsübergängen

P=0

OmniGuard ITA

zustandslos

Stalker

Kane SM

RealSecure StakeOut

NetRanger

GrIDS

NetStalker

String matching

Auditdaten Betriebssystem

benutzerspezifische Profile

Netzwerkverkehr

Abbildung 1: Die Verwendung der gängigen Techniken in ID-Systemen Das obige Diagramm gibt eine Übersicht über die von den verschiedenen ID-Systemen verwendeten Techniken. Entlang der x-Achse sind verschiedene Quellen zu untersuchender Daten aufgetragen. Es sei angemerkt, daß es keinen funktionalen Zusammenhang zwischen den verwendeten Techniken und der tatsächlichen Praxistauglichkeit der verschiedenen Systeme gibt. So benutzt beispielsweise RealSecure eine relativ einfache Technik, die aber in Kombination mit der großen, mitgelieferten Datenbank mit den Angriffsmustern (Signaturdaten) sehr effektiv ist.

12.07.2000

debis IT Security Services

Seite 6

Grundlagen, Forderungen und Marktübersicht für Intrusion Detection Systeme (IDS) und Intrusion Response Systeme (IRS)

Einleitung

Auf der anderen Seite benutzen reine Forschungsprototypen wie EMERALD sehr dedizierte Techniken, die aber wegen der relativ kleinen Signaturdatenbank praktisch dazu führen, daß das System nicht als brauchbarer Schutz eingesetzt werden kann.

1.5 Gliederung Die Studie gliedert sich in vier Teile. Kapitel 2 behandelt die Grundlagen der Intrusion Detection und Intrusion Response. Insbesondere werden mögliche Angriffe gegen Rechnersysteme und Methoden zu ihrer Erkennung beschrieben. Darüber hinaus werden die Angriffe unter Anwendung vorgenannter Methode bezüglich ihrer Erkennbarkeit kategorisiert. Kapitel 3 ist eine Studie zu existierenden ID-Forschungsprojekten und am Markt verfügbaren ID-Produkten. Auf Basis der in Kapitel 2 dargelegten Grundlagen wird ein Klassifikationsschema für ID-Systeme entwickelt und die untersuchten Systeme werden auf die darin festgelegten Kriterien hin untersucht. In Kapitel 4 und 5 wird ein Anforderungskatalog für Intrusion Detection und Intrusion Response Systeme entwickelt, der sich zur Definition einer ITSEC Funktionalitätsklasse eignet. Neben allgemeinen Aspekten werden Anforderungen an •

Architektur,

•

Benutzerschnittstelle,

•

Wartung,

•

Schutz,

•

Skalierbarkeit und

•

Integration mit anderen Sicherheitsmechanismen

formuliert. Die Studie schließt mit einer umfangreichen Bibliographie zum Thema „Intrusion Detection“.

12.07.2000

debis IT Security Services

Seite 7

Grundlagen, Forderungen und Marktübersicht für Intrusion Detection Systeme (IDS) und Intrusion Response Systeme (IRS)

Intrusion Detection und Intrusion Response - Grundlagen

2. Intrusion Detection und Intrusion Response - Grundlagen Der Anschluß eines internen Computernetzes an ein externes Netz erfordert eine Vielzahl von Maßnahmen, die das interne Netz vor dem externen, oftmals unsicheren Netz schützen. Der Anschluß eines Firmennetzes an das Internet ist nur ein Beispiel für eine solche Kopplung. Eine typische Schutzmaßnahme besteht darin, eine Firewall zwischen das interne und das externe Netz zu schalten. Leider ist keine Firewall vollständig sicher: Konfigurationsfehler und Programmierfehler können ausgenutzt werden, um das zu schützende Netz anzugreifen. Darüber hinaus erfassen Firewalls in der Regel nicht das Abtasten nach aktiven Ports (port scanning). Angriffe auf Netze – insbesondere sogenannte Skriptangriffe – beginnen allerdings häufig mit einem solchen Abtasten. Es ist daher notwendig, die Aktivitäten auf einzelnen Rechnern und dem gesamten Netz zu überprüfen. Zur Überprüfung stellt das System dem Administrator Informationen in Form von Auditdaten zur Verfügung. Diese Daten werden während des Betriebs vom Betriebssystem (OS audit), einzelnen Applikation (application audit) oder definierten Systemschnittstellen, wie z.B. syslogd (unter Unix und Windows NT) aufgezeichnet. Die dabei anfallende Menge von Auditdaten ist unter Umständen so groß, daß sie nicht manuell vom Systemadministrator nach allen Aspekten möglicher Angriffe durchsucht werden kann. Darüber hinaus sind die Administratoren nicht zu jeder Zeit verfügbar. Werkzeuge, die sowohl die vom System bereitgestellten Auditdaten untersuchen als auch eigenständig in der Lage sind, Systemkomponenten zu überwachen, unterstützen die Administratoren bei ihrer Arbeit. Da zukünftig immer mehr Arbeit über das Internet bzw. Intranets (firmeninterne Netze unter Verwendung von Internet-Technologie) abgewickelt werden wird, werden Werkzeuge zu automatischen Erkennung von Angriffen neben solchen zur sicheren Kommunikation immer wichtiger.

2.1 Übersicht In diesem Kapitel beschreiben wir die Grundlagen der Intrusion Detection. Abschnitt 2.2 beschreibt die grundlegenden Konzepte zur automatischen Erkennung von Angriffen. Wir diskutieren an dieser Stelle die verschiedenen Komponenten eines IDS, sowie die Grundtechniken der Signaturanalyse und der Anomalieerkennung. In Abschnitt 2.3 beschreiben wir unterschiedliche Methoden, die dazu benutzt werden, um in Rechnersysteme und –netze einzudringen. In Abschnitt 2.4 wird ein Schema vorgestellt, das es erlaubt, aus verschiedenen Charakteristika eines Angriffs eine zur Erkennung geeignete ID-Grundtechnik zu wählen. Die vorgenannte Methode wird in Abschnitt 2.5 genutzt, um die in Abschnitt 2.3 beschriebenen Angriffe hinsichtlich ihrer Erkennbarkeit zu analysieren. Der folgende Abschnitt 2.6 beschreibt die notwendigen Einsatzvorbereitungen für ein IDS. Weiterhin vergleichen wir dort den möglichen Aufwand bei der Wartung und Konfiguration eines IDS mit dem zu erwartenden Nutzen. Abschnitt 2.7 beschreibt Ziele und die im Rahmen der Intrusion Response möglichen Maßnahmen. Wir beenden das 12.07.2000

debis IT Security Services

Seite 8

Grundlagen, Forderungen und Marktübersicht für Intrusion Detection Systeme (IDS) und Intrusion Response Systeme (IRS)

Intrusion Detection und Intrusion Response - Grundlagen

Grundlagenkapitel in Abschnitt 2.8 mit einer Diskussion über den Stand der Technik von IDSystemen und ihre Effektivität.

2.2 Automatische Erkennung von Angriffen mittels Intrusion Detection Eine Intrusion kann gemäß [Heberlein, Levitt and Mukherjee, 1991] wie folgt beschrieben werden: „Eine Menge von Handlungen, deren Ziel es ist, die Integrität, die Verfügbarkeit oder die Vertraulichkeit eines Betriebsmittels zu kompromittieren““. Allgemeiner gefaßt kann man unter einer Intrusion die absichtliche Verletzung der Sicherheitsmaßnahmen eines System verstehen. Das Ziel der Intrusion Detection (ID) ist es, diese Verletzungsversuche zu erkennen, sie für den die Systemsicherheit zuständigen Personen zu melden und geeignete Gegenmaßnahmen zu treffen, bzw. das System für Intrusions-Gegenmaßnahmen (Intrusion Response System, IRS) mit geeigneter Information über den Angriff zu versorgen.

2.2.1 Grundlegende Begriffe Ein Intrusions-Erkennungssystem (IDS) besteht aus den folgenden drei Hauptkomponenten: • Einer Komponente zur Datensammlung, welche Informationen z.B. über den allgemeinen Systemzustand und die Betriebsmittelvergabe sammelt. Diese Information kann quantitativer Art sein, z.B.: der Port 4711 empfing während der letzten Sekunde 20 SYN-Pakete. Es kann sich allerdings auch um qualitative Aussagen handeln, etwa der folgenden Art: Benutzer Felix schickte eine E-Mail ab, kurz nachdem der sich beim System angemeldet hat. • Einer Komponente zur Datenanalyse, welche die gesammelten Daten im Hinblick auf mögliche Angriffe analysiert. • Einer Komponente zur Ergebnisdarstellung, die das Analyseergebnis benutzergerecht aufbereitet und dem Sicherheitsbeauftragten als Entscheidungshilfe für das weitere Vorgehen liefert. Die oben aufgeführten Komponenten können noch weiter verfeinert werden. Dies führt auf der einen Seite zu einer Menge von Design-Alternativen, auf der anderen Seite zu unterschiedlichen Funktionalitäten eines ID-Systems. Die möglichen Verfeinerungen des IDGrobentwurfs führen zu einem Klassifikationsschema für ID-Systeme, welches in Abschnitt 3.2 vorgestellt wird.

12.07.2000

debis IT Security Services

Seite 9

Grundlagen, Forderungen und Marktübersicht für Intrusion Detection Systeme (IDS) und Intrusion Response Systeme (IRS)

Intrusion Detection und Intrusion Response - Grundlagen

2.2.2 Datensammlung Für den Erfolg eines ID-Systems ist es wichtig, aus welcher Quelle die Daten zur Intrusionserkennung genommen werden. Die beste Analysekomponente ist wirkungslos, wenn ihr nicht in ausreichendem Maße Daten zu Verfügung stehen. Folgende Datenquellen können unterschieden werden: Auditdaten aus verschiedenen Systemeinheiten. Die Audit-Datensätze enthalten Meldungen und Statusinformation auf hoher Abstraktionsebene (z.B.: „Wer hat sich angemeldet?” oder „Wann traten Schutzverletzungen auf?”). Die Audit-Datensätze spiegeln einen chronologischen Ereignisstrom wider. Es ist extrem schwierig, gute Audit-Datensätze zu erzeugen. Sowohl zu große als auch zu kleine Protokolldatenmengen erschweren die Analyse. Im Hinblick auf ein ID-System sind TCSEC C2+ Auditdaten besser geeignet als die Protokolldaten eines IBM Mainframe Überwachungssystems. Viele Auditsysteme erzeugen große Datenmengen, die nur einen beschränkten Wert für ID-Systeme haben. Ältere Betriebssystemgenerationen beinhalten eine viel zu schwache Sicherheitsarchitektur. Infolgedessen werden auch sicherheitskritische Ereignisse nicht hinreichend detailliert protokolliert. Sinnvolle Quellen für ID-relevante Auditdaten sind: •

von Teilen des Betriebssystems überwachte Komponenten wie Dateisysteme (hier sind Zugriffsrechte von besonderem Interesse), Netzdienste (wer hat sich von außen angemeldet) etc.

•

von Sicherheitsanwendungen Systemkomponenten

wie

z.B.

Firewalls

überwachte

Betriebsmittelvergabe durch das Betriebssystem. Hier sind Paramter wie CPUAuslastung, Ein-/Auslagerungsrate des virtuellen Speichers, Anzahl aktiver Netzverbindungen etc. interessant. Netzverkehrsdurchsatz. Hier sind Parameter wie Quell- und Zieladresse eines Pakets, sowie der Quell- und Ziel-Port interessant. Auch können die bei den verschiedenen Protokollen zu wählenden Optionen (z.B. Source Routing, SYN-Bit etc.) für das ID-System von Interesse sein. Werden Auditdaten auf einer höheren Abstraktionsebene gesammelt, z.B. von einem ProxyServer, so bedingt dies zwangsweise den Verlust der Daten auf niedrigerer Ebene. Als Folge können viele der in 2.3.2 besprochenen Angriffe nicht erkannt werden. Es ist daher notwendig, Daten auch auf niedrigen Ebenen zu sammeln, zumal diese Ebenen nur sehr schwache Sicherheitsmechanismen haben.

12.07.2000

debis IT Security Services

Seite 10

Grundlagen, Forderungen und Marktübersicht für Intrusion Detection Systeme (IDS) und Intrusion Response Systeme (IRS)

Intrusion Detection und Intrusion Response - Grundlagen

2.2.3 Datenanalyse Der tatsächliche Erkennungsprozeß findet in der Analysekomponente des IDS statt. Hier gibt es zwei unterschiedliche Techniken: Mißbrauchserkennung (misuse detection, auch als Signaturanalyse bezeichnet) und Anomalieerkennung. Während die Mißbrauchserkennung versucht, bekannte Angriffe zu identifizieren, hat Anomalieerkennung das Ziel, die unmittelbaren Folgen eines Angriffs zu erkennen. Damit ist es, zumindest vom Ansatz her, mittels Anomalieerkennung möglich, das System auch vor noch unbekannten Angriffen zu schützen.

2.2.4 Mißbrauchserkennung Dieser Ansatz versucht, in den Auditdaten die für bekannte Angriffe typischen Muster zu erkennen. Hier finden häufig „String Matching“-Algorithmen Anwendung: Der Datenstrom wird auf ein bestimmtes Muster hin untersucht. Hierbei ist noch nicht spezifiziert, wie mächtig dabei die Sprache zur Beschreibung des zu suchenden Musters sein kann. Die Mißbrauchserkennung stellt gewisse Anforderungen an den zu erkennenden Angriff: •

Es muß bekannt sein, worauf dieser Angriff basiert (beispielsweise IP-Paket mit falscher Größenangabe).

•

Es muß eine Signatur für diesen Angriff vorliegen.

•

Die Signatur muß für das ID-System zugänglich gespeichert werden.

Die Angriffsmuster werden in einer sogenannten Signaturdatenbank gespeichert. Diese Datenbank bildet die zentrale Komponente des Mißbrauchserkennungssystems.

2.2.5 Anomalieerkennung Dieser Ansatz basiert auf der Überlegung, daß ein Angriff ein atypisches Systemverhalten (Anomalie) erzeugt, wodurch er erkannt werden kann. Um solche Abweichungen vom Normalverhalten festzustellen, ist es zunächst notwendig, innerhalb des zu schützenden Systems festzulegen, was „normales Verhalten“ ist. Das Wissen um das normale Verhalten leitet sich aus dem bisherigen Benutzerverhalten ab. Hierzu gibt es unterschiedliche Verfahren: 1. Statistische Ansätze Das System versucht hierbei zu einer vorgegeben Parametermenge (CPUAuslastung, Seitenwechselrate etc.) zunächst die Normalwerte zu bestimmen. Dies können zustandsunabhängige Mittelwerte sein (die CPU-Auslastung ist immer bei 12.07.2000

debis IT Security Services

Seite 11

Grundlagen, Forderungen und Marktübersicht für Intrusion Detection Systeme (IDS) und Intrusion Response Systeme (IRS)

Intrusion Detection und Intrusion Response - Grundlagen

20 %). Es kann sich aber auch um zustandsabhängige Werte handeln (bedingte Wahrscheinlichkeiten). Sobald ein Parameter sich außerhalb des für ihn als normal definierten Bereichs bewegt, wird ein Alarm ausgelöst. Optional kann angegeben werden, wie hoch die Abweichung vom Normverhalten ist. 2. Logische Ansätze In den statistischen Ansätzen spiegelt sich die zeitliche Abfolge von Ereignissen nicht in den Parametern wider. Eine vom Normverhalten abweichende Abfolge von Ereignissen kann aber genauso aufschlußreich sein wie Statistiken. Logische Ansätze zur Anomalieerkennung berücksichtigen daher die zeitliche Abfolge von Ereignissen und beschreiben das Normverhalten anhand von Regeln. Entsprechende Systeme betrachten bestimmte Ereignisfolgen als typisch. Beobachtet das System den Anfang einer gewissen Ereignisfolge, so erwartet es, daß auch der Rest der Ereignisfolge abläuft. Ist dies nicht der Fall, wird das beobachtete Systemverhalten als anomal bewertet.

2.2.6 Ergebnisdarstellung Die Aufgabe der Ergebnisdarstellungskomponente ist es, die Ausgabe der Datenanalyse benutzergerecht zu präsentieren. Dazu gibt es in Abhängigkeit der Datenanalysemethode verschiedene Möglichkeiten. •

Mißbrauchserkennungssysteme können Ja/Nein-Ausgaben liefern. Falls der Vergleich einer Signatur mit einem konkreten Angriff positiv ausfällt, so wurde ein Angriff entdeckt; sonst nicht2. Damit liefert die Mißbrauchserkennung keine kontinuierlichen Werte, anhand derer die Schwere (d.h. der potentiell mögliche Schaden) eines Angriffes abgeschätzt werden kann. Nichtsdestotrotz kann anhand des erkannten Angriffstyps eine Schwere zugeordnet werden.

•

Anomalieerkennungssysteme bieten sogannte Verdachtsbewertungen (suspicion values) an, die angeben, wie stark das aktuelle Verhalten vom Normalwert abweicht. In Abhängigkeit dieses Wertes können unterschiedliche Benachrichtigungs- bzw. Alarmierungswege gewählt werden.

2

Die Unterscheidung zwischen Mißbrauchserkennung und Anomalieerkennung verläuft nicht immer scharf. Unter dem Namen „Signaturanalyse mit Schwellenwert“ wird eine Variante der Mißbrauchserkennung verstanden, welche an der Grenze zwischen Mißbrauchserkennung und Anomalieerkennung angesiedelt ist. Die Ja/Nein-Ausgaben sind nur bei reiner Mißbrauchserkennung durch Signaturanalyse möglich.

12.07.2000

debis IT Security Services

Seite 12

Grundlagen, Forderungen und Marktübersicht für Intrusion Detection Systeme (IDS) und Intrusion Response Systeme (IRS)

Intrusion Detection und Intrusion Response - Grundlagen

Eine weitere wichtige Komponente ist die lokale Darstellung der Analyseergebnisse. Mittels einer grafischen Benutzeroberfläche können die Ergebnisse anwenderfreundlich dargestellt werden. Neben dieser bildschirmorientierten Präsentation können Ergebnisse wie z.B. ein Alarm auf unterschiedliche Weisen an den Sicherheitsbeauftragten weitergeleitet werden: •

Pager-Dienste und mobile Telefone erlauben es, die Sicherheitsbeauftragten auch über größere Entfernungen hinweg zu benachrichtigen. Dies kann insbesondere bei besonders gravierenden Angriffen sinnvoll sein.

•

Benachrichtigung über das interne Netz. Diese Methode ist sinnvoll, falls der Sicherheitsbeauftragte die Konsole nicht permanent beobachten kann. Wählt man diese Vorgehensweise, so ist darauf zu achten, daß die Verbindung zwischen den beteiligten Stationen kryptographisch gesichert ist, damit die Information nicht durch einen Angreifer verfälscht werden kann. Desweiteren ist darauf zu achten, daß die beteiligten Systeme nicht Opfer von Denial-of-Service-Angriffen werden und die Meldungen folglich nicht dargestellt werden können.

•

Alarmmeldung an ein entferntes System über ein gesichertes Netzsegment (z.B. einen dedizierten seriellen Anschluß).

•

Lokaler Alarm. Hierbei muß das Sicherheitspersonal die IDS-Konsole ständig beobachten.

2.3 Angriffe auf Computer und Netze Dieses Unterkapitel beschreibt Angriffe auf Rechner über externe Netze. Wir haben die Angriffe in verschiedene Kategorien unterteilt, um so eine strukturierte Übersicht über die Menge der Angriffen zu geben. Diese Kategorien sind nicht notwendigerweise disjunkt, d.h. ein Angriff kann durchaus in mehrere Kategorien fallen. Darüber hinaus wird zu jedem Angriff die Systemschwäche angeben, die er ausnutzt. Dies kann z.B. eine Designschwäche sein, ein Implementierungsfehler oder ein Konfigurationsfehler. Wir teilen die Menge der Systemschwächen wie folgt auf: Konfigurationsfehler: Hierunter fallen all die Fehler, die auf einer falschen Parameterauswahl beruhen. Insbesondere können dies auch Zugriffsrechte sein. Implementierungsfehler: Bekannte Vertreter dieser Klasse sind durch Pufferüberläufe bedingte Fehler. Auch Fehler in der Implementierung des TCP/IP-Stacks fallen unter diese Klasse. Designfehler im Kommunikationsprotokoll: In diesem Fall enthält das Kommunikationsprotokoll z.B. eine Authentisierungsschwäche, die einen sogenannten Spoofing-

12.07.2000

debis IT Security Services

Seite 13

Grundlagen, Forderungen und Marktübersicht für Intrusion Detection Systeme (IDS) und Intrusion Response Systeme (IRS)

Intrusion Detection und Intrusion Response - Grundlagen

Angriff ermöglicht. Oftmals sehen die Protokolle für relevante Operationen überhaupt keine Authentisierung vor (z.B. ARP Spoofing). Designfehler in der Dienstspezifikation: Diese Fehler sind analog zu den vorgenannten Designfehlern im Kommunikationsprotokoll, mit dem Unterschied, daß hier der Fehler im Design des auf das Kommunikationsprotokoll aufsetzenden Dienstes liegt. Ein Beispiel hierfür ist die Schwäche des DNS-Dienstes, welche ein DNS-Spoofing erlaubt. Designfehler in der Anwendung: Dies sind Fehler, die nicht auf Fehler im Protokolldesign oder in der Implementierung zurückzuführen sind. Die Ursache für den Fehler ist oftmals eine Schwäche im Sicherheitsmechanismus der Anwendung, wie z.B. eine Authentisierungsprozedur, die das systematische Ausprobieren von Paßwörtern erlaubt. Fehlverhalten der Benutzer: Benutzer, die sich nicht gemäß der Sicherheitspolitik verhalten, stellen ein großes Risiko für den gesamten Netzbereich, in dem sie arbeiten, dar. Häufig sind dies Benutzer, die ein schwaches Paßwort wählen oder das Paßwort von außen leicht zugänglich machen (Zettel auf dem Schreibtisch). Andere: Dies sind Schwachstellen und Fehler, die zu keinem der oben genannten Punkte gehören. Das Hauptmerkmal dieser Schwachstellen ist, daß sich nicht sagen läßt, wie diese zu beheben sind. Als Beispiel für eine solche Schwachstelle kann der unter 2.3.1.1 beschriebene Port-Scan dienen. Der Angreifer nutzt hierbei die Eigenschaft eines Dienstes aus, auf Anfagen Rückantworten zu geben. Obwohl diese Eigenschaft bei einer Vorbereitung zu einem Angriff mißbraucht werden kann, handelt es sich nicht um eine Schwachstellen im Design des Protokolls oder seiner Implementierung. Diese Kategorien ermöglichen eine einfache und natürliche Charakterisierung der zu besprechenden Angriffe. Wie bereits erwähnt, kann ein Angriff durchaus in mehrere Kategorien fallen. Beispielsweise könnte das Anbieten eines mit einem Designfehler behafteten Dienstes als Konfigurationsfehler kategorisiert werden. Es ist daher zweckmäßig, die ursächliche Schwachstelle für einen Angriff zu finden. Für das obige Beispiel bedeutet dies, daß nur der Designfehler als Basis für den Angriff aufgeführt wird. Neben den ursächlichen Schwachstellen eines Systems, die vom Angreifer ausgenutzt werden, werden zu jedem der Angriffe auch noch die möglichen Schäden angegeben. Dabei werden die folgenden Kategorien Anwendung finden: Angreifer erhält Information über das anzugreifende Ziel: Angriffe mit dieser Schadensfolge dienen üblicherweise der Vorbereitung weiterer Angriffe. Zugriff auf Netzressourcen: Hierbei umgeht der Angreifer Firewall-Komponenten, erhält so Zugriff zum Netz und kann dann beispielsweise Pakete durch dieses Netz schleusen. 12.07.2000

debis IT Security Services

Seite 14

Grundlagen, Forderungen und Marktübersicht für Intrusion Detection Systeme (IDS) und Intrusion Response Systeme (IRS)

Intrusion Detection und Intrusion Response - Grundlagen

Zugriff auf Rechnerressourcen: Je nach Art des Zugriffs und der dabei gewonnen Benutzerrechte können hierbei weitere Folgeschäden entstehen. Dazu gehören beispielsweise der Verlust der Vertraulichkeit, Integritätsverlust oder auch der Verlust lokaler Ressourcen. Darüber hinaus kann das kompromittierte System auch als Absprungstelle für Angriffe gegen andere Rechner verwendet werden. Verlust der Verfügbarkeit: Hiervon sind typischerweise Daten betroffen (insbesondere Dateien). Der Verlust von Daten beim Transport stellt in der Regel keinen nennenswerten Verlust dar, da solche Fehler meist auf Protokollebene behandelt werden. Wenn solche Fehler beim Transport massiv auftreten werden sie im folgenden unter der Rubrik Denial-of-Service zusammengefaßt. Bei Ausnahmen, wie dem UDP-basierten syslog-Protokoll wird dies gesondert ausgewiesen. Datenintegritätsverlust während des Transports: Hierbei gelingt es dem Angreifer, die Daten während des Transports zu verfälschen (beispielsweise Modifikation des DATA-Eintrags und der Prüfsumme bei TCP/IP). Datenvertraulichkeitsverlust während des Transports: Dem Angreifer gelingt es, die versendeten Daten abzuhören bzw. mitzuschneiden. Datenintegritätsverlust auf Rechner: Dem Angreifer gelingt es, Daten, die auf einem Rechner gespeichert sind, zu modifizieren. Datenvertraulichkeitsverlust auf Rechner: Dem Angreifer gelingt es, lesenden Zugriff auf die auf einem Rechner gespeicherten Daten zu erhalten. Datenechtheitsverlust: Hierbei wird die Quelle der Daten verfälscht. Dem Angreifer gelingt es beispielsweise, den Absender einer E-Mail zu verfälschen (bei E-Mail spoofing). Denial-of-Service: Dem Angreifer gelingt es, Dienste (teilweise) lahm zu legen, so daß sie für eine gewisse Zeit nicht zur Verfügung stehen. Auch diese Klassen sind nicht notwendigerweise disjunkt, da es Folgeschäden geben kann. So kann beispielsweise der unerlaubte Zugriff auf einen Rechner den Verlust der Datenintegrität oder auch der Datenechtheit bedingen. Umgekehrt kann der Verlust der Datenintegrität einer Konfigurationsdatei den unerlaubten Zugriff auf einen Rechner erst ermöglichen. Aus diesem Grund werden bei den Angriffen nur die unmittelbaren Schäden aufgeführt. Abschnitt 2.3.1 beschreibt die Planungs- und Informationssammlungsphase eines Angriffs. Die darauf folgenden Abschnitte 2.3.2 bis 2.3.7 beschreiben die Ausführung der verschiedenen Angriffe. Diese werden gemäß ihres Abstraktionsgrades unterteilt in •

Angriffe auf unterer Ebene (ARP, IP, ICMP etc.)

•

Angriffe auf mittlerer Ebene (DNS, NFS, NIS etc.)

12.07.2000

debis IT Security Services

Seite 15

Grundlagen, Forderungen und Marktübersicht für Intrusion Detection Systeme (IDS) und Intrusion Response Systeme (IRS)

•

Intrusion Detection und Intrusion Response - Grundlagen

Angriffe auf hoher Ebene (sendmail, recursive finger etc.)

Diese Ebenen werden auch als Dienstebenen bezeichnet. Abschnitt 2.3.2 beschreibt Angriffe auf unterer Dienstebene, Abschnitt 2.3.3 solche auf mittlerer und 2.3.4 die auf hoher Dienstebene. Abschnitt 2.3.5 behandelt Angriffe, welche Schwachstellen des Authentisierungssystems ausnutzen. Das Einbringen kompromittierenden Codes (malicious code) wird in Abschnitt 2.3.6 diskutiert. Wir schließen unsere Betrachtungen mit Angriffen auf WWW-Dienste in Abschnitt 2.3.7.

2.3.1 Angriffsplanung Üblicherweise erfolgt der eigentliche Angriff erst, nachdem der Angreifer zusätzliche Information über das Zielsystem gesammelt hat. Um diese zu erlangen, werden Aktionen durchgeführt, die ebenfalls als Angriffe bezeichnet werden, aber keinen direkten Schaden hinterlassen. Bei einem vorbereitenden Angriff wird neben allgemeiner Information über das Zielsystem auch Information darüber gesammelt, wie der Angreifer möglichst unbemerkt agieren kann. Beliebte Varianten sind hierbei das sogenannte „social engineering“, sowie das Sammeln von Systemproben (welcher Dienst ist auf welchem Port aktiv) oder auch die Kombination von technischen und sozialen Vorgehensweisen. Der Angreifer benötigt Informationen über das Betriebssystem der Zielrechners, z.B. welche Version des Betriebssystems läuft und welche Patches eingespielt wurden. Darüber hinaus ist es für ihn interessant zu erfahren, wie gut das System administriert wird. Folgende Möglichkeiten zur Angriffsplanung stehen einem versierten Angreifer zur Verfügung: •

TCP port scans

•

UDP port scans

•

Suche nach Zusatzinformation anhand von Diensten wie finger, Identd etc.

Neben diesen Techniken findet das bereits erwähnte „social engineering“ Anwendung. Hierbei ruft der Angreifer beispielsweise den Systemadministrator an und spielt ihm einen ratlosen Benutzer vor oder gibt sich gegenüber einem Benutzer als Administrator aus („Wir müssen ein paar Patches einspielen, können Sie sich bitte abmelden und Ihr Paßwort vorher auf ‚geheim‘ setzen?“).

12.07.2000

debis IT Security Services

Seite 16

Grundlagen, Forderungen und Marktübersicht für Intrusion Detection Systeme (IDS) und Intrusion Response Systeme (IRS)

Intrusion Detection und Intrusion Response - Grundlagen

2.3.1.1 TCP Port scans Es gibt verschiedene Varianten des TCP-Port-Scans, die aus der ursprünglichen daraus erwachsen sind, daß sie verschiedene Protokollierungsmechanismen umgehen und so nachträglich nicht mehr zu entdecken sind. Aktiver Port Scan Ein TCP Port Scan ermöglicht es, festzustellen, welche TCP-basierten Dienste ein Zielrechner anbietet. Der aktive TCP Port Scan basiert auf dem dreistufigen Initiierungsvorgang (sog. three-way handshake) zum TCP-Verbindungsaufbau: 1. Angreifer sendet SYN an zu testenden Port des Zielsystems 2. Zielsystem antwortet mit SYN/ACK 3. Angreifer sendet ACK an Zielsystem Nachdem die Verbindung in Schritt 3 zustande gekommen ist, weiß der Angreifer, daß der entsprechende Port des Zielsystems aktiv ist. Angriffe dieser Art können leicht mit Programmen wie dem TCP-Wrapper entdeckt werden. Ursächlicher Fehler: Keiner Mögliche Schäden: Angreifer erhält Information über Zielsystem

Half Open Scan Der sogenannte Half Open Scan ist ein geschickterer Weg für den Angreifer, den Port Scan unentdeckt durchzuführen. Hierbei werden nicht alle 3 Stufen des TCP-Verbindungsaufbaus durchgeführt, sondern lediglich die ersten 2. Dies hat zu Folge, daß der Angreifer nach Schritt 2 weiß, daß ein Dienst auf dem entsprechenden Port wartet. Der Verbindungsaufbau ist – da die dritte Stufe nicht ausgeführt wurde – nicht erfolgreich und wird somit auch nicht protokolliert. Programme wie tcplog sind allerdings in der Lage, auch die fehlgeschlagenen Versuche eines TCP-Verbindungsaufbaus zu protokollieren. Ursächlicher Fehler: Keiner Mögliche Schäden: Angreifer erhält Information

12.07.2000

debis IT Security Services

Seite 17

Grundlagen, Forderungen und Marktübersicht für Intrusion Detection Systeme (IDS) und Intrusion Response Systeme (IRS)

Intrusion Detection und Intrusion Response - Grundlagen

Stealth Scanning Die subtilste Möglichkeit, die vorhandenen TCP-Dienste abzutasten, ist das sogenannte Stealth Scanning. Dieses •

ist sehr schwer zu protokollieren,

•

kann Firewall-Schutzmechanismen umgehen (da kein Versuch eines Verbindungsaufbaus stattfindet),

•

ist nicht mittels netstat zu erkennen,

•

besteht aus keiner Stufe des 3-Stufen Verbindungsaufbaus.

Der Angreifer sendet ein FIN-Paket an den Zielport. Der Port ist genau dann inaktiv, wenn der Angreifer ein RST Paket erhält. Das Stealth Scanning ist nur möglich, wenn das Zielsystem auch das zuvor beschriebene Verhalten zeigt. Ist dies nicht der Fall, wie z.B. bei Windows NT, so versagt diese Methode. Ursächlicher Fehler: Designschwäche des TCP-Protokolls Mögliche Schäden: Angreifer erhält Information RPC Stealth Scan Ein Remote Procedure Call (RPC) ist eine Möglichkeit, Prozeduren auf nicht lokalen Rechnern auszuführen. Eine Ansammlung von Prozeduren wird als Programm bezeichnet. Möchte ein Anwender eine bestimmte Prozedur innerhalb eines bestimmten Programms aufrufen, so sendet er dazu eine initiale Anfrage (initial query), die die gewünschte Programmnummer, die gewünschte Prozedurnummer sowie die entsprechenden Argumente etc. enthält, an den Zielrechner. Diese Prozedur wird dann mit den entsprechenden Parametern ausgeführt. Die Prozedurnummer entspricht einem eindeutigen Bezeichner. Es gibt eine Prozedurnummer, zu der es immer eine Prozedur gibt: Prozedur Nr. 0. Möchte ein Angreifer nun herausfinden, welche Programmnummern auf dem Zielsystem aktiv sind, so fragt er sukzessive alle Programmnummern nach der Prozedur 0. Die Prozedur 0 hat keine Argumente und liefert auch keinen Wert zurück. Wenn allerdings der Aufruf an diese Prozedur fehlschlägt, so wird ein Fehlercode übermittelt. Der Angreifer kann so feststellen, ob das entsprechende Programm aktiv ist oder nicht. Zuvor muß jedoch herausgefunden werden, auf welchen Ports RPC läuft. In Abhängigkeit davon, ob RPC basierend auf UDP oder auf TCP implementiert ist (gewöhnlich UDP), wird ein UDP- oder TCP-Port Scan durchgeführt. Sobald ein aktiver Port gefunden wurde, fragt der Angreifer mit Programmnummer i nach Prozedur 0. Falls der Aufruf abgewiesen wird, bekommt der Angreifer eine Fehlermeldung. Falls der Aufruf nicht abgewiesen wird, weiß er, daß auf dem betreffenden Port ein RPC-Dienst mit Programmnummer i horcht. Ursächlicher Fehler: Keiner 12.07.2000

debis IT Security Services

Seite 18

Grundlagen, Forderungen und Marktübersicht für Intrusion Detection Systeme (IDS) und Intrusion Response Systeme (IRS)

Intrusion Detection und Intrusion Response - Grundlagen

Mögliche Schäden: Angreifer erhält Information

2.3.1.2 UDP Port Scans UDP ist ein verbindungsloses Protokoll und besitzt daher – im Gegensatz zu TCP – keine Verbindungsaufbauprozedur. Deshalb gibt es auch keinen sicheren Weg, nach aktiven UDPDiensten zu suchen. Es gibt allerdings eine Möglichkeit nach inaktiven UDP-Ports zu suchen: Ein Rechner, der auf einem bestimmten Port keinen UDP-Dienst anbietet, antwortet mit der Fehlermeldung ICMP Port Unreachable, falls Daten zu dem entsprechenden Port gesendet werden. Von den inaktiven Ports kann der Angreifer nun auf die aktiven schließen. Ursächlicher Fehler: Keiner Mögliche Schäden: Angreifer erhält Information

2.3.1.3 Suche nach verwertbarer Information Jeder der folgenden Dienste liefert dem Angreifer Information über das Angriffsziel, seine Benutzer etc. Die so gewonnene Information kann dazu mißbraucht werden, das Zielsystem zu kompromittieren. Finger, rusers Diese Dienste liefern Information über die momentan aktiven Benutzer eines Systems. Ursächlicher Fehler: Designfehler in der Dienstspezifikation Mögliche Schäden: Angreifer erhält Information Netstat Netstat liefert Netzstatusinformation wie aktuelle geöffnete TCP- oder UDP-Verbindungen. Ein Angreifer kann so leicht feststellen, welche Ports aktiv sind. Ursächlicher Fehler: Designfehler in der Dienstspezifikation Mögliche Schäden: Angreifer erhält Information

Rstatd, sysstat Diese Dienste liefern Information über den aktuellen Ressourcenverbrauch sowie über die momentan aktiven Prozesse einer bestimmten Maschine. 12.07.2000

debis IT Security Services

Seite 19

Grundlagen, Forderungen und Marktübersicht für Intrusion Detection Systeme (IDS) und Intrusion Response Systeme (IRS)

Intrusion Detection und Intrusion Response - Grundlagen

Ursächlicher Fehler: Designfehler in der Dienstspezifikation Mögliche Schäden: Angreifer erhält Information

Identd Dieser Dienst, falls auf einem Client installiert, verschickt bei Bedarf Information darüber, wer einen bestimmten Port benutzt. Wählt ein Benutzer eine bestimmte Webseite, begrüßt ihn das System z.B. mit Hello [email protected] Die Information, wer der Benutzer ist (in diesem Fall der Benutzer user) wurde durch den Server identd des Benutzers angefragt. Ursächlicher Fehler: Designfehler in der Dienstspezifikation Mögliche Schäden: Angreifer erhält Information

Rwho Liefert Information darüber, wer die remote users sind. Ursächlicher Fehler: Designfehler in der Dienstspezifikation Mögliche Schäden: Angreifer erhält Information

Nbstat (nur bei Windows NT) Nbtstat -a nodename oder Nbtstat -A ipaddress liefert Information über •

die zur Zeit aktiven Benutzer,

•

die laufenden Dienste,

•

den NT-Domänennamen,

•

den Namen der Arbeitsstation und

•

die Ethernet Hardware-Adresse.

Darüber hinaus kann auch der Name des Adminstrator-Accounts mittels Nbstat ermittelt werden.

12.07.2000

debis IT Security Services

Seite 20

Grundlagen, Forderungen und Marktübersicht für Intrusion Detection Systeme (IDS) und Intrusion Response Systeme (IRS)

Intrusion Detection und Intrusion Response - Grundlagen

Ursächlicher Fehler: Designfehler in der Dienstspezifikation Mögliche Schäden: Angreifer erhält Information

2.3.2 Angriffe auf unterer Ebene Viele Angriffe werden auf den unteren Protokollebenen des OSI Referenzmodells durchgeführt. Dies hat – zumindest für den Angreifer – häufig den Vorteil, daß auf dieser Ebene nur eine schwache Protokollierung stattfindet. Darüber hinaus setzen bekannte Sicherheitsmechnismen wie Authentisierung erst auf höherer Ebene ein, so daß auf unteren Ebenen nur schwache Sicherheitsmechanismen vorhanden sind.

2.3.2.1 Angriffe auf ARP-Ebene Das Address Resolution Protocol (ARP) wird verwendet, um die Media Access Control MAC-Adresse eines Rechners innerhalb eines Zielnetzes zu ermitteln. Die MAC-Adresse ist die 48-bit lange, weltweit eindeutige Hardwareadresse der Ethernetkarte. Das ARP dient dazu, eine gegebene IP-Adresse in die zugehörige Hardwareadresse umzuwandeln. Falls beispielsweise ein Router ein IP-Paket mit dem Ziel 195.95.23.120 erhält, fragt er mittels eines Broadcasts innerhalb des Zielnetzes: „Wer hat die IP-Adresse 195.95.23.120?“. Nur das entsprechende Gerät meldet sich auf diese Anfrage und antwortet: „Ich habe diese IPAdresse und meine Hardwareadresse (MAC-Adresse) ist 123456.“ Es gibt bei diesem Verfahren eine Schwachstelle: Jeder Host hält in einem lokalen Zwischenspeicher die ihm bekannten Zuordnungen von IP-Adressen zu Hardwareadressen für eine gewisse Zeitspanne vor. Dieser Zwischenspeicher wird nicht nur nach ARPAnfragen (Pull-Technik) überschrieben, sondern kann auch durch eine Push-Technik überschrieben werden: Der Angreifer kann dem Host z.B. alle 20 Minuten eine Nachricht mit dem Inhalt „Das Gerät mit der IP-Adresse 195.95.23.120 bin ich und ich habe die MACAdresse 234567“ senden. Der Host glaubt dies, da auf ARP-Ebene keine Authentisierung stattfindet, und aktualisiert die Information in seinem Zwischenspeicher entsprechend. Dieser Angriff funktioniert nur innerhalb eines Netzsegments, da ARP ein nicht Routingfähiges Protokoll ist. Dennoch sollten die Schäden, die durch einen solchen Angriff entstehen, nicht unterschätzt werden. ARP-Angriffe können Router und Firewalls täuschen. Eine mögliche Schutzmaßnahme gegen ARP-Angriffe besteht darin, den ARPZwischenspeicher als statisch zu konfigurieren. Damit büßt man allerdings die Flexibilität des ARP-Protokolls ein: Jede neue Maschine muß beim Router angemeldet werden. ARP-Angriffe führen mindestens zu einem Denial-of-Service des Angriffsziels, da die Maschine innerhalb des Netzes nicht mehr erreichbar ist. Ursächlicher Fehler: Designfehler im Kommunikationsprotokoll 12.07.2000

debis IT Security Services

Seite 21

Grundlagen, Forderungen und Marktübersicht für Intrusion Detection Systeme (IDS) und Intrusion Response Systeme (IRS)

Intrusion Detection und Intrusion Response - Grundlagen

Mögliche Schäden: Denial-of-Service, Vertraulichkeitsverlust der transportierten Daten, Integritätsverlust der transportierten Daten.

2.3.2.2 Angriffe auf IP-Ebene

IP Fragmentierung Die TCP-Header-Information kann fragmentiert sein, d.h. ein einzelner TCP-Header ist über zwei IP-Datagramme verteilt: das erste Datagramm enthält die Bits 1, 2, ..., (32 + i) und das zweite die Bits (32 + i + 1), ..., END. Router, welche die TCP-Header nach bestimmten Zeichenketten untersuchen, können so überlistet werden. Ist ein Router so konfiguriert, daß er überprüfen soll, ob die Signale SYN = 1 und ACK = 0 sind, so wird er diese Information innerhalb des vierten Worts eines TCP-Headers suchen. Da der Header fragmentiert ist, wird der Router das Paket nicht erkennen. Ursächlicher Fehler: Designfehler im Kommunikationsprotokoll Mögliche Schäden: Zugriff auf Netzressourcen

Reserved Bit Überprüfung eines fragmentierten SYN-Pakets Der Angreifer kann fragmentierte SYN-Pakete versenden, selbst wenn der Paketfilter angewiesen wurde, diese in Verbindung mit einem bestimmten Port nicht durchzulassen. Der Angreifer setzt dazu das Reserved Bit. Grund für dieses seltsame Verhalten ist ein Programmierfehler beim Paketfilter. Dieser Angriff kann Firewall-Komponenten umgehen und so Zugriff auf Daten erlauben, die eigentlich geschützt werden sollten. Ursächlicher Fehler: Designfehler im Kommunikationsprotokoll, Implementierungsfehler. Mögliche Schäden: Zugriff auf Netzressourcen

Falsche IP-Parameter Hierunter fallen eine Reihe von IP-spezifischen Angriffen. Zum Beispiel sind viele Systeme gefährdet, falls sie IP-Pakete erhalten, bei denen Quell- und Zieladresse übereinstimmen. Auch kann ein IP-Paket mit falscher Längenangabe die Implementierung des IP-Stacks des Zielsystems so durcheinanderbringen, daß das komplette Betriebssystem zum Stehen kommt (Ping of Death). Diese Art von Angriffen ist bekannt unter den Namen teardrop, land 12.07.2000

debis IT Security Services

Seite 22

Grundlagen, Forderungen und Marktübersicht für Intrusion Detection Systeme (IDS) und Intrusion Response Systeme (IRS)

Intrusion Detection und Intrusion Response - Grundlagen

attack, bonk usw.3 Ursache für den Erfolg dieser Angriffe sind fehlerhafte TCP/IPImplementierungen. Ursächlicher Fehler: Implementierungsfehler Mögliche Schäden: Denial-of-Service

SYN mit unerreichbarer Quelladresse Der Angreifer sendet ein SYN-Paket an einen bestimmten Port des Angriffsziels und deutet so den gewünschten Verbindungsaufbau an. Das SYN-Paket enthält eine gefälschte und unerreichbare IP-Quelladresse. Der angesprochene Rechner reserviert Speicher für die gewünschte Verbindung und verschickt SYN-ACK um den Verbindungsaufbau positiv zu bestätigen. Da die Quelladresse des ursprünglich gesendeten IP-Pakets nicht erreichbar ist, wartet das Angriffsziel vergebens auf die ACK Bestätigung. Wiederholt man die obige Prozedur sehr schnell hintereinander, alloziert das angegriffene System zu viele Betriebsmittel für nicht zustandekommende Verbindungen und bricht zusammen. Ursächlicher Fehler: Designfehler im Kommunikationsprotokoll Mögliche Schäden: Denial-of-Service

CPU-Angriffe mittels Telnet (nur Windows NT) Der Angreifer stellt eine Telnet-Verbindung zu einem anfälligen Port her (z.B. 53, 135 oder 1031). Er gibt dann ca. 10 beliebige Zeichen ein und bedient die Eingabetaste. Bei dem betroffenen NT System steigt die CPU Auslastung sofort auf 100% und es kommt zu einem de-facto-Stillstand. Abhängig vom betroffenen Port sind auch andere Schäden möglich. Ursächlicher Fehler: Implementierungsfehler Mögliche Schäden: Denial-of-Service

3

Der bislang größte bekanntgewordene Angriff auf Rechner der NASA sowie US-Universitäten wurde Anfang März 1998 durchgeführt. Die betroffenen Betriebssysteme waren Windows 95 und Windows NT. Alle anderen Systeme (Solaris, Linux, Mac OS) zeigten sich als resistent gegen diesen Angriff.

12.07.2000

debis IT Security Services

Seite 23

Grundlagen, Forderungen und Marktübersicht für Intrusion Detection Systeme (IDS) und Intrusion Response Systeme (IRS)

Intrusion Detection und Intrusion Response - Grundlagen

Windows NT Internet Information Server (IIS) Crash Der Angreifer benutzt eine Telnet-Verbindung zu einem Web-Server auf Port 80 und gibt den Befehl GET ../.. ein. Microsofts Internet Information Server bricht augenblicklich zusammen. Ursächlicher Fehler: Implementierungsfehler Mögliche Schäden: Denial-of-Service

2.3.2.3 Angriffe auf ICMP-Ebene Das Internet Control Message Protocol (ICMP) dient zum externen Konfigurieren und Warten von Netzkomponenten. ICMP Clients können auch asynchrone Meldungen senden. Dies wird häufig als ICMP Trap bezeichnet.

ICMP Redirect Ein Bestandteil der ICMP-Spezifikation sind die sogenannten ICMP Redirect Meldungen. Diese verändern die Routing-Tabellen des Zielrechners (ähnlich wie bei RIP in Abschnitt 2.3.2.4). Daten können so abgefangen und ausspioniert werden. Ursächlicher Fehler: Designfehler im Kommunikationsprotokoll Mögliche Schäden: Vertraulichkeitsverlust der übermittelten Daten, Integritätsverlust der übermittelten Daten.

ICMP Destination Unreachable Das ICMP-Protokoll unterstützt Nachrichten des Typs „destination unreachable“ sowie „time to live exceeded“, welche üblicherweise generiert werden, falls ein Rechner nicht oder mit einer bestimmten Anzahl von Sprüngen (hops) nicht erreicht werden kann. Diese Nachrichten können für denial-of-service Angriffe genutzt werden. Es existieren keine Autorisierungsmechanismen zum Versenden solcher Nachrichten, damit kann jeder Quellrechner obige Nachrichten an jeden Zielrechner schicken. Ursächlicher Fehler: Designfehler im Kommunikationsprotokoll Mögliche Schäden: Denial-of-Service

12.07.2000

debis IT Security Services

Seite 24

Grundlagen, Forderungen und Marktübersicht für Intrusion Detection Systeme (IDS) und Intrusion Response Systeme (IRS)

Intrusion Detection und Intrusion Response - Grundlagen

ICMP Echo Request (Ping of Death) Der Angreifer sendet hierbei ICMP Echo Request Pakete (auch PING-Pakete genannt), die eine kritische Größe haben. Das betroffene Zielsystem bricht beim Empfang derartiger Pakete zusammen (Ping of Death). Die meisten ICMP-Implementierungen können nur mit Paketen umgehen, die von der in der Spezifikation geforderten Maximalgröße nicht abweichen. Mit Hilfe entsprechender Programmen ist es möglich, nicht spezifikationsgemäße Ping-Pakete zusammenzubauen. Ursächlicher Fehler: Implementierungsfehler Mögliche Schäden: Denial-of-Service

ICMP-Zeitstempel ICMP sieht die Möglichkeit vor, Zeitstempel anzufordern. Falls eine Authentisierungsmethode sich auf die lokale Uhrzeit eines Rechners verläßt, so kann diese Methode leicht ausgehebelt werden, da die Uhrzeit vom Angreifer mittels eines ICMPZeitstempels angefordert werden kann. Obwohl der Einsatz einer solch schwachen Authentisierung sehr unwahrscheinlich ist, kann die lokale Uhrzeit der Maschine unter Umständen dennoch für Angriffe ausgenutzt werden. Ursächlicher Fehler: Designfehler im Kommunikationsprotokoll Mögliche Schäden: Angreifer gewinnt Information

ICMP-Tunnel Die grundlegende Idee eines ICMP-Tunnels ist es, im Datenfeld eines ICMP Echo Requests Daten unterzubringen, die auf dem Zielsystem von einem Server interpretiert werden. Dies ist natürlich mit jedem anderen Protokoll auch möglich. Das Problem ist lediglich, daß ICMP Echo Request Pakete von Administratoren üblicherweise als relativ unkritisch angesehen und infolgedessen auch nicht gefiltert werden. Unter Verwendung solcher Pakete kann man daher eine Firewall „tunneln”, d.h. trotz aktiver Firewall Daten übermitteln. Allerdings setzt dieser Angriff voraus, daß es dem Angreifer vorher gelungen ist, auf dem Zielrechner einen Server zu installieren, der diese Pakte entgegennimmt und interpretiert. Ursächlicher Fehler: Konfigurationsfehler, Designfehler in der Dienstspezifikation Mögliche Schäden: Zugriff auf Rechnerressourcen, Datenvertraulichkeitsverlust, Datenintegritätsverlust, Verfügbarkeitsverlust, Denial-of-Service.

12.07.2000

debis IT Security Services

Seite 25

Grundlagen, Forderungen und Marktübersicht für Intrusion Detection Systeme (IDS) und Intrusion Response Systeme (IRS)

Intrusion Detection und Intrusion Response - Grundlagen

2.3.2.4 Spoofing Bei Spoofing-Angriffen versucht sich der Angreifer hinter einer falschen Adresse zu verstecken. Spoofing-Angriffe können verschiendene Dienste betreffen. Der anfangs in Abschnitt 2.3.2.1 besprochene ARP-Angriff ist ebenfalls eine Art von Spoofing: Der Angreifer gaukelt dem Router eine falsche Identität vor.

IP Spoofing Hierbei bringt der Angreifer im IP-Header eine falsche Quelladresse unter. Dies entspricht dem Versenden eines Briefs mit falschem Absender. Da auf IP-Ebene keine Authentisierung stattfindet, kann das Zielsystem die Authentizität des Absenders nicht überprüfen. Ursächlicher Fehler: Designfehler im Kommunikationsprotokoll Mögliche Schäden: Zugriff auf Netzressourcen

TCP-Sequenznummernvorhersage Hierbei handelt es sich um einen Angriff, der oft in Kombination mit IP Spoofing ausgeführt wird. Der Angriff wurde 1985 von Robert Morris beschrieben und wird in zwei Schritten ausgeführt: In einem ersten Schritt stellt der Angreifer eine normale Verbindung zum Zielsystem her: Der Angreifer sendet ein SYN-Paket zusammen mit einer Startsequenznummer INS-A. Der Zielrechner antwortet mit einem SYN-Paket mit einer Startsequenznummer INS-Z, gefolgt von einem ACK-Paket mit INS-A (der Startsequenznummer). Der Angreifer wiederum bestätigt dieses mit ACK und INS-Z. In einem zweiten Schritt versucht der Angreifer einen Verbindungsaufbau mit einer gefälschten IP-Adresse, etwa 1.2.3.4. Dazu sendet er ein SYN-Paket mit der Startsequenznummer INS-A‘ an das Zielsystem. Das Zielsystem antwortet nun mit den Paketen (SYN, INS-Z‘) und (ACK, INS-A‘). Allerdings schickt das Zielsystem diese Daten an die Adresse 1.2.3.4. Die Taktik des Angreifers ist es nun, zu antworten, bevor 1.2.3.4 antwortet. Dazu startet der Angreifer gleichzeitig einen SYN Denial-of-Service Angriff gegen 1.2.3.4, um diesen „mundtot“ zu machen. Um korrekt zu antworten, muß der Angreifer INS-Z‘ kennen. Der Wert dieser Zahl basiert auf •

dem Wert INS-Z der vorherigen normalen Verbindung und

•

dem Zeitintervall zwischen letzter und neuer Verbindung.

12.07.2000

debis IT Security Services

Seite 26

Grundlagen, Forderungen und Marktübersicht für Intrusion Detection Systeme (IDS) und Intrusion Response Systeme (IRS)

Intrusion Detection und Intrusion Response - Grundlagen

Da der Angreifer INS-Z und das Zeitintervall kennt, wird die Anzahl der möglichen Werte für den zu ratenden Wert INS-Z‘ zumindest so eingeschränkt, daß der Angreifer sukzessive alle möglichen Werte durchprobieren kann. ACK Pakete mit falschem INS-Z‘ Wert werden vom Zielsystem verworfen. Ursächlicher Fehler: Designfehler im Kommunikationsprotokoll Mögliche Schäden: Zugriff auf Rechnerressourcen

DNS Spoofing Dieser Angriff erfolgt in zwei Schritten: •

Im ersten Schritt stellt der Angreifer angreifer.com eine rekursive Anfrage an einen Name-Server nameserver.com (er fragt nach der zugehörigen IP-Adresse von angreifer.com), um eine sogenannte Query-ID zu erhalten. Die Rolle dieser Query-ID ist vergleichbar mit der Startsequenznummer beim TCPSequenznummernangriff. Der Name-Server schlägt die IP-Adresse von angreifer.com nach und sendet diese zusammen mit der Query-ID an den fragenden Rechner (in diesem Fall an den Angreifer). Der Angreifer weiß, daß die Query-ID nach jeder Anfrage um 1 erhöht wird. Startet er nochmals eine Anfrage, hat er gute Chancen, die dabei vergebene Query-ID vorher zu erraten.

•

Im zweiten Schritt des Angriffs fragt angreifer.com den Name-Server nameserver.com nach der IP-Adresse von www.opfer.com. Da nameserver.com diese nicht kennt (dies läßt sich durch eine geeignete Wahl des Name-Servers erreichen), versucht nameserver.com, sie bei dem zuständigen Name-Server nachzuschlagen (dieser Name-Server könnte beispielsweise nameserver.opfer.com heißen). Bevor jedoch nameserver.opfer.com antworten kann, imitiert angreifer.com diese Antwort und gibt so seine eigene IPAdresse gegenüber nameserver.com als die von www.opfer.com aus. Dazu muß er lediglich die Query-ID erraten, die nameserver.com benutzt, um bei nameserver.opfer.com nachzufragen. Diese kann er jedoch – mit den Informationen aus dem ersten Schritt – leicht erraten. Wenn der Angreifer es schafft, mit der richtigen Query-ID zu antworten, bevor nameserver.opfer.com antwortet, wird die spätere Antwort von nameserver.opfer.com von nameserver.com einfach verworfen.

Der Angreifer hat es nun geschafft, den DNS-Cache von nameserver.com zu verunreinigen. Jede Anfrage nach www.opfer.com wird nun an angreifer.com geleitet. Ursächlicher Fehler: Designfehler in der Dienstspezifikation Mögliche Schäden: Datenvertraulichkeitsverlust während des Transports, Datenechtheitsverlust 12.07.2000

debis IT Security Services

Seite 27

Grundlagen, Forderungen und Marktübersicht für Intrusion Detection Systeme (IDS) und Intrusion Response Systeme (IRS)

Intrusion Detection und Intrusion Response - Grundlagen

RIP Spoofing Das Routing Information Protokoll (RIP, RFC 1058) wird unter anderem dazu benutzt, die Routing-Tabellen eines Rechner oder Routers auf dem aktuellen Stand zu halten. Normalerweise werden diese Tabellen alle 30 Sekunden aktualisiert. Dabei sendet ein Router seine Tabellen mittels Broadcasts an alle benachbarten Router. Bei diesem Vorgang findet keine Authentisierung statt; die Router glauben dieser Information blind. Ein „RIP Spoofing“-Angriff kann zwei Typen von Schäden nach sich ziehen: •

Das an den angegriffenen Router angeschlossene Netz verliert seine Verbindungen; es kommt zum Denial-of-Service.

•

Daten, die für das lokale Netz bestimmt sind, können durch den Angreifer umgeleitet werden. Er kann die Daten mitlesen oder sie sogar verfälschen.

Ursächlicher Fehler: Designfehler im Kommunikationsprotokoll Mögliche Schäden: Denial-of-Service, Datenintegritätsverlust während des Transports, Datenvertraulichkeitsverlust während des Transports.

2.3.2.5 Source Routing Der Initiator einer TCP/IP Verbindung kann den Routing-Mechanismus dazu veranlassen, die Pakete über eine vordefinierte Strecke zu schicken. Gemäß RFC 1122 müssen die Antwortpakete des Zielrechners dieselbe Strecke in umgekehrter Richtung durchlaufen. Wählt der Angreifer als Quelladresse die Adresse eines vom Opfer als vertrauenswürdig angesehenen Rechners (trusted host) und aktiviert Source-Routing über seine eigene IPAdresse, so kann er sich damit alle Rechte des als vertrauenswürdig angesehenen Rechners erschleichen. Auch ein Umgehen von Firewall-Systemen ist so möglich. Ursächlicher Fehler: Designfehler im Kommunikationsprotokoll Mögliche Schäden: Datenintegritätsverlust Datenvertraulichkeitsverlust während des Transports.

während

des

Transports

,

2.3.2.6 Session Hijacking Hierbei übernimmt der Angreifer eine bestehende Verbindung. Eine bestehende Verbindung kann einen sogenannten nicht-synchronisierten Zustand einnehmen, in dem die beiden Rechner noch immer verbunden sind, aber keine Daten mehr ausgetauscht werden können.

12.07.2000

debis IT Security Services

Seite 28

Grundlagen, Forderungen und Marktübersicht für Intrusion Detection Systeme (IDS) und Intrusion Response Systeme (IRS)

Intrusion Detection und Intrusion Response - Grundlagen

Ziel des Angreifers ist es zunächst, einen nicht-synchronisierten Zustand herzustellen. Der Angreifer versucht dann, den beiden ursprünglichen Kommunikationsteilnehmern protokollkonforme Pakete unterzuschieben, so daß diese akzeptiert werden. Bei einer Telnet-Verbindung kann der Angreifer zum Beispiel ein ls –al Kommando durch rm –r * ersetzen. Session Hijacking ist ein sehr technischer Angriff. Allerdings sind in letzter Zeit Werkzeuge wie Juggernaut aufgetaucht, die von Jedermann ohne technische Detailkenntnis benutzt werden können. Ursächlicher Fehler: Designfehler im Kommunikationsprotokoll Möglicher Schaden: Zugriff auf Rechnerressourcen

2.3.2.7 Überfluten (Flooding) Beim sog. Flooding wird das Opfer mit Daten überflutet. Ursache für die Wirksamkeit des Angriffs sind meistens Konfigurationsfehler oder auch Schwächen im Selbstschutz der Systemkomponenten. Ursächlicher Fehler: Designfehler in allen Varianten, Konfigurationsfehler Mögliche Schäden: Denial-of-Service

Überflutung mittels E-Mail (Mail Flooding) Hierbei versendet der Angreifer große Datenmengen per E-Mail. Das Empfangssystem bricht unter großen Datenmenge zusammen: Das Spool-Verzeichnis ist voll oder es treten andere Überlastungen auf. Ursächlicher Fehler: Keiner, Konfigurationsfehler Mögliche Schäden: Denial-of-Service

SYN-Überflutung (SYN Flooding) Der Angreifer gibt vor, eine TCP-Verbindung aufbauen zu wollen, und sendet ein SYNPaket. Das Zielsystem reserviert für diese Verbindung Betriebsmittel und antwortet mit SYN/ACK; dann wartet es auf das ACK des Angreifers. Der Angreifer sendet dieses ACK jedoch nicht, sondern versucht, eine weitere Verbindung aufzubauen, indem er die obige Prozedur wiederholt. 12.07.2000

debis IT Security Services

Seite 29

Grundlagen, Forderungen und Marktübersicht für Intrusion Detection Systeme (IDS) und Intrusion Response Systeme (IRS)

Intrusion Detection und Intrusion Response - Grundlagen

Das angegriffene System alloziert nach und nach so viele Betriebsmittel, bis keine Ressourcen mehr zur Verfügung stehen und die Dienste gar nicht mehr oder nur noch sehr schleppend ausgeführt werden können Ursächlicher Fehler: Designfehler im Kommunikationsprotokoll Mögliche Schäden: Denial-of-Service

Überfluten des System-Log (System Log Flooding) Der Angreifer versucht, vor seinem eigentlichen Angriff den Protokollmechanismus des Zielsystems auszuschalten. Dazu führt er Aktionen durch, von denen er weiß, daß sie protokolliert werden und große Protokolldatenmengen erzeugen. Dadurch läuft der Protokollspeicher voll und der Protokollmechanismus wird bei schlechter Konfiguration ausgeschaltet. Ursächlicher Fehler: Keiner, Konfigurationsfehler Mögliche Schäden: Denial-of-Service

Überflutung mit Daten (Data Flooding) Dies ist eine generische Beschreibung aller Angriffstechniken, bei denen der Angreifer dem Zielsystem große Datenmengen schickt, die dann von ihm nicht mehr korrekt bearbeitet werden können. Ursächlicher Fehler: Keiner Mögliche Schäden: Denial-of-Service

Überflutung mit Open/Close Anfragen (Open/Close Flood) Durch das schnelle Öffnen oder Schließen von Verbindungen kann der Angreifer einige Dienste zum Zusammenbruch bringen. Ursächlicher Fehler: Keiner Mögliche Schäden: Denial-of-Service

12.07.2000

debis IT Security Services

Seite 30

Grundlagen, Forderungen und Marktübersicht für Intrusion Detection Systeme (IDS) und Intrusion Response Systeme (IRS)

Intrusion Detection und Intrusion Response - Grundlagen

2.3.2.8 Angriffe durch Kapseln und Tunnelangriffe (Encapsulation/Tunneling) Der Angreifer kann im Datenfeld fast jedes Transportprotokolls Daten unterbringen, die auf der Empfangsseite interpretiert werden. So kann zum Beispiel Apple-Talk durch IP getunnelt werden (wie auch bei Apple-Talk 5.0 geschehen). Natürlich kann auch IP in IP gekapselt und so getunnelt werden. Es ist durchaus üblich und häufig sogar wünschenswert, daß Protokolle getunnelt werden. Beispiele sind: •

AppleTalk

•

IPX

•

IP selber

Der Grund für den Erfolg von Tunnelangriffen liegt in der Tatsache, daß Router und Firewalls die im Datenfeld stehenden Daten häufig nicht überwachen. Die indirekten Folgen können sein: •

Vertraulichkeitsverlust der zu transportierenden Daten

•

Integritätsverlust der zu transportierenden Daten

•

Umgehen von Security Gateways, z.B. Firewalls

Ursächlicher Fehler: Konfigurationsfehler Mögliche Schäden: Zugriff auf Rechner- und Netzressourcen

2.3.3 Angriffe auf mittlerer Ebene Im folgenden Abschnitt werden Angriffe gegen Dienste und Mechanismen auf Stufe 7 des OSI-Referenzmodells beschrieben. Obwohl dies die höchste Stufe in diesem Datenkommunikationsmodell ist, handelt es sich hierbei bezüglich der IDS Analyse um die mittlere Ebene des vorgestellten dreistufigen Service-Modells.

2.3.3.1 DNS-Angriffe Es gibt verschiedene Angriffe auf den Domain Name Service (DNS). Viele von ihnen nutzen die Tatsache aus, daß ein DNS-Server nicht überprüfen kann, von welcher Gegenstelle er Information über die Namensumsetzung erhält. Dieses Problem ist vergleichbar mit dem bereits vorgestellten ARP Spoofing (Abschnitt 2.3.2.1). Falls ein DNS Server A beim Server B einen Namen oder eine Adresse erfragt, so ist er in der Regel auch bereit, Information entgegen zu nehmen, nach der er nicht explizit gefragt hat. Zum Beispiel wäre folgender Ablauf möglich: A:

Wie lautet die IP-Adresse von www.yahoo.com?

12.07.2000

debis IT Security Services

Seite 31

Grundlagen, Forderungen und Marktübersicht für Intrusion Detection Systeme (IDS) und Intrusion Response Systeme (IRS)

Intrusion Detection und Intrusion Response - Grundlagen

B:

Die Adresse ist 204.71.177.72. Außerdem ist die IP-Adresse supergeheim.com dieselbe wie die von www.böse-menschen.org.

A:

.

von

DNS-Cache-Verunreinigung Bei der DNS-Cache-Verunreinigung (Cache Poisoning) wird im Alias-Feld eines Datensatzes (d.h. im CNAME Feld) falsche Information eingetragen. Das Feld üblicherweise dazu, einen Rechner mit unaussprechlichem Namen hkj7353.provider.de) unter einem leichter zu merkenden Namen www.provider.de) anzusprechen. Beispiel:

DNSdient (etwa (etwa

skstw@merlin: > host -t cname www.provider.de www.provider.de is a nickname for hkj7353.provider.de Ein Angreifer kann nun seinen DNS-Server so abändern, daß supergeheim.org ein Spitzname für unvertraulich.angreifer.org ist. Ursächlicher Fehler: Designfehler in der Dienstspezifikation Mögliche Schäden: Authentizitätsverlust.

Vertraulichkeitsverlust

(für

die

im

Cache

liegenden

Daten),

DNS Spoofing Dieser Angriff ist bereits in Abschnitt 2.3.2.4 beschrieben worden.

Reverse Lookup Das sogenannte Reverse Lookup ermöglicht es einem System, welches DNS-Anfragen stellt (DNS-Client), zwei komplementäre Anfragen zu stellen und die Antworten auf Konsistenz zu prüfen. Ein System kann so nicht nur erfragen, daß beispiel.de die IP-Adresse 1.2.3.4 hat, sondern sich zusätzlich vergewissern, daß der Rechner mit der IP-Adresse 1.2.3.4 den Namen beispiel.de besitzt. Dies gibt dem DNS-Client zusätzliche Sicherheit. Findet ein Angreifer heraus, daß ein Rechner kein Reverse Lookup durchführt, so kann er diesem Rechner leichter eine gefälschte DNS-Antwort unterschieben. Ursächlicher Fehler: Konfigurationsfehler 12.07.2000

debis IT Security Services

Seite 32

Grundlagen, Forderungen und Marktübersicht für Intrusion Detection Systeme (IDS) und Intrusion Response Systeme (IRS)

Intrusion Detection und Intrusion Response - Grundlagen

Mögliche Schäden: Datenechtheitsverlust

2.3.3.2 Network Information System (NIS) Das Network Information System (NIS) ist ein RPC-basierter Dienst (Remote Procedure Call). Da NIS keine Authentisierung auf RPC-Ebene durchführt, kann sich eine beliebige Maschine mittels eines gefälschten RPC leicht gegenüber einem Opfer als RPC-Server ausgeben. Hierbei handelt es sich im weiteren Sinne wieder um einen Spoofing-Angriff. Der Angriff verläuft nun ähnlich wie IP Spoofing, ist aber sogar noch einfacher durchzuführen, da die meisten RPC-Implementierungen auf dem Protokoll UDP basieren: Der NIS-Client sendet eine RPC-Anfrage an den NIS-Server. Der Angreifer erstellt eine gefälschte RPC-Antwort, bevor der Server antworten kann. Solch eine gefälschte Antwort kann beispielsweise die NIS-Adreßtabellen ändern. Indem man in der hosts.byaddrAbbildung eine Maschine aus der Datei .rhosts des Opfers durch den Namen der angreifenden Maschine ersetzt, kann der Angreifer mittels rlogin oder rsh Zugriff auf den NIS-Client erhalten. Ursächlicher Fehler: Designfehler in der Dienstspezifikation Mögliche Schäden: Zugriff auf Rechnerressourcen

2.3.3.3 FTP Aktiver / Passiver FTP-Angriff Es gibt zwei Angriffsmethoden auf das File-Transfer-Protokoll (FTP), durch die ein Angreifer die zu übertragenden Daten abfangen kann. Die verwendete Methode ist davon abhängig, ob der FTP-Server im aktiven oder passiven Modus betrieben wird. Entsprechend unterscheidet man aktive und passive Angriffe. Beide Angriffsarten kontaktieren in einem ersten Schritt den Server. In einem zweiten Schritt wird dann der Port ausgehandelt, über den der Datei-Transfer abgewickelt werden soll; hierbei unterscheidet man die Angriffe: •

Aktive Betriebsart: Der Client horcht auf einem nicht priviligierten TCP-Port und teilt dem Server diese Port-Nummer mit. Der Server öffnet eine Verbindung von seinem Port 20 (Standard-FTP-Port) zu dem entsprechenden Port des Clients.

•

Passive Betriebsart: Der Client teilt dem Server mit, daß er zum Datentransfer bereit ist. Der Server wartet auf einem nicht privilegiertem Port und teilt dem Client diese Port-Nummer mit. Zur Datenübertragung öffnet der Client eine Verbindung zu dem entsprechenden Server-Port.

12.07.2000

debis IT Security Services

Seite 33

Grundlagen, Forderungen und Marktübersicht für Intrusion Detection Systeme (IDS) und Intrusion Response Systeme (IRS)

Intrusion Detection und Intrusion Response - Grundlagen

Ein Angreifer nutzt nun die Tatsache aus, daß niemand überprüft, ob das Paar (Client, Server) aus Schritt 1 noch dasselbe ist wie in Schritt 2. Im passiven Modus kann der Angreifer nun versuchen, die Port-Nummer auf der Server-Seite zu erraten. Hat er sie erraten, öffnet er genau wie der richtige Client eine Verbindung zu diesem Port. Der Server merkt nicht, daß hier Daten an zwei Clients über denselben Port geschickt werden, obwohl sich nur einer in Schritt 1 angemeldet hat. Die Port-Nummer ist leicht zu erraten. Dazu öffnet der Angreifer eine gewöhnliche FTPVerbindung und erfährt so die Port-Nummer des Datenkanals auf dem Server. Diese PortNummern werden gewöhnlich in direkt aufsteigender Reihenfolge vergeben, so daß die nächsten zu verwendenden Port-Nummern leicht zu erraten sind. Ein ähnlicher Angriff ist auch im aktiven Modus durchführbar. Ursächlicher Fehler: Designfehler in der Dienstspezifikation Mögliche Schäden: Datenechtheitsverlust, Datenvertraulichkeitsverlust auf Rechner

Brute-Force Angriffe Neben den oben genannten Angriffen gibt es auch Brute-Force Angriffe auf FTP: •

Paßwortangriff: FTP verlangt eine Authentisierung des Nutzers auf der Basis eines Nutzernamens und eines Paßworts. Durch erschöpfende Suche oder sogenannte Paßwort-Cracker kann dieser Mechanismus kompromittiert werden (vgl. Abschnitt 2.3.5 ).

•

Anonymes FTP: Ein Gastbenutzer (Benutzername: anonymous) kann versehentlich falsche Benutzerrechte erhalten. z.B. kann das ftpWurzelverzeichnis für alle beschreibbar sein und ein FTP-Gastbenutzer kann den Befehl put .rhosts absetzen und so Zugriff auf die Maschine erhalten.

•

TFTP kann dazu benutzt werden /etc/passwd zu übertragen.

Ursächlicher Fehler: Designfehler in der Anwendung, Konfigurationsfehler Mögliche Schäden: Zugriff auf Rechnerressourcen, Datenvertraulichkeitsverlust auf Rechner, Datenintegritätsverlust auf Rechner

2.3.3.4 HTTP Obwohl das Hypertext Transfer Protocol (HTTP) keine bekannten Schwächen hat, gibt es doch einige Möglichkeiten den httpd-Dämon mißbräuchlich zu nutzen. So kann zum Beispiel der Paßwort-Autorisierungsmechanismus durch zusätzliche Schrägstriche in der 12.07.2000

debis IT Security Services

Seite 34

Grundlagen, Forderungen und Marktübersicht für Intrusion Detection Systeme (IDS) und Intrusion Response Systeme (IRS)

Intrusion Detection und Intrusion Response - Grundlagen

URL überwunden werden: http://www.host.de//secret.html. (vgl. auch Abschnitt 2.3.5). Ursächlicher Fehler: Designfehler in der Anwendung, Implementierungsfehler Mögliche Schäden: Datenvertraulichkeitsverlust auf Rechner

2.3.3.5 X11 Eine X11 Sitzung kann, wie unter 2.3.2.6 beschrieben, mittels Session Hijacking übernommen werden. Der Bildschirm einer X11 Sitzung kann von einem Angreifer aus den internen Netz auch kopiert werden. Dazu wird das Kommando xwd benutzt, welches den Bildschirminhalt in eine Datei schreibt, die sich der Angreifer anschließend mittels xwud anschauen kann. Ein Beispiel für ein solche Sitzung verläuft folgendermaßen: $ rlogin target $ xwd -root -display localhost:0.0 > ~/picfile.xwd $ setenv DISPLAY ineptiae:0.0 $ xwud -in ~/picfile.xwd Ursächlicher Fehler: Konfigurationsfehler Mögliche Schäden: Datenvertraulichkeitsverlust auf Rechner (der auf dem Bildschirm sichtbaren Daten)

2.3.3.6 SMB Crash (nur Windows NT) Schickt man einem Windows NT 3.5 oder NT 3.51 Rechner von einem Samba SMB-Client den Befehl DIR ..\, so erscheint der sogenannte Blue Screen of Death (Rechnerabsturz) . Der Fehler wird durch einen zerstörten Heap in srv.sys ausgelöst. Ursächlicher Fehler: Implementierungsfehler Mögliche Schäden: Denial-of-Service

12.07.2000

debis IT Security Services

Seite 35

Grundlagen, Forderungen und Marktübersicht für Intrusion Detection Systeme (IDS) und Intrusion Response Systeme (IRS)

Intrusion Detection und Intrusion Response - Grundlagen

2.3.3.7 Network File System (NFS) Das Network File System (NFS) hat einige inhärente Sicherheitsschwachstellen. Falls ein Dateisystem angemeldet wird, überprüft der mountd-Dämon, ob der Client die notwendigen Rechte besitzt, und exportiert das Dateisystem, indem er ein sogenanntes file-handle an den Client sendet. Dieses file-handle, auch magic-cookie genannt, ist eine Pseudozufallszahl, welche für die Authentisierung benutzt wird. Folgende Sicherheitsprobleme können auftreten: •

Das file-handle kann geraten werden.

•

Solange der Client ein korrektes file-handle besitzt, kann er auf die exportierten Dateisysteme gemäß der Unix-Dateizugriffsrechte zugreifen. Es gibt keinen Mechanismus, der den Client dazu zwingt, nach einer unmount-Operation ein neues file-handle zu beantragen. Das file-handle ist solange gültig, bis das Dateisystem des Servers reinstalliert wird. Es gibt keine Möglichkeit, ein file-handle für ungültig zu erklären.

•

Die Authentisierung während des mount-Prozesses basiert einzig auf der IP-Adresse des Clients, die jedoch gefälscht sein kann (IP Spoofing, vgl. Abschnitt 2.3.2.4).

•

Nachdem das Dateisystem angemeldet wurde, hat jeder Rechner mit einem korrekten file-handle Zugriff auf das Dateisystem.

Andere im Zusammenhang mit NFS zu nennenden Fehler sind: •

Falls die export-Liste mehr als 255 Zeichen enthält, kommt es zu einem Pufferüberlauf und ein Zugriffsschutz für das Dateisystem ist nicht mehr gegeben.

•

Ältere mountd-Dämonen erlauben es, mittels des Kommandos cd.. bis zum Wurzelverzeichnis eines nicht exportierten Dateisystems vorzudringen.

•

Ältere portmapper können mountd dazu veranlassen, Dateisysteme auch solchen Rechnern zur Verfügung zu stellen, die nicht in der /etc/exports-Liste aufgeführt sind („RPC mount vulnerability”).

Ursächlicher Fehler: Designfehler in der Dienstspezifikation, Designfehler in der Anwendung, Implementierungsfehler Mögliche Schäden: Datenintegritätsverlust, Verfügbarkeitsverlust, Datenvertraulichkeitsverlust

2.3.4 Angriffe auf hoher Ebene (Anwendungsebene) Angriffe auf Anwendungsebene nutzen zumeist bekannte Implementierungsfehler einer Anwendung aus. Im folgenden werden Beispiele für diesen Angriffstyp angegeben.

12.07.2000

debis IT Security Services

Seite 36

Grundlagen, Forderungen und Marktübersicht für Intrusion Detection Systeme (IDS) und Intrusion Response Systeme (IRS)

Intrusion Detection und Intrusion Response - Grundlagen

2.3.4.1 Sendmail Die Sendmail-Anwendung stellt den SMTP (Simple Mail Transfer Protocol)-Dienst zur Verfügung und ist üblicherweise Bestandteil eines jeden Unix-Systems. Sendmail ist dafür bekannt, daß es viele Implementierungsfehler besaß, die häufig von alten Versionen weitervererbt wurden. Das Hauptproblem besteht darin, daß Sendmail mit root-Berechtigung läuft. Angriffe auf Sendmail führen häufig dazu, daß der Angreifer root-Rechte erlangt. Ursächlicher Fehler: Implementierungsfehler, Designfehler in der Anwendung Mögliche Schäden: Zugriff auf Rechnerressourcen

2.3.4.2 Mail Spoofing Ein Benutzer kann sich an Port 25 anmelden (beispielsweise mittels mconnect victim.com oder telnet victim.com 25) und so direkt mit dem SMTP-Server kommunizieren. Er kann dann E-Mail-Nachrichten unter beliebigem Namen absenden. Ursächlicher Fehler: Designschwäche des Kommunikationsprotokolls Mögliche Schäden: Datenechtheitsverlust

2.3.4.3 Überflutung mittels des finger-Dienstes (Finger Flooding) Einige Implementierungen des finger-Dienstes erlauben es, rekursive Anfragen zu stellen, die dazu führen können, daß das System zu viele Betriebsmittel verbraucht und es zum Einstellen der Dienste kommt (Denial-of-Service). Ursächlicher Fehler: Designschwäche der Dienstspezifikation Mögliche Schäden: Denial-of-Service

2.3.4.4 Verteilter, koordinierter Angriff Ein Angreifer erstellt eine Webseite, die Code enthält, welcher beispielsweise den TelnetPort eines bestimmten Rechners angreift. Falls auf diese Seite innerhalb kurzer Zeit häufig zugegriffen wird, so attackiert jeder Benutzer – absichtlich oder unbeabsichtigt – den betreffenden Rechner. Dies kann zum Einstellen der Dienste auf diesem Rechner führen. Ursächlicher Fehler: Designschwäche der Dienstspezifikation Mögliche Schäden: Denial-of-Service 12.07.2000

debis IT Security Services

Seite 37

Grundlagen, Forderungen und Marktübersicht für Intrusion Detection Systeme (IDS) und Intrusion Response Systeme (IRS)

Intrusion Detection und Intrusion Response - Grundlagen

2.3.5 Angriffe auf das Authentisierungssystem Alle Anwendungen, bei denen im Zuge der Online-Authentisierung Paßwörter im Klartext übermittelt werden, sind bei den folgenden Angriffen gefährdet. Ein erfolgreicher Angriff auf ein Paßwort-Schutzmechanismus kann dazu führen, daß der Angreifer Zutritt zum zu schützenden System erhält.

2.3.5.1 Lauschangriff Paßwörter, die im Klartext über das Netz versendet werden, können leicht abgehört werden. Dies ist im Falle von Broadcast-Netzen besonders gefährlich. Das Lauschen am Netz kann sich jedem Protokollierungsmechanismus entziehen und bleibt somit unentdeckt. Ursächlicher Fehler: Designschwäche des Kommunikationsprotokolls Mögliche Schäden: Zugriff auf Rechnerressourcen

2.3.5.2 Erraten von Paßwörtern Paßwortgeschützte Authentisierungsmechanismen sind häufig Ziel von Angriffen, die mittels eines elektronischen Wörterbuchs ausgeführt werden. Der Angreifer versucht mittels erschöpfender Suche das richtige Paßwort zu finden. Grund für den Erfolg eines solchen Angriffs sind zumeist schwach gewählte Paßwörter. Ursächlicher Fehler: Fehlverhalten der Benutzer Mögliche Schäden: Zugriff auf Rechnerressourcen

2.3.5.3 Unerlaubtes Löschen von Dateien (nur Windows NT) Legt ein Benutzer unter Windows NT eine Datei auf einem Server an und entfernt anschließend alle Zugriffsrechte, so kann trotzdem jeder diese Datei löschen. Ursächlicher Fehler: Implementierungsfehler Mögliche Schäden: Datenintegritätsverlust auf Rechner

12.07.2000

debis IT Security Services

Seite 38

Grundlagen, Forderungen und Marktübersicht für Intrusion Detection Systeme (IDS) und Intrusion Response Systeme (IRS)

Intrusion Detection und Intrusion Response - Grundlagen

2.3.5.4 Microsoft Dot Dot Bug (nur Windows NT) Durch Eingabe einer URL in einem Format wie http://www.geheim.de/..\.. kann der Angreifer Dateien lesen, die oberhalb des WWW-Wurzelverzeichnisses liegen. Darüber hinaus kann ein Angreifer auf diese Weise auch Skripten ausführen: http://www.geheim.de/geheimeSkripten..\..\scriptname.

2.3.6 Import von kompromittierendem Code Es gibt verschiedene Formen von kompromittierendem Code. Der dadurch entstehende Schaden hängt von der Funktionalität des Codes im Einzelfall ab.

2.3.6.1 Viren Unter einem Virus versteht man ein sich selbst replizierendes Programm. Viren sind häufig in sogenannten trojanischen Pferden (s.u.) versteckt und/oder enthalten Information darüber, wann sie Schaden anrichten sollen (Zeitbombeneffekt). Ein Virus nistet sich bei einem Wirtprogramm ein (z.B. TeX) oder setzt sich im Bootsektor fest. Es ist darüber hinaus in der Lage, Kopien von sich in anderen Programmen unterzubringen und diese Programme so zu infizieren. Ein Virus hat typischerweise ein bestimmtes Muster (Codesequenz), anhand dessen es identifiziert werden kann. Man unterscheidet zwei Arten von Viren: transiente Viren und residente Viren. Die Codeausführung eines transienten Virus‘ wird beendet, sobald sein Wirtprogramm beendet wird. Ein residentes Virus kann über die Beendigung des Wirtprogramms hinaus im Speicher verweilen und aktiv sein. Da das Virus mit denselben Benutzerrechten wie sein Wirt läuft, ist es häufig auch im Besitz der notwendigen Rechte, um Dateien zu löschen, anzulegen etc. Sollte der Benutzer besondere Rechte haben (root), so kann das Virus auch für andere Benutzer Schaden anrichten. Ursächlicher Fehler: Benutzerfehlverhalten, Konfigurationsfehler Mögliche Schäden: Datenintegritätsverlust auf Rechner, Datenvertraulichkeitsverlust auf Rechner, Verlust der Verfügbarkeit, Denial-of-Service.

2.3.6.2 Trojanische Pferde Unter einem trojanischen Pferd versteht man ein Programm, welches unerwartete Funktionalität hat. Dies kann zum Beispiel eine login-Prozedur sein, die alle verarbeiteten Paßwörter sammelt und an einen Angreifer weiterleitet. 12.07.2000

debis IT Security Services

Seite 39

Grundlagen, Forderungen und Marktübersicht für Intrusion Detection Systeme (IDS) und Intrusion Response Systeme (IRS)

Intrusion Detection und Intrusion Response - Grundlagen

Ursächlicher Fehler: Benutzerfehlverhalten, (absichtlicher) Programmierfehler Mögliche Schäden: Zugriff auf Rechner

2.3.6.3 Würmer Ein Wurm ist ein Programm, welches Kopien seiner selbst über ein Netz propagiert. Im Gegensatz zu einem Virus, das stets von einem Wirt abhängig ist, ist ein Wurm ein eigenständiges Programm. Um von einem Ziel zum nächsten innerhalb eines Netzes zu gelangen, mißbraucht ein Wurm eine Systemschwäche (z.B. das berühmte sendmaildebug-Sicherheitsloch). Ursächlicher Fehler: andere Sicherheitslücken Mögliche Schäden: Zugriff auf Rechnerressourcen, Denial-of-Service, Datenintegritätsverlust auf Rechner, Datenvertraulichkeitsverlust auf Rechner,

2.3.6.4 Falltüren (Trapdoors) Eine Falltür (auch Hintertür genannt) ist eine zusätzliche Eigenschaft eines Programms, mit deren Hilfe Sicherheitsmechanismen überwunden werden können (sendmails debug beispielsweise). Hat ein Angreifer eine Falltür gefunden, so kann er in den Besitz zusätzlicher Rechte gelangen. Ursächlicher Fehler: absichtliche Designfehler aller Arten Mögliche Schäden: Zugriff auf Rechnerressourcen

2.3.7 Probleme im Zusammenhang mit dem Word-Wide-Web (WWW) Das Internet und die daran angeschlossenen firmeninternen Netze (Intranets) entwickeln sich rasch von ihren Ursprüngen als Plattform für statische HTML-Anwendungen weiter. Hyptertext-Informationssysteme wie z.B. Web-Browser stellen neue Sicherheitsrisiken dar. Diese Risiken basieren häufig auf fehlerhaftem Design sowie fehlerhafter Implementierung. Browser bieten die Möglichkeit, Programme aus dem Internet herunter zu laden und auf dem lokalen Rechner ablaufen zu lassen (beispielsweise Java-Applets bzw. Java-Programme oder auch in Java Script oder ActiveX geschriebene Anwendungen bzw. Anwendungsteile). Benutzer begegnen fremden Programmen häufig mit erstaunlich großem Vertrauen und unterschätzen das von diesen ausgehende Risiko. Darüber hinaus kann z.B. auch die Java Virtual Machine (vgl. Abschnitt 2.3.7.1) einen Fehler haben, der von heruntergeladenen Applikationen ausgenutzt wird. 12.07.2000

debis IT Security Services

Seite 40

Grundlagen, Forderungen und Marktübersicht für Intrusion Detection Systeme (IDS) und Intrusion Response Systeme (IRS)

Intrusion Detection und Intrusion Response - Grundlagen

Die folgenden Angriffe zeigen die Risiken beim Einsatz moderner Web-Technologien.

2.3.7.1 Java Java ist eine Programmiersprache, die mit C++ vergleichbar ist, aber auf die in C++ möglichen Zeigeroperationen verzichtet. Der wesentliche Vorteil von Java besteht darin, daß Java-Anwendungen auf jedem Rechner ablauffähig sind, der über eine entsprechende Laufzeitumgebung – die sogenannte Java Virtual Machine – verfügt. Unabhängig davon, ob man sich Java-Applets, Java-Skripten oder Java-Applikationen aus dem Netz lädt, birgt die Ausführung dieser Programme stets ein Sicherheitsrisiko. Dies gilt nicht nur für PCs, sondern auch für Unix-Systeme, da unter Umständen die Java Virtual Machine fehlerhaft sein kann und die Programme diese Fehler ausnutzen. Ursächlicher Fehler: Implementierungsfehler, Designfehler in der Anwendung Mögliche Schäden: Zugriff auf Rechnerressourcen

2.3.7.2 Cookies Die folgende Passage wurde den WWW Security FAQs entnommen A „cookie“ is a mechanism developed by the Netscape Corporation to make up for the stateless nature of the HTTP protocol. Normally, each time a browser requests the URL of a page from a Web server the request is treated as a completely new interaction. The fact that the request may be just the most recent in a series of requests as the user browses methodically through the site is lost. Although this makes the Web more efficient, this stateless behaviour makes it difficult to create things like shopping carts that must remember the user’s actions over an extended period of time. Cookies [...] can only be used to store information that you have provided at some point. To give a benign example, if you fill out a form giving your favourite colour, a server can turn this information into a cookie and send it to your browser. The next time you contact the site, your browser will return the cookie, allowing the server to alter background colour of its pages to suit your preferences. However cookies can be used for more controversial purposes. Each access your browser makes to a Web site leaves some information about you behind, creating a gossamer trail across the Internet. Among the tidbits of data left along this trail are the name and IP address of your computer, the brand of browser you’re using, the operating system you’re running, the URL of the Web page you accessed, and the URL of the page you were last viewing. Without cookies, it 12.07.2000

debis IT Security Services

Seite 41

Grundlagen, Forderungen und Marktübersicht für Intrusion Detection Systeme (IDS) und Intrusion Response Systeme (IRS)

Intrusion Detection und Intrusion Response - Grundlagen

would be nearly impossible for anyone to follow this trail systematically to learn much about your Web browsing habits. They would have to reconstruct your path by correlating hundreds or thousands of individual server logs. With cookies, the situation changes considerably. Obige Beschreibung zeigt, daß aus der Benutzung von Cookies zwar keine direkten Angriffsmöglichkeiten entstehen. Jedoch kann ein Angreifer auf Basis der durch Cookies erhalten Informationen, Ansatzpunkte für weitere Angriffe erarbeiten. Ursächlicher Fehler: Keiner Mögliche Schäden: Angreifer erhält Information

2.3.7.3 ActiveX Die folgende Passage wurde dem WWW Security FAQ entnommen: ActiveX is a technology developed by the Microsoft Corporation for distributing software over the Internet. Like Java Applets, an ActiveX „control“ can be embedded in a Web page, where it typically appears as a smart interactive graphic. A number of ActiveX controls are available for the Microsoft Internet Explorer (the only browser to support them so far4), including a scrolling marquee, a background sound generator, and an ActiveX control that executes Java applets. Unlike Java, which is a platform-independent programming language, ActiveX controls are distributed as executable binaries, and must be separately compiled for each target machine and operating system. The ActiveX security model is considerably different from Java applets. Java attempts to achieve security by restricting the behavior of applets to a set of safe actions. ActiveX, on the other hand, places no restrictions on what a control can do. Instead, each ActiveX control can be digitally „signed“ by its author in such a way that the signature cannot be altered or repudiated using a system called „Authenticode.“ The digital signatures are then certified by a trusted „certifying authority“, such as VeriSign, to create the equivalent of a shrink-wrapped software package. When a digital certificate is granted, the software developer pledges that the software is free from viruses and other malicious components. If you download a signed ActiveX control and it crashes your machine, you’ll at least know who to blame.

4

Netscape hat angekündigt, daß in Zukunft ActiveX vom Netscape Navigator unterstützt werden soll.. NCompass Labs, Inc. of Vancouver, British Columbia, bietet bereits ein ActiveX PlugIn für den Netscape Browser an. (www.ncompasslabs.com)

12.07.2000

debis IT Security Services

Seite 42

Grundlagen, Forderungen und Marktübersicht für Intrusion Detection Systeme (IDS) und Intrusion Response Systeme (IRS)

Intrusion Detection und Intrusion Response - Grundlagen

This security model places the responsibility for the computer system’s security squarely on the user’s head. Before the browser downloads an ActiveX control that hasn’t been signed at all, or that has been signed but certified by an unknown certifying authority, the browser presents a dialog box warning the user that this action may not be safe. The user can elect to abort the transfer, or may continue the transfer and take his chances. Obige Beschreibung zeigt, daß das Sicherheitsmodell von ActiveX Hauptsächlich auf dem Vertrauen der Benutzer in die Provider von ActiveX-Controls beruht. Der Benutzer hat in der Regel keine Möglichkeit die im Binär-Code vorliegenden ActiveX-Controls auf Bedrohungen hin zu untersuchen. Es ist abzuwarten, wie effektiv dieser Ansatz sein wird und ob die Benutzer sich die Zeit nehmen werden, eine Liste von vertrauenswürdigen ActiveX-Control-Providern zu pflegen. Die aktuellen Ansätze, sogenannte Code-Zertifizierungsstellen (CA, certification authority) bereitzustellen, sind noch recht unzureichend. CAs verlangen zur Zeit kaum Beweise, welche die Identität eines Softwareentwicklers sichern. Häufig genügt die Angabe einer Kreditkartennummer. Nach unserem Wissensstand gibt es keine Abnahme von ActiveX Controls über die CAs. ActiveX kann über die Browsereinstellungen ausgeschalten werden. Darüber hinaus gibt es Programme, die Applets blockieren (z.B. http://www.digitivity.com ). Ursächlicher Fehler: Designfehler der Anwendung Mögliche Schäden: Zugriff auf Rechnerressourcen

2.3.7.4 CGI Das Common Gateway Interface (CGI) ist eine Schnittstellenspezifikation mit deren Hilfe ein Browser Daten aus einer Datenbank dynamisch zur Erzeugung von HTML-Code zusammenstellen kann. CGI-Anfragen können an eine URL angehangen werde. Die folgende Befehlszeile fordert beispielsweise die Daten aus /etc/passwd an: http://www.secret.de/cgi-bin/query?%0a/bin/cat%20/etc/passwd Die Zeichenketten %0a und %20 stellen ASCII Zeilenvorschub bzw. das Leerzeichen dar. CGI-Skripts sind bekannt für ihre häufigen Sicherheitsschwachstellen, da sie mit einer Art „Mini-Server“ vergleichbar sind. Ursächlicher Fehler: Designfehler der Anwendung Mögliche Schäden: Zugriff auf Rechnerressourcen

12.07.2000

debis IT Security Services

Seite 43

Grundlagen, Forderungen und Marktübersicht für Intrusion Detection Systeme (IDS) und Intrusion Response Systeme (IRS)

Intrusion Detection und Intrusion Response - Grundlagen

2.3.7.5 MIME Der Empfang von MIME-Nachrichten kann ebenfalls Schäden verursachen. Ein Angreifer kann zum Beispiel eine E-Mail mit folgendem Inhalt versenden: Content-Type:

Message/External-body;

name=“.rhosts“; site=“ftp.visigoth.org“; access-type=“anon-ftp“; directory=“.“; Content-Type:

text/plain

Dieses Skript fordert vom unter „site“ angegebenen Rechner die Datei .rhosts an und kopiert sie in das aktuelle Verzeichnis des Empfängers der E-Mail. Ursächlicher Fehler: Designfehler der Anwendung Mögliche Schäden: Zugriff auf Rechnerressourcen

2.3.7.6 WWW Spoofing Hierbei handelt es sich um einen sogenannten „Mann-in-der-Mitte“-Angriff (man-in-themiddle), der sich einer Technik namens URL Rewriting bedient. Beim URL Rewriting wird eine URL-Adresse umgelenkt. Dies funktioniert nur auf für diesen Zweck präparierten Servern, d.h. der Angreifer muß selbst einen Web-Server betreiben. Darüber hinaus muß jemand, bevor er Opfer dieses Angriffs wird, auf diesen modifizierten Web-Server zugreifen. Zu diesem Zweck versucht der Angreifer das Opfer auf seine Web-Site aufmerksam zu machen. Greift das Opfer auf ein Dokument des präparierten Servers zu, so wird ihm ein Dokument mit ausschließlich gefälschten URLs zugespielt. Dabei kann die Adresse www.onlinebanking.de auf www.angreifer.de/www.online-banking.de umgeleitet werden. Auf diese Art und Weise kann dem Benutzer ein falsches Web vorgespielt werden. Der Benutzer kann diesen Angriff leicht entdecken, indem er die Statusanzeige seines Browsers beobachtet. Ursächlicher Fehler: Designfehler in der Dienstspezifikation Mögliche Schäden: Datenechtheitsverlust, Datenintegritätsverlust während des Transports, Datenvertraulichkeitsverlust während des Transports 12.07.2000

debis IT Security Services

Seite 44

Grundlagen, Forderungen und Marktübersicht für Intrusion Detection Systeme (IDS) und Intrusion Response Systeme (IRS)

Intrusion Detection und Intrusion Response - Grundlagen

2.4 Kategorisierung von Angriffen bezüglich ihrer Erkennbarkeit In Kapitel 2.3 wurden die möglichen Angriffe auf Rechner und Rechnernetze detailliert beschrieben. Die dort beschriebenen Angriffe wurden gemäß der Dienstebene, auf der sie stattfinden, ähnlich zum OSI-Referenzmodell kategorisiert. Dabei wurden folgende Kategorien verwendet: Niedrige Ebene: Hier wurden folgende Angriffsfamilien behandelt: •

ARP-, IP- oder ICMP-Angriffe

•

Verschiedene Formen von Spoofing

•

Verschiedene Formen von Überflutung

•

Verschiedene Formen von Tunneln

Mittlere Ebene: Hier wurden Angriffe wie •

Aktiver/passiver FTP-Angriff

•

DNS-, X11-, NIS- und NFS-Angriffe

beschrieben. Hohe Ebene: Hier wurden folgende Angriffstypen beschrieben: •

Angriffe auf Authentisierungsmechanismen

•

Mißbrauch von Anwendungen

•

Verteilter, koordinierter Angriff

Darüber hinaus wurden verschiedene Arten des Abtastens nach aktiven Diensten (Scanning) sowie das Einschleppen von Software mit Schadensfunktionalität und Angriffe auf Dienste des WWW beschrieben. Die oben skizzierte Kategorisierung bietet leider keine Möglichkeit, von der Kategorie auf die zu verwendende Erkennungstechnik zu schließen. Dies ist aber häufig wünschenswert, da eine Kategorisierung im Hinblick auf die Erkennbarkeit von Angriffen dem Sicherheitsbeauftragten wertvolle Dienste leisten kann. So kann dieser beispielsweise schnell feststellen, ob ein Angriff überhaupt wirksam von einem IDS erkannt werden kann und wenn ja, wie dies geschehen kann. Dabei können Angriffe auf verschiedenen Dienstebenen durchaus in dieselbe Erkennbarkeitskategorie fallen. Zum Beispiel weisen sowohl ein ICMP-Redirect-Angriff als auch ein WWW Spoofing-Angriff einen typischen Fingerabruck auf: Bei ICMP-Redirect ist es das Setzen des Redirect-Bits und bei WWW Spoofing sind es die verlängerten URLs. Ein weiteres Beispiel sind „IP Spoofing“-Angriffe. Das Rechnernetz kann vor diesen Angriffen geschützt werden, indem die adäquaten Sicherheitsrichtlinien umgesetzt werden. Das heißt, ein Paket mit einer internen Netzadresse sollte niemals von einem externen, eingehenden Port durchgelassen werden. Ähnliches gilt für ActiveX-Code. Dieser sollte von einem Firewall-System stets gefiltert werden. Jedes Durchlassen solcher Pakete ist 12.07.2000

debis IT Security Services

Seite 45

Grundlagen, Forderungen und Marktübersicht für Intrusion Detection Systeme (IDS) und Intrusion Response Systeme (IRS)

inkonsistent mit den Sicherheitsrichtlinien Integritätsbedingung verstanden werden.

Intrusion Detection und Intrusion Response - Grundlagen

und

kann

so

als

Verletzung

einer

2.4.1 Ziele Die oben genannten Beispiele veranschaulichen, daß eine Kategorisierung der Angriffe bezüglich ihrer Erkennbarkeit sich deutlich von einer Kategorisierung bezüglich der Dienstebene unterscheidet. Das zentrale Ziel der Kategorisierung gemäß der Erkennbarkeit ist es, Unterstützung bei der Erkennung neuer, bisher noch unbekannter Angriffe zu geben. Das zu entwerfende Schema soll es auch Administratoren, die keine Experten im ID-Bereich sind, ermöglichen, schnell die zuverlässigen Gegenmaßnahmen bei einem Angriff zu finden, indem die folgenden Schritte durchgeführt werden: 1. Zugriff auf eine detaillierte Beschreibung des Angriffs (z.B. in einer CERTMeldung) 2. Analyse der Beschreibung auf eine oder mehrere der in Abschnitt 2.4.2 aufgeführten Eigenschaften hin 3. Bestimmung der mit der Eigenschaft verbunden ID-Grundtechnik Darüber hinaus gibt die Kategorisierung einen strukturierten Überblick über die Angriffscharakteristika.

2.4.2 Erkennungstechniken Bevor ein neuer Angriff erkannt werden kann, muß zunächst erst einmal festgestellt werden, daß ein Rechnersystem – absichtlich oder unbeabsichtigt – Opfer eines Angriffs wurde. Falls ein vollkommen neuer Angriff gegen ein System gefahren wird, so ist es sehr wahrscheinlich, daß dieser Angriff nicht rechtzeitig erkannt wird und die Folgen (z.B. Denialof-Service) spürbar sind. Zur Zeit ist nur eine Absicherung gegen bekannte Angriffe wirksam möglich5. Sobald ein Angriff identifiziert wurde, müssen seine Grundeigenschaften herausgefiltert werden. Dadurch wird eine Einordnung in folgende Kategorien möglich:

5

Es ist zu beachten, daß Ansätze wie Anomalieerkennung zum heutigen Zeitpunkt noch weit von einer praktischen Einsetzbarkeit entfernt sind (vgl. auch Abschnitt 2.2.2).

12.07.2000

debis IT Security Services

Seite 46

Grundlagen, Forderungen und Marktübersicht für Intrusion Detection Systeme (IDS) und Intrusion Response Systeme (IRS)

Intrusion Detection und Intrusion Response - Grundlagen

2.4.2.1 Gehäuftes Auftreten von TCP/IP-Paketen Angriffscharakteristik: Das System erhält während eines Zeitintervalls deutlich mehr TCP/IP-Pakete eines bestimmten Typs (SYN, ACK etc.) als gewöhnlich. Zur Feststellung dieses Tatbestands kann ein Sniffer installiert werden, der überprüft, wieviele Pakete eines bestimmten Typs auftreten. Das gehäuftes Auftreten von TCP/IP-Paketen wird im folgenden auch als proliferiertes Auftreten bezeichnet. Angriffe aus dieser Kategorie können mit Hilfe einer schwellwertgesteuerten Signaturanalyse erkannt werden. Die Datenquelle wird dabei durch einen Sniffer zur Verfügung gestellt. • SYN-Überflutung • Session Hijacking (ACK-Stürme) • Abtasten (gehäuftes Auftreten von Time-Out-Meldungen) • Open/Close-Überflutung • DNS Spoofing

2.4.2.2 Gehäufter Bedarf an Betriebsmitteln Angriffscharakteristik: Das Rechnersystem nimmt Daten entgegen, die den Bedarf an Betriebsmitteln wie CPU-Zeit, Plattenplatz etc. sprunghaft ansteigen lassen. Solche Angriffe können erkannt werden, indem die Betriebsmittelzuteilung durch Werkzeuge wie ps, du, df etc. überwacht wird. Die Angriffe sind dabei typischerweise Überflutungsangriffe wie •

E-Mail-Überflutung

•

System-Log-Überflutung

2.4.2.3 Iterierter Verbindungsaufbau zum Authentisierungssystem Angriffscharakteristik: Das System erhält ständig neue Verbindungsaufbauwünsche zum Authentisierungssystem. Dies weist möglicherweise auf ein erschöpfendes Durchprobieren von Paßwörtern hin. Jeder Verbindungswunsch zum Authentisierungssystem sollte protokolliert werden. Es sollten auf jeden Fall erfolgreiche und erfolglose Authentisierungsversuche festgehalten werden. Die Analyse der Logbucheinträge liefert Evidenz dafür, ob es sich um einen Angriff handelt oder nicht. Authentisierungsversuche bei schwachen Mechanismen wie z.B. TCPSequenznummernvorhersage können durch Sniffer und schwellwertgesteuerte Signaturanalyse erkannt werden. 12.07.2000

debis IT Security Services

Seite 47

Grundlagen, Forderungen und Marktübersicht für Intrusion Detection Systeme (IDS) und Intrusion Response Systeme (IRS)

Intrusion Detection und Intrusion Response - Grundlagen

Beispiele für diese Kategorie sind •

Angriffe auf Paßwörter

•

TCP Sequenznummernvorhersage

•

Erraten des NFS file handles

2.4.2.4 Angriffe mit charakteristischen Zeichenketten Angriffscharakteristik: Das Rechnersystem erhält eine charakteristischen Zeichenkette (magic string) wie z.B. debug oder ein ungültiges IP-Paket. Um hier einen Angriff feststellen zu können, sind umfangreiche Analysen notwendig. Es sollten die Schwächen aller Dienste untersucht werden, die von dem Angreifer benutzt wurden. Ist der Angriff einmal identifiziert, so ist das spätere Erkennen des Angriffs anhand der gefundenen charakteristischen Zeichenkette relativ einfach, da der Proxy oder Sniffer bei den einkommenden Daten nur noch einen Musterabgleich durchführen muß. Beispiele für Angriffe aus dieser Kategorie sind: •

IP mit falschen Parametern

•

ICMP Echo Request

•

CPU-Angriffe (nur bei NT)

•

ICMP Redirect

•

finger-Überflutung

•

WWW Spoofing

•

Einkapselung/Tunneln

2.4.2.5 Angriffe mittels einer charakteristischen Zustandsüberführungssequenz Angriffscharakteristik: Das System erhält eine Folge von Angriffsschritten mit Schadenspotential (malicious code). Auch diese Klasse erfordert eine sorgsame Untersuchung aller vom Angreifer ausgeführten Schritte, die mitunter sehr aufwendig sein kann. Angriffe dieses Typs sind eine weiterentwickelte Variante der charakteristischen Zeichenketten. Anstelle einer einzigen Zeichenkette, wird eine Folge von Zeichenketten verwendet. Jede einzelne der Zeichenketten kann unkritisch sein, jedoch kann ihre Sequenz das System in einen kritischen Zustand bringen. Der Zusammenhang zwischen diesen beiden Varianten entspricht dem Unterschied zwischen einem Nonterminal-Symbol und einem endlichen Automaten.

12.07.2000

debis IT Security Services

Seite 48

Grundlagen, Forderungen und Marktübersicht für Intrusion Detection Systeme (IDS) und Intrusion Response Systeme (IRS)

Intrusion Detection und Intrusion Response - Grundlagen

Beispiele für Angriffe aus dieser Kategorie sind •

Aktive bzw. passive FTP-Angriffe

2.4.2.6 Verletzung der Integritätsbedingungen Angriffscharakteristik: Hierbei empfängt das Rechnersystem Daten, die es gemäß den Sicherheitsrichtlinien nicht erhalten sollte (zum Beispiel eine interne IP-Adresse, die von einem externen Sender kommt). Ein Angriff dieser Art stellt eine explizite Verletzung der Sicherheitsrichtlinien dar. Angriffe dieses Typs können festgestellt werden, indem die Implementierung der Sicherheitsrichtlinien auf Korrektheit und Vollständigkeit überprüft wird. Dazu gehört eine Überprüfung sämtlicher Konfigurationsdateien, Sicherheitsparameter etc. auf Routern, Firewall-Hosts u.ä. Integritätsbedingungen sind ein wesentlicher Bestandteil bei der Umsetzung von Sicherheitsmaßnahmen, da sie Regeln formulieren, die immer gültig sein müssen. Es sei darauf hingewiesen, daß es sich bei einer Verletzung einer Integritätsbedingung nicht notwendigerweise um einen Angriff handeln muß. Beispiele für diese Klasse sind: •

IP Spoofing

•

Source Routing

•

Java

•

Cookies

•

ActiveX

•

MIME

•

Angriffe, die dem Auspionieren des Systems über Dienste wie finger, rusers etc. dienen. Externe Benutzer dürfen keinen Zugriff auf einen dieser Dienste erhalten.

2.4.3 Auswirkung und Nutzen Die oben beschriebene Kategorisierung der Angriffe stellt ein nützliches und praktisches Hilfsmittel bei der Angriffserkennung durch ein ID-System dar. Sie ist deutlich konkreter als die bisher verwendeten Kategorien „Erkennbarkeit mittels Signaturanalyse“ und „Erkennbarkeit mittels Anomalieerkennung“. Sie ist aber auch abstrakter als Beschreibungen der Art „finger-Überflutung kann mittels Suche nach @@@@host.domain erkannt werden“. Die Kategorisierung stellt mit der Vermeidung von zu abstrakten Formulierungen auf der einen und durch zu viele Details verwirrenden Formulierungen auf der anderen Seite ein

12.07.2000

debis IT Security Services

Seite 49

Grundlagen, Forderungen und Marktübersicht für Intrusion Detection Systeme (IDS) und Intrusion Response Systeme (IRS)

Intrusion Detection und Intrusion Response - Grundlagen

brauchbares Hilfsmittel für Systemadministratoren und Sicherheitsbeauftragte dar, die nach einem Angriff neue Sicherheitsmaßnahmen treffen müssen. Die Kategorisierung •

dient dem SSO als Erste-Hilfe-Maßnahme bei der Entdeckung von und Vorsorge vor Angriffen auf Rechnersysteme.

•

stellt die Grundinformation zur Rekonfigurierung des IDS dar, um einen neuen Angriff zu erkennen.

•

hilft ein tieferes Verständnis von Angriffen auf Rechnersysteme zu entwickeln, ohne einen Spezialisten fragen zu müssen.

•

hilft präzisere Forderungen für Gegenmaßnahmen aufzustellen.

•

hilft dem SSO dabei, alternative Möglichkeiten zur Angriffsentdeckung zu entwickeln. Dies ist besonders in Hinblick darauf interessant, daß es nicht immer eine allgemein als optimal akzeptierte Lösung gibt.

2.5 Das Erkennen von Angriffen auf Rechner und Rechnernetze In Abschnitt 2.3 wurde beschrieben, wie die Angriffe auf Rechner und Rechnernetze funktionieren. Ziel dieses Abschnitts ist es nun darzustellen, wie die unter 2.3 beschriebenen Angriffe erkannt werden können. Im folgenden werden vier verschiedene Möglichkeiten zur Angriffserkennung unterschieden: •

Sniffing: Das ID-System sammelt Daten über den Netzverkehr (gewöhnlich auf IPEbene). Hiermit können, zumindest theoretisch, alle vom Netz ausgehenden Angriffe erkannt werden. Dies erfordert aber, daß der IP-Stack des zu schützenden Systems genau simuliert wird und die Pakete auch bis hin zur Anwendungsebene zusammengebaut werden.

•

Logbucheinträge des Betriebssystems: Das ID-System analysiert die Logbucheinträge und kann so viele Angriffe erkennen, ohne den gesamten Datenverkehr zu berücksichtigen (wie es beim Sniffing der Fall wäre). Entscheidend hierbei ist, welche Ereignisse als protokollierenswert eingestuft und dann auch tatsächlich im Logbuch festgehalten werden.

•

Proxy: Einige Angriffe sind anwendungsspezifisch, wie zum Beispiel WWW Spoofing. Sie können von Proxys entdeckt werden, da diese ohne die gesamte Datenmenge zur tatsächlichen Applikation hin durchreichen. Wird die Erkennung mit Hilfe modifizierter Proxys durchgeführt, so verläßt sich das IDS dabei auf einen fremden TCP/IP-Stack. Angriffe auf niedriger Ebene können dabei natürlich nicht erkannt werden.

•

Integritätsüberwachung mittels Tripwire: Tripwire (Stolperdraht) ist der Name eines Programms, welches die Integrität zuvor angegebener Dateien überprüft. Mittels

12.07.2000

debis IT Security Services

Seite 50

Grundlagen, Forderungen und Marktübersicht für Intrusion Detection Systeme (IDS) und Intrusion Response Systeme (IRS)

Intrusion Detection und Intrusion Response - Grundlagen

Tripwire kann festgestellt werden, ob Daten (z.B. Konfigurationsdateien) modifiziert wurden. Die folgenden Abschnitte beschreiben welche Erkennungstechniken für die einzelnen in Abschnitt 2.3 beschriebenen Angriffe einsetzbar sind. Die Unterabschnitte von Abschnitt 2.5 haben dabei dieselbe Unternumerierung wie in Abschnitt 2.3. Es wird jeweils die Erkennungstechnik auf der höchsten Abstraktionsebene angegeben. (Bsp.: Ein Angriff auf Applikationsebene, der mittels eines Application-Proxies erkannt werden kann, ist auch mit Hilfe eines Sniffers erkennbar, wenn dieser in ausreichend geschickter Weise die applikationsspezifischen Netzwerkpakete zusammensetzt.) Zunächst seien einige Bemerkungen zum Gebrauch der Terminologie vorangestellt. Bisher war immer von zwei grundlegenden ID-Techniken die Rede: Anomalieerkennung und Mißbrauchserkennung (auch Signaturanalyse genannt). Daneben wurde die schwellwertgesteuerte Signaturanalyse in der Grauzone zwischen den gerade genannten Techniken angeordnet. Die für diese Erkennung notwendigen konkreten Schwellenwerte müssen für jedes System und jeden Angriff einzeln festgelegt werden, da dazu bisher keine allgemeingültigen Verfahren entwickelt wurden.

2.5.1 Angriffsplanung 2.5.1.1 Das Abtasten von TCP-Ports (TCP Port Scan) Aktiver Port Scan Das aktive Abtasten nach TCP-Diensten kann entdeckt werden, indem ein Schwellenwert gesetzt wird, der die Anzahl der erlaubten Anfragen zum TCP-Verbindungsaufbau von derselben IP-Quelladresse aus beschränkt. Diese Aufbauversuche müssen vom System protokolliert werden. Diese Aufgabe muß unter Umständen sogar das IDS übernehmen. Anschließend kann analysiert werden, ob der Schwellenwert überschritten wurde. Diese Methode hat zwei Nachteile. Erstens kann der Angreifer seine IP-Quelladresse fälschen (IP Spoofing). In diesem Fall ist zu überlegen, ob das IDS auf die Überprüfung der Quelladresse verzichten kann. Dies birgt natürlich die Gefahr, daß in seltenen Fällen Fehlalarme ausgelöst werden. Die entsprechenden Einstellungen müssen unbedingt vom Administrator vorgenommen werden können. Zweitens kann ein Angreifer das Abtasten der Ports geschickt über mehrere Stunden oder Tage verteilen. Dabei hilft sogar die Tatsache, daß von den zur Verfügung stehenden Ports nur eine geringe Anzahl der für einen Angriff interessanten Dienste zur Verfügung stellt. Der Angreifer hat also große Chancen, unentdeckt zu bleiben.

12.07.2000

debis IT Security Services

Seite 51

Grundlagen, Forderungen und Marktübersicht für Intrusion Detection Systeme (IDS) und Intrusion Response Systeme (IRS)

Intrusion Detection und Intrusion Response - Grundlagen

Half Open Scan Halboffenes Abtasten kann auf ähnliche Weise wie das aktive Abtasten erkannt werden. Da jedoch hierbei keine Verbindung zustande kommt, ist es sehr wahrscheinlich, daß halboffenes Abtasten nicht vom Betriebssystem protokolliert wird. Somit ist das IDS selbst dafür verantwortlich, solche Ereignisse festzuhalten. Darüber hinaus gelten auch hier die beiden beim aktiven Abtasten genannten Einschränkungen.

Stealth Scanning Wie beim halboffenen Abtasten ist auch hier das Protokollieren das Hauptproblem. Ein Sniffer kann jedoch die FIN-Pakete entdecken. Es gelten wieder die beiden oben genannten Einschränkungen. Bem.: Ein Angreifer kann auch eine geschickte Kombination der Abtasttechniken verwenden, um so den Schwellenwert zu unterlaufen. In diesem Fall muß das IDS die Kombination der Techniken berücksichtigen.

Unsichtbares Abtasten nach RPC-Diensten (RPC Stealth Scan) Der Angriff beginnt mit einem Abtasten nach aktiven TCP-Ports. Falls das IDS – warum auch immer – dies nicht bemerkt hat, so existiert immer noch die Möglichkeit, den Aufruf der Procedure 0 und so den gesamten Abtastvorgang zu entdecken. Allerdings müssen hierbei wieder Schwellenwerte zum Einsatz kommen, wodurch diese Erkennungsmethode genauso wie die vorherigen drei unterlaufen werden kann.

2.5.1.2 Abtasten nach UDP-Diensten (UDP Port Scan) Der Angreifer sendet UDP-Pakete an einen bestimmten Port. Falls der Dienst nicht verfügbar ist, wird mit der Meldung „ICMP Port Unavailable“ geantwortet. Das IDS kann einen Schwellenwert dazu benutzen festzustellen, ob der Quotient zwischen UDPVerbindungsversuchen und „ICMP Port Unavailable“-Meldungen kritisch ist.

12.07.2000

debis IT Security Services

Seite 52

Grundlagen, Forderungen und Marktübersicht für Intrusion Detection Systeme (IDS) und Intrusion Response Systeme (IRS)

Intrusion Detection und Intrusion Response - Grundlagen

2.5.1.3 Suche nach Systeminformation Die Befehle finger und rusers Das IDS kann die Protokolldaten des Betriebssystems überprüfen und so feststellen, ob und von welcher IP-Quelladresse aus der Dienst angefordert wurde. Stellt das Betriebssystem diese Funktionalität nicht zur Verfügung, muß das IDS selbst für die entsprechenden Logbucheinträge sorgen. Es kann selbstverständlich nicht überprüft werden, ob der Angreifer die vom Dienst gelieferten Informationen mißbraucht. Netstat s. finger Rstatd, sysstat s. finger Identd s. finger Rwho s. finger Nbstat (nur NT) s. finger

2.5.2 Angriffe auf unterer Protokollebene 2.5.2.1 ARP-Ebene Ein Sniffer kann feststellen, ob ein Rechner Information bekommt, die er nicht explizit angefordert hat. Dazu kann die Anzahl der geforderten Datensätze mit der Anzahl der gelieferten Datensätze verglichen werden. Jeder zuviel gelieferte Datensatz ist verdächtig.

12.07.2000

debis IT Security Services

Seite 53

Grundlagen, Forderungen und Marktübersicht für Intrusion Detection Systeme (IDS) und Intrusion Response Systeme (IRS)

Intrusion Detection und Intrusion Response - Grundlagen

2.5.2.2 IP-Ebene IP Fragmentierung (Fragmentation) Ein Sniffer kann Pakete mit fragmentiertem TCP-Header entdecken. Darüber hinaus besteht auch die Möglichkeit, den Router so zu konfigurieren, daß er Pakete mit fragmentierten Headern ablehnt. Fragmentierte SYN-Pakete mit reserved bit check Dieser Angriff basiert auf einem Implementierungsfehler. Falls ein Router fragmentierte SYN-Pakete durchläßt (da er den Implementierungsfehler geerbt hat), so kann ein Sniffer diese noch immer erkennen. Falsche IP Parameter Diese Angriffe nutzen Implementierungsfehler im TCP/IP-Stack aus. Ein Sniffer kann diese Pakettypen durchaus erkennen. SYN mit unerreichbarer Quelladresse Der Angriff kann mittels Anomalieerkennung entdeckt werden. Für einige der betroffenen Betriebssysteme stehen Patches zur Verfügung, die das Problem beheben. CPU-Angriff mittels Telnet-Verbindung Ein Proxy kann die für einen Port nicht zulässigen Befehle bzw. Zeichenketten entdecken. Windows NT Internet Information Server (NT IIS)-Absturz Dies kann mittels eines Proxys entdeckt werden.

2.5.2.3 ICMP-Ebene ICMP Redirect Ein Sniffer kann entdecken, ob diese Option innerhalb eines Pakets gesetzt ist. ICMP Destination Unreachable Es kann im allgemeinen nicht festgestellt werden, ob die IP-Quelladresse im ICMP_Destination_Unreachable-Paket gefälscht wurde. Es kann allerdings wie beim normalen IP Spoofing festgestellt werden, ob die gefälschte Adresse eine interne Adresse ist, die an einem eingehenden externen Port ankommt.

12.07.2000

debis IT Security Services

Seite 54

Grundlagen, Forderungen und Marktübersicht für Intrusion Detection Systeme (IDS) und Intrusion Response Systeme (IRS)

Intrusion Detection und Intrusion Response - Grundlagen

ICMP Echo Request (Ping of Death) Ein Sniffer kann feststellen, ob die versendeten IP-Pakete nicht mit der entsprechenden RFC konform sind. Das IDS kann den IP-Stack simulieren, um die tatsächliche Größe des Pakets zu bestimmen. ICMP-Zeitstempel Ein IDS kann feststellen, ob jemand diesen Dienst anfordert. ICMP Tunnel Es kann Bestandteil einer Security Policy sein, daß ICMP-Pakete nur die durch die ICMPSpezifikation festgelegten Muster im Datenfeld enthalten oder das Datenfeld leer ist. Falls ein ICMP-Paket diese Bedingung nicht erfüllt, so kann es durch ein IDS erkannt werden.

2.5.2.4 Spoofing IP Spoofing „IP Spoofing”-Angriffe können entdeckt werden, falls an der externen Schnittstelle eines Routers eine interne Adresse ankommt. Werden externe Adressen gefälscht, so ist es im allgemeinen nicht möglich diese als gefälscht zu entlarven. TCP-Sequenznummernvorhersage Das IDS kann überprüfen, ob jemand Sequenznummern durchprobiert. Der Erfolg des Angriffs basiert nicht nur auf der Tatsache, daß sich die Sequenznummern relativ leicht erraten lassen, sondern auch darauf, daß Pakete mit falschen Sequenznummern vom IPStack einfach verworfen werden. Wenn das IDS die entsprechenden Pakete überwacht anstatt sie ebenfalls zu ignorieren, so kann das IDS – falls die Zahl solcher Pakete einen bestimmten Schwellenwert überschreitet – einen Alarm auslösen. Dabei muß das IDS allerdings in der Lage sein, exakt den IP-Stack des zu schützenden Systems nachzubilden. DNS Spoofing Hier kann das IDS – ähnlich wie bei der TCP-Sequenznummernvorhersage – versuchen, das Erraten der Query-IDs festzustellen. Dazu wird ein Sniffer oder ein DNS-Proxy benötigt. RIP Spoofing Nicht erkennbar.

12.07.2000

debis IT Security Services

Seite 55

Grundlagen, Forderungen und Marktübersicht für Intrusion Detection Systeme (IDS) und Intrusion Response Systeme (IRS)

Intrusion Detection und Intrusion Response - Grundlagen

2.5.2.5 Source Routing Ein Sniffer kann feststellen, ob die entsprechen Option aktiviert ist.

2.5.2.6 Session Hijacking Hierbei werden meistens ACK-Stürme erzeugt. Das IDS kann mittels eines Schwellenwerts feststellen, ob diese auftreten.

2.5.2.7 Überfluten Überfluten mittels E-Mail Das IDS kann überprüfen, ob Anzahl oder Größe eingehender E-Mail-Sendungen bestimmte Schwellenwerte überschreiten. Es muß sich bei solchen Überschreitungen jedoch nicht immer um einen absichtlichen Mißbrauch des Dienstes handeln. Überflutung mittels SYN-Paketen Falls die Anzahl der empfangenen SYN-Pakete pro Zeitintervall einen bestimmten Schwellenwert überschreitet, wird ein Alarm ausgelöst. Überflutung des Systemlogbuchs Analog zu „Überfluten mittels E-Mail“ und „Überflutung mittels SYN-Paketen”. Überflutung mittels Daten Analog zu „Überfluten mittels E-Mail“ und „Überflutung mittels SYN-Paketen”. Überflutung mittels Open/Close Analog zu „Überfluten mittels E-Mail“ und „Überflutung mittels SYN-Paketen”.

2.5.2.8 Einkapselung / Tunneln Vgl. ICMP Tunnel (im Abschnitt 2.5.2.3).

12.07.2000

debis IT Security Services

Seite 56

Grundlagen, Forderungen und Marktübersicht für Intrusion Detection Systeme (IDS) und Intrusion Response Systeme (IRS)

Intrusion Detection und Intrusion Response - Grundlagen

2.5.3 Angriffe auf mittlerer Ebene (Dienstebene)

2.5.3.1 DNS Angriffe DNS-Cache-Verunreinigung (DNS Cache Poisoning) Das IDS kann überprüfen, ob der Rechner DNS-Datensätze (Resource Records, RR) erhielt, die er nicht explizit angefordert hat. Einige Betriebssysteme überprüfen dies bereits und halten das Ergebnis im Logbuch fest. Reverse Lookup Es ist nicht feststellbar, ob ein Angreifer zu ermitteln versucht, ob ein Zielsystem reverse lookup ausführt.

2.5.3.2 NIS Der Angreifer antwortet auf eine NIS-Anfrage, bevor der eigentliche NIS-Server dazu kommt. Die Antworten des NIS-Servers werden dann verworfen. Ein NIS-Proxy könnte feststellen, ob auf eine NIS-Anfrage Antworten von verschiedenen IP-Quelladressen kommt und diese Anomalie dann protokollieren. Nutzt der Angreifer IP-Spoofing, so funktioniert diese Erkennungstechnik nicht.

2.5.3.3 FTP Aktiver / Passiver FTP Angriff Bei beiden Angriffsarten kann mittels eines FTP-Proxys die Quelladresse des FTP-Client überwacht werden. Dies stellt die Funktionalität des fehlenden Authentisierungsmechanismus zur Verfügung. Darüber hinaus kann geprüft werden, ob mehrere Clients gleichzeitig über denselben Port Daten anfordern. FTP-Paßwort-Angriff Analog zu anderen Paßwortangriffen. FTP-Konfigurationsfehler Das IDS kann mittels eines FTP-Proxys überprüfen, ob der Client Kommandos wie z.B. put .rhosts absetzt.

12.07.2000

debis IT Security Services

Seite 57

Grundlagen, Forderungen und Marktübersicht für Intrusion Detection Systeme (IDS) und Intrusion Response Systeme (IRS)

Intrusion Detection und Intrusion Response - Grundlagen

TFTP Der Mißbrauch mittels TFTP ist nicht feststellbar. Es ist jedoch z.B. mittels eines denkbaren TFTP-Proxys überprüfbar, ob ein Angreifer versucht, mittels TFTP die Datei /etc/passwd zu stehlen.

2.5.3.4 HTTP Ein Sniffer kann den Netzverkehr nach Zeichenketten wie http://<something here>// durchsuchen.

2.5.3.5 X11 Es ist nicht bekannt, ob Anomalieerkennung in der Lage ist, das Stehlen des Bildschirminhalts zuverlässig zu entdecken. Ein Ansatz wäre eine Datenflußanalyse, die die übertragene Datenmenge analysiert. Große Datenmengen vom XServer zu Clients werden als ungewöhnlich eingestuft.

2.5.3.6 SMB-Absturz (nur Windows NT) Der entsprechende Angriff kann mittels eine Sniffers entdeckt werden.

2.5.3.7 NFS Erraten des NFS-Datei-Handles Das Erraten des Datei-Handles durch einen Angreifer kann durch Analyse der Logdateien oder auch durch Sniffing festgestellt werden – vorausgesetzt, dieser hat nicht bereits mit dem ersten Rateversuch Erfolg. NFS-Exportliste Es kann entdeckt werden, ob die Exportliste mehr als 255 Buchstaben enthält. Es kann nicht festgestellt werden, ob ein Benutzer diesen Sachverhalt zum Mißbrauch nutzt. NFS mountd Mittels eines Proxy könnte die Tiefe des Client im angebundenen Dateibaum kontrolliert werden. Negative Tiefen werden erkannt.

12.07.2000

debis IT Security Services

Seite 58

Grundlagen, Forderungen und Marktübersicht für Intrusion Detection Systeme (IDS) und Intrusion Response Systeme (IRS)

Intrusion Detection und Intrusion Response - Grundlagen

2.5.4 Angriffe auf hoher Ebene (Applikationsebene) 2.5.4.1 Sendmail Der Vorgang kann mittels eines Proxys festgestellt werden.

2.5.4.2 Mail Spoofing Falls die unter MAIL FROM: eingetragene Adresse auf dem entsprechenden Rechner gültig ist, so kann Mail Spoofing nicht festgestellt werden. Ansonsten können die durchgeführten HOPs in der Mail Hinweise auf den tatsächlichen Pfad und somit auch über den ursprünglichen Sender liefern.

2.5.4.3 Überflutung mittels finger Das IDS kann feststellen, ob jemand den finger-Dienst angefordert hat. Es ist nicht feststellbar, ob die dabei gelieferte Information mißbraucht wird. Rekursive finger– Anfragen können entdeckt werden, indem ein Sniffer oder Proxy nach Mustern wie finger @@@@@@ Ausschau hält.

2.5.4.4 Verteilter koordinierter Angriff Kann mittels Schwellenwerten entdeckt werden, die festlegen, wieviele Verbindungen zu einem Port als normal gelten. Dies erfordert unter Umständen, daß das IDS die entsprechenden Ports beobachtet.

2.5.5 Angriffe auf das Authentisierungssystem

2.5.5.1 Lauschangriff Dies ist ohne aktive Überprüfungen nicht feststellbar.

2.5.5.2 Erraten von Paßwörtern Es kann überprüft werden, ob die Anzahl der erfolglosen Anmeldeversuche einen bestimmten Wert überschreitet. 12.07.2000

debis IT Security Services

Seite 59

Grundlagen, Forderungen und Marktübersicht für Intrusion Detection Systeme (IDS) und Intrusion Response Systeme (IRS)

Intrusion Detection und Intrusion Response - Grundlagen

2.5.5.3 Unberechtigtes Löschen von Dateien (Nur Windows NT) Ein solcher Vorgang kann unter der Voraussetzung, daß das Löschen protokolliert wird, mittels Anomalieerkennung festgestellt werden.

2.5.5.4 Microsoft Dot Dot Bug (nur Windows NT) Mittels eines HTTP-Proxy kann die kritische URL erkannt werden.

2.5.6 Einfuhr von Code mit Schadensfunktionalität (malicious code)

2.5.6.1 Viren Falls ein Virus mittels FTP eingeschleppt wird, kann der entsprechende Proxy die übermittelten Daten überprüfen – vorausgesetzt, sie sind nicht verschlüsselt und die Signatur ist bekannt. Alternativ kann, wie im folgenden beschrieben, auf Betriebssystemebene eine Virenüberprüfung der Applikationen erfolgen. Wie viele andere Angriffe auch können Viren heuristisch entdeckt werden. Die dabei verwendeten Heuristiken können z.B. Regeln wie „Kein Programm darf den Code eines anderen Programms modifizieren“ sein. Sobald ein Programm versucht, den Code eines anderen Programms zu verändern, wird ein Alarm ausgelöst. Dabei können natürlich auch Ausnahmen zugelassen werden, etwa um das Einspielen von Patches zu ermöglichen. Der Erfolg solcher Anwendungen hängt stark von der Dateistruktur des entsprechenden Betriebssystems ab. Je feiner ein Betriebssystem zwischen Dateikomponenten unterscheidet, um so genauer lassen sich die Heuristiken formulieren. Beispielsweise wird beim Betriebssystem Mac OS zwischen der Resource und der Data Fork einer Datei unterschieden. Systeme wie Windows oder Unix erlauben keine Unterscheidung zwischen Dateikomponenten.

2.5.6.2 Trojanische Pferde Ein Tripwire-System kann überprüfen, ob kritische Systemdateien modifiziert wurden.

12.07.2000

debis IT Security Services

Seite 60

Grundlagen, Forderungen und Marktübersicht für Intrusion Detection Systeme (IDS) und Intrusion Response Systeme (IRS)

Intrusion Detection und Intrusion Response - Grundlagen

2.5.6.3 Würmer Würmer können auf direkte oder indirekte Art entdeckt werden: Die direkte Methode überprüft Symptome wie erhöhte Netzaktivität, wohingegen die indirekte den Mißbrauch bekannter Sicherheitsschwächen (sekundäre Schwachstellen) festzustellen versucht (der bekannte Internet-Wurm von 1988 nutzte u.a. eine sendmail-Schwäche aus, um sich auszubreiten). Die direkte Methode erfordert die Überwachung eines größeren Netzes. Neben den sich ergebenden organisatorischen Schwierigkeiten ist nicht klar, ob diese Methode überhaupt zuverlässig funktioniert (insbesondere die Anzahl der Fehlalarme kann u.U. sehr hoch sein). Das einzige System, welches für sich in Anspruch nimmt, eine direkte Methode zu verwenden, ist GrIDS (vgl. [Staniford-Chen, et al., 1996]). Sobald der Netzverkehr einen gewissen Schwellenwert überschreitet, wird ein Alarm ausgelöst. Allerdings kann das Booten von sogenannten diskless clients (SUN ELC/SLC) auch dazu führen, daß die Netzlast ansteigt, ohne daß ein Angriff vorliegt. Der Erfolg der indirekten Methode stützt sich alleine auf das Erkennen des Ausnutzens der sekundären Schwachstellen. Es gibt keine allgemeine Methode, um Würmer indirekt zu entdecken.

2.5.6.4 Falltüren Die Existenz von Falltüren (trapdoors) ist mittels eines IDS nicht erkennbar. Jedoch kann die Installation eines Trapdoor-Programms mittels Integritätsprüfung (beispielsweise mittels tripwire) erkannt werden.

2.5.7 Probleme beim Einsatz von WWW-spezifischer Software

2.5.7.1 Java Falls ein TCP-Paket Java-Code enthält, so kann dies festgestellt werden, indem das IDS nach Schlüsselwörtern wie volatile, transient, instanceof etc. sucht. Es ist dabei nur schwer feststellbar, ob es sich um harmlosen oder gefährlichen Code handelt. Der Einsatz von Programme, die ähnlich wie Viren-Scanner arbeiten kann hier weiterhelfen.

2.5.7.2 Cookies Ein IDS kann genauso wie ein Browser feststellen, ob ein Cookie übermittelt wird. Es kann nicht festgestellt werden, ob ein Cookie dazu mißbraucht wird, einen Angriff vorzubereiten. 12.07.2000

debis IT Security Services

Seite 61

Grundlagen, Forderungen und Marktübersicht für Intrusion Detection Systeme (IDS) und Intrusion Response Systeme (IRS)

Intrusion Detection und Intrusion Response - Grundlagen

2.5.7.3 ActiveX In Analogie zu Java-Code kann hier überprüft werden, ob ActiveX-Code übermittelt wird. Es kann nicht festgestellt werden, ob dieser Code Schaden anrichtet (außer es sind bestimmte Code-Signaturen bekannt).

2.5.7.4 CGI Vom Standpunkt der Sicherheit aus sollten CGI-Skripts wie Programme behandelt werden. Sie können Schwachstellen haben, die sich ein Angreifer zu Nutze machen kann. In diesem Zusammenhang läßt sich keine pauschale Aussage zu CGI-Skripts machen. Jedes Skript muß gesondert auf Schwachstellen hin überprüft werden.

2.5.7.5 MIME Vgl. Java und ActiveX

2.5.7.6 WWW Spoofing Das IDS kann den übertragenen HTTP-Code mittels eines Sniffers oder eines Proxys analysieren. Muster im Code wie http://<something>/http:// können so erkannt werden.

2.5.8 Zusammenfassung Die folgende Tabelle faßt die in diesem Kapitel besprochenen Angriffe zusammen. Die Spalte Name gibt an, um welchen Angriff es sich handelt. Die Spalten Signaturanalyse und Anomalieerkennung kennzeichnen, ob der Angriff mit der entsprechenden Methode erkennbar ist. Dabei wird die Effektivität der Erkennung wie folgt gekennzeichnet: +

:

Der Angriff ist mit dieser Methode erkennbar

-

:

Der Angriff ist mit dieser Methode nicht erkennbar

(+) :

12.07.2000

Die Anwendung der entsprechenden Methode ist fragwürdig. Zum Beispiel kann das Schlüsselwort DEBUG zuverlässig mittels Signaturanalyse erkannt werden. Es könnte auch mit Anomalieerkennung erkannt werden, falls das Nichtvorkommen von DEBUG als ”normal” definiert wurde. Allerdings sind die Anwendungsmodalitäten und die Praktikabilität der Methode fragwürdig.

debis IT Security Services

Seite 62

Grundlagen, Forderungen und Marktübersicht für Intrusion Detection Systeme (IDS) und Intrusion Response Systeme (IRS)

Intrusion Detection und Intrusion Response - Grundlagen

Da bestimmte Verfahren nicht absolut zuverlässig sind (z.B. schwellwertgesteuerte Signaturanalyse), werden die Felder korrekt und vollständig eingeführt, um die Zuverlässigkeit der betreffenden Methode zu kennzeichnen. Korrekt bedeutet: Falls das IDS einen Alarm auslöst, so fand tatsächlich ein Angriff statt. Vollständig beschreibt die umgekehrte Richtung: Falls ein System angegriffen wird, so wird auch garantiert ein Alarm ausgelöst. Diese beiden Begriffe werden hier in einem schwächeren Sinne benutzt: Eine Methode erkennt einen Angriff korrekt, falls es nicht zu übermäßig vielen Fehlalarmen kommt.6 Das Feld Datenquelle gibt die höchste Ebene an, auf der der entsprechende Angriff erkannt werden kann (vgl. dazu auch die Bemerkungen am Anfang dieses Abschnitts). Das Feld Bemerkungen enthält kurze Hinweise darauf, wie der Angriff zu erkennen ist. Genauere Beschreibungen sind im referierten Abschnitt nachzulesen. Die Spalte Erkennungstechnik gibt an, mit welcher Erkennungstechnik gemäß des in Abschnitt 2.4.2 vorgestellten Klassifikationsschemas der Angriff erkannt werden kann. Wir wollen diese Begriffe am Beispiel einer SYN-Überflutung illustrieren: Name

SYNÜberflutung

Sig. Anom. korrekt Analy. Detec

+

1)

+

+

vollst. Datenquelle

-

SNIFF LOG

Bemerk. ErkennungsUnd technik Referenz 2.3.2.7 2.5.2.7

Prolif. TCP/IP

Hier wird beschrieben, daß der unter 2.3.2.7 und 2.5.2.7 beschriebene Angriff der SYNÜberflutung mittels Signaturanalyse mit Schwellenwert (durch die Endnote angedeutet) und Anomalieerkennung korrekt erkannt werden kann. Der Angriff kann allerdings von keiner Methode vollständig erkannt werden (da der Schwellenwert einfach genau um 1 zu hoch gesetzt sein kann). Die notwendigen Daten kann die Analysekomponente dabei von einem Sniffer oder aus Logbucheinträgen beziehen (falls SYN-Versuche protokolliert werden). Die Erkennungstechnik gemäß des Klassifikationsschemas aus Abschnitt 2.4.2 ist in der letzten Spalte beschrieben. Eine Beschreibung der Endnoten 1) – 6) befindet sich am Ende der Tabelle.

6

Obwohl dies alles andere als eine formal präzise Definition ist, läßt sich doch mit der Vewendungsweise dieser

Begriffe eine praktisch nützliche Aussage treffen. Sehr schön wäre es natürlich, ein formales Modell zu entwickeln, welches die Fehlerwahrscheinlichkeit des Verfahrens miteinbezieht (vergleichbar zum PAC-Modell von Valiant [Valiant, 1984]). Da es allerdings keine mathematische Definition eines Angriffs gibt, sind solche Modelle nicht übertragbar. Dasselbe gilt übrigens auch für die sogenannten „Beweise“, daß das Virenerkennungproblem unentscheidbar ist – die Menge der Viren ist mathematisch überhaupt nicht definiert. Infolgedessen läßt sich auch kein Entscheidungsproblem für diese Menge aufstellen. 12.07.2000

debis IT Security Services

Seite 63

Grundlagen, Forderungen und Marktübersicht für Intrusion Detection Systeme (IDS) und Intrusion Response Systeme (IRS)

Name

Intrusion Detection und Intrusion Response - Grundlagen

Sig. Anom korrekt vollst Daten- Bemerk. Analy. Detec. quelle und Referenz

Erkennungstechnik

TCP Active Port Scan

+1)

+

+

-

LOG

2.3.1.1 2.5.1.1

Prolif TCP/IP

TCP Half Open Scan

+1)

+

+

-

SNIFF 2.3.1.1 LOG 2.5.1.1

Prolif. TCP/IP

TCP Stealth Scanning

+1)

+

+

-

SNIFF FIN Symptom 2.3.1.1 2.5.1.1

Prolif. TCP/IP

RPC Stealth Scan

+

1)

+

+

-

SNIFF PROC 0 2.3.1.1 2.5.1.1

Prolif. TCP/IP; charakteristische Zeichenkette

UDP Port Scan

+

1)

+

+

-

SNIFF ICMP Port Unavailable Nachrichten 2.3.1.2 2.5.1.2

Prolif. UDP

Finger

+

(+)

+

+

LOG

6)

2.3.1.3 2.5.1.3 Rusers

+

(+)

+

+

LOG

6)

2.3.1.3 2.5.1.3 Netstat

+

(+)

+

+

LOG

6)

2.3.1.3 2.5.1.3 Rstatd

+

(+)

+

+

LOG

6)

2.3.1.3 2.5.1.3 Systat

+

(+)

+

+

LOG

6)

2.3.1.3 2.5.1.3 12.07.2000

debis IT Security Services

Prolif. Befehle; charakteristische. Zeichenkette charakteristische . Zeichenkette

charakteristische . Zeichenkette

charakteristische . Zeichenkette

charakteristische . Zeichenkette

Seite 64

Grundlagen, Forderungen und Marktübersicht für Intrusion Detection Systeme (IDS) und Intrusion Response Systeme (IRS)

Name

Identd

Intrusion Detection und Intrusion Response - Grundlagen

Sig. Anom korrekt vollst Daten- Bemerk. Analy. Detec. quelle und Referenz +

(+)

+

+

LOG

6)

2.3.1.3 2.5.1.3 Whois

+

(+)

+

+

LOG

6)

2.3.1.3 2.5.1.3 Rwho

+

(+)

+

+

LOG

6)

2.3.1.3 2.5.1.3 Nbstat

+

(+)

+

+

LOG

6)

2.3.1.3 2.5.1.3

Erkennungstechnik

charakteristische . Zeichenkette

charakteristische . Zeichenkette

charakteristische . Zeichenkette

charakteristische . Zeichenkette

ARP Spoofing

+

+

-

+

SNIFF nur vom internen Netz möglich 2.3.2.1 2.5.2.1

Integritätsverletzung; charakteristische . Zeichenkette

IP Fragmentierung

+

(+)

+

+

SNIFF 2.3.2.2 2.5.2.2

charakteristische . Zeichenkette

Fragmentierte SYN-Pakete mit Reserved Bit Check

+

(+)

+

+

SNIFF 2.3.2.2 2.5.2.2

charakteristische . Zeichenkette

Falsche IP Parameter

+

(+)

+

+

SNIFF 2.3.2.2 2.5.2.2

charakteristische . Zeichenkette

SYN mit unerreichbarer SRC

-

+

-

-

2.3.2.2 2.5.2.2

Prolif. TCP/IP

CPU-Angriffe

+

(+)

2.3.2.2 2.5.2.2

charakteristische . Zeichenkette

12.07.2000

Proxy

debis IT Security Services

Seite 65

Grundlagen, Forderungen und Marktübersicht für Intrusion Detection Systeme (IDS) und Intrusion Response Systeme (IRS)

Name

Intrusion Detection und Intrusion Response - Grundlagen

Sig. Anom korrekt vollst Daten- Bemerk. Analy. Detec. quelle und Referenz

Erkennungstechnik

NT IIS Absturz

+

-

-

-

Proxy

2.3.2.2 2.5.2.2

charakteristische . Zeichenkette

ICMP Redirect

+

(+)

+

+

SNIFF 2.3.2.3 2.5.2.3

charakteristische . Zeichenkette

ICMP Destination Unreachable

-

-

ICMP echo request (Ping of Death)

+

+

+

+

SNIFF 2.3.2.3 2.5.2.3

ICMPZeitstempel

-

-

-

-

2.3.2.3 2.5.2.3

+2)

+

+

-

ICMP Tunnel2)

2.3.2.3 2.5.2.3

SNIFF ICMP-Pakete sollten einen Zeitstempel im Datumsfeld haben

Keine

charakteristische . Zeichenkette

Keine

charakteristische . Zeichenkette oder Zustandsüberführung

2.3.2.3 2.5.2.3 IP Spoofing

+

(+)

+

+

LOG

nur gefälschte Integritätsinnere verletzung Adressen

2.3.2.4 2.5.2.4 TCP Sequenznummernvorhersage

12.07.2000

+

1)

+

+

-

LOG

debis IT Security Services

2.3.2.4 2.5.2.4

Iterat. Auth.; Prolif. TCP/IP

Seite 66

Grundlagen, Forderungen und Marktübersicht für Intrusion Detection Systeme (IDS) und Intrusion Response Systeme (IRS)

Name

DNS Spoofing

Intrusion Detection und Intrusion Response - Grundlagen

Sig. Anom korrekt vollst Daten- Bemerk. Analy. Detec. quelle und Referenz +

1)

(+)

+

-

SNIFF dicht

Erkennungstechnik

Prolif. TCP/IP

aufsteigende Query IDs

2.3.2.4 2.5.2.4 RIP Spoofing

-

-

-

-

2.3.2.4 2.5.2.4

Source Routing

+

(+)

+

+

SNIFF 2.3.2.5 2.5.2.5

charakteristische . Zeichenkette

Session Hijacking

+

1)

(+)

+

-

SNIFF ACK Stürme 2.3.2.6 2.5.2.6

Prolif. TCP/IP

E-MailÜberflutung

+

1)

+

+

-

LOG

Keine

Große Prolif. Bedarf an Volumina an Betriebsmitteln E-Mail können auch normal sein

2.3.2.7 2.5.2.7 SYNÜberflutung

+

1)

+

+

-

SNIFF 2.3.2.7 LOG 2.5.2.7

Prolif. TCP/IP

LogbuchÜberflutung

+1)

+

+

-

LOG

Prolif. Bedarf an Betriebsmitteln

vgl. E-MailÜberflutung

2.3.2.7 2.5.2.7 DataÜberflutung

-

+

-

-

SNIFF Nur manche LOG Ports

Prolif. Bedarf an Betriebsmitteln

protokollieren

2.3.2.7 2.5.2.7

12.07.2000

debis IT Security Services

Seite 67

Grundlagen, Forderungen und Marktübersicht für Intrusion Detection Systeme (IDS) und Intrusion Response Systeme (IRS)

Name

Intrusion Detection und Intrusion Response - Grundlagen

Sig. Anom korrekt vollst Daten- Bemerk. Analy. Detec. quelle und Referenz

Erkennungstechnik

Open/CloseÜberflutung

+

1)

+

-

-

SNIFF 2.3.2.7 2.5.2.7

Prolif TCP/IP

AppleTalk Kapselung2)

+2)

-

-

-

SNIFF 2.3.2.8 2.5.2.8

charakteristische . Zeichenkette oder Zustandsüberführung

IPX Encapsulation2)

+

2)

-

-

-

SNIFF 2.3.2.8 2.5.2.8

charakteristische . Zeichenkette oder Zustandsüberführung

+

2)

-

-

-

SNIFF 2.3.2.8 2.5.2.8

charakteristische . Zeichenkette oder Zustandsüberführung

LOG

2.3.3.1 2.5.3.1

Integritätsverletzung; charakteristische . Zustandsüberführung

2.3.3.1 2.5.3.1

Keine

IP Kapselung

2)

DNS Cache Verunreinigung

+

(+)

+

+

Reverse Lookup

-

-

-

-

NIS

-3)

+3)

+

+

Proxy.

2.3.3.2 2.5.3.2

charakteristische . Zustandsüberführung; Integritätsverletzung

Aktive/Passiv FTP

+1)

+

+

-

SNIFF 2.3.3.3 2.5.3.3

charakteristische . Zustandsüberführung

FTP Paßwortangriff

+1)

+

-

-

LOG

Iterat. Auth.

12.07.2000

debis IT Security Services

2.3.3.3 2.5.3.3

Seite 68

Grundlagen, Forderungen und Marktübersicht für Intrusion Detection Systeme (IDS) und Intrusion Response Systeme (IRS)

Name

Intrusion Detection und Intrusion Response - Grundlagen

Sig. Anom korrekt vollst Daten- Bemerk. Analy. Detec. quelle und Referenz

Fehlerhafte FTP Konfiguration

+

Login: NULL

4)

Erkennungstechnik

+

+

-

Proxy

2.3.3.3 2.5.3.3

Integritätsverletzung

+

(+)

+

+

LOG

2.3.3.3 2.5.3.3

Integritätsverletzung

TFTP

-

-

-

-

2.3.3.3 2.5.3.3

Integritätsverletzung

HTTP Umgehen v. Paßwörtern

+

+

+

+

SNIFF 2.3.3.4 2.5.3.4

charakteristische . Zeichenkette

X11

-

+

-

-

Proxy.

charakteristische . Zustandsüberführung

SMB Crash

+

-

+

+

SNIFF 2.3.3.6 2.5.3.6

charakteristische . Zeichenkette

Erraten des NFS DateiHandles

+1)

+

-

-

LOG

Iterat. Auth. Prolif. UDP

sehr schwierig 2.3.3.5 2.5.3.5

file-handle probing zählen

2.3.3.7 2.5.3.7 NFS Exportliste

-

-

-

-

2.3.3.7 2.5.3.7

Keine

NFS mountd

-

-

-

-

2.3.3.7 2.5.3.7

Keine

sendmail debug

+

(+)

+

+

2.3.4.1 2.5.4.1

charakteristische . Zustandsüberführung oder Zeichenkette

E-Mail Spoofing

-

+

-

-

2.3.4.2 2.5.4.2

Integritätsverletzung

12.07.2000

LOG Proxy.

debis IT Security Services

Seite 69

Grundlagen, Forderungen und Marktübersicht für Intrusion Detection Systeme (IDS) und Intrusion Response Systeme (IRS)

Name

Intrusion Detection und Intrusion Response - Grundlagen

Sig. Anom korrekt vollst Daten- Bemerk. Analy. Detec. quelle und Referenz

Erkennungstechnik

Überflutung mittels finger

+

+

+

+

SNIFF suchen nach charakteristische . finger Zeichenkette @@@ 2.3.4.3 2.5.4.3

Verteilter, koordinierter Angriff

-

+

-

-

LOG

Lauschangriff

-

-

-

-

2.3.4.4 2.5.4.4

Prolif. TCP/IP

2.3.5.1 2.5.5.1

Keine

2.3.5.2 2.5.5.2

Iterat. Auth.

2.3.5.3 2.5.5.3

Integritätsverletzung

Erraten von Paßwörtern

+

1)

+

+

-

Unerlaubtes Löschen v. Dateien

-

+

+

+

Microsoft Dot Dot Bug

+

(+)

+

+

Proxy.

2.3.5.4 2.5.5.4

charakteristische . Zeichenkette

Virus

+

-

+

+

Proxy.

2.3.6.1 2.5.6.1

charakteristische . Zeichenkette, Prolif sys-rsrc; Integritätsverletzung

Trojanisches Pferd

-

+

+

-

Tripwire

2.3.6.2 2.5.6.2

Integritätsverletzung

Würmer

-

+

-

-

SNIFF vgl. GrIDS 2.3.6.3 2.5.6.3

Prolif. TCP/IP

Hintertüren (Trapdoors)

-

+

+

-

Tripwire

2.3.6.4 2.5.6.4

Integritätsverletzung

5)

-

-

-

Proxy

2.3.7.1 2.5.7.1

charakteristische . Zeichenkette

Java

12.07.2000

+

LOG

debis IT Security Services

Seite 70

Grundlagen, Forderungen und Marktübersicht für Intrusion Detection Systeme (IDS) und Intrusion Response Systeme (IRS)

Name

Intrusion Detection und Intrusion Response - Grundlagen

Sig. Anom korrekt vollst Daten- Bemerk. Analy. Detec. quelle und Referenz

Erkennungstechnik

Cookies

+

5)

-

-

-

Proxy

2.3.7.2 2.5.7.2

charakteristische . Zeichenkette

ActiveX

+5)

-

-

-

Proxy

2.3.7.3 2.5.7.3

charakteristische . Zeichenkette

-

-

-

-

2.3.7.4 2.5.7.4

Keine

MIME

+5)

-

-

-

Proxy

2.3.7.5 2.5.7.5

charakteristische . Zeichenkette

WWW Spoofing

+

(+)

+

+

Proxy.

2.3.7.6 2.5.7.6

charakteristische . Zeichenkette

CGI

Tabelle 1: Übersicht über Angriffe auf Rechner und Rechnernetze 1) mit Schwellenwerten erkennbar 2) ein typischer Kapselungs- bzw. Tunnelangriff: Bekannte Protokolle können entdeckt werden. Es kann nicht entdeckt werden, ob die durch den Tunnel gesendeten Daten Schaden verursachen können. Außerdem muß es auf der Gegenseite ein Programm geben, welches die Daten entgegennimmt. 3) erkennbar, falls am externen, eingehenden Port eine interne IP-Adresse ankommt. Sonst nicht erkennbar. 4) Angreifer kann Benutzerrechte erlangen 5) Es kann erkannt werden, ob Java-, ActiveX- oder MIME-Code übermittelt wird. Es kann nicht festgestellt werden, ob dieser Code Schaden verursacht. 6) Es kann nicht entdeckt werden, ob die hierbei erhaltenen Informationen mißbraucht werden.

2.6 Der praktische Einsatz von ID-Systemen Die praktischen Aspekte beim Einsatz von ID-Systemen sind noch sehr unzureichend untersucht und es existieren kaum Erfahrungsberichte. Dies gilt in besonderem Maße für die Anomalieerkennung, für deren Einsatz wenig statistische Werkzeuge zur Verfügung stehen. Die Mißbrauchsanalyse hingegen kann einige sich im praktischen Einsatz befindende 12.07.2000

debis IT Security Services

Seite 71

Grundlagen, Forderungen und Marktübersicht für Intrusion Detection Systeme (IDS) und Intrusion Response Systeme (IRS)

Intrusion Detection und Intrusion Response - Grundlagen

Produkte vorweisen. Wie bereits erwähnt, können hier mittels Signaturanalyse Angriffe mit einem hohen Korrektheitsgrad erkannt werden. Gibt es zu einem Angriff eine Signatur, so wächst der zu betreibende Aufwand zur Erkennung des Angriffs exponentiell in Abhängigkeit vom Effektivitätsgrad des Angriffs. Bei der Anomalieerkennung verhält es sich umgekehrt: der Aufwand bei der Erkennung wächst logarithmisch mit der Effektivität des Angriffs.

Anomalieerkennung Erkennungsaufwand

Mißbrauchserkennung

Effektivität des Angriffs Abbildung 2: Aufwandsunterschiede bei der Angriffserkennung Ein COTS (Commercial-of-the-Shelf) ID-System muß in verschiedensten Umgebungen mit unterschiedlichen Sicherheitsrichtlinien zuverlässig arbeiten können. Das IDS selbst muß vor möglichen Angriffen sicher geschützt sein. Dazu gehört auch der Schutz von IDS-Konfigurationsdateien, Signaturdatenbank, den Monitormeldungen – insbesondere der Auditdaten. Falls ein Angreifer in der Lage ist, sich die Benutzerprofile der Anomalieerkennungskomponente zu besorgen, so kann er damit Rückschlüsse auf die Verhaltensweisen ziehen, die garantiert keinen Alarm auslösen werden. Ein mögliches Ziel für den Angreifer ist auch der Administrator-Account des IDS. Ist dieser Account kompromittiert, so hat der Angreifer damit die Möglichkeit, den Schutz durch das IDS unwirksam zu machen. Die Benutzerschnittstelle des IDS ist maßgeblich am erfolgreichen Einsatz eines ID-Systems beteiligt. Das IDS sollte in der Lage sein, die gemeldeten Alarme nach vordefinierten Prioritäten zu sortieren. Es muß bei jedem gemeldeten Alarm nachvollzogen werden können, wodurch dieser ausgelöst wurde. Neben ihrer Alarmfunktion werden ID-Systeme auch als Untersuchungswerkzeug zur Angriffsanalyse eingesetzt. Dazu gehört auch, die Untersuchungsergebnisse festhalten zu können. Dies ist besonders dann wichtig, wenn verschiedene Administratoren für die Aufrechterhaltung des Rechnerbetriebs verantwortlich sind. 12.07.2000

debis IT Security Services

Seite 72

Grundlagen, Forderungen und Marktübersicht für Intrusion Detection Systeme (IDS) und Intrusion Response Systeme (IRS)

Intrusion Detection und Intrusion Response - Grundlagen

2.6.1 Voraussetzungen für Anomalieerkennung Der Ursprung der Anomalieerkennung lag in dem Bedarf, Benutzer, die unter falschem Account agieren, zu entdecken. So sollte es zum Beispiel möglich sein, festzustellen, ob Herr Hacker unter dem Account von Herrn Ahnunglos agiert. Dabei wird sich Herr Hacker anders verhalten als Herr Ahnungslos. Anomale Aktivität muß nicht notwendigerweise einen Mißbrauch darstellen. Vom ID-Standpunkt aus bedeutet anomales Verhalten lediglich ein vom üblichen Benutzerverhalten abweichendes Verhalten, wobei folgende Parameter zur Betrachtung herangezogen werden: •

Seitenwechselrate

•

CPU-Last

•

Anzahl der Telnet-Anforderungen während eines Zeitraums

•

Anzahl der aktiven Ports

•

etc.

Eine solche Ansammlung von Parametern wird als Situation bezeichnet. Eine Situation kann benutzerspezifisch sein (z.B. Herr Soundso verbraucht viel CPU-Zeit), systemspezifisch (z.B. der Rechner telnetserver.com hat immer alle Ports zwischen 20 und 30 geöffnet) oder auch gruppenspezifisch etc. Ein IDS benötigt zur Anomalieerkennung die folgende Information: •

Welche Teilmengen von Systemparametern bilden eine Situation (im obigen Sinne)?

•

Welche Werte haben diese Parameter normalerweise?

Der SSO muß die entsprechenden Parameter wählen und deren Normwerte bestimmen. Obwohl es nicht zu den Hauptaufgaben eines IDS gehört, sollte ein IDS mit Anomalieerkennung auch Unterstützung beim Erstellen von Benutzerprofilen geben. Insbesondere ist eine Unterstützung während der sogenannten Trainingsphase notwendig. Die gelieferten Auditdaten müssen auf der einen Seite ausreichend sein, dürfen aber nicht detaillierter als notwendig sein, da das Erstellen von Auditdaten einen negativen Einfluß auf die Gesamtperformanz hat. Abhängig von Größe und Archivierungszeiträumen der Auditdatenmengen ist zusätzlicher Plattenplatz notwendig. Das IDS muß darüber hinaus das Einspielen und Erzeugen von Updates der Benutzerprofile unterstützen. Falls sich die Netztopologie ändert, muß das IDS leicht an die neue Topologie anpaßbar sein. Neue Angriffe erfordern es unter Umständen, daß neue Situationen (im obigen Sinne) erstellt werden müssen. Hierbei muß der Umstieg von den alten Parametern auf die neuen unterstützt werden (z.B. Übernahme/Anpassung der bestehenden Werte). Werkzeuge zur Anomalieerkennung können verschiedene Möglichkeiten zur Erstellung der Benutzerprofile anbieten. Entweder wird ein Standardprofil mit ausgeliefert, welches dann an 12.07.2000

debis IT Security Services

Seite 73

Grundlagen, Forderungen und Marktübersicht für Intrusion Detection Systeme (IDS) und Intrusion Response Systeme (IRS)

Intrusion Detection und Intrusion Response - Grundlagen

das tatsächliche Benutzerverhalten angepaßt wird, oder bereits erstellte Auditdaten werden dem IDS erneut vorgespielt. Das Problem des initialen Benutzerprofils stellt sich auch für jeden neuen Benutzer. Die Erstellung geeigneter Benutzerprofile kann mit Hilfe eines statistischen Inferenzsystems erfolgen. Dabei sollte auf jeden Fall berücksichtigt werden, daß solche Verfahren (ähnlich wie Maschinelles Lernen oder Neuronale Netze) noch Gegenstand der aktuellen Forschung sind. Anomalieerkennung kann von der Verfügbarkeit guter statistischer Inferenzsysteme profitieren, sobald diese verfügbar sein werden. Die Vorteile der Anomalieerkennung sind unter anderem: •

Möglichkeit der Angriffsentdeckung ohne a priori-Wissen über den Angriff oder die betreffenden Systemschwächen

•

Möglichkeit, Angreifer zu entdecken, die unter falschem Benutzeraccount arbeiten, ohne dabei expliziten Mißbrauch zu verursachen

•

Der Ansatz der Anomalieerkennung basiert auf der allgemeinen Auditfähigkeit eines Betriebssystems. Er ist nicht auf ein spezielles Betriebssystem beschränkt.

Die Nachteile der Anomalieerkennung beinhalten Punkte wie: •

Die Wahl der Parametereinstellungen ist kritisch und darüber hinaus von der Verhaltensweise des Gesamtsystems abhängig. Dies kann zu Fehlalarmen bzw. auch zum Übersehen von Angriffen führen.

•

Anomalieerkennung ist noch weit von einer praktischen Einsetzbarkeit entfernt.

2.6.2 Voraussetzungen für Mißbrauchserkennung Mißbrauchserkennung hat das Ziel, unerwünschte Benutzeraktivität zu entdecken. Im Gegensatz zum Begriff der “normalen Situation”, wie er bei der Anomalieerkennung verwendet wird, hängt der Begriff des “Mißbrauchs” nicht vom Benutzerverhalten ab. Ein Mißbrauch ist ein vordefiniertes Muster, welches das Ausnutzen einer Systemschwachstelle, bösartigen Code (Viren) etc. beschreibt. Mißbrauchserkennung kann mittels Signaturanalyse durchgeführt werden. Es sind zwei Typen von Signaturanalyse zu unterscheiden •

Reine Signaturanalyse (Schwellenwert = 0)

•

schwellwertgesteuerte Signaturanalyse (Schwellenwert ≥ 0)

12.07.2000

debis IT Security Services

Seite 74

Grundlagen, Forderungen und Marktübersicht für Intrusion Detection Systeme (IDS) und Intrusion Response Systeme (IRS)

Intrusion Detection und Intrusion Response - Grundlagen

Reine Signaturanalyse bedeutet: Sobald in den Auditdaten eine Angriffssignatur gefunden wurde, wird ein Alarm ausgelöst. Schwellwertgesteuerte Signaturanalyse zählt die Vorkommen bestimmter Angriffsmuster in den Auditdaten. Wenn diese Anzahl einen gewissen Wert überschreitet, wird ein Alarm ausgelöst. Reine Signaturanalyse kann als Spezialfall von schwellwertgesteuerter Signaturanalyse aufgefaßt werden. Vorteile der Mißbrauchserkennung sind u.a.: •

Da Angriffe gegen Rechnersysteme häufig auf Basis von Angriffskripten durchgeführt werden, lassen sich aus diesen leicht Signaturen ableiten. Daher können mittels Signaturanalyse die meisten Angriffe zuverlässig erkannt werden.

•

Der Aufwand zur Installation und Wartung eines IDS mit Signaturanalyse ist relativ gering (vorausgesetzt, die Signaturen müssen nicht vom Anwender entwickelt werden).

•

Die Erkennung eines Angriffs ist effizient (Komplexität von “String Matching”Algorithmen).

•

Falls eine Angriffssignatur in den Auditdaten vorkommt, so kann nach der Alarmmeldung schnell festgestellt werden, ob es sich tatsächlich um einen Angriff handelt oder nicht.

Nachteile der Mißbrauchserkennung sind u.a.: •

Der Erfolg hängt unmittelbar von der Güte der Signaturdatenbank ab. Zu jedem Angriff muß eine individuelle Signatur erstellt werden. Falls ein Angriffsmuster in der Datenbank nicht vorkommt, wird ein entsprechender Angriff nicht erkannt.

•

Ein bekannter Angriff kann leicht abgewandelt werden, so daß er nicht mehr von der Signaturanalyse erkannt wird, dennoch aber die Sicherheit gefährdet.

•

Die Signaturdaten sind von dem zu schützenden Zielsystem abhängig und wenig portabel.

•

Unter Umständen ist eine Anpassung der Signaturdaten an das lokale System notwendig. Dies ist sehr aufwendig, da das proprietäre Format der Signaturdatenbanken und das Fehlen geeigneter Werkzeuge die Anpassung dieser Datenbanken bei COTS-Produkten nahezu unmöglich machen.

2.6.3 Voraussetzungen Anomalieerkennung

für

einen

hybriden

Einsatz

von

Mißbrauchs-

und

Die beiden Ansätze “Mißbrauchserkennung” und “Anomalieerkennung” können so kombiniert werden, daß Nachteile der einen Methode durch einen Vorteil der anderen 12.07.2000

debis IT Security Services

Seite 75

Grundlagen, Forderungen und Marktübersicht für Intrusion Detection Systeme (IDS) und Intrusion Response Systeme (IRS)

Intrusion Detection und Intrusion Response - Grundlagen

ausgeglichen werden. Durch den Einsatz eines hybriden Systems können nicht nur bekannte Angriffe erkannt werden, für die bereits Signaturen existieren, sondern auch bis dahin unbekannte Angriffe. So kann die fast vollständige Ausschöpfung der erlaubten Anmeldeversuche keiner Angriffssignatur entsprechen, jedoch kann dies für einen bestimmten Account ein anomales Verhalten darstellen. Dieser kann dann vom SSO genauer überprüft werden. Vorteile der hybriden Erkennung sind u.a.: •

Ererbung der Vorteile von Anomalieerkennung und Mißbrauchserkennung

•

Beseitigen vieler Nachteile der Teilverfahren

Nachteile der hybriden Erkennung sind u.a.: •

Die hybride Erkennung ererbt die Summe des Administrationsaufwands der beiden Teilansätze Anomalieerkennung und Mißbrauchserkennung.

•

Produkte, die beide Verfahren kombinieren, sind noch nicht ausgereift. Insbesondere die Anomalieerkennung ist noch nicht praktisch einsetzbar.

2.6.4 Aufwand vs. Sicherheit Ähnlich wie bei vielen anderen heute verfügbaren Sicherheitswerkzeugen lassen sich die Wartungs- und Betriebskosten bei ID-Systemen schlecht abschätzen, wohingegen die initialen Kosten (Produkt, Installation) noch anhand der Einstandspreise abschätzbar sind.. Insbesondere ist der Aufwand für die Trainingsphase bei Anomalieerkennung (auch Burn-InPhase genannt) schlecht abschätzbar.. Dazu kommt, daß diese auch hohe Nebenkosten durch eine instabile Systemumgebung bedingt. Die Kosten, um ein sicheres System zu etablieren, sind u.a. von folgenden Faktoren abhängig: •

Wie hoch ist die Expertise der Administratoren?

•

Welche Werkzeuge stehen zum Modellieren der Signaturen zur Verfügung?

•

Wie geschickt und effektiv sind die zu behandelnden Angriffe?

•

Was für Betriebssysteme sind betroffen?

•

Welche Anwendungen werden eingesetzt? Viele Programme sind für ihre immanenten Sicherheitsschwächen bekannt, andere sind für ihre Implementierungsfehler berüchtigt.

12.07.2000

debis IT Security Services

Seite 76

Grundlagen, Forderungen und Marktübersicht für Intrusion Detection Systeme (IDS) und Intrusion Response Systeme (IRS)

Intrusion Detection und Intrusion Response - Grundlagen

•

Welche Informationsquellen müssen nach neuen Angriffen untersucht werden? Mailinglisten wie NTSEC (Windows NT Security) enthalten viel redundante und unwichtige Information.

•

Wie gut ist die Qualität der zu Verfügung stehenden Information? Einige Mailinglisten wie z.B. bugtraq sind moderiert. Dadurch erhalten die Abonnenten nur relevante Nachrichten.

Unter Berücksichtigung der o.g. Aspekte kann dennoch versucht werden, die verschiedenen Kosten bei den unterschiedlichen Erkennungsverfahren miteinander zu vergleichen. Wie zu erwarten, wächst die Sicherheit unterproportional mit dem Aufwand, der bei Wartung und Installation des IDS betrieben wird. Folgende Kategorien von IDS-gesicherten Rechnersystemen werden im folgenden betrachtet (hierbei ist die triviale Kategorie eines ungesicherten Systems mit einbezogen). Reines BS ohne Patches: Ist diesem Fall ist kein IDS installiert. Auch auf das Einspielen von Patches wurde verzichtet. Die Sicherheit des Systems ist noch immer wie „out-of-the-box“ und damit verschwindend gering. Der zu betreibende Aufwand bei der Sicherheitsadministration ist nahezu Null. Reines BS mit Patches: Die Installation der neuesten Patches sichert ein Rechnersystem gegen das Ausnutzen bekannter Sicherheitsschwächen. Für viele Schwächen werden jedoch vom Hersteller prinzipiell keine Patches angeboten. Für andere Schwächen sind die prinzipiell angebotenen Patches über längere Zeit nicht verfügbar. Patches können Systeme auch nur gegen spezielle bekannte Angriffe schützen. BS mit Signaturanalyse: Die zusätzliche Installation eines IDS mit Signaturanalyse erfordert geringen administrativen Aufwand. Das Einbringen vom Hersteller gelieferter neuer Signaturdaten übersteigt auf keinen Fall den Aufwand beim Installieren von Patches. Dies gilt insbesondere für ID-Systeme, die in der Lage sind, viele Rechner gleichzeitig zu überwachen. Man erhält ein System mit relativ guten Sicherungs- und Erkennungsmechanismen für bekannte Angriffe. Indem die Signaturdatenbank selbständig erweitert und den eigenen Bedürfnissen anpaßt wird, kann zusätzliche Sicherheit gewonnen werden. Dies erfordert jedoch einen hohen Aufwand, da ein sehr genaues Verständnis der Angriffe notwendig ist. BS mit Anomalieerkennung: Der Nachteil der Anomalieerkennung besteht darin, daß die sogenannte Burn-in-Phase sehr viel Aufwand erfordert. Darüber hinaus ist eine ständige Wartung unabdingbar, um die Fehlalarmquote niedrig zu halten. Funktioniert alles wie gewünscht, so liegt ein System vor, welches relativ gut auch gegen unbekannte Angriffe schützt. Die folgende Tabelle faßt das oben Gesagte zusammen. Für den zu betreibenden Aufwand wird – unter Berücksichtigung der oben genannten Einflußfaktoren – eine untere Schranke 12.07.2000

debis IT Security Services

Seite 77

Grundlagen, Forderungen und Marktübersicht für Intrusion Detection Systeme (IDS) und Intrusion Response Systeme (IRS)

Intrusion Detection und Intrusion Response - Grundlagen

angegeben (die möglichst an der kleinsten oberen liegen soll). Die Abschätzung erfolgt für ein Netz mit ca. 250 Unix-Maschinen. Komponente

Update

Sicherheit

Sicherheit

in bezug auf bekannte

in bezug auf

Installationsaufwand

Wartungsaufwand

unbekannte

(in Manntagen

(in MT pro

[MT])

Woche)

Angriffe

Angriffe

(0: niedrig;

(0: niedrig;

9: hoch)

9: hoch)

Reines BS (kein IDS, keine Patches)

–

0

0

N.A.

0

Reines OS (kein IDS, aber neueste Patches)

Hersteller

4

0

N.A.

2.5

Signaturerk.

Hersteller

6

0

4

0.5 + 2.5

Signaturerk.

Hersteller & Anwender

8

0-1

30

3-4 + 2.5

Anomalieerk.

Anwender

3-4

4

20

5-6 + 2.5

Tabelle 2: Aufwand vs. Sicherheit

2.6.5 Rechtliche Aspekte der Intrusion Detection Beim Einsatz von Intrusion Detection Systemen (IDS) sind folgende rechtliche Aspekte in bezug auf die Auditdaten relevant: •

die datenschutzrechtliche Behandlung und

•

die rechtliche Verwertbarkeit bei der Beweisführung vor Gericht.

2.6.5.1 Datenschutzrechtliche Behandlung Hier sind folgende Rechtsnormen anwendbar: •

das Bundesdatenschutzgesetz (BDSG), § 14 (4) und § 31,

12.07.2000

debis IT Security Services

Seite 78

Grundlagen, Forderungen und Marktübersicht für Intrusion Detection Systeme (IDS) und Intrusion Response Systeme (IRS)

Intrusion Detection und Intrusion Response - Grundlagen

•

für nicht-öffentliche oder öffentlich-rechtliche Wettbewerbsunternehmen: das Betriebsverfassungsgesetz (BtrVG), § 87 (1),

•

für öffentliche Stellen: das Personalvertretungsrecht des Bundes bzw. des jeweiligen Landes,

•

das Gesetz über die Nutzung von Telediensten (TDG),

•

das Gesetz über den Datenschutz bei Telediensten (TDSG), § 4-6.

Im folgenden werden die auf Intrusion Detection anwendbare Teile dieser Rechtsnormen aufgeführt. Das BDSG fordert für öffentliche Stellen in §14 (4) und für nicht-öffentliche Stellen in §31 eine besondere Zweckbindung für personenbezogene Daten, die der Datenschutzkontrolle, der Datensicherung oder der Sicherstellung des ordnungsgemäßen Betriebes einer Datenverarbeitungsanlage dienen. Personenbezogene Daten, die zu o. g. Zwecken gespeichert werden, dürfen nur für diese Zwecke verwendet werden. Soweit Daten potentiell auch eine Überwachung der betreffenden Mitarbeiter ermöglichen, sind die Regelungen zur innerbetrieblichen Mitbestimmung zu beachten. Für nicht-öffentliche Arbeitgeber sieht das Betriebsverfassungsgesetz in § 87 (1) ein Mitspracherecht der Arbeitnehmer bei der Sammlung von Daten, die der Leistungs- und Verhaltenskontrolle der Mitarbeiter dienen können, vor. Hierbei genügt die Zustimmung, eine explizite Betriebsvereinbarung ist nicht erforderlich. Eine Zweckbindung ist bereits im BDSG festgelegt. Für öffentliche Arbeitgeber existiert ein jeweils spezifisches Personalvertretungsrecht für den Bund und die einzelnen Länder. Dort ist auch jeweils die Zustimmungspflicht des Personals festgelegt. Eine mögliche Maßnahme zur Gewährleistung eines verbesserten Datenschutzes wäre die automatische Pseudonymisierung der Auditdaten. Damit könnte aus den Daten kein direkter Rückschluß auf einzelne Mitarbeiter erfolgen. Zur Verfolgung ewaitiger Verstöße gegen die Sicherheitspolitik ist es jedoch notwendig, die Pseudonymisierung im Bedarfsfall aufzuheben. Mit der Pseudonymisierung wird eine eventuelle Mitbestimmungspflicht deshalb nicht beseitigt. Werden im Rahmen der Sammlung von Auditdaten auch personenbezogene Nutzungsdaten von Angeboten im Sinne des Teledienstgesetzes gesammelt, so findet dieses Gesetz und das Teledienstdatenschutzgesetz Anwendung. Hierbei kann der § 6 (2) Nr. 1 besondere Bedeutung erlangen. Dort wird eine frühestmögliche Löschung der Nutzungsdaten vorgeschrieben, spätestens jedoch nach Beendigung der Nutzung. Wird eine Pseudonymisierung vorgenommen, so ist auch die Erfassung von Nutzungsprofilen gestattet (§ 4 (4) TDSG). Die Zusammenführung von Nutzungsprofilen mit dem Träger des Pseudonyms ist ausdrücklich untersagt. Dies hat wesentliche Auswirkungen für die Intrusion Detection. Danach können für den o.g. Problemkreis zwar weiterhin Auditdaten in pseudonymisierter Form gesammelt werden, eine 12.07.2000

debis IT Security Services

Seite 79

Grundlagen, Forderungen und Marktübersicht für Intrusion Detection Systeme (IDS) und Intrusion Response Systeme (IRS)

Intrusion Detection und Intrusion Response - Grundlagen

Verfolgung von Angreifern durch eine Aufhebung der Pseudonymisierung wird damit jedoch verhindert. 2.6.5.2 Rechtliche Verwertbarkeit Hier sind folgende Rechtsnormen anwendbar: •

die Strafprozeßordnung (StPO), § 72 ff,

•

die Zivilprozeßordnung (ZPO), § 415

Die Auditdaten sind kein rechtsverbindliches Beweismittel im Sinne des § 416 der Zivilprozeßordnung (ZPO), wie z.B. ein beurkundetes Schriftstück. Die Auditdaten unterliegen der freien Beweiswürdigung. Die Beurteilung des Beweiswertes steht im Ermessen des Gerichts. Damit stehen die Auditdaten auf einer Stufe mit Beweismitteln wie Augenscheinnahme oder Zeugenaussage. Die Bewertung solcher Beweismittel kann auch durch einen Sachverständigen vorgenommen werden. Ein wesentlicher Schwachpunkt konventioneller Audit-Systeme ist die Möglichkeit, die Auditdaten nachträglich beliebig modifizieren oder vollständig unabhängig generieren zu können. Die Ausführung einer solcher Fälschung ist sehr einfach und kann mit Hilfe eines Rechners geschehen, der mit einem Texteditor ausgerüstet ist. Werden die Audit-Datensätze mit einer automatischen Integritätssicherung versehen, so ist eine Modifikation oder nachträgliche Generierung erkennbar. Dies könnte z.B. Über eine automatische digitale Signatur der Audit-Dateien erfolgen. Das setzt jedoch voraus, daß der für die Signierung verwendete private Schlüssel vertraulich verwahrt wird und dies auch nachgewiesen werden kann. Eine Integritätssicherung der Auditdaten kann zu einer Verbesserung des Beweiswertes führen. 2.6.5.3 Maßnahmen Um die oben genannten rechtlichen Anforderungen an ein IDS einzuhalten, müssen mindestens folgende Maßnahmen getroffen werden: •

Falls personenbezogene Auditdaten auch nur temporär festgehalten werden, muß der Betreffende über diesen Sachverhalt aufgeklärt werden (beispielsweise beim Einrichten des Accounts, Besuch des Webservers etc.).

•

Löschung der personenbezogenen Nutzungsdaten spätestens nach Beendigung der Nutzung

•

Pseudonomisieren der Nutzungsdaten

•

Sicherstellung der Authentizität von Audit- bzw. Nutzungsdaten durch ein zertifiziertes Auditsystem, welches Daten verfälschungssicher festhält

12.07.2000

debis IT Security Services

Seite 80

Grundlagen, Forderungen und Marktübersicht für Intrusion Detection Systeme (IDS) und Intrusion Response Systeme (IRS)

Intrusion Detection und Intrusion Response - Grundlagen

Ein zentraler Punkt betrifft die Sicherstellung der Richtigkeit der aufgezeichneten Auditdaten, da ansonsten die rechtliche Verwertbarkeit dieser Daten nicht garantiert werden kann. Für den Einsatz von ID-Systemen hat dies unmittelbare Folgen, da solche Systeme häufig selbst Auditdaten bereitstellen. Es müssen mindestens folgende Maßnahmen getroffen werden: Zertifizierte Auditdaten: Es muß sichergestellt werden, daß die Auditdaten die Nutzung so protokollieren, wie sie tatsächlich geschehen ist. Im einzelnen können folgenden Typen von ID-Systemen unterschieden werden: •

Network Sniffer: Dieser Typ erfordert eine Zertifizierung des ID-System

•

Host-basiert: Dieser Typ benutzt die Auditdaten des Betriebssystems. Somit ist eine Zertifizierung aller Betriebssystemkomponenten (syslogd etc.) notwendig, die an der Bereitstellung der Auditdaten beteiligt sind.

Integritätsschutz der Auditdaten: Sobald die Authentizität der Auditdaten gewährleistet werden kann, muß im folgenden Schritt die Integrität dieser Daten sichergestellt werden. Dies kann unter anderem durch folgende Maßnahmen geschehen: •

Speicherung auf WORM Medien wie z.B. CD-ROM, Drucker etc.

•

Einsatz personalisierter Chipkarten für digitale Signaturen

2.7 Intrusion Response — Automatische Gegenmaßnahmen bei Angriffen Sobald ein Angreifer Zugriff auf ein Rechnersystem oder auf einen Teil von ihm erlangt hat, kann er im Rahmen der erlangten Rechte beliebig hohen Schaden anrichten. Die Maßnahmen, die in einem solchen Fall zu ergreifen sind, müssen in den Sicherheitsrichtlinien beschrieben sein. Falls ein Angreifer ein System bis zum Erreichen eines Denial-of-Service penetriert, so möchte der betroffene Systembetreiber den Angreifer ermitteln können. Dies erfordert, daß genügend Information vorhanden sein muß, um den Angreifer ausfindig zu machen. Aus diesem Grunde kann es hilfreich sein, nicht sofort alle Verbindungen zum Angreifer zu schließen, sondern ihn kontrolliert weitere Angriffe durchführen zu lassen. Dahingegen kann es Angriffe geben, deren Risikopotential so groß ist, daß das angegriffene System sofort heruntergefahren werden muß. Es gibt demzufolge zwei Hauptziele bei IR-Maßnahmen: den Angreifer ausfindig zu machen (d.h. rechtlich verwertbare Daten zu sammeln) und weitere Schäden abzuwenden. Beide Ziele erfordern unterschiedliche Umsetzungen. Der folgende Abschnitt beschreibt ausführlich •

die möglichen Ziele von IR-Richtlinien und

•

deren Erreichung.

Es wird sich herausstellen, daß die IR-Richtlinien nicht unabhängig von den Gesamtsicherheitsrichtlinien gesehen werden können. Die Gesamtsicherheitsrichtlinien 12.07.2000

debis IT Security Services

Seite 81

Grundlagen, Forderungen und Marktübersicht für Intrusion Detection Systeme (IDS) und Intrusion Response Systeme (IRS)

Intrusion Detection und Intrusion Response - Grundlagen

bilden das Rückgrat für die IR-Richtlinien. Beide Richtlinien müssen zueinander konsistent sein. Nur so können Fragen wie •

Verletzt ein IR-Ziel oder eine IR-Maßnahme die IR-Richtlinien oder die Gesamtsicherheitsrichtlinien?

•

Wurden alle notwendigen Schritte unternommen, die Richtlinien umzusetzen?

geklärt werden. Die IR-Fähigkeiten der im Rahmen dieser Studie besprochenen ID-Systeme sind am Ende dieses Abschnitt tabellarisch aufgeführt.

2.7.1 IR-Ziele Wie bereits einführend erwähnt, müssen die IR-Ziele innerhalb der globalen Sicherheitsrichtlinen berücksichtigt werden. Diese müssen bestimmen, welche Angriffe als temporär akzeptabel gelten können. Die IR-Ziele lassen sich immer als eine Kombination aus •

Identifizieren des Angreifers,

•

Schutz vor weiteren Schäden und

•

Beheben entstandener Schäden

darstellen. Das Identifizieren des Angreifers stellt Anforderungen an den Auditmechanismus des Betriebssystems und den des ID-Systems. Ziel der Identifikation muß zunächst sein, die richtige IP-Adresse des Angreifers herauszubekommen. Dazu sind nicht nur umfangreiche Protokollierungsmaßnahmen nötig, sondern auch Maßnahmen, um den Angreifer rückverfolgen zu können. Diese Maßnahmen müssen die Möglichkeit einschließen, daß der Angreifer den Angriff nicht von seinem Ursprungsrechner aus startet, sondern dazu weitere Rechner kompromittiert (Sprungbrett) oder IP-Adressen spooft. Schutz vor Schäden – insbesondere vor weiteren Schäden – scheint zunächst dem Ziel, den Angreifer ausfindig zu machen, diametral entgegengesetzt zu sein. Dies gilt jedoch nur bedingt. Das strategische Ziel, den Angreifer ausfindig zumachen, deckt sich durchaus mit strategischen Ziel, das System zu schützen. Lediglich die dabei getroffenen Maßnahmen, können divergieren. Im Idealfall kann ein ID- bzw. IR-System alle Ziele verwirklichen.

2.7.2 Maßnahmen Die Maßnahmen, die zur Umsetzung der IR-Richtlinien zu treffen sind, können in drei Klassen eingeteilt werden: 12.07.2000

debis IT Security Services

Seite 82

Grundlagen, Forderungen und Marktübersicht für Intrusion Detection Systeme (IDS) und Intrusion Response Systeme (IRS)

Intrusion Detection und Intrusion Response - Grundlagen

•

automatische IR-Maßnahmen (welche vom IR-System selbständig angestoßen werden),

•

halbautomatische IR-Maßnahmen (bei denen eine Interaktion von SSO und IRS notwendig ist) und

•

manuelle IR-Maßnahmen (werden nur vom SSO ausgeführt).

Die zu treffenden IR-Maßnahmen können in verschiedenen Stufen ausgeführt werden. Sie können zum Beispiel mit detaillierter Protokollierung beginnen und dann über das Deaktivieren von Ports bis zum Herunterfahren des Systems führen. In [Halme and Bauer, 1995] sind verschiedene Stufen der IR-Maßnahmen beschrieben. Maßnahmen, die in bezug auf alle drei Ziele (Identifizieren des Angreifers, Verhinderung von weiteren Schäden und Beheben entstandener Schäden) optimal sind, erfordern eine genaue Analyse der Angriffsverhaltens, der entstandenen Schäden und der Kenntnis, welche Daten auf den betroffenen Rechnern gespeichert sind und wie diese konfiguriert sind. Es ist daher sehr wahrscheinlich, daß geeignete Gegenmaßnahmen nur halbautomatisch getroffen werden können. Artikel (siehe z.B. [Cheswick, 1992]) geben einen guten Eindruck darüber, wie schwierig es ist, die optimale Strategie zu finden. Ob eine Gegenmaßnahme automatisch, halbautomatisch oder manuell durchzuführen ist, hängt nicht nur von der entsprechenden Maßnahme ab, sondern auch von den Sicherheitsrichtlinien. Im folgenden werden daher nur Maßnahmen dargestellt, die automatisch durchgeführt werden können. Dies bedeutet nicht, daß sie immer im Einklang mit der Sicherheitspolitik sind.

2.7.2.1 Verhinderung von Schäden mittels Gegenangriff Im Falle eines Angriffs, kann das angegriffene System einen Gegenangriff starten, der ein Denial-of-Service des angreifenden Rechners zum Ziel hat. Eine solche automatisch durchführbare Gegenmaßnahme ist nicht unproblematisch, da sicherzustellen ist, daß •

der angreifende Rechner vom Angreifer nicht nur als Sprungbrett verwendet wird,

•

der angreifende Rechner seine IP-Adresse nicht nur vortäuscht und

•

der Gegenangriff gerechtfertigt ist (Selbstjustizeffekt).

Es sei nochmal darauf hingewiesen, daß solche Maßnahmen technisch möglich sind, jedoch nicht immer juristisch gerechtfertigt werden können.

2.7.2.2 Verhinderung von (weiteren) Schäden mittels Abschottung Eine ad-hoc Maßnahme bei einem Angriff besteht im Abschotten der angegriffenen Maschine durch 12.07.2000

debis IT Security Services

Seite 83

Grundlagen, Forderungen und Marktübersicht für Intrusion Detection Systeme (IDS) und Intrusion Response Systeme (IRS)

Intrusion Detection und Intrusion Response - Grundlagen

•

Schließen der betreffenden TCP/UDP-Ports,

•

Termination von Programmen und Diensten,

•

Ablehnen von IP-Datagrammen, die von der angreifenden IP-Adresse kommen oder

•

Sperren des Benutzeraccounts, falls der Angriff von einer internen Quelle kommt.

Das Schließen eines Ports kann auf UNIX-Systemen z.B. durch Rekonfiguration des inetd erfolgen. In ähnlicher Weise kann die Beendigung anderer Programme und Dienste erfolgen. Dabei muß allerdings sichergestellt werden, daß dieser Dienst nach einer gewissen Zeit wiederaufgenommen werden kann, da der Angreifer sonst leicht Denial-of-Service Angriffe gegen den betreffenden Dienst oder sogar das System fahren kann. Sinnvoller ist es daher, zunächst IP-Pakete abzulehnen, die vom angreifenden System kommen. Dazu kann beispielsweise die Firewall oder der Router dynamisch rekonfiguriert werden. Dabei muß bedacht werden, daß diese Maßnahme selbst wieder zu Sicherheitsproblemen führen kann: das IR-System muß sich gegenüber dem zu rekonfigurierenden System authentisieren. Des weiteren muß sichergestellt werden, daß die Rekonfiguration restriktiver als die Konfiguration ist. Darüber hinaus muß sichergestellt werden, daß die entsprechenden Komponenten während der Rekonfigurierung ihre Funktionalität weiterhin zur Verfügung stellen. Nachteile dieser Maßnahme sind: •

Der Angreifer stellt durch die abgelehnten IP-Pakete fest, daß seine Handlungen entdeckt wurden.

•

Die Sperrung von Diensten verhindert, daß der Auditmechanismus weitere Daten, die zur Identifizierung des Angreifers führen können, sammelt.

Abschottungsmaßnahmen müssen daher auf ihre Vereinbarkeit mit der Sicherheitspolitik gründlich geprüft werden.

2.7.2.3 Identifizieren des Angreifers Das Identifizieren des Angreifers erfordert einen hohen Protokollierungsaufwand. Da dieser nicht zu jedem Zeitpunkt praktikabel ist, muß er vom IDS zum richtigen Zeitpunkt angestoßen werden. Die Auswahl dieses Zeitpunkts ist ein typisches Beispiel für eine halbautomatische Gegenmaßnahme. Um zu verhindern, daß der Angreifer während der notwendigen Protokollierungsmaßnahmen weiteren Schaden anrichtet, kann er in eine sogenannte Gummizelle gelockt werden. Das Verfahren ist ausführlich in [Cheswick and Bellovin, 1996] beschrieben. Die grundlegende Idee ist dabei, den Angreifer auf einen vorher präparierten Rechner zu locken (www.nuclear.com).

12.07.2000

debis IT Security Services

Seite 84

Grundlagen, Forderungen und Marktübersicht für Intrusion Detection Systeme (IDS) und Intrusion Response Systeme (IRS)

Intrusion Detection und Intrusion Response - Grundlagen

Benutzt ein Angreifer allerdings weitere Rechner als Sprungbretter von seinen Angriff, so müssen auf den betreffenden Rechner ebenfalls erweiterte Protokollierungsmaßnahmen aktiviert werden, um den Angreifer ausfindig machen zu können. Grundsätzlich stehen folgende Möglichkeiten zur Verfügung: •

Suche nach dem Rechner mittels DNS (bei cleveren Angreifern eher mit mäßigem Erfolg)

•

Benachrichtigung eines Computer Emergency Response Teams (CERT)

•

Administratoren der als Sprungbretter benutzten Maschinen alarmieren (möglichst per Telefon und nicht mittels E-Mail).

Das Identifizieren des Angreifers wird wesentlich schwieriger, wenn er einen X.25 Zugang oder einen Telefonzugang benutzt. In diesem Fall benötigt man eine richterliche Genehmigung zum Abhören dieser Leitungen. Es gibt keine klaren Regeln, wie der Angreifer tatsächlich ausfindig zu machen ist. Berichte wie Takedown! [Shimomura, 1996] zeigen, daß es möglich ist. Sie beschreiben allerdings auch den zu betreibenden Aufwand.

2.7.2.4 Schadensbeseitigung Unter Umständen ist die Beseitigung der entstandenen Schäden nicht möglich. Dies gilt zum Beispiel für Angreifer, die den root-Account kompromittiert haben und so beliebigen Schaden auf einem System anrichten konnten. In diesem Fall ist es wichtig, über aktuelle Sicherungskopien zu verfügen, die dann bei Bedarf eingespielt werden können. Darüber hinaus muß der Angriff möglichst früh erkannt werden, um so die Aktualität der brauchbaren Sicherheitskopien zu gewährleisten. Dabei muß auch genau festgestellt werden, welche Sicherungskopie keine vom Angreifer verfälschte Daten enthält. Ist es dem Angreifer unentdeckt gelungen, vor längerer Zeit ein trojanisches Pferd zu installieren, so wird er immer wieder das System kompromittieren können. Die möglichen Schadenstypen können wie folgt unterteilt werden: Integritätsverlust: Dem Angreifer ist es gelungen, Dateien (zum Beispiel die Bilanz) zu manipulieren, Konfigurationen zu verändern etc Verfügbarkeitsverlust: Dem Angreifer ist es gelungen, Dateien durch andere zu ersetzen oder zu löschen. Authentizitätsverlust: Der Angreifer konnte Information wie z.B. den Autor eines Dokuments oder einer E-Mail fälschen. Der Angreifer kann auch unter anderem Benutzernamen agieren. Vertraulichkeitsverlust: Dem Angreifer ist es gelungen, nur für einen bestimmten Personenkreis zugelassene Dokumente zu lesen (z.B. Paßwortdatei, medizinische Berichte etc.). 12.07.2000

debis IT Security Services

Seite 85

Grundlagen, Forderungen und Marktübersicht für Intrusion Detection Systeme (IDS) und Intrusion Response Systeme (IRS)

Intrusion Detection und Intrusion Response - Grundlagen

Die Verfügbarkeit und Integrität kann durch das Einspielen entsprechender Sicherheitskopien wieder hergestellt werden. Der Verlust der Authentizität kann durch Sicherheitskopien nur bedingt wieder hergestellt werden. Sollten Schlüssel kompromittiert worden sein, so können neue gewählt werden. Im Gegensatz zu Integrität, Verfügbarkeit und Authentizität kann die Vertraulichkeit nicht wieder hergestellt werden.

2.7.2.5 Zusammenfassung Die folgende Tabelle gibt eine Übersicht über die IR-Fähigkeiten der in Kapitel 3 zu besprechenden ID-Systeme. Reine IR-Systeme gibt es zur Zeit nicht. Systeme aus Kapitel 3, die hier nicht aufgeführt sind, verfügen über keine IR-Fähigkeiten.

System

Intrusion Response

NetRanger

Automatisches Rekonfigurieren des BorderGuard (shunning), Termination von Programmen und Abschotten von Ports, Angriffsprotokollierung

RealSecure Angriffsprotokollierung, Aufruf benutzerdefinierter Programme (mit deren Hilfe der Angreifer in eine Gummizelle gelockt werden könnte) NetStalker

Kappen von Verbindungen, Abschotten von Ports

StakeOut

Aufruf benutzerdefinierter Programme (mit deren Hilfe der Angreifer in eine Gummizelle gelockt werden könnte)

OmniGuard Termination von Programmen, Verweigern von Zugriffen auf Betriebsmittel SecureNet

Termination von Programmen

LogSurfer

Aufruf benutzerdefinierter Programme (mit deren Hilfe der Angreifer in eine Gummizelle gelockt werden könnte) Tabelle 3:IR Fähigkeiten von ID-Systemen

2.8 Effektivität von ID und IR Systemen Dieser Abschnitt behandelt das Potential von ID und IR Systemen. Dabei werden aktuell verfügbare, sowie zukünftige Techniken berücksichtigt.

12.07.2000

debis IT Security Services

Seite 86

Grundlagen, Forderungen und Marktübersicht für Intrusion Detection Systeme (IDS) und Intrusion Response Systeme (IRS)

Intrusion Detection und Intrusion Response - Grundlagen

2.8.1 Wie erfolgreich ist die aktuelle ID/IR Technik? Im Rahmen der vorliegenden Studie wurden 15 verschiedene ID/IR Systeme verglichen. Dabei wurden sowohl kommerzielle Produkte, als auch Prototypen aus der ID-Forschung untersucht. Die Entwicklung von ID begann als Entwicklung erweiterte Auditmaßnahmen und hat heute den Status einer eigenständigen Produktkategorie erreicht, die 30% von 400 befragten US Firmen innerhalb der nächsten Jahre einzusetzen beabsichtigen (Quelle: PC Week, 12. Januar 1998). Dieselbe Befragung kam zu dem Schluß, daß 33,1% der befragten Firmen den Kauf eines Firewall-Systems beabsichtigen, 48,3% planen den Kauf von Verschlüsselungsprodukten und 26,4% den von Virenerkennungsprogrammen. Dies zeigt die große Akzeptanz von ID Produkten. Mit dem Schritt vom Forschungsprototyp zum kommerziellen ID Produkt wird es unumgänglich, die Vor- und Nachteile der einzelnen Produkte näher zu beleuchten. Dabei spielt die Fähigkeit der einzelnen Produkte, Angriffe zu erkennen, eine wesentliche Rolle für den Einsatz eines IDS. Eine Methode, solche Vergleiche durchzuführen ist in [Puketza, 1996] beschrieben. Kommerzielle Magazine beginnen mehr und mehr, sich mit dem Thema ID auseinander zu setzen, und vergleichen die Performance von ID Produkte, vgl. [InternetWeek 22 Sep 97]. Die meisten ID-Systeme setzen Signaturanalyse ein, um Angriffe zu erkennen. Dies hat, wie bereits mehrfach erwähnt, den Effekt, daß sie nur solche Angriffe entdecken, die exakt dem vordefinierten Muster entsprechen. Der Erfolg eines solchen Systems ist allerdings nicht zu unterschätzen. Der fortführende Erfolg der Signaturanalyse setzt allerdings auch auf die Unfähigkeit der Angreifer, Skript-basierte Angriffe so zu modifizieren, daß sie ein IDS unterlaufen können. Dies gilt auch für Virenerkennungssoftware. Die Schattenseite der Signaturanalyse ist, daß alle existierenden Angriffe soweit analysiert werden müssen, daß eine Erstellung der Signatur überhaupt erst möglich wird. Solange die Signaturdatenbanken nicht mit großer Regelmäßigkeit erneuert werden, wird sich der „Angriff des Tages“, wie er in vielen IRCs diskutiert wird, der Erkennung entziehen. Anstelle jedoch zu jedem Implementierungsfehler, der zur Sicherheitsschwäche führt, eine Signatur zu entwickeln, ist es unter Umständen geschickter, den Fehler direkt zu beheben (mittels eines Patches). Allerdings wird es immer Fehler geben, für die es in absehbarer Zeit keine Patches geben wird, für die aber leicht eine Signatur entworfen werden kann. Diese Fehler profitieren am stärksten von der Signaturanalyse. Im Gegensatz zur Signaturanalyse, die relativ einfach durchzuführen ist, ist die Anomalieerkennung schon inhärent schwieriger, da sie größeren Administrationsaufwand und größere systemspezifische Anpassung erfordert. Darüber hinaus kann die Anomalieerkennung in der Anfangsphase zu einer enttäuschend großen Anzahl von Fehlkategorisierungen (Angriff / Kein Angriff) führen. Dies hat zur Konsequenz, daß reine Anomalieerkennung immer der Signaturanalyse hinterherhinkt. Die beiden Ansätze können jedoch durchaus nebeneinander existieren, wodurch sogar noch Vorteile erzielt werden, da viele Schwächen der Anomalieerkennung durch Signaturanalyse aufgehoben werden und 12.07.2000

debis IT Security Services

Seite 87

Grundlagen, Forderungen und Marktübersicht für Intrusion Detection Systeme (IDS) und Intrusion Response Systeme (IRS)

Intrusion Detection und Intrusion Response - Grundlagen

umgekehrt. Es ist wahrscheinlich, das Systeme, die beide Ansätze in sinnvollem Maß integrieren, sich als bevorzugt herausstellen werden. Die Unterstützung im IR-Bereich ist jedoch in allen aktuell verfügbaren Werkzeugen beschränkt. Einige Werkzeuge weisen zwar die Fähigkeit auf, erhöhte Auditmaßnahmen durch führen zu können sowie benutzerdefinierte Programme auszuführen, jedoch reichen diese Maßnahmen bei weitem nicht aus, entschlossene Angreifer zu identifizieren. Das folgende Beispiel, gibt einen Eindruck über die zu treffenden Maßnahmen: Die U.S. Air Force verfolgte einen Angreifer über verschiedene als Sprungbretter genutzte Rechner zurück, um so Identität ausfindig zu machen. Dabei erhielten sie eine legitime Zugangsberechtigung zu Rechnersystemen außerhalb der Vereinigten Staaten. Dort konnten sie Standardauditwerkzeuge benutzen, um den Angreifer zu identifizieren. Die von der U.S. Air Force gewählten Maßnahmen galten als extrem ungewöhnlich, erforderten eine neue Interpretation der rechtlichen Lage und wurden durch verschiedene Kontakte mit der Computer Crime Unit [CMAD III ‘95] unterstützt. Weitere berühmte Beispiele sind The Cuckoo’s Egg ([Stoll, 1989]) sowie Takedown! ([Shimomura, 1996]).

2.8.2 ID Trends Die Umsetzung von ID-Techniken in kommerzielle Werkzeuge erfolgt in starker Abhängigkeit von dem immer größer werdenden Bedarf. Größeres Sicherheitsbewußtsein und die Erkenntnis, wie anfällig ungeschützte Systeme sind, bereiten den Boden für den enorm expandierenden ID-Markt. Dies gilt insbesondere, nachdem bekannt wurde, daß Firewalls teilweise nur einen unzureichenden Schutz liefern. Es ist sehr wahrscheinlich, daß IDS-Entwickler ihre Produkte so anpassen werden, daß diese kooperativ mit anderen Sicherheitswerkzeugen (Firewalls, Virenerkennung, biometrische Authentisierung etc.) genutzt können. Das Erfassen von Daten aus physischen Sicherheitsmechanismen und Informationen über externe Benutzeraktivität (z.B. Internetanwendungen) können bei der ID-Analyse lokaler Systemaktivität hilfreich sein. Ähnlich wie bei frühen Firewall-Produkten sind die Hauptzielgruppen von ID-Werkzeugen Behörden und große Banken. Kommerzielle IDS Anbieter werden dem Vorbild der FirewallHersteller folgen und ihre Produkte mittels gut gestalteter Preispolitik und Plug-and-Play Eigenschaften in einen breiteren Markt drücken. An dieser Stelle werden Aspekte wie Benutzerfreundlichkeit, die Fähigkeit, Intranet-Anwendungen zu unterstützen, und die Unterstützung populärer Betriebssysteme wie Windows immer wichtiger. Ebenfalls in den Kinderschuhen ist der Trend, ID-Systeme mit anderen Sicherheitswerkzeugen in einem Paket anzubieten. Immer mehr Hersteller erkennen das Verkaufsargument, Sicherheitslösungen aus einer Hand anzubieten. Ein weiterer Marketingansatz verfolgt das Ziel, die Überwachung von Rechnersystemen als 12.07.2000

debis IT Security Services

Seite 88

Grundlagen, Forderungen und Marktübersicht für Intrusion Detection Systeme (IDS) und Intrusion Response Systeme (IRS)

Intrusion Detection und Intrusion Response - Grundlagen

Dienstleistung zu verkaufen. IBM Global Services kündigte 1997 einen 24x7 Support für die NetRanger Sensoren durch IBMs Internet Emergency Response Service an. Hierbei beobachtet der Dienstleister das System des Kunden und übernimmt auch die IRMaßnahmen. Ob dieser Ansatz des Komplettservices sich auf Dauer durchsetzen wird ist noch offen. IBMs Dienstleistung zielt auf einen Markt, wo sich der Preis von 75 000 $ durch die zu liefernde Qualität und die Unterstützung beim sicheren e-Business rechtfertigen läßt. Eine gemäßigtere Variante, die sofortigen Gewinn verspricht, ist die Einrichtung von sogenannter On-Call Unterstützung.

2.8.3 IR Trends Zur Zeit wird IR-Unterstützung als Teilfunktionalität von ID-Werkzeugen implementiert7. Einige der im Rahmen dieser Studie untersuchten Produkte bieten IR-Unterstützung in einfacher Form an (vgl. Tabelle 3). Der Haupteinwand beim Einsatz von automatischen IR Maßnahmen betrifft den potentiellen Schaden, den ein amoklaufendes IR System verursachen kann. Aber selbst im moderaten Fall ist der Einsatz von aktiven Gegenmaßnahmen juristisch noch völlig ungeklärt. Es ist darüber hinaus damit zu rechnen, daß ein Angreifer, der um die IR Maßnahmen eines Systems weiß, diese geschickt ausnutzen kann, so daß der eigentliche Angriff in der Auslösung der IR Maßnahmen liegt.

2.8.4 Maximierung der Anti-Intrusions Effektivität Die AINT Taxonomie (vgl. [Halme und Bauer, 1995]) beschreibt ID und IR als zwei von sechs möglichen Maßnahmen, auf Einbrüche in Rechnersysteme zu reagieren. Bei der Untersuchung des Potentials von ID- und IR- Systemen sollten traditionelle Maßnahmen wie Einbruchsverhinderung (intrusion prevention) und weniger gut erforschte Ansätze wie Einbruchsabschirmung (intrusion deflection) nicht übersehen werden. Die Verbindung dieser kooperativen Techniken zu einem integrierten Gesamtverteidigungssystem kann eine sinnvolle Allianz gegen Einbruchsversuche darstellen. Die präventive Benutzung statischer Sicherheitswerkzeuge wie z.B. SafeSuite, NetSonar, SATAN, COPS, Asmodeus kann Sicherheitsschwächen ausfindig machen, bevor diese von Eingreifern ausgenutzt werden,

7

Wie jedoch [Halme und Bauer, 1995] beschrieben, ist es möglich, ein IR-System von einem IDS so abzukoppeln, daß die Funktionalität dennoch gewährleistet werden kann. Es ist möglich, Auslöser für IR-Maßnahmen so zu plazieren, daß keine ID-Analyse im eigentlichen Sinne vorhergehen muß.

12.07.2000

debis IT Security Services

Seite 89

Grundlagen, Forderungen und Marktübersicht für Intrusion Detection Systeme (IDS) und Intrusion Response Systeme (IRS)

Intrusion Detection und Intrusion Response - Grundlagen

Wie der Abschnitt 2.7.2 über IR-Maßnahmen gezeigt hat, sind elaborierte IR-Maßnahmen kaum verfügbar. Diese Lücke kann durch Erforschung geeigneter Strategien für forensische Analyse von Einbruchsversuchen in Rechnersysteme geschlossen werden.

12.07.2000

debis IT Security Services

Seite 90

Grundlagen, Forderungen und Marktübersicht für Intrusion Detection Systeme (IDS) und Intrusion Response Systeme (IRS)

Produkt-/Projektstudie

3. Produkt-/Projektstudie Dieses Kapitel beschreibt die wichtigsten ID-Systeme, die •

am Markt vorhanden,

•

in der Forschung aktuell oder

•

von besonderem historischen Interesse

sind. Zunächst wird ein Klassifikationsschema entwickelt, welches die Aufgabe hat, die wesentlichen Merkmale der zu besprechenden ID-Systeme darzustellen und eine Abgrenzung der Systeme untereinander erlaubt.

3.1 Methode Das Klassifikationsschema für ID-Systeme, wie es in Abschnitt 3.2 vorgestellt wurde, basiert auf den Ergebnissen zur Ermittlung des State-of-the-Art im Bereich Intrusion Detection, sowie der Untersuchung der bekanntesten ID-Systeme. Jedes IDS wurde auf folgende Aspekte hin untersucht: •

Praktische Einsetzbarkeit, insbesondere seine Kooperation mit Firewalls

•

Skalierbarkeit in bezug auf größere Netze und neue Angriffsszenarien

•

Wie gut wurden die Forschungsergebnisse aus dem ID-Bereich umgesetzt?

•

Sicherheitsrelevante Aspekte, wie z.B. die Modifikation der IDS Konfiguration

•

Grenzen des ID-Systems

Dabei wurden folgende Quellen zur Ermittlung der Systemprofile benutzt: •

Konferenzbeiträge

•

White Papers und Produktinformation des Herstellers

•

Technische Berichte

•

Begutachtete Zeitschriftenartikel

•

Fragebogen an die Hersteller

Das Studium der Forschungsberichte führte zu dem in Kapitel 2 vorgestellten Klassifikationsschema, welches zur Profilerstellung und Bewertung der ID-Systeme verwendet wird. Aus diesem Klassifikationsschema wurde ein Fragebogen zusammengestellt, der an die Hersteller der betreffenden ID-Systeme mit der Bitte um Beantwortung versendet wurde. Anschließend wurden die Systemprofile erstellt und den Herstellern dann zur Überprüfung auf Korrektheit und Vollständigkeit zugesandt.

12.07.2000

debis IT Security Services

Seite 91

Grundlagen, Forderungen und Marktübersicht für Intrusion Detection Systeme (IDS) und Intrusion Response Systeme (IRS)

Produkt-/Projektstudie

3.2 Klassifikationskriterien für ID-Systeme Die Klassifikation kann in folgende Sektionen unterteilt werden: Architekturaspekte: Diese haben einen großen Einfluß auf die Performance und Erweiterbarkeit. So ist zum Beispiel ein IDS mit verteilter Datensammlung wesentlich skalierbarer als eines, welches von zentraler Stelle aus alle Daten sammelt. Systemspezifische Aspekte: Ist ein IDS tatsächlich erhältlich? Wie hoch ist sein Preis? In welchen Umgebungen (Betriebssystemen, Rechnern) kann das System eingesetzt werden? Ist zusätzliche Hardware notwendig? Angriffe: Welche Angriffstypen können erkannt werden? Wie gut können Angriffe erkannt werden, die nicht von einer Firewall entdeckt werden? Wie gut schützt sich das IDS selbst gegen Angriffe?

Diese Sektionen können nun weiter verfeinert werden, um so genaue Klassifikationskriterien für ID-Systeme zu erhalten. Angriffsszenarien Die aktuell verfügbaren ID-Systeme können nur eine begrenzte Teilmenge der möglichen Angriffe erkennen. Jedes System hat seine Stärken und Schwächen im Erkennen von Angriffen. Dies hängt im wesentlichen von der Art der implementierten Datensammlungskomponenten ab. Die folgenden Angriffstypen werden unterschieden:

12.07.2000

debis IT Security Services

Seite 92

Grundlagen, Forderungen und Marktübersicht für Intrusion Detection Systeme (IDS) und Intrusion Response Systeme (IRS)

Abtastende Suche nach TCP/UDP/RPC-Diensten (mit Half Open Scans und Stealth Scans)

Produkt-/Projektstudie

JA oder NEIN oder N.A. (not Addressed)

Spoofing (IP, DNS, WEB etc.) Denial-of-Service-Angriffe (SYN Flooding, PING etc.) Routing-Angriffe (Source Routing, ICMP Redirect) Versuchte Einbrüche (Erraten des Paßworts, Erraten des NIS file handles) Angriffe auf bekannte Sicherheitslöcher (sendmail, NIS, NFS, bind etc.) Software mit Schadensfunktionalität (Viren, Würmer etc.) Angriffe über WWW-Dienste (ActiveX, Java, MIME etc.) Erkennungsstärken des IDS

Typische Angriffsszenarien (Herstellerangaben)

Auditdaten Wir bereits erwähnt, hängt die Stärke eines IDS wesentlich vom Typ der verwendeten Auditdaten ab. Werden nur Protokolldaten des Betriebssystems verwendet, so können Angriffe wie IP Spoofing nicht erkannt werden. Einige ID-Systeme sind in der Lage, die Auditdaten gemäß einer Abstraktionshierarchie zu bearbeiten. Dabei werden Daten, die auf Netzebene von einem Sniffer gesammelt wurden, in eine Repräsentation auf höherer Abstraktionsebene überführt (z.B. Horn-Klauseln). Dieses Verfahren dient dazu, die Datenmenge zu reduzieren (gemäß [Frank, 1994] kann ein Benutzer innerhalb von 8 Stunden durchaus zwischen 3 und 30 MB Auditdaten produzieren). Wird ein solches Abstraktionsverfahren eingesetzt, ist es nicht nur wichtig, aus welcher Quelle die Daten stammen (z.B. Sniffer), sondern auch, welches Ziel sie haben (z.B. Inferenzsysteme mit Produktionsregeln, Expertensystem). Darüber hinaus ist die Granularität der gesammelten Daten von Interesse. Angriffe auf unteren Protokollebenen können nur dann richtig erkannt werden, wenn genügend detaillierte Daten zur Verfügung stehen. Ein Sniffer, der lediglich den Ursprung eines Pakets meldet, besitzt wenig Praxistauglichkeit. Ein wichtiger Praxisaspekt betrifft die Fähigkeit eines IDS, Daten aus verschiedenen Quellen verarbeiten zu können. Eine Quelle kann z.B. die Datensammlungskomponente eines anderen ID-Systems oder auch eine Firewall sein. Dabei müssen Sammlungs- und Analysekomponente ein gemeinsames Datenformat verarbeiten können. 12.07.2000

debis IT Security Services

Seite 93

Grundlagen, Forderungen und Marktübersicht für Intrusion Detection Systeme (IDS) und Intrusion Response Systeme (IRS)

Produkt-/Projektstudie

Datenanalyse Die Besprechung der Datenanalyse erfolgt im wesentlichen gemäß der Klassifikation aus Abschnitt 2.2.3. Die folgenden Anmerkungen sollen die in Abschnitt 2.2.3 gemachten Äußerungen ergänzen: •

Das Ziel der Datenanalyse ist es, Verletzungen der Sicherheitsvorgaben zu entdecken. Nach Möglichkeit soll dies geschehen, bevor Schäden durch den Angriff entstanden sind.

•

Die Signaturanalyse erlaubt nur die Erkennung von bereits bekannten und erforschten Angriffen. Unbekannte Angriffe können mittels Anomalieerkennung dann erkannt werden, wenn sie ein normabweichendes Verhalten erzeugen.

•

Signaturanalyse erfordert eine regelmäßige Wartung der Signaturdatenbank (dies ist durchaus in Analogie zu einem Virenscanner zu sehen). Möchte ein Anwender die Erkennungsmuster selbst definieren, so muß er regelmäßig die Informationsquellen über neue Angriffsarten verfolgen (z.B. CERT-Hinweise und -Diskussionsforen). Auch Komponenten zur Anomalieerkennung müssen geeignet gewartet werden, um falschen Alarmen vorzubeugen und Angriffe korrekt zu erkennen.

•

In Abhängigkeit von der verwendeten Erkennungsmethode können Variationen bekannter Angriffe dazu führen, daß diese Variationen nun nicht mehr von der Mißbrauchserkennungskomponente erkannt werden.

•

Im Gegensatz zur Anomalieerkennung erfordert die Signaturanalyse, daß die Auditdaten vollständig und in richtiger Reihenfolge vorhanden sind. Werden z.B. TCP/IP-Pakete nicht richtig zusammengebaut, so kann dies dazu führen, daß Angriffe nicht oder nicht richtig erkannt werden.

•

Ein wesentlicher Vorteil der Signaturanalyse ist es, daß Angriffe eindeutig identifiziert werden können. Dies erlaubt auch die sofortige Einleitung von Gegenmaßnahmen. Anomalieerkennung erlaubt nur vage Ergebnisse. Gelingt es einem Angreifer, nicht vom als „normal” definierten Verhalten abzuweichen, so wird er durch die Anomalieerkennung nicht enttarnt werden. Darüber hinaus kann es bei Anomalieerkennung zu einer hohen Fehlerrate kommen. Dies macht eine manuelle Begutachtung der von der Anomalieerkennung produzierten Ausgabedaten notwendig.

•

Ein Anomalieerkennungssystem benötigt eine sogenannte Lernphase, in der es das “normale” Verhalten lernt. Darüber hinaus muß die Anomalieerkennung in der Lage sein, sich dynamisch an neues Benutzerverhalten anzupassen (dies kann durchaus semi-automatisch geschehen). Es muß dabei allerdings verhindert werden, daß das Angriffsverhalten als “normal” gelernt wird.

•

Es sei darauf hingewiesen, daß Anomalieerkennung alle Vor- und Nachteile statistischer Inferenz und induktiver Techniken ererbt, wie z.B. falsche Vorhersagen.

12.07.2000

debis IT Security Services

Seite 94

Grundlagen, Forderungen und Marktübersicht für Intrusion Detection Systeme (IDS) und Intrusion Response Systeme (IRS)

Produkt-/Projektstudie

Dies führt unter Umständen dazu, daß das gesamte ID-System unzuverlässig arbeitet und seine Zweckmäßigkeit extrem fragwürdig ist. Es wäre daher wünschenswert, daß für Anomalieerkennung angegeben würde, wie hoch die Fehlerwahrscheinlichkeit der ermittelten Ergebnisse ist. Mathematische Modelle, die solche Aussagen zulassen, finden sich meist unter dem Stichwort PAC-Lernen (vgl. [Valiant, 1984]). Leider ist es schwierig, diese Begriffe vollständig auf Anomalieerkennung zu übertragen, da es keine brauchbare mathematische Definition eines Angriffs gibt. Architektur Der eingangs beschriebene Grobentwurf unterteilte ein ID-System in die Komponenten Datensammlung, Datenanalyse und Ergebnisdarstellung. In bezug auf die ersten beiden Komponenten können weitere Fälle unterschieden und damit Unterteilungen vorgenommen werden: •

Das gesamte Rechnernetz wird von überwacht, die ihre Beobachtungen weiterreicht. D.h. Datensammlung:

zentral

Datenanalyse:

zentral

einer zentralen Datensammlungsstation an eine zentrale Analysekomponente

•

Mehrere Sammelstationen, auch Monitore genannt, geben ihre Daten an eine zentrale Analysestation weiter. Hier liegt eine verteilte Datensammlung mit zentraler Analyse vor.

•

Falls es mehrere Monitore gibt, die ihre Daten an verschiedene Analysestationen weitergeben, so sind sowohl Datensammlung als auch –analyse verteilt.

Einige ID-Systeme bieten eine lokale Aufbereitung der Analysedaten an, die dann an eine zentrale Analysestation weitergereicht werden. In diesem Fall handelt es sich um eine hybride Datenanalyse. Benachrichtigung Sobald ein möglicher Angriff entdeckt wurde, kann das System auf verschiedene Arten den SSO benachrichtigen. Abschnitt 0 führt die möglichen Alarmübermittlungsarten auf. Die verschiedenen Möglichkeiten, die auf das betreffende ID-System zutreffen, sind unter dem Punkt Benachrichtigung aufgeführt. Um die Sicherheitsschwächen in einem Rechner oder Rechnernetz zu finden, ist es wichtig, daß das ID-System sämtliche Information, die zu einem erfolgreichen Angriff geführt hat, mitschneidet. Aus diesem Grund ist der Bericht unentbehrlich. Mindestens genauso wichtig wie die Berichterstellung ist die Angriffsprotokollierung. Der Eintrag Angriffsprotokollierung

12.07.2000

debis IT Security Services

Seite 95

Grundlagen, Forderungen und Marktübersicht für Intrusion Detection Systeme (IDS) und Intrusion Response Systeme (IRS)

Produkt-/Projektstudie

wird mit JA gefüllt, falls das IDS in der Lage ist, dem Angriff die richtigen Auditdaten zuzuordnen. Reaktion Viele der verfügbaren ID-Systeme beinhalten bereits Intrusion Response (IR)-Komponenten und können so im Angriffsfall selbständige Gegenmaßnahmen durchführen, wie z.B. das Blockieren von Ports und/oder die Rekonfiguration von Routern. Manche ID-Systeme sind in der Lage, beliebige Programme auszuführen. Die möglichen Reaktionen sind unter dem Punkt Maßnahmen aufgeführt. Benutzerschnittstelle Ein IDS besitzt typischerweise zu viele Parameter, als daß diese vom SSO mittel einer zeichenorientierten Konsole handhabbar wären. Eine grafische Benutzeroberfläche (Graphical User Interface, GUI) ist deswegen unabdingbar. Thumbprinting Thumbprinting (vgl. [Staniford-Chen, 1995]) stellt eine Möglichkeit dar, Benutzer innerhalb eines Netzes zu identifizieren, obwohl sich ihre User-ID (UID) geändert hat. Beispielsweise kann paul@cs-vax dieselbe Person sein wie anna@ai-sun. Beim Thumprinting wird dem Benutzer eine Netz-ID (NID) zugewiesen. Zielumgebung Hier wird die für das betreffende System geeignete Zielumgebung angegeben. Manche Systeme eignen sich nur zur Überwachung eines einzelnen Arbeitsplatzes, während andere große Netze beobachten und analysieren können.

Kooperation mit Firewalls Hier werden u.a. folgende Fragestellungen betrachtet: In welchem Umfang ist das IDS in der Lage, die von einer Firewall produzierten Auditdaten zu verarbeiten? In welchem Umfang kann das IDS neben einer Firewall eingesetzt werden, ohne daß sich beide Systeme behindern? Welche Firewall-Produkte werden unterstützt? Eine Firewall führt auch Analysen auf niedrigen Protokollebenen durch. Inwieweit können Firewall und IDS kooperieren, so daß redundante Analysen des Datenstroms (Datendurchsatz!) vermieden werden können? Inwieweit ist das IDS in der Lage, als Gegenmaßnahme zu einem Angriff die Firewall zu rekonfigurieren?

12.07.2000

debis IT Security Services

Seite 96

Grundlagen, Forderungen und Marktübersicht für Intrusion Detection Systeme (IDS) und Intrusion Response Systeme (IRS)

Produkt-/Projektstudie

Erweiterbarkeit / Programmierschnittstelle Unter diesem Punkt werden die Möglichkeiten beschrieben, das IDS mit neuen Angriffssignaturen zu erweitern. Kann der Anwender eigene Signaturen selbst entwickeln und diese anschließend einbinden? Wie häufig wird die Signaturdatenbank durch den Hersteller aktualisiert? Welche Kosten entstehen bei einem solchen Update? Wie gut kann das IDS an die Zielumgebung angepaßt werden? Ist es möglich, systemspezifische Informationen (z.B.: /dev/ttya ist ein Einwählmodem), benutzerspezifische Information (z.B.: Herr Müller hat nächsten Monat Urlaub) und/oder lokale Sicherheitsrichtlinien (z.B.: Benutzer sollen ActiveX nicht verwenden) zu hinterlegen?

Performanz Es werden zwei Performanzaspekte berücksichtigt: •

Analyse: Wie schnell kann ein Angriff entdeckt werden. Eine Echtzeitanalyse ist auf jeden Fall wünschenswert. Kann das System auch Angriffe vorhersagen?

•

Gesamtsystem: In welchem Umfang belastet das IDS das gesamte Netz bzw. in welchem Umfang belasten die IDS-Komponenten die Rechner, auf denen sie ablaufen? Dies ist insbesondere für die rechnerbasierte Überwachung interessant.

Adaptivität Es wird zwischen zwei Arten der Adaptivität unterschieden. Die erste Art, Anpassen an das Benutzerverhalten, steht in engem Zusammenhang mit statistischer Anomalieerkennung. Angenommen das System hat gelernt, daß anna@ai-sun den GNU C Compiler und Emacs benutzt. Eines Tages entscheidet sich Anna dazu, Java zu lernen. Wie schnell ist das System in der Lage zu lernen, daß Anna eine neue Programmiersprache lernt und nicht das System angreift? Wieviel administrativen Aufwand kostet es bei einer semi-automatischen Umstellung, dem IDS beizubringen, daß Anna Java lernt? Der zweite Punkt betrifft den Automatischen Wechsel der Abstraktionsebene. Angenommen das IDS arbeitet mit bereits abstrahierten Auditdaten. Ist das IDS beispielsweise in der Lage, im Falle eines Angriffs die Granularität der Auditdaten automatisch zu verfeinern, um so mehr Information über den Angriff zu erhalten?

Datenschutzrechtliche Aspekte Es stellen sich u.a. folgende Fragen: Was geschieht mit den Benutzerdaten? Haben sich die Entwickler des IDS Gedanken zum Datenschutz gemacht? Inwieweit ist ein ehrlicher Benutzer vor dem Sammlungseifer des IDS geschützt? Werden die Daten anonymisiert? Wann geschieht das? 12.07.2000

debis IT Security Services

Seite 97

Grundlagen, Forderungen und Marktübersicht für Intrusion Detection Systeme (IDS) und Intrusion Response Systeme (IRS)

Produkt-/Projektstudie

Systembeschreibung Hier wird das betreffende IDS genauer beschrieben. Die Information dazu entstammt aus Herstellerunterlagen, Vergleichstests, technischen Berichten etc. Wir haben keine eigenen Tests der Software durchgeführt.

Format/Semantik der Ein-/Ausgabedaten: Welche Auditdaten werden analysiert? Wie ist das Format dieser Auditdaten? Welche Bedeutung haben diese Auditdaten (d.h., was bedeutet es, wenn der Eintrag XY den Wert 3.1415 hat)?

Verfügbarkeit: Handelt es sich bei dem hier vorliegenden IDS um ein kommerzielles Produkt oder lediglich um einen universitären Prototyp? Neben den häufig fehlenden Signaturdatenbanken sind viele Prototypen gar nicht mehr verfügbar.

Systemanforderungen: Welche technischen Voraussetzungen (Hardware, Software) sind notwenig, um das IDS in Betrieb nehmen zu können?

Sicherheit Wie gut schützt sich das IDS selbst gegen Angriffe? Können ID-Komponenten von einem Angreifer durch andere Komponenten ersetzt werden? Wie sicher läuft die Kommunikation zwischen einer Datensammlungsstation und der Analysestation ab?

Dokumentation Gibt es hinreichend gute Dokumente, mit denen die Funktionsweise des ID-Systems nachvollzogen werden kann oder gibt es lediglich Hochglanzbroschüren?

Am Ende dieses Kapitels befindet sich eine zusammenfassende Tabelle, welche die wesentlichen Eigenschaften der untersuchten ID-Systeme zusammenfaßt. 12.07.2000

debis IT Security Services

Seite 98

Grundlagen, Forderungen und Marktübersicht für Intrusion Detection Systeme (IDS) und Intrusion Response Systeme (IRS)

Produkt-/Projektstudie

Notation in den folgenden Tabellen: JA:

Merkmal ist bei dem entsprechenden IDS verfügbar.

NEIN:

Merkmal ist bei dem entsprechenden IDS nicht verfügbar.

N.A.:

Not Addressed.

NEIN*:

Das IDS verfügt im Lieferzustand (out-of-the-box) nicht über dieses Merkmal, kann jedoch entsprechend konfiguriert werden.

12.07.2000

debis IT Security Services

Seite 99

Grundlagen, Forderungen und Marktübersicht für Intrusion Detection Systeme (IDS) und Intrusion Response Systeme (IRS)

Produkt-/Projektstudie

3.3 EMERALD (http://www.csl.sri.com/emerald/index.html) Angriffsszenarien: Abtastende Suche nach TCP/UDP/RPC-Diensten (mit Half Open Scans und Stealth Scans)

NEIN*

Spoofing (IP, DNS, WEB etc.)

JA

Denial-of-Service-Angriffe (SYN Flooding, PING etc.)

JA

Routing Angriffe (Source Routing, ICMP Redirect)

NEIN*

Versuchte Einbrüche (Erraten des Paßworts, Erraten des NIS file handles)

N.A.

Angriffe auf bekannte Sicherheitslöcher (sendmail, NIS, NFS, bind etc.)

N.A.

Software mit Schadensfunktionalität (Viren, Würmer etc.)

N.A.

Angriffe über WWW-Dienste (ActiveX, Java, MIME etc.)

NEIN*

Erkennungsstärken des IDS

Die EMERALD-Architektur erlaubt es, heterogene Angriffe sowie Normababweichungen des Benutzerverhaltens in bezug auf Zuverlässigkeit, Sicherheit etc. zu erkennen. Tatsächliche Signaturen und Profile wurden in diesem Zusammenhang jedoch nicht erstellt.

Auditdaten: Quelle:

12.07.2000

Benutzerlogdaten, Applikationslogdaten, Datagramme, SNMP-Verkehr, externe Monitore (vgl.

debis IT Security Services

Seite 100

Grundlagen, Forderungen und Marktübersicht für Intrusion Detection Systeme (IDS) und Intrusion Response Systeme (IRS)

Produkt-/Projektstudie

Systembeschreibung), Daten anderer ID-Systeme Ziel:

Hauptmonitore (vgl. Systembeschreibung)

Granularität:

fein - grob

Datenanalyse: Rechnerebene:

JA

Netzebene:

JA

Signaturanalyse:

JA, Signature Engine (vgl. Systembeschreibung)

Anomalieerkennung:

JA, Profiler Engine

statistisch:

JA

Methode:

Bayes’sche Inferenz

logisch:

JA

weitergehende Analyse:

NEIN

Architektur: Datensammlung:

verteilt

Datenanalyse:

hybrid

Kommunikation:

asynchron

Reaktion: Benachrichtigung:

Der “Resolver” versendet hierarchisch geordnete Benachrichtigungen

Bericht:

JA, verschieden Formen

Maßnahmen:

automatische Gegenmaßnahmen möglich

Angriffsprotokollierung:

JA

Benutzerschnittstelle:

JA, grafisch

Thumbprinting:

JA

Zielumgebung:

Große Firmennetze, Zusatzwerkzeug zu anderen zentralisierten ID-Komponenten

12.07.2000

debis IT Security Services

Seite 101

Grundlagen, Forderungen und Marktübersicht für Intrusion Detection Systeme (IDS) und Intrusion Response Systeme (IRS)

Produkt-/Projektstudie

Zusammenarbeit mit Firewalls:

SunScreen, andere möglich

Erweiterbarkeit / Programmierschnittstellen:

API verfügbar, Protokollspezifikation „fast fertig“

Performanz: Analyse:

Echtzeit

Gesamtsystem:

N.A.

Adaptivität: Anpassen an das Benutzerverhalten:

JA (keine weitere Information)

Automatischer Wechsel der Abstraktionsebene:

JA (keine weitere Information)

Datenschutzrechtliche Aspekte:

N.A.

Systembeschreibung: •

EMERALD beinhaltet ein hierarchisches Schema zu Datenanalyse, d.h. es gibt folgende Typen von Analyseschemata: firmenweite Analyse (höchste Ebene), bereichsweite Analyse (mittlere Ebene) und Dienstanalyse (unterste Ebene).

•

EMERALD basiert wie DIDS (s.u.) auf einer Monitorarchitektur. Jedem Monitor ist ein spezifischer Bereich zugeordnet (d.h. Firma, Bereich oder Dienst). Jeder Monitor besteht aus einer zentralen Einheit (dem Resource Object), die die aufgabenspezifischen Konfigurationsdaten enthält, sowie den dezentralen Einheiten Resolver, Profiler und Signaturerkennung. Profiler Engine: Hier findet die statistische, profilbasierte Anomalieerkennung statt. Die Profile sind als Klassen im Resource-Objekt enthalten. Jede Profiler Engine untersucht einen bestimmten Ereignisstrom. Signaturerkennung: Diese enthält die für den Monitortyp relevante Signaturdatenbank. Sie wird im Resource-Objekt des Monitors gespeichert.

•

Resolver: Ein Monitor kann aus mehreren Profilern und Signaturerkennern bestehen. Diese Komponenten können große Datenmengen (event logs) analysieren und erstellen weniger große Protokolldatenmengen über Angriffe bzw. Verhaltensabweichungen. Diese Protokolldatenmengen werden an den Resolver übergeben, der dann die geeigneten Reaktionen festlegen muß.

•

Die Dienstmonitore analysieren in Echtzeit die Daten der Netzinfrastruktur (z.B. Router und Gateways).

•

Die Bereichsmonitore sammeln die Angriffsprotokolldaten der Dienstmonitore, um so eine bereichsweite Analyse von eventuellen Angriffen zu ermöglichen.

12.07.2000

debis IT Security Services

Seite 102

Grundlagen, Forderungen und Marktübersicht für Intrusion Detection Systeme (IDS) und Intrusion Response Systeme (IRS)

•

Produkt-/Projektstudie

Die Firmenmonitore bekommen Bereichsdaten als Eingabe. Ihre Aufgabe ist es, Angriffe wie z.B. den Internet-Wurm oder Angriffe auf Netzdienste zu erkennen.

Format/Semantik der Ein-/Ausgabedaten: Die Dokumentation des Common Intrusion Detection Format (CIDF) soll in Kürze veröffentlicht werden (vgl. dazu auch Abschnitt 4.2.2.1, Punkt 35.). Limitationen:

N.A.

Verfügbarkeit: EMERALD ist noch in der Entwicklung. Das Projekt soll bis 1999 gefördert werden Systemanforderungen:

SUN OS oder Solaris

Sicherheit:

Kryptographische Authentisierung

Bemerkungen: Wir erhielten von den Entwicklern von EMERALD die Auskunft, daß EMERALD eine bedeutende Weiterentwicklung der Netzanalysefähigkeiten von IDES und NIDES ist. EMERALD ist jedoch kein kommerzielles Produkt, sondern wird von der DARPA gefördert. IDES wird vollständig unter EMERALD subsumiert.

12.07.2000

debis IT Security Services

Seite 103

Grundlagen, Forderungen und Marktübersicht für Intrusion Detection Systeme (IDS) und Intrusion Response Systeme (IRS)

Produkt-/Projektstudie

3.4 DIDS

Angriffsszenarien: Abtastende Suche nach TCP/UDP/RPC-Diensten (mit Half Open Scans und Stealth Scans)

N.A.

Spoofing (IP, DNS, WEB etc.)

N.A.

Denial-of-Service-Angriffe (SYN Flooding, PING etc.)

N.A.

Routing Angriffe (Source Routing, ICMP Redirect)

N.A.

Versuchte Einbrüche (Erraten des Paßworts, Erraten des NIS file handles)

JA (doorknob attack, network browsing)

Angriffe auf bekannte Sicherheitslöcher (sendmail, NIS, NFS, bind etc.)

N.A.

Software mit Schadensfunktionalität (Viren, Würmer etc.)

N.A.

Angriffe über WWW-Dienste (ActiveX, Java, MIME etc.)

N.A.

Erkennungsstärken des IDS

doorknob attack, network browsing

Auditdaten: Quelle: HEG (vgl. Systembeschreibung):

OS Auditdaten

LEG (vgl. Systembeschreibung):

Netzdienste

Ziel:

DIDS Director (vgl. Systembeschreibung)

Granularität:

fein

Datenanalyse: Rechnerebene: 12.07.2000

JA debis IT Security Services

Seite 104

Grundlagen, Forderungen und Marktübersicht für Intrusion Detection Systeme (IDS) und Intrusion Response Systeme (IRS)

Produkt-/Projektstudie

Netzebene:

JA

Signaturanalyse:

JA, HEG/LEG (vgl. Systembeschreibung)

Anomalieerkennung:

JA, HEG/LEG

statistisch:

JA (LAN Monitor)

Methode:

N.A.

logisch:

JA (Director (XPS))

weitergehende Analyse:

NEIN

Architektur: Datensammlung:

verteilt

Datenanalyse:

hybrid

Kommunikation:

asynchron, ISO CMIP based

Reaktion: Benachrichtigung:

JA (SSO)

Bericht:

N.A.

Maßnahmen:

N.A.

Angriffsprotokollierung:

N.A.

Benutzerschnittstelle:

N.A.

Thumbprinting:

JA, über NID (Network UserIdentification); z. Zt. noch etwas problematisch.

Zielumgebung:

Heterogene Umgebung aus C2 oder höher zertifizierten Rechnern / Betriebssystemen.

Zusammenarbeit mit Firewalls:

N.A.

Erweiterbarkeit / Programmierschnittstellen:

JA, Verwendbarkeit mit anderen ID-Werkzeugen (geplant)

Performanz: Analyse:

N.A.

Gesamtsystem:

N.A.

12.07.2000

debis IT Security Services

Seite 105

Grundlagen, Forderungen und Marktübersicht für Intrusion Detection Systeme (IDS) und Intrusion Response Systeme (IRS)

Produkt-/Projektstudie

Adaptivität: Anpassen an das Benutzerverhalten:

N.A.

Automatischer Wechsel der Abstraktionsebene:

N.A.

Datenschutzrechtliche Aspekte:

N.A.

Systembeschreibung: •

DIDS besteht aus den Hauptbestandteilen DIDS Director (DD), einem einzelnen Hostmonitor für jeden Rechner und einem LAN-Monitor für jedes LAN-Segment. Die Kommunikation zwischen diesen Komponenten basiert auf ISO CMIP. Host Monitor: Dieser besteht aus einem Host-Ereignisgenerator (HEG) und einem Host-Dienstboten (Agent). Der HEG sammelt und analysiert Auditdaten und erstellt eine Liste besonderer Ereignisse, die dann über den Host-Dienstboten (der die Kommunikation zwischen Monitor und DD abwickelt) zum DD gesandt wird. LAN Monitor: Dieser besteht aus einem LAN-Ereignisgenerator (LEG) und einem LAN-Dienstboten (Agent). Die Funktionalität des LEG ist eine Teilmenge der Funktionalität des NCM der UC Davis. DIDS Director (DD): Dieser besteht aus einem Kommunikationsmanager, dem Expertensystem und der Benutzerschnittstelle. Kommunikationsmanager: Dieser ist für die Kommunikation zwischen DD und Host Monitor sowie zwischen DD und LAN Monitor verantwortlich. Sobald einer der Monitore ein besonderes Ereignis meldet, wird diese Meldung mit Hilfe des Kommunikationsmanagers zum DD geschickt. XPS: Das Expertensystem basiert auf Regeln mit PROLOG-ähnlicher Syntax und hat eine sehr einfache Lernfähigkeit. Das XPS besitzt einen Inferenzmechanismus, mit dessen Hilfe reine Auditdaten in eine abstraktere Darstellung überführt werden können. Benutzerschnittstelle: Diese erlaubt dem System Security Officer (SSO) eine interaktive Kontrolle des Gesamtsystems. Der SSO kann so die Aktivitäten auf jedem einzelnen Rechner sowie auf dem Netz beobachten.

Format/Semantik der Ein-/Ausgabedaten:

N.A

Einschränkungen:

N.A.

Verfügbarkeit: DIDS soll von Trident Data Systems (www.tds.com) als Produkt entwickelt werden. Wir erhielten folgende Stellungsnahme von Trident:

12.07.2000

debis IT Security Services

Seite 106

Grundlagen, Forderungen und Marktübersicht für Intrusion Detection Systeme (IDS) und Intrusion Response Systeme (IRS)

Produkt-/Projektstudie

Trident has discussed the possibility of productizing DIDS for distribution to other US Government agencies, or possibly for sale to the commercial information protection marketplace. The Air Force has agreed that, under certain conditions, Trident could develop DIDS into a commercial product, and we have discussed possible development and production approaches with a number of potential customers and teaming partners. Trident Data Systems does not currently project a release date for a commercial version of DIDS. Organizations interested in using DIDS as it currently exists are encouraged to contact the appropriate agencies within the US Air Force for additional information. Systemanforderungen: Host Monitor läuft auf Sicherheitserweiterung.

SUN

SparcStations

(SUN

Sicherheit:

12.07.2000

OS

4.0.x)

mit

SUN

C2

N.A.

debis IT Security Services

Seite 107

Grundlagen, Forderungen und Marktübersicht für Intrusion Detection Systeme (IDS) und Intrusion Response Systeme (IRS)

Produkt-/Projektstudie

3.5 GrIDS (http://www.seclab.cs.ucdavis.edu/arpa/grids) Angriffsszenarien: Abtastende Suche nach TCP/UDP/RPC-Diensten (mit Half Open Scans und Stealth Scans)

NEIN

Spoofing (IP, DNS, WEB etc.)

NEIN

Denial-of-Service-Angriffe (SYN Flooding, PING etc.)

NEIN

Routing Angriffe (Source Routing, ICMP Redirect)

NEIN

Versuchte Einbrüche (Erraten des Paßworts, Erraten des NIS file handles)

JA (jedoch nicht viele)

Angriffe auf bekannte Sicherheitslöcher (sendmail, NIS, NFS, bind etc.)

NEIN

Software mit Schadensfunktionalität (Viren, Würmer etc.)

JA (hauptsächlich Würmer)

Angriffe über WWW-Dienste (ActiveX, Java, MIME etc.)

NEIN

Erkennungsstärken des IDS

Würmer

Auditdaten: Quelle:

Daten von Sniffern oder einem anderen IDS, welches auf einem einzelnen Rechner oder LAN läuft.

Ziel:

Grafik-Modul (vgl. Systembeschreibung)

Granularität:

fein

Datenanalyse: Rechnerebene:

NEIN

Netzebene:

JA

Signaturanalyse:

NEIN

12.07.2000

debis IT Security Services

Seite 108

Grundlagen, Forderungen und Marktübersicht für Intrusion Detection Systeme (IDS) und Intrusion Response Systeme (IRS)

Produkt-/Projektstudie

Anomalieerkennung:

NEIN

weitergehende Analyse:

NEIN

Architektur: Datensammlung:

verteilt

Datenanalyse:

verteilt

Kommunikation:

N.A.

Reaktion: Benachrichtigung:

JA

Bericht:

NEIN

Maßnahmen:

NEIN

Angriffsprotokollierung:

JA

Benutzerschnittstelle:

GUI

Thumbprinting:

NEIN

Zielumgebung:

TCP/IP-Netze mit Tausenden von Benutzern.

Zusammenarbeit mit Firewalls:

NEIN

Erweiterbarkeit / Programmmierschnittstelle:

JA

Performanz: Analyse:

N.A.

Gesamtsystem:

N.A.

Adaptivität: Anpassen an das Benutzerverhalten:

NEIN

Automatischer Wechsel der Abstraktionsebene:

NEIN

Datenschutzrechtliche Aspekte:

N.A.

Systembeschreibung: GrIDS ist ein Meta-IDS, welches versucht die Ausgabedaten anderer IDKomponenten so aufzubereiten, daß Angriffe, die von den einzelnen Komponenten übersehen werden, entdeckt werden können. Angriffserkennung: GrIDS konstruiert aus der Netzaktivität einen sogenannten Aktivitätsgraph. Dieser Graph enthält eine gerichtete Kante von v_1 nach v_2, 12.07.2000

debis IT Security Services

Seite 109

Grundlagen, Forderungen und Marktübersicht für Intrusion Detection Systeme (IDS) und Intrusion Response Systeme (IRS)

Produkt-/Projektstudie

falls es eine Datenübertragung von der Maschine v_1 zur Maschine v_2 gab. Falls die Größe des Graphen einen bestimmten Schwellenwert überschreitet, so wird der SSO benachrichtigt. Um zu vermeiden, daß jede kaskadierende Netzaktivität (z.B. SMTP in einigen Fällen) Fehlalarme auslöst, besitzt GrIDS Filterregeln, die festlegen, welche Netzaktivität ignoriert werden soll. Skalierbarkeit: GrIDS geht davon aus, daß der Hauptteil der Netzaktivität lokal bleibt (beispielsweise innerhalb einer Abteilung). Eine weitere Annahme ist, daß diese Subnetze partiell geordnet werden können. So erhält man eine Abteilungshierarchie. Indem nun alle Rechner eines Subnetzes zu einem Superknoten zusammengefaßt werden (vergleichbar mit strengen Zusammenhangskomponenten), erhält man einen Graph, der – im Idealfall – deutlich kleiner als der Ausgangsgraph ist. Die Entwickler von GrIDS werben damit, auf diese Weise stets einen handhabbaren Aktivitätsgraphen erzeugen zu können, so daß das System beliebig skalierbar sei. Format/Semantik der Ein-/Ausgabedaten:

N.A.

Verfügbarkeit:

Das System ist ein Prototyp, der verfügbar sein wird, sobald die Evaluation an der UC Davis abgeschlossen ist.

Systemanforderungen:

Läuft auf verschiedenen UnixDerivaten, erfordert Perl 5.

Einschränkungen:

Die Integrität der Kommunikationsdaten kann nicht sichergestellt werden, d.h. es ist möglich, GrIDS-Komponenten durch eigene Werkzeuge zu ersetzen.

Sicherheit:

N.A.

Bemerkungen:

keine

12.07.2000

debis IT Security Services

Seite 110

Grundlagen, Forderungen und Marktübersicht für Intrusion Detection Systeme (IDS) und Intrusion Response Systeme (IRS)

Produkt-/Projektstudie

3.6 LogSurfer http://www.cert.dfn.de Angriffsszenarien: Abtastende Suche nach TCP/UDP/RPC-Diensten (mit Half Open Scans und Stealth Scans)

NEIN

Spoofing (IP, DNS, WEB etc.)

NEIN

Denial-of-Service-Angriffe (SYN Flooding, PING etc.)

NEIN*

Routing Angriffe (Source Routing, ICMP Redirect)

NEIN

Versuchte Einbrüche (Erraten des Paßworts, Erraten des NIS file handles)

NEIN*

Angriffe auf bekannte Sicherheitslöcher (sendmail, NIS, NFS, bind etc.)

NEIN*

Software mit Schadensfunktionalität (Viren, Würmer etc.)

NEIN*

Angriffe über WWW-Dienste (ActiveX, Java, MIME etc.)

NEIN*

Erkennungsstärken des IDS

Auditdaten: Quelle:

Auditdaten, die mit Hilfe von Regulären Ausdrücken analysiert werden können

Ziel:

andere Programme (via Unix Pipe)

Granularität:

mittel

Datenanalyse: Rechnerebene:

JA, falls dies von der Regelmenge unterstützt wird

Netzebene:

NEIN

12.07.2000

debis IT Security Services

Seite 111

Grundlagen, Forderungen und Marktübersicht für Intrusion Detection Systeme (IDS) und Intrusion Response Systeme (IRS)

Produkt-/Projektstudie

Signaturanalyse:

JA, in Abhängigkeit von der Regelmenge

Anomalieerkennung:

JA, in Abhängigkeit von der Regelmenge

statistisch:

NEIN

logisch:

JA, regelbasiert

weitergehende Analyse:

NEIN

Architektur: Datensammlung:

zentral

Datenanalyse:

zentral

Kommunikation:

kein Kommunikationsmodell

Reaktion: Benachrichtigung:

JA

Bericht:

JA

Maßnahmen:

Ausführen beliebiger anderer Programme

Angriffsprotokollierung:

N.A.

Benutzerschnittstelle:

NEIN

Thumbprinting:

NEIN

Zielumgebung:

einzelner Rechner

Zusammenarbeit mit Firewalls:

NEIN (aber Regelmenge kann prinzipiell Firewall-Auditdaten analysieren)

Erweiterbarkeit / Programmierschnittstellen:

JA, Signaturdatenbank

Performanz: Analyse:

N.A.

Gesamtsystem:

N.A.

Adaptivität: Anpassen an das Benutzerverhalten:

NEIN

Automatischer Wechsel der Abstraktionsebene:

NEIN

12.07.2000

debis IT Security Services

Seite 112

Grundlagen, Forderungen und Marktübersicht für Intrusion Detection Systeme (IDS) und Intrusion Response Systeme (IRS)

Datenschutzrechtliche Aspekte:

Produkt-/Projektstudie

N.A.

Systembeschreibung: LogSurfer ist ein Programm, welches einzelne Zeilen einer Logdatei einliest und diese versucht gegen eine Menge von Regulären Ausdrücken abzugleichen. Falls der Abgleich erfolgreich ist, können vordefinierte Aktionen ausgeführt werden. LogSurfer benutzt “Regeln”, um solche Aktionen auszulösen. Die Prämisse einer solchen Regel beginnt mit einer Menge von Regulären Ausdrücken. Darüber hinaus verfügt LogSurfer über einen einfachen Mechnismus, um Negation darzustellen. Mit seiner Hilfe können beispielsweise Regeln der Form “Falls die Logzeile das Pattern x und nicht das Pattern y enthält, dann ...” formuliert werden. Format/Semantik der Ein-/Ausgabedaten:

N.A.

Verfügbarkeit: ftp://ftp.cert.dfn.de/pub/tools/audit/logsurfer/ Systemanforderungen:

Unix-Rechner

Einschränkungen:

kein Sniffing

Sicherheit:

N.A.

Bemerkungen:

keine

12.07.2000

debis IT Security Services

Seite 113

Grundlagen, Forderungen und Marktübersicht für Intrusion Detection Systeme (IDS) und Intrusion Response Systeme (IRS)

Produkt-/Projektstudie

3.7 RealSecure http://www.iss.net Angriffsszenarien: Abtastende Suche nach TCP/UDP/RPC-Diensten (mit Half Open Scans und Stealth Scans)

JA

Spoofing (IP, DNS, WEB etc.)

JA (IP)

Denial-of-Service-Angriffe (SYN Flooding, PING etc.)

JA

Routing Angriffe (Source Routing, ICMP Redirect)

JA

Versuchte Einbrüche (Erraten des Paßworts, Erraten des NIS file handles)

JA

Angriffe auf bekannte Sicherheitslöcher (sendmail, NIS, NFS, bind etc.)

JA

Software mit Schadensfunktionalität (Viren, Würmer etc.)

NEIN

Angriffe über WWW-Dienste (ActiveX, Java, MIME etc.)

JA

Erkennungsstärken des IDS

X-force Datenbank: (http://www.iss.net/ xforce/display.htm)

Auditdaten: Quelle:

IP-Pakete

Ziel:

Signaturanalyse-Modul

Granularität:

fein

Datenanalyse: Rechnerebene:

JA

Netzebene:

JA

Signaturanalyse:

JA

12.07.2000

debis IT Security Services

Seite 114

Grundlagen, Forderungen und Marktübersicht für Intrusion Detection Systeme (IDS) und Intrusion Response Systeme (IRS)

Produkt-/Projektstudie

Anomalieerkennung: statistisch:

JA

Methode:

N.A.

logisch:

JA

weitergehende Analyse:

N.A.

Architektur: Datensammlung:

zentral

Datenanalyse:

zentral

Kommunikation:

TCP-Port 590 sowie UDP-Ports 900 und 901 zur Kommunikation zwischen mehreren RealSecure-Systemen.

Reaktion: Benachrichtigung:

JA

Bericht:

JA

Maßnahmen:

Event logging; Benachrichtigung des SSO mittels Konsolenmeldungen, E-Mails oder Pagern; Beendigung von Programmen; Aufruf eines benutzerdefinierten Programms; Kombination dieser Maßnahmen.

Angriffsprotokollierung:

JA

Benutzerschnittstelle:

GUI

Thumbprinting:

NEIN

Zielumgebung:

Einzelne Rechner, Netze, WebSites, Firewalls.

Zusammenarbeit mit Firewalls:

JA (keine weitere Information)

Erweiterbarkeit / Programmierschnittstellen:

Kann vom Systemadministrator erweitert werden.

Performanz: Analyse:

12.07.2000

Echtzeit

debis IT Security Services

Seite 115

Grundlagen, Forderungen und Marktübersicht für Intrusion Detection Systeme (IDS) und Intrusion Response Systeme (IRS)

Gesamtsystem:

Produkt-/Projektstudie

keine signifikante Mehrlast laut Hersteller. Laut Aussage von Herrn Borsing vom deutschen Distributor COMCAD gibt es jedoch einen deutlichen Lastzuwachs auf dem Rechner, der die Daten sammelt.

Adaptivität: Anpassen an das Benutzerverhalten:

NEIN

Automatischer Wechsel der Abstraktionsebene:

NEIN

Datenschutzrechtliche Aspekte:

N.A.

Systembeschreibung: RealSecure ist ein Sniffer, der jedes Protokoll der TCP/IP-Protokollfamilie beobachten und filtern kann. RealSecure kann so konfiguriert werden, daß protokollabhängig nach Quell- und Zielport, Quell- und/oder Zieladresse gefiltert werden kann. RealSecure beobachtet den Netzverkehr und führt einen Abgleich der dort gefundenen Muster mit denen in der Signaturdatenbank durch. RealSecure sollte an einigen strategisch relevanten Punkten innerhalb des zu schützenden Netzes plaziert werden (z.B. in der Nähe eines Routers). Sobald RealSecure einen möglichen Angriff entdeckt, wird ein Alarm ausgelöst und mit einer benutzerdefinierten Reaktion geantwortet (Intrusion Response). Format/Semantik der Ein-/Ausgabe:

N.A.

Verfügbarkeit:

JA

Systemanforderungen:

SUN Solaris 2.3 oder höher, SUN OS 4.1.x, Linux (Kernelversion 1.3 oder höher), Windows NT 3.51 und 4.0

Einschränkungen:

Laut [Ptacek und Newsham, 1998] erkennt RealSecure fragmentierte IP-Pakete nicht korrekt.

Sicherheit:

N.A.

Bemerkungen:

Relativ gute Dokumentation.

12.07.2000

debis IT Security Services

Seite 116

Grundlagen, Forderungen und Marktübersicht für Intrusion Detection Systeme (IDS) und Intrusion Response Systeme (IRS)

Produkt-/Projektstudie

3.8 Stalker (http://www.haystack.com) Angriffsszenarien: Abtastende Suche nach TCP/UDP/RPC-Diensten (mit Half Open Scans und Stealth Scans)

NEIN (nur SATAN Scans)

Spoofing (IP, DNS, WEB etc.)

NEIN

Denial-of-Service-Angriffe (SYN Flooding, PING etc.)

NEIN

Routing Angriffe (Source Routing, ICMP Redirect)

NEIN

Versuchte Einbrüche (Erraten des Paßworts, Erraten des NIS file handles)

JA

Angriffe auf bekannte Sicherheitslöcher (sendmail, NIS, NFS, bind etc.)

JA

Software mit Schadensfunktionalität (Viren, Würmer etc.)

JA (crack, gimme etc.)

Angriffe über WWW-Dienste (ActiveX, Java, MIME etc.)

JA

Erkennungsstärken des IDS

SATAN attacks

Auditdaten: Quelle:

OS Audit Records

Ziel:

Misuse Detector Komponente

Granularität:

fein - mittel

Datenanalyse: Rechnerebene:

JA

Netzebene:

NEIN

Signaturanalyse:

JA, mit Schwellwertberücksichtigung

12.07.2000

debis IT Security Services

Seite 117

Grundlagen, Forderungen und Marktübersicht für Intrusion Detection Systeme (IDS) und Intrusion Response Systeme (IRS)

Produkt-/Projektstudie

Anomalieerkennung: statistisch:

NEIN

Methode:

N.A.

logisch:

NEIN

weitergehende Analyse:

NEIN

Architektur: Datensammlung:

zentral (in Version 1) verteilt (in Version 2)

Datenanalyse:

zentral

Kommunikation:

KEINE (Version 1) Keine Angaben (Version 2)

Reaktion: Benachrichtigung:

JA

Bericht:

JA

Maßnahmen:

NEIN

Attack logging:

JA

Benutzerschnittstelle:

Motif oder OpenLook GUI

Thumbprinting:

NEIN (geplant)

Zielumgebung:

Heterogenes Unix-Umfeld

Zusammenarbeit mit Firewalls: Stalker 2.1 kann Auditdaten der Firewalls TIS Gauntlet und IBM NetSP verabeiten. Darüber hinaus ist Stalker über ein API in der Lage, Auditdaten im SVR4++ Format zu lesen. Erweiterbarkeit / Programmierschnittstellen:

JA (Signaturdatenbank und Skalierbarkeit auf größere Netze). Darüber hinaus gibt es ein API für SVR4++ Auditdaten (vgl. Zusammenarbeit mit Firewalls).

Performanz: Analyse:

N.A.

Gesamtsystem:

N.A.

12.07.2000

debis IT Security Services

Seite 118

Grundlagen, Forderungen und Marktübersicht für Intrusion Detection Systeme (IDS) und Intrusion Response Systeme (IRS)

Produkt-/Projektstudie

Adaptivität: Anpassen an das Benutzerverhalten:

NEIN

Automatischer Wechsel der Abstraktionsebene:

NEIN

Datenschutzrechtliche Aspekte:

N.A.

Systembeschreibung: Stalker analysiert Auditdaten. Stalker analysiert nicht auf IP Netzebene. Stalker besteht aus den folgenden Komponenten: Tracer/Browser: Diese Komponente beantwortet u.a. folgende Fragen: •

Was passierte letzte Nacht auf dem Datenbank-Server?

•

Hat sich jemand von außerhalb des Firmennetzes eingeloggt und wenn ja, wie?

•

Hat jemand unberechtigterweise bestimmte Programme aufgerufen?

•

Wer hat letzte Woche auf die Daten der Lohnbuchhaltung zugegriffen?

•

Hat jemand von außerhalb versucht, eine „SUID (Set-User-ID) root”-Datei zu installieren?

Die Ergebnisse werden mittels elektronischer Post, Anzeige an der Konsole oder Dateieintrag übermittelt. Eine Benachrichtigung mittels Pager ist ebenfalls möglich. Misuse Detector: Diese Komponente beantwortet u.a. folgende Fragen: •

Hat jemand versucht, ein trojanisches Pferd zu installieren?

•

Wer hat versucht, root-Rechte zu erlangen?

•

Hat jemand versucht, mittels eines Sniffers Paßwörter zu stehlen?

Audit Control: organisiert die Sammlung von Auditdaten über das Netz. Es arbeitet in einem heterogenen Unix-Umfeld und sammelt die Daten von einer zentralen Stelle aus. Hier kann auch definiert werden, welche Ereignisse zu protokollieren sind. Storage Manager: speichert die über das Netz gesammelten Auditdaten. Der Storage Manager kann die gesammelten Daten in einer Verzeichnishierachie (directory hierarchy) ablegen; er bildet darüber hinaus eine Schnittstelle zum Betriebssystem. Format/Semantik der Ein-/Ausgabedaten: 12.07.2000

debis IT Security Services

N.A. Seite 119

Grundlagen, Forderungen und Marktübersicht für Intrusion Detection Systeme (IDS) und Intrusion Response Systeme (IRS)

Verfügbarkeit:

Produkt-/Projektstudie

JA

Systemanforderungen: Stalker 2.1 ist für folgende Systeme verfügbar: SUN Microsystems, IBM, SCO UnixWare, und HP Unix-Systeme. Es unterstützt Motif, CDE und OpenLook. Einschränkungen:

kein Schüffeln auf Netzebene

Sicherheit:

N.A.

Bemerkungen:

keine

12.07.2000

debis IT Security Services

Seite 120

Grundlagen, Forderungen und Marktübersicht für Intrusion Detection Systeme (IDS) und Intrusion Response Systeme (IRS)

Produkt-/Projektstudie

3.9 NetRanger (http://www.network.com) Angriffsszenarien: Abtastende Suche nach TCP/UDP/RPC-Diensten (mit Half Open Scans und Stealth Scans) Spoofing (IP, DNS, WEB etc.)

JA

JA (IP)

Denial-of-Service-Angriffe (SYN Flooding, PING etc.)

JA

Routing Angriffe (Source Routing, ICMP Redirect)

JA

Versuchte Einbrüche (Erraten des Paßworts, Erraten des NIS file handles)

JA

Angriffe auf bekannte Sicherheitslöcher (sendmail, NIS, NFS, bind etc.)

JA

Software mit Schadensfunktionalität (Viren, Würmer etc.)

N.A.

Angriffe über WWW-Dienste (ActiveX, Java, MIME etc.)

N.A.

Erkennungsstärken des IDS

SYN, sendmail, ping sweep, IP Source Routing und Spoofing, FTP und telnet Mißbrauch, SATAN Angriffe etc. (über 100)

Auditdaten: Quelle:

Netzüberwachung (Sniffing)

Ziel:

NetRanger Director (über eine mit BorderGuard gesicherte Verbindung); die Daten können darüber hinaus in eine Datenbank geschrieben werden (z.B. Oracle) und dann später mittels eines „Data Mining“-Werkzeugs analysiert werden.

12.07.2000

debis IT Security Services

Seite 121

Grundlagen, Forderungen und Marktübersicht für Intrusion Detection Systeme (IDS) und Intrusion Response Systeme (IRS)

Granularität:

Produkt-/Projektstudie

fein

Datenanalyse: Rechnerebene:

NEIN

Netzebene:

JA

Signaturanalyse:

JA

Anomalieerkennung:

NEIN

weitergehende Analyse:

NEIN

Architektur: Datensammlung:

verteilt

Datenanalyse:

zentral

Kommunikation:

Kommunikation über Secure IP

Reaktion: Benachrichtigung:

JA

Bericht:

JA

Maßnahmen:

Verbindungsabbruch

Angriffsprotokollierung:

JA

Benutzerschnittstelle: Graphisch (HP OpenView unterstützte GUI mit Network Node Manager auf HP/UX 10.0, Solaris 2.4 und 2.5) Thumbprinting:

NEIN

Zielumgebung:

Netze mittlerer Größe

Zusammenarbeit mit Firewalls: NetRanger kann vor einer Firewall plaziert werden und bietet so ID-Maßnahmen sowohl für die Server, die ebenfalls vor der Firewall liegen, als auch für die Firewall selbst. Erweiterbarkeit / Programmierschnittstellen:

12.07.2000

debis IT Security Services

JA (Signaturdatenbank)

Seite 122

Grundlagen, Forderungen und Marktübersicht für Intrusion Detection Systeme (IDS) und Intrusion Response Systeme (IRS)

Produkt-/Projektstudie

Performanz: Analyse:

Echtzeit

Gesamtsystem:

läuft auf dediziertem Rechner

Adaptivität: Anpassen an das Benutzerverhalten:

NEIN

Automatischer Wechsel der Abstraktionsebene:

NEIN

Datenschutzrechtliche Aspekte:

N.A.

Systembeschreibung: NetRanger besteht aus einem oder mehreren sog. Sensoren – NSX genannt –, einem sicheren Kommunikationskanal sowie einem Managementsystem. Die Sensoren werden zwischen dem vertrauenswürdigen Netz und dem externen Netz plaziert. Sie melden ihre Beobachtungen über einen proprietären, fehlertoleranten „point-to-point”Kommunikationskanal dem Managementsystem. Die Kommunikation erfolgt verschlüsselt. Der Benutzer kann zwischen verschieden Kryptoverfahren auswählen. Über diesen sicheren Kommunikationskanal werden auch die Konfigurationdaten an die NSXe versendet; auch die Alarmmeldung vom NSX an Managementstation erfolgt verschlüsselt über diesen Kanal. Das Managementsystem – Director genannt – verfügt über eine grafische Oberfäche, über welche die NSX-Alarme gemeldet werden; die Konfiguration der NSX erfolgt ebenfalls über diese Oberfläche. Der Director protokolliert alle besonderen Vorkommnisse und ermöglicht die Erstellung von Trendberichten. Jeder Director kann bis zu 100 NSX-Sensoren verwalten. Laut Aussagen des Herstellers kann NetRanger Angriffsmuster erkennen, selbst wenn die IP-Pakete fragmentiert sind oder auch der Header fragmentiert ist. Format/Semantik der Ein-/Ausgabedaten:

N.A.

Verfügbarkeit:

JA

Systemanforderungen:

NSX läuft unter Solaris.

Einschränkungen:

N.A.

Sicherheit:

Kommunikation über Secure IP

Bemerkungen:

keine

12.07.2000

debis IT Security Services

Seite 123

Grundlagen, Forderungen und Marktübersicht für Intrusion Detection Systeme (IDS) und Intrusion Response Systeme (IRS)

Produkt-/Projektstudie

3.10 NetStalker (http://www.haystack.com) Angriffsszenarien: Abtastende Suche nach TCP/UDP/RPC-Diensten (mit Half Open Scans und Stealth Scans)

N.A.

Spoofing (IP, DNS, WEB etc.)

N.A.

Denial-of-Service-Angriffe (SYN Flooding, PING etc.)

JA

Routing Angriffe (Source Routing, ICMP Redirect)

N.A.

Versuchte Einbrüche (Erraten des Paßworts, Erraten des NIS file handles)

JA

Angriffe auf bekannte Sicherheitslöcher (sendmail, NIS, NFS, bind etc.)

N.A.

Software mit Schadensfunktionalität (Viren, Würmer etc.)

N.A.

Angriffe über WWW-Dienste (ActiveX, Java, MIME etc.)

N.A.

Erkennungsstärken des IDS

Haystack-Datenbank

Auditdaten: Quelle:

Routermeldungen; Überwachung für jedes TCP/IPProtokoll möglich

Ziel:

N.A.

Granularität:

fein (ICMP) – mittel (X-protocol)

Datenanalyse: Rechnerebene:

NEIN

Netzebene:

JA

Signaturanalyse:

JA

12.07.2000

debis IT Security Services

Seite 124

Grundlagen, Forderungen und Marktübersicht für Intrusion Detection Systeme (IDS) und Intrusion Response Systeme (IRS)

Produkt-/Projektstudie

Anomalieerkennung:

N.A.

weitergehende Analyse:

N.A.

Architektur: Datensammlung:

zentral

Datenanalyse:

zentral

Kommunikation:

N.A.

Reaktion: Benachrichtigung:

JA: E-Mail, Pager, SNMP Traps

Bericht:

JA

Maßnahmen:

Verbindungsabbruch, Schließen einzelner Ports

Angriffsprotokollierung:

N.A.

Benutzerschnittstelle:

GUI

Thumbprinting:

N.A.

Zielumgebung:

Netze

Zusammenarbeit mit Firewalls NetStalker arbeitet eng mit der NSC NetSentry Firewall zusammen. Während NetSentry u.U. Pakete nach der Header/Datenfeld-Analyse zurückweist, inspiziert NetStalker diese Pakete, um Angriffsmuster zu entdecken. Erweiterbarkeit / Programmierschnittstellen:

Unterstützung mehrerer gleichzeitiger Router; Signaturdatenbank kann erweitert werden.

Performanz: Analyse:

Echtzeit

Gesamtsystem:

N.A.

Adaptivität: Anpassen an das Benutzerverhalten:

N.A.

Automatischer Wechsel der Abstraktionsebene:

N.A.

12.07.2000

debis IT Security Services

Seite 125

Grundlagen, Forderungen und Marktübersicht für Intrusion Detection Systeme (IDS) und Intrusion Response Systeme (IRS)

Datenschutzrechtliche Aspekte:

Produkt-/Projektstudie

N.A.

Systembeschreibung: NetStalker benutzt die Paketfiltereigenschaft der NSC-Router, um Information über Netzverbindungen der NetStalker-Workstation zu übermitteln und so den Zugang zu den Netzressourcen, die vom Router überwacht werden, zu kontrollieren. Vom ICMP-Request bis zu NFS oder dem X-Protokoll können alle Ebenen der Netzkommunikation überwacht werden. (Weitere Informationen sind leider nicht verfügbar.) Format/Semantik der Ein-/Ausgabedaten:

N.A.

Verfügbarkeit:

NEIN

Systemanforderungen: - SUN SPARC Station mit mind. 32 MB RAM und 50 MB Plattenplatz - SUN OS 4.1.x oder Solaris 2.x - NSC Security Router, Border Guard oder DX Series Einschränkungen:

JA (Nur bestimmte Produkte, s.o.)

Sicherheit:

N.A.

Bemerkungen:

Das Produkt ist nicht mehr verfügbar.

12.07.2000

debis IT Security Services

Seite 126

Grundlagen, Forderungen und Marktübersicht für Intrusion Detection Systeme (IDS) und Intrusion Response Systeme (IRS)

Produkt-/Projektstudie

3.11 NIDES (http://www.csl.sri.com) Angriffsszenarien: Abtastende Suche nach TCP/UDP/RPC-Diensten (mit Half Open Scans und Stealth Scans)

NEIN*

Spoofing (IP, DNS, WEB etc.)

NEIN*

Denial-of-Service-Angriffe (SYN Flooding, PING etc.)

NEIN*

Routing Angriffe (Source Routing, ICMP Redirect)

NEIN*

Versuchte Einbrüche (Erraten des Paßworts, Erraten des NIS file handles)

NEIN*

Angriffe auf bekannte Sicherheitslöcher (sendmail, NIS, NFS, bind etc.)

NEIN*

Software mit Schadensfunktionalität (Viren, Würmer etc.)

NEIN*

Angriffe über WWW-Dienste (ActiveX, Java, MIME etc.)

NEIN*

Erkennungsstärken des IDS

Eine Menge von 39 Regeln steht für SUN Unix zu Verfügung.

Auditdaten: Quelle:

proprietäres generisches Auditformat

Ziel:

N.A.

Granularität:

N.A.

Datenanalyse: Rechnerebene:

JA

Netzebene:

NEIN

Signaturanalyse:

JA (falls entsprechende Regeln vorhanden)

12.07.2000

debis IT Security Services

Seite 127

Grundlagen, Forderungen und Marktübersicht für Intrusion Detection Systeme (IDS) und Intrusion Response Systeme (IRS)

Anomalieerkennung:

Produkt-/Projektstudie

JA

statistisch:

JA

Methode:

X^2 ähnlich

logisch:

JA (die Regelmenge)

weitergehende Analyse:

N.A.

Architektur: Datensammlung:

verteilt

Datenanalyse:

zentral

Kommunikation:

N.A.

Reaktion: Benachrichtigung:

JA, Systemadministrator wird per E-Mail benachrichtigt

Bericht:

N.A.

Maßnahmen:

N.A.

Angriffsprotokollierung:

N.A.

Benutzerschnittstelle:

X-Windows, kontextsensitive Hilfe

Thumbprinting:

N.A.

Zielumgebung:

N.A.

Zusammenarbeit mit Firewalls:

N.A.

Erweiterbarkeit / Programmierschnittstellen:

NIDES kann mittels des generischen Auditdaten-Formats an viele Systeme angepaßt werden.

Performanz: Analyse:

Echtzeit oder Batchbetrieb

Gesamtsystem:

Echtzeit oder Batchbetrieb

Adaptivität: Anpassen an das Benutzerverhalten:

JA

Automatischer Wechsel der Abstraktionsebene:

N.A.

Datenschutzrechtliche Aspekte:

12.07.2000

N.A.

debis IT Security Services

Seite 128

Grundlagen, Forderungen und Marktübersicht für Intrusion Detection Systeme (IDS) und Intrusion Response Systeme (IRS)

Produkt-/Projektstudie

Systembeschreibung: NIDES ist ein hybrides ID-Werkzeug, welches sowohl Signaturanalyse (Mißbrauchsanalyse) als auch Anomalieerkennung bietet. Die Anomalieerkennung basiert auf einem statistischen Ansatz. Verhalten, welches in deutlichem Maße von dem als Normverhalten definierten abweicht, wird als Intrusion gewertet. Dazu benutzt NIDES Benutzerprofile, die aus über 30 verschiedenen Kriterien (CPU- und I/O-Last, benutzte Kommandos, Systemfehler, lokale Netzaktivität etc.) zusammengestellt werden. Die Benutzerprofile werden periodisch auf den neuesten Stand gebracht. Die Signaturanalyse vergleicht die Auditdaten mit Angriffsmustern (wie üblich). Die Signaturdatenbank kann vom Benutzer angepaßt werden. Format/Semantik der Ein-/Ausgabe

N.A.

Verfügbarkeit:

Prototyp im Beta Test (1994), nicht weiter unterstützt, nicht verfügbar.

Systemanforderungen:

SUN OS 4.1.x or Solaris 1.1 SUN BSM or C2 auditing

Einschränkungen:

N.A.

Sicherheit:

N.A.

Bemerkungen:

Nach Informationen der Entwickler ist NIDES kaum verfügbar. EMERALD verfügt jedoch über den vollen Funktionalitätsumfang von NIDES. Auch der Prototyp von NIDES wird nicht weiter unterstützt.

12.07.2000

debis IT Security Services

Seite 129

Grundlagen, Forderungen und Marktübersicht für Intrusion Detection Systeme (IDS) und Intrusion Response Systeme (IRS)

Produkt-/Projektstudie

3.12 StakeOut (http://www.stakeout.harris.com/) Angriffsszenarien: Abtastende Suche nach TCP/UDP/RPC-Diensten (mit Half Open Scans und Stealth Scans)

JA

Spoofing (IP, DNS, WEB etc.)

JA (IP)

Denial-of-Service-Angriffe (SYN Flooding, PING etc.)

JA

Routing Angriffe (Source Routing, ICMP Redirect)

JA

Versuchte Einbrüche (Erraten des Paßworts, Erraten des NIS file handles)

JA

Angriffe auf bekannte Sicherheitslöcher (sendmail, NIS, NFS, bind etc.)

JA

Software mit Schadensfunktionalität (Viren, Würmer etc.)

N.A.

Angriffe über WWW-Dienste (ActiveX, Java, MIME etc.)

N.A.

Erkennungsstärken des IDS

Große Anzahl vordefiniertet Trigger (keine weiteren Informationen)

Auditdaten: Quelle:

TCP/IP-Pakete

Ziel:

N.A.

Granularität:

fein – mittel

Datenanalyse: Rechnerebene:

NEIN

Netzebene:

JA

Signaturanalyse:

JA

12.07.2000

debis IT Security Services

Seite 130

Grundlagen, Forderungen und Marktübersicht für Intrusion Detection Systeme (IDS) und Intrusion Response Systeme (IRS)

Produkt-/Projektstudie

Anomalieerkennung:

JA (Signaturanalyse mit Schwellenwert)

weitergehende Analyse:

NEIN

Architektur: Datensammlung:

zentral

Datenanalyse:

zentral

Kommunikation:

StakeOut benutzt die Schnittstelle STREAM DLPI zur Kommunikation im Netzwerk. Für die Kommunikation mit dem Alert Viewer wird eine verschlüsselte TCP-Socketverbindung verwendet; für die Kommunikation mit dem Harris Network Management (HNM, http://www.hnm.harris.com) werden SUN RPCs verwendet. Darüber hinaus ist das Absetzen von SNMP Traps möglich.

Reaktion: Benachrichtigung:

JA: E-Mail, Pager

Bericht:

JA (kann zu einem beliebigen SNMP-Client gesendet werden)

Maßnahmen:

Benachrichtigung, benutzerdefinierte Reaktion

Angriffsprotokollierung:

JA

Benutzerschnittstelle:

GUI (X/Motif)

Thumbprinting:

NEIN

Zielumgebung:

10-Mbit-Ethernet-Netze (andere sind möglich, jedoch nicht getestet)

Zusammenarbeit mit Firewalls:

NEIN (kann aber gemeinsam mit Firewalls verwendet werden, z.B. CyberGuard)

Erweiterbarkeit / Programmierschnittstellen:

Die Programmierschnittstelle ist nur vorhanden, falls HNM benutzt wird. Die Signaturdatenbank wird

12.07.2000

debis IT Security Services

Seite 131

Grundlagen, Forderungen und Marktübersicht für Intrusion Detection Systeme (IDS) und Intrusion Response Systeme (IRS)

Produkt-/Projektstudie

vom Hersteller ständig überarbeitet. Performanz: Analyse:

Echtzeit

Gesamtsystem:

Prototyp lief laut Hersteller auf einer SUN Sparc Ix mit 64 MB RAM, welche das interne T1-Netz hinter einer CyberGuard Firewall ohne Paketverlust beobachtete.

Adaptivität: Anpassen an das Benutzerverhalten:

NEIN (statistische Komponente z. Zt. in der Entwicklung)

Automatischer Wechsel der Abstraktionsebene:

NEIN

Datenschutzrechtliche Aspekte:

N.A.

Systembeschreibung: StakeOut wird über eine Ethernet-Netzwerkkarte an das Netz angeschlossen. Das System überwacht die TCP/IP-Kommunikation auf einem Netzsegment, indem es den gesamten Datenverkehr im Netz analysiert. Die Pakete werden mit der Signaturdatenbank verglichen. Falls eine Übereinstimmung mit einem Angriffsmuster entdeckt wird, protokolliert das System den Vorfall mit Quell- und Ziel-IP-Adresse, der aktuellen Uhrzeit sowie einer kurzen Beschreibung. StakeOut bietet auch Anomalieerkennung an. Falls ein Angriff erkannt wurde, protokolliert das System solange den gesamten IP Verkehr vom Angreifer zum internen Netz, bis ein vordefinierter Zeitrahmen überschritten wird oder der Benutzer diese Protokollierung unterbricht. Format/Semantik der Ein-/Ausgabe Eingabedaten sind die IP-Pakete, die im Promiscuous Mode aufgenommen werden. Ausgegeben werden IP-Pakete und Alarmmeldungen.

Verfügbarkeit:

12.07.2000

JA (ca. $3000); Staffelpreise möglich)

debis IT Security Services

Seite 132

Grundlagen, Forderungen und Marktübersicht für Intrusion Detection Systeme (IDS) und Intrusion Response Systeme (IRS)

Produkt-/Projektstudie

Systemanforderungen:

Minimum: SUN Ultra 1, 140 MHz, Solaris 2.5.1, 64 MB RAM, 2 GB Plattenplatz (für Logdaten)

Einschränkungen:

StakeOut wurde nur auf Ethernet getestet.

Sicherheit: Logdaten sind mit DES verschlüsselt. Konfigurationsdaten sind ebenfalls mit DES verschlüsselt und können nur mit root-Rechten auf dem Rechner, auf dem StakeOut installiert ist, geändert werden. Sämtliche Text-Zeichenketten der Anwendung sind verschlüsselt, um ein Ändern der Fehlermeldungen im Programm zu verhindern. Auch TCP-Socket-Verbindungen zur Administration sind verschlüsselt, lediglich SNMP Traps sind NICHT verschlüsselt. Bemerkungen:

12.07.2000

keine

debis IT Security Services

Seite 133

Grundlagen, Forderungen und Marktübersicht für Intrusion Detection Systeme (IDS) und Intrusion Response Systeme (IRS)

Produkt-/Projektstudie

3.13 AID http://www-rnks.informatik.tu-cottbus.de/~sobirey/aid.html Angriffsszenarien: Abtastende Suche nach TCP/UDP/RPC-Diensten (mit Half Open Scans und Stealth Scans)

N.A.

Spoofing (IP, DNS, WEB etc.)

N.A.

Denial-of-Service-Angriffe (SYN Flooding, PING etc.)

N.A.

Routing Angriffe (Source Routing, ICMP Redirect)

N.A.

Versuchte Einbrüche (Erraten des Paßworts, Erraten des NIS file handles)

N.A.

Angriffe auf bekannte Sicherheitslöcher (sendmail, NIS, NFS, bind etc.)

N.A.

Software mit Schadensfunktionalität (Viren, Würmer etc.)

N.A.

Angriffe über WWW-Dienste (ActiveX, Java, MIME etc.)

N.A.

Erkennungsstärken des IDS

10 verschiedene Angriffsszenarien (keine weitere Information)

Auditdaten: Quelle:

Auditdaten

Ziel:

AID Manager (vgl. Beschreibung)

Granularität:

grob

Datenanalyse: Rechnerebene:

JA

Netzebene:

JA (Host-basiertes Netz-Auditing)

Signaturanalyse:

JA

12.07.2000

debis IT Security Services

Seite 134

Grundlagen, Forderungen und Marktübersicht für Intrusion Detection Systeme (IDS) und Intrusion Response Systeme (IRS)

Produkt-/Projektstudie

Anomalieerkennung:

N.A.

weitergehende Analyse:

N.A.

Architektur: Datensammlung:

verteilt

Datenanalyse:

zentral

Kommunikation:

Secure RPC

Reaktion: Benachrichtigung:

JA

Bericht:

N.A

Maßnahmen:

N.A.

Angriffsprotokollierung:

JA

Benutzerschnittstelle:

GUI

Thumbprinting:

N.A.

Zielumgebung:

N.A.

Zusammenarbeit mit Firewalls:

N.A.

Erweiterbarkeit / Programmierschnittstellen:

Signaturdatenbank

Performanz: Analyse:

Echtzeit

Gesamtsystem:

untersucht 2,5 MB Auditdaten pro Minute

Adaptivität: Anpassen an das Benutzerverhalten:

N.A.

Automatischer Wechsel der Abstraktionsebene:

N.A.

Datenschutzrechtliche Aspekte:

N.A.

Systembeschreibung: Das AID System besteht aus verschiedenen Clients, welche die Auditdaten untersuchen und ihren Bericht in einer abstrahierten Form mittels Secure RPC in einem betriebssystemunabhängigen Format an den AID Manager weiterleiten. Der AID Manager benutzt ein Expertensystem, um festzustellen, ob die ihm gelieferten Daten einen Angriff

12.07.2000

debis IT Security Services

Seite 135

Grundlagen, Forderungen und Marktübersicht für Intrusion Detection Systeme (IDS) und Intrusion Response Systeme (IRS)

Produkt-/Projektstudie

darstellen. Die Inferenzkomponente des XPS („Expertensystem“) basiert auf einem DEA (Deterministischen Endlichen Automat), der eine Signaturanalyse druchführt. Format/Semantik der Ein-/Ausgabe

N.A.

Verfügbarkeit:

JA

Systemanforderungen:

SUN Solaris 2.x

Einschränkungen:

N.A.

Sicherheit:

Benutzt Secure RPC, Pseudonymisiert die Auditdaten

Bemerkungen:

keine

12.07.2000

debis IT Security Services

(Prototyp)

Seite 136

Grundlagen, Forderungen und Marktübersicht für Intrusion Detection Systeme (IDS) und Intrusion Response Systeme (IRS)

Produkt-/Projektstudie

3.14 IDES

Angriffsszenarien: Abtastende Suche nach TCP/UDP/RPC-Diensten (mit Half Open Scans und Stealth Scans)

N.A.

Spoofing (IP, DNS, WEB etc.)

N.A.

Denial-of-Service-Angriffe (SYN Flooding, PING etc.)

N.A.

Routing Angriffe (Source Routing, ICMP Redirect)

N.A.

Versuchte Einbrüche (Erraten des Paßworts, Erraten des NIS file handles)

N.A.

Angriffe auf bekannte Sicherheitslöcher (sendmail, NIS, NFS, bind etc.)

N.A.

Software mit Schadensfunktionalität (Viren, Würmer etc.)

N.A.

Angriffe über WWW-Dienste (ActiveX, Java, MIME etc.)

N.A.

Erkennungsstärken des IDS

N.A.

Auditdaten: Quelle:

SUN OS Auditdaten, SUN C2 Auditdaten, Unix Accounting

Ziel:

Realm Schnittstelle (diese konvertiert die reinen Auditdaten in das IDES Auditdaten-Format)

Granularität:

mittel

Datenanalyse: Rechnerebene:

JA

Netzebene:

NEIN

Signaturanalyse:

JA

12.07.2000

debis IT Security Services

Seite 137

Grundlagen, Forderungen und Marktübersicht für Intrusion Detection Systeme (IDS) und Intrusion Response Systeme (IRS)

Anomalieerkennung:

Produkt-/Projektstudie

JA

statistisch:

JA

Methode:

N.A.

Meßdaten:

CPU-Last, I/O-Last, Durchsatz Mailverkehr, Durchsatz Netzaktivität.

logisch:

JA (XPS-gestützte Anomalieerkennung)

weitergehende Analyse:

N.A.

Architektur: Datensammlung:

verteilt

Datenanalyse:

zentral

Kommunikation:

RPC über TCP/IP-Kanal

Reaktion: Benachrichtigung:

JA

Bericht:

JA

Maßnahmen:

N.A.

Angriffsprotokollierung:

N.A.

Benutzerschnittstelle:

X-Windows, benutzerdefinierbare Kategorien (Views)

Thumbprinting:

N.A.

Zielumgebung:

N.A.

Zusammenarbeit mit Firewalls:

N.A.

Erweiterbarkeit / Programmierschnittstellen:

Schnittstellenbibliothek, Signaturdatenbank

Performanz: Analyse:

Echtzeit

Gesamtsystem:

auf dediziertem Rechner

Adaptivität: Anpassen an das Benutzerverhalten:

N.A.

Automatischer Wechsel der Abstraktionsebene:

N.A.

12.07.2000

debis IT Security Services

Seite 138

Grundlagen, Forderungen und Marktübersicht für Intrusion Detection Systeme (IDS) und Intrusion Response Systeme (IRS)

Datenschutzrechtliche Aspekte:

Produkt-/Projektstudie

N.A.

Systembeschreibung: IDES kann Rechner unter verschiedenen Betriebssystemen beobachten. IDES unterteilt die heterogene Systemumgebung in Gruppen von Rechnern mit gleichem AuditdatenFormat (Realms). Jeder Rechner sendet seine Auditdaten in normalisierter Form an das IDES-System (eine Schnittstelle wandelt das Realm-spezifische Auditdaten-Format in das IDES-Auditdaten-Format um und normalisiert dieses damit). Das IDES-System analysiert die Daten, um einen möglichen Angriff festzustellen. Das IDES System besteht aus folgenden Komponenten: - Realm Schnittstelle - statistische Anomalieerkennung - XPS-gestützte (logische) Anomalieerkennung - Benutzerschnittstelle Die statistische und die XPS-basierte Anomalieerkennung arbeiten parallel. Die statistische Komponente vergleicht die normalisierten Auditdaten mit den Werten in einer Datenbank. Wird die Abweichung zu groß, so wird ein Alarm ausgelöst. Das XPS arbeitet ähnlich; anstatt jedoch statistische Abweichungen zu ermitteln, vergleicht es die Auditdaten mit den Prämissen von Produktionsregeln. Diese Produktionsregeln legen fest, wann ein Alarm auszulösen ist; im Alarmfall wird der SSO informiert. Die Benutzerschnittstelle unterscheidet drei Typen von Benutzern: den SSO, den Datenanalysten und den Systemadministrator. Jeder von ihnen interessiert sich für andere Aspekte, die ihm mit Hilfe verschiedener Ansichten (Views) präsentiert werden. Format/Semantik der Ein-/Ausgabe Die Eingabedaten enthalten Information über die CPU-Last, Dateizugriffe, Netzdurchsatz etc. Verfügbarkeit:

Verschiedene Betaversionen sind verfügbar (1992), werden jedoch nicht mehr unterstützt.

Systemanforderungen:

SUN OS 4.0.x

Einschränkungen:

N.A.

Sicherheit:

N.A.

Bemerkungen:

Das Werkzeug wird nicht mehr unterstützt. Zu IDES und NIDES

12.07.2000

debis IT Security Services

Seite 139

Grundlagen, Forderungen und Marktübersicht für Intrusion Detection Systeme (IDS) und Intrusion Response Systeme (IRS)

Produkt-/Projektstudie

sind viele Forschungsberichte verfügbar (vgl. Literaturliste).

12.07.2000

debis IT Security Services

Seite 140

Grundlagen, Forderungen und Marktübersicht für Intrusion Detection Systeme (IDS) und Intrusion Response Systeme (IRS)

Produkt-/Projektstudie

3.15 Kane Security Monitor (http://www.intrusion.com/) Angriffsszenarien: Abtastende Suche nach TCP/UDP/RPC-Diensten (mit Half Open Scans und Stealth Scans)

NEIN

Spoofing (IP, DNS, WEB etc.)

NEIN

Denial-of-Service-Angriffe (SYN Flooding, PING etc.)

JA auf Host-Ebene

Routing Angriffe (Source Routing, ICMP Redirect)

NEIN

Versuchte Einbrüche (Erraten des Paßworts, Erraten des NIS file handles)

JA

Angriffe auf bekannte Sicherheitslöcher (sendmail, NIS, NFS, bind etc.)

JA

Software mit Schadensfunktionalität (Viren, Würmer etc.)

NEIN

Angriffe über WWW-Dienste (ActiveX, Java, MIME etc.)

NEIN

Erkennungsstärken des IDS

N.A.

Auditdaten: Quelle:

Eigene Auditdaten, Betriebssystemauditdaten von WindowsNT; kein Sniffing

Ziel:

Analyser

Granularität:

mittel

Datenanalyse: Rechnerebene:

JA

Netzebene:

NEIN

Signaturanalyse:

JA, Schwellenwert-unterstützt

12.07.2000

debis IT Security Services

Seite 141

Grundlagen, Forderungen und Marktübersicht für Intrusion Detection Systeme (IDS) und Intrusion Response Systeme (IRS)

Anomalieerkennung:

Produkt-/Projektstudie

NEIN

statistisch:

N.A.

Methode:

N.A.

Meßdaten:

N.A.

logisch:

N.A.

weitergehende Analyse:

NEIN

Architektur: Datensammlung:

verteilt

Datenanalyse:

zentral

Kommunikation:

verschlüsselt (keine genauere Information verfügbar)

Reaktion: Benachrichtigung:

JA: E-Mail, Pager etc.

Bericht:

JA

Maßnahmen:

N.A.

Angriffsprotokollierung:

NEIN

Benutzerschnittstelle:

GUI

Thumbprinting:

NEIN

Zielumgebung:

Windows NT-Netze

Zusammenarbeit mit Firewalls:

zusammen einsetzbar

Erweiterbarkeit / Programmierschnittstellen:

Signaturdatenbank; skalierbar für größere Netze

Performanz: Analyse:

auf dediziertem Rechner

Gesamtsystem:

minimaler Performanzverlust

Adaptivität: Anpassen an das Benutzerverhalten:

NEIN

Automatischer Wechsel der Abstraktionsebene: n.a. NEIN Datenschutzrechtliche Aspekte:

12.07.2000

N.A.

debis IT Security Services

Seite 142

Grundlagen, Forderungen und Marktübersicht für Intrusion Detection Systeme (IDS) und Intrusion Response Systeme (IRS)

Produkt-/Projektstudie

Systembeschreibung: Der Kane Security Monitor (KSM) ermöglicht eine zentrale Analyse der verteilt gesammelten Auditdaten. Die Daten werden von einer Menge von NT Rechnern gesammelt und anschließend auf einer Konsole analysiert. KSM entdeckt verdächtiges Verhalten mittels Signaturanalyse. Der SSO kann die vordefinierte Signaturdatenbank selbständig erweitern, indem er Regeln wie „schicke mir eine E-Mail, falls jemand einen Account auf dem Rechner eröffnet” hinzufügt. Format/Semantik der Ein-/Ausgabedaten:

In den Auditdaten werden Systemaufrufe protokolliert.

Verfügbarkeit:

JA (ca. 1290 DM für eine NT Server Lizenz und 190 DM für eine NT Workstation Lizenz)

Systemanforderungen:

NT Workstation mit Pentium 100 oder schneller. Client und Console: 32 MB RAM und 10 MB Plattenplatz.

Einschränkungen:

kein Sniffing, nur für Windows NT

Sicherheit:

N.A.

Bemerkungen:

keine

12.07.2000

debis IT Security Services

Seite 143

Grundlagen, Forderungen und Marktübersicht für Intrusion Detection Systeme (IDS) und Intrusion Response Systeme (IRS)

Produkt-/Projektstudie

3.16 OmniGuard Intruder Alert (http://www.axent.com/) Angriffsszenarien: Abtastende Suche nach TCP/UDP/RPC-Diensten (mit Half Open Scans und Stealth Scans)

NEIN

Spoofing (IP, DNS, WEB etc.)

NEIN

Denial-of-Service-Angriffe (SYN Flooding, PING etc.)

JA

Routing Angriffe (Source Routing, ICMP Redirect)

NEIN

Versuchte Einbrüche (Erraten des Paßworts, Erraten des NIS file handles)

JA

Angriffe auf bekannte Sicherheitslöcher (sendmail, NIS, NFS, bind etc.)

JA

Software mit Schadensfunktionalität (Viren, Würmer etc.)

NEIN

Angriffe über WWW-Dienste (ActiveX, Java, MIME etc.)

JA

Erkennungsstärken des IDS

Auditdaten: Quelle:

Unix-Syslog, Unix-Systemdatei wtmp, Process Accounting, Application Log, benutzerdefinierte Quellen

Ziel:

IA Manager

Granularität:

mittel

Datenanalyse: Rechnerebene:

JA

Netzebene:

N.A.

Signaturanalyse:

JA

12.07.2000

debis IT Security Services

Seite 144

Grundlagen, Forderungen und Marktübersicht für Intrusion Detection Systeme (IDS) und Intrusion Response Systeme (IRS)

Anomalieerkennung:

Produkt-/Projektstudie

JA

statistisch:

N.A.

logisch:

N.A.

weitergehende Analyse:

NEIN

Architektur: Datensammlung:

verteilt

Datenanalyse:

zentral

Kommunikation:

Verschlüsslete TCP/IP- und IPX/SPX-Kommunikation

Reaktion: Benachrichtigug:

JA: E-Mail, Pager etc.

Bericht:

JA (inklusive einer Sicherheitsstatistik, die den SSO bei der Feineinstellung des IA unterstützt)

Maßnahmen:

Zugriffsverweigerung, Beendigung von Programmen etc.

Angriffsprotokollierung:

N.A.

Benutzerschnittstelle:

GUI (läuft auf verschiedenen Systemen, vgl. Liste unten)

Thumbprinting:

N.A.

Zielumgebung:

heterogene Netze

Zusammenarbeit mit Firewalls:

JA (keine weitere Information)

Erweiterbarkeit / Programmierschnittstellen:

Signaturdatenbank, größere Netze

Performanz: Analyse:

Echtzeit

Gesamtsystem:

typische Mehrlast: 5% (für den Agenten)

Adaptivität: Anpassen an das Benutzerverhalten:

NEIN

Automatischer Wechsel der Abstraktionsebene:

NEIN

12.07.2000

debis IT Security Services

Seite 145

Grundlagen, Forderungen und Marktübersicht für Intrusion Detection Systeme (IDS) und Intrusion Response Systeme (IRS)

Datenschutzrechtliche Aspekte:

Produkt-/Projektstudie

N.A.

Systembeschreibung: Das Produkt OmniGuard Intruder Alert besteht aus den folgenden drei Arten von Komponenten: •

Console GUI

•

Manager

•

Agent

Die Agenten werden dazu benutzt, die einzelnen Komponenten (Betriebssysteme, Firewalls, Router etc.) des Netzes zu beobachten. Die Benutzeroberfläche (GUI) steuert den IA Manager, der wiederum die Agenten lenkt. Die Benutzeroberfläche ist auf Windows-Plattformen ablauffähig, während die Agenten und Manager auf größeren Workstations ablaufen. Die Agenten beobachten die Auditdaten des Betriebssystems und SNMP Traps. Jeder Agent ist auf eine bestimmte Komponente spezialisiert: Es gibt Web-Server-Agenten, Anwendungsagenten, Betriebssystem-Agenten etc. Der Hersteller erneuert die Signaturdatenbanken für diese Agenten kontinuierlich. Der Manager benachrichtigt im Alarmfall den SSO. Format/Semantik der Ein-/Ausgabedaten:

N.A.

Verfügbarkeit:

JA

Systemanforderungen: SUN Solaris und SUN OS auf Sparc IBM AIX auf RS 6000 und Power PC HP-UX auf PA-RISC Digital Unix auf OSF/1 und AXP Silicon Graphics IRIX NCR MPRAS auf Intel Motorola SVR3 und SVR4 (nur Agenten) Sequent Dynix (nur Agent) Novell Netware 3.x und 4.x (nur Manager und Agenten) Windows 3.1 und 95 (nur GUI) Windows NT Einschränkungen:

12.07.2000

kein Sniffing

debis IT Security Services

Seite 146

Grundlagen, Forderungen und Marktübersicht für Intrusion Detection Systeme (IDS) und Intrusion Response Systeme (IRS)

Produkt-/Projektstudie

Sicherheit:

Ab Version 3.0 ist die Kommunikation zwischen Manager, Agent und GUI mit Diffie-Hellmann verschlüsselt. Die Logdateien sind ebenfalls verschlüsselt.

Bemerkungen:

keine

12.07.2000

debis IT Security Services

Seite 147

Grundlagen, Forderungen und Marktübersicht für Intrusion Detection Systeme (IDS) und Intrusion Response Systeme (IRS)

Produkt-/Projektstudie

3.17 PDAT (Protocol Data Analysis Tool) Angriffsszenarien: Abtastende Suche nach TCP/UDP/RPC-Diensten (mit Half Open Scans und Stealth Scans)

NEIN

Spoofing (IP, DNS, WEB etc.)

NEIN

Denial-of-Service-Angriffe (SYN Flooding, PING etc.)

NEIN

Routing Angriffe (Source Routing, ICMP Redirect)

NEIN

Versuchte Einbrüche (Erraten des Paßworts, Erraten des NIS file handles)

JA, teilweise

Angriffe auf bekannte Sicherheitslöcher (sendmail, NIS, NFS, bind etc.)

NEIN*

Software mit Schadensfunktionalität (Viren, Würmer etc.)

NEIN

Angriffe über WWW-Dienste (ActiveX, Java, MIME etc.)

NEIN

Erkennungsstärken des IDS

N.A.

Auditdaten: Quelle:

Auditdaten des Betriebssystems

Ziel:

PDAT

Granularität:

mittel

Datenanalyse: Rechnerebene:

JA

Netzebene:

NEIN

Signaturanalyse:

JA

Anomalieerkennung:

JA

12.07.2000

statistisch:

JA

Methode:

Durchschnittswerte und Varianz debis IT Security Services

Seite 148

Grundlagen, Forderungen und Marktübersicht für Intrusion Detection Systeme (IDS) und Intrusion Response Systeme (IRS)

Produkt-/Projektstudie

Meßdaten:

Versuchte Logins u.ä.

logisch:

N.A.

weitergehende Analyse:

N.A.

Architektur: Datensammlung:

zentral

Datenanalyse:

zentral

Kommunikation:

KEINE

Reaktion: Benachrichtigung:

JA

Bericht:

N.A.

Maßnahmen:

N.A.

Angriffsprotokollierung:

JA

Benutzerschnittstelle:

GUI (X11)

Thumbprinting:

NEIN

Zielumgebung:

N.A.

Zusammenarbeit mit Firewalls:

NEIN

Erweiterbarkeit / Programmierschnittstellen:

N.A.

Performanz: Analyse:

N.A.

Gesamtsystem:

N.A.

Adaptivität: Anpassen an das Benutzerverhalten:

JA

Automatischer Wechsel der Abstraktionsebene:

NEIN

Datenschutzrechtliche Aspekte:

N.A.

Systembeschreibung: PDAT analysiert die Auditdaten und kann so konfiguriert werden, daß Ereignisse wie 10 fehlgeschlagene Loginversuche zum Alarm führen. In diesem Fall benachrichtigt PDAT den SSO mittels E-Mail und/oder schickt eine Warnmeldung (E-Mail) an die Konsole. PDAT benutzt Methoden der Künstlichen Intelligenz, um das Benutzerverhalten zu erlernen. (Näheres zu diesen Methoden ist nicht bekannt.) 12.07.2000

debis IT Security Services

Seite 149

Grundlagen, Forderungen und Marktübersicht für Intrusion Detection Systeme (IDS) und Intrusion Response Systeme (IRS)

Produkt-/Projektstudie

PDAT ist in der Programmiersprache Prolog geschrieben und führt statistische Varianzanalyse durch. Format/Semantik der Ein-/Ausgabedaten:

Systemaufrufe in den Auditdaten

Verfügbarkeit:

NEIN

Systemanforderungen:

N.A.

Einschränkungen:

kein Sniffing

Sicherheit:

keine

Bemerkungen: PDAT wurde im Rahmen des ESPRIT-Projekts „Commandos” entwickelt und liegt in einer Prototyp-Implementierung vor. Das Papier [Weiss und Baur, 1990] beschreibt kurz die Hauptaspekte des Systems. Die Autoren haben diesen Ansatz jedoch nicht weiter verfolgt.

12.07.2000

debis IT Security Services

Seite 150

Grundlagen, Forderungen und Marktübersicht für Intrusion Detection Systeme (IDS) und Intrusion Response Systeme (IRS)

Produkt-/Projektstudie

3.18 Übersicht: Lizenzgebühren and Verfügbarkeit Produkt/Projekt

Verfügbarkeit

Preis (Größenordnung)

Emerald

1999

DIDS

beabsichtigtes Angebot durch Trident Systems (www.trident.de)

GrIDS

Prototype verfügbar ab Ende 1997

LogSurfer

JA

kostenlos

RealSecure

JA

ca. 10 000 DM

Stalker

JA

Stalker: 38 000 DM ca. 900 DM pro Client (10% Rabatt ab 10 Stück)

NetRanger

JA

NSX lite: 30 000 DM NSX heavy: 40 000 DM Director: 20 000 DM

NetStalker

nicht mehr verfügbar

–

NIDES

früherer Prototyp (1994) – nicht mehr verfügbar

StakeOut

JA

3000 US$

IDES

nicht mehr verfügbar

–

Kane Security Monitor

JA

1300 DM für einen NT Server, 50 000 DM für bis zu 250 Server; 185 DM pro NT Workstation, 3000 DM für bis zu 100 Clients

OmniGuard

JA

auf Anfrage

PDAT

NEIN

–

Bem.

N.A.

AID

Tabelle 4: Lizenzgebühren und Verfügbarkeit von ID-Systemen

12.07.2000

debis IT Security Services

Seite 151

Grundlagen, Forderungen und Marktübersicht für Intrusion Detection Systeme (IDS) und Intrusion Response Systeme (IRS)

Produkt-/Projektstudie

3.19 Übersicht: Hauptmerkmale der ID-Systeme Sniff: Das IDS ist in der Lage, einzelne IP-Datagramme zu analysieren (Network Sniffing). Audit: Das IDS ist in der Lage, Auditdaten und Logdaten zu analysieren. Collection: Gibt an, ob die Datensammlung auf verschiedenen Rechnern (verteilt) oder nur auf einem einzelnen Rechner (zentral) unterstützt wird. Ein IDS, welches die verteilte Datensammlung unterstützt, ist in Bezug auf wachsende Netzgröße skalierbarer. Analysis: Findet die Analyse auf nur einem einzelnen, zentralen Rechner (zentral) statt, findet sie – bei verteilter Sammlung – nur auf dem Rechner statt, der die Daten gesammelt hat (verteilt) oder ist sowohl eine zentrale als auch eine verteilte Analyse (hybrid) möglich? Extend. Signature base: Grundsätzlich wird davon ausgegangen, daß jeder Hersteller monatlich ein Update seiner Signaturdatenbank herausgibt. Kann der Benutzer darüber hinaus eigene Signaturen hinzufügen? Encryption: Verwendet das IDS Verschlüsselungstechniken und wenn ja, an welchen Stellen? FW: Ist das IDS in der Lage mit einem Firewallprodukt zusammenzuarbeiten. Falls dies prinzipiell möglich ist, der Hersteller allerdings kein konkretes Firewallprodukt nennen kann, so ist dies mit ‘+’ gekennzeichnet. Ist ein Feld in der Tabelle nicht belegt, so liegen zu diesem Punkt keine Informationen vor.

12.07.2000

debis IT Security Services

Seite 152

Grundlagen, Forderungen und Marktübersicht für Intrusion Detection Systeme (IDS) und Intrusion Response Systeme (IRS)

Produkt-/Projektstudie

Product

Sniff.

Audit

Collection

Analysis

Extend. Encryption Signature base

FW

Emerald

JA

JA

verteilt

hybrid

JA

SunScree

JA

verteilt

hybrid

JA

NEIN

verteilt

verteilt

NEIN

LogSurfer NEIN

JA

zentral

zentral

JA

RealSec.

JA

NEIN

zentral

zentral

NEIN

+

Stalker

NEIN

JA

verteilt

zentral

JA

TIS Gauntlet, IBM NetSP, SVR4+

NetRang

JA

NEIN

verteilt

zentral

NetStalke JA

NEIN

zentral

zentral

NEIN

NIDES

JA

verteilt

zentral

JA

StakeOut JA

NEIN

zentral

zentral

AID

NEIN

JA

verteilt

IDES

NEIN

JA

Kane

NEIN

DIDS GrIDS

NEIN

Authenticat.

Secure IP

+

NEIN

TCP/IP communic.

+

zentral

NEIN

Secure RPC communic.

verteilt

zentral

JA

JA

verteilt

zentral

JA

OmniGua NEIN

JA

verteilt

zentral

PDAT

JA

zentral

zentral

NEIN

NEIN

JA

NEIN

Tabelle 5: Hauptmerkmale der ID-Systeme

12.07.2000

debis IT Security Services

Seite 153

Grundlagen, Forderungen und Marktübersicht für Intrusion Detection Systeme (IDS) und Intrusion Response Systeme (IRS)

Anforderungskatalog an ein ID-System

4. Anforderungskatalog an ein ID-System Dieses Kapitel enthält einen Anforderungskatalog für ID-Systeme. Zunächst werden die Hauptanforderungen an ein ID-System beschrieben. Anschließend wird aus diesen eine Liste funktionaler Merkmale abgeleitet. Diese Liste ermöglicht zusammen mit den Anforderungen zur Vetrauenswürdigkeit eines ID-Systems die Erstellung einer Funktionalitätsklasse gemäß ITSEC (und evtl. eine analoge Kategorisierung nach den Common Criteria). Darüber hinaus werden Anforderungen diskutiert, die über die Aspekte Funktionalität und Vertrauenswürdigkeit hinausgehen. Es sei angemerkt, daß, obwohl sich der Anforderungskatalog zur Definition einer Funktionalitätsklasse gemäß ITSEC eignet und an den Common Criteria orientiert, er noch keine Funktionalitätsklasse darstellt.

4.1 Ziel Das unmittelbare Ziel von IDS ist die Erkennung von Angriffen auf zu schützende Ressourcen. Dies dient den folgenden übergeordneten Zielen: •

Die Verfügbarkeit der vom IDS zu schützenden IT-Dienste sicherzustellen und

•

die Integrität sowie

•

die Verfügbarkeit der im zu schützenden System gespeicherten Informationen zu garantieren.

Darüber hinaus ist Intrusion Detection in dem hier zu betrachtenden Kontext eine notwendige Voraussetzung für Intrusion Response. Um die oben genannten Ziele zu erreichen, sammelt das IDS Daten von verschiedenen Quellen und untersucht diese Daten auf einen möglichen Angriff gegen das zu schützende System. Sobald ein Angriff entdeckt wird, alarmiert das IDS den Sicherheitsbeauftragten per E-Mail, Pager etc. Anschließend übermittelt das IDS dem Intrusion Response System die zur Ergreifung von adäquaten Gegenmaßnahmen notwendigen Informationen.

4.2 Ein Prototyp für eine ID-Funktionalitätsklasse Der im folgenden beschriebene Vorschlag für eine Funktionalitätsklasse umfaßt sechs abstrakte Kategorien: •

Sicherheitsaudit

•

Wartungsunterstützung

•

Schutz der Sicherheitsfunktionen

12.07.2000

debis IT Security Services

Seite 154

Grundlagen, Forderungen und Marktübersicht für Intrusion Detection Systeme (IDS) und Intrusion Response Systeme (IRS)

•

Vertraulichkeit personengebundener Daten

•

Identifizierung und Authentifizierung

•

Verfügbarkeit der Dienste

Anforderungskatalog an ein ID-System

Jede Klasse enthält Funktionalitätsbeschreibungen, die zum Erreichen des erfolgreichen Einsatzes eines ID-Systems notwendig sind.

4.2.1 Sicherheitsaudit Das IDS muß sicherstellen, daß sämtliche von ihm gesammelten Daten nur aus vertrauenswürdigen Quellen stammen. Es sollte daher sowohl die Authentizität der Quelle als auch die Integrität der erhaltenen Daten überprüfen. Desweiteren muß das IDS möglichst viele Quellen zur Datensammlung berücksichtigen. Diese Aspekte führen zu einem Anforderungskatalog zur Datengenerierung und Datensammlung. Um die Verfügbarkeit der Dienste und der Systeme, die vom IDS zu schützen sind, sicherzustellen, darf die Analyse die zu schützenden Systeme nicht zu stark belasten. Dieser Aspekt führt zu einer Liste von Forderungen bezüglich der Datenanalyse. Sobald die Daten vom IDS gesammelt und ausgewertet wurden, kann der SSO mit der Überprüfung der Auswertung beginnen. Dabei muß das IDS ihn mindestens soweit unterstützen, daß verschiedene Sichten (Views) auf die Auditdaten und ihre Analyse möglich sind, um so gezielte Nachforschungen zu ermöglichen. Die entsprechenden Forderungen sind unter dem Punkt „Präsentation der Auditdaten“ (vgl. Abschnitt 4.2.1.3) formuliert. Der SSO muß anhand der Auditdaten-Analyse entscheiden, ob eventuell eine detailliertere Analyse oder eine detailliertere Datensammlung notwendig ist. Das IDS muß in beiden Fällen entsprechende Funktionalitäten bereitstellen. Darüber hinaus muß das IDS in der Lage sein, die gesammelten Daten abzuspeichern und ihre Echtheit und Unverfälschtheit für spätere juristische Zwecke sicherzustellen. Hieraus ergeben sich Forderungen bezüglich der Ereignisauswahl und der Speicherung von Auditdaten. Nachdem die Auditdaten hinreichend genau analysiert wurden, muß von dem IDS im Angriffsfall ein Alarm ausgelöst werden. Das IDS muß nun das IRS mit allen Daten versorgen, die das IRS benötigt, um entsprechende Gegenmaßnahmen einzuleiten. Dies führt zu Forderungen bezüglich der security audit automated response.

4.2.1.1 Generierung der Auditdaten 1. Das IDS muß in der Lage sein, die gesammelten Daten sowohl auf bekannte Angriffe hin (Mißbrauchserkennung) als auch auf normabweichendes Verhalten

12.07.2000

debis IT Security Services

Seite 155

Grundlagen, Forderungen und Marktübersicht für Intrusion Detection Systeme (IDS) und Intrusion Response Systeme (IRS)

Anforderungskatalog an ein ID-System

hin (Anomalieerkennung) hin zu untersuchen. Das IDS muß in der Lage sein, alle in Kapitel 2 beschriebenen Angriffe zu erkennen.

Unerwünschte Aktivität kann entweder bekannt sein – in diesem Fall existieren Signaturen – oder unbekannt; im zweiten Fall muß sie aber mittels Normabweichung erkennbar sein. In dieser Studie wurde an mehreren Stellen bereits darauf hingewiesen, daß die Produktreife der Mißbrauchserkennung im Gegensatz zur Anomalieerkennung wesentlich fortgeschrittener ist. Die noch ungelösten Probleme beim tatsächlichen Einsatz von Anomalieerkennung führen zu einer hohen Fehlkategorisierungsrate (Angriff bzw. kein Angriff). Die wesentliche Fähigkeit eines ID-Systems, neben bekannten alten Angriffen auch neue Angriffe erkennen zu können, kann hilfsweise auch erreicht werden durch eine schnelle Aktualisierung der Signaturdatenbanken mittels einer Push-Technik durch den Hersteller sofort bei Bekanntwerden eines neuen Angriffs. 2. Das IDS muß in der Lage sein, sowohl auf Netz- (Network-Sniffing) als auch auf Betriebssystemebene (Logbuch) die Datenüberwachung durchzuführen.

Die Quelldaten für Intrusion Detection bestehen aus Datensätzen, die vom Logbuchmechanismus auf Anwendungs- und Betriebssystemebene bzw. vom Mechanismus zur Überwachung des Netzverkehrs gesammelt wurden. Kapitel 2 enthält eine vollständige Beschreibung der am häufigsten verwendeten Angriffstechniken zusammen mit einer Klassifizierung der Angriffe. 3. Das IDS muß in der Lage sein, Aktivität auf Mehrbenutzersystemen, Einzelplatzrechnern und Systemen wie Firewalls zu überwachen.

Um eine adäquate Übersicht über die Aktivitäten zu erhalten, die Angriffe widerspiegeln können, ist es notwendig, daß das ID-System Daten von verschiedenen Plattformen verarbeiten kann. 4. Das IDS muß in der Lage sein, Aktivität auf Anwendungsebene zu untersuchen.

Um mit einer Firewall zusammenarbeiten zu können, muß der Proxy der Firewall Auditdaten auf Anwendungsebene liefern können; z.B. Befehlszeilen der Form ftp get . 5. Das IDS muß in der Lage sein, gekapselte Protokolle zu erkennen und zu überwachen.

Dies bedeutet, daß das IDS z.B. in der Lage sein muß, sowohl TCP und UDP in IP als auch AppleTalk in IP zu erkennen. Jeder Ausschluß eines bekannten Protokolls, für das ein interpretierender Dämon existiert, ist ein Sicherheitsrisiko, welches die Erfolgsaussicht eines Angriffs deutlich erhöht. 6. Die aus den verschieden Datenquellen erhaltenen Informationen muß das IDS direkt an die Analysekomponente weiterleiten.

Es sollte keine Verzögerung bei der Erkennung verdächtiger Aktivitäten aufgrund von verzögerter Weiterleitung von Eingabeinformationen auftreten. 7. Das IDS muß die Aufnahme externer, sicherheitsrelevanter Information ermöglichen. 12.07.2000

debis IT Security Services

Seite 156

Grundlagen, Forderungen und Marktübersicht für Intrusion Detection Systeme (IDS) und Intrusion Response Systeme (IRS)

Anforderungskatalog an ein ID-System

Information über Benutzerverhalten und zu erwartende Aktivität, wie sie beispielsweise in Kalendern oder Arbeitsplänen festgehalten ist, kann z.B. der Anomalieerkennung wertvolle Hinweise über das zu erwartende Benutzerverhalten liefern. 8. Das IDS muß die Erstellung von Benutzer- und Gruppenprofilen unterstützen.

In Umgebungen, in denen das Benutzerverhalten gleichmäßig stabil ist, ist es von Vorteil, das Benutzerverhalten zu erfassen, um so Normabweichungen feststellen zu können. 9. Das IDS muß in der Lage sein, die vom zu schützenden System verwendeten Protokolle zu verarbeiten.

Das IDS muß sämtliche Protokolldaten erkennen können. Für viele IT-Systeme umfaßt dies mindestens: IP, TCP, UDP, ICMP. 4.2.1.2 Analyse der Auditdaten 10. Das IDS muß in der Lage sein, Angriffe in Echtzeit zu erkennen.

Das IDS muß die Echtzeiterkennung von Angriffen durch den Einsatz eines Performance-Management-Systems unterstützen können. Obwohl Echtzeiterkennung nur ein Teil der gesamten Erkennungsfähigkeiten des IDSystems ausmachen kann – zum Beispiel wird Anomalieerkennung bei einem nicht in Echtzeit arbeitendem Datenbanksystem nicht möglich sein – bedeutet dies, daß das IDS dennoch in der Lage sein muß, automatisch gestartete Skriptangriffe zu erkennen. 11. Das IDS muß die Möglichkeit unterstützen, Angriffe vorherzusagen.

Das IDS kann durch den Einsatz von sogenannten Suspicious Counters und durch Performance-Analysen Angriffe erkennen, bevor diese tatsächlich ausgeführt werden. Dazu gehört u.a. auch das Erkennen von angriffsvorbereitenden Aktionen wie Port Scanning. 12. Das IDS muß in der Lage sein, Angriffe zu erkennen, die zur Informationssammlung dienen.

Diese Angriffe können, wie bereits beschrieben, Information sammeln, die zu einem deutlich späteren Zeitpunkt für einen tatsächlichen Angriff genutzt wird. 13. Die Signaturdatenbank des IDS muß mindestens alle Angriffe, die auf bekannten Systemschwächen der zu schützenden Systeme bestehen, erkennen können.

Die vom Hersteller eines Betriebssystems gewartet Liste bekannter Systemschwachstellen und Informationen zu Patches sollte in die Signaturdatenbank des betreffenden ID eingearbeitet worden sein. 14. Die Anomalieerkennungskomponente des IDS muß in der Lage sein, normales Benutzerverhalten durch Analyse von Verhaltensmustern zu modellieren.

12.07.2000

debis IT Security Services

Seite 157

Grundlagen, Forderungen und Marktübersicht für Intrusion Detection Systeme (IDS) und Intrusion Response Systeme (IRS)

Anforderungskatalog an ein ID-System

Das als normal zu definierende Verhalten ergibt sich aus dem in der Vergangenheit als sicherheitsunkritisch eingestuften Benutzerverhalten. Dabei müssen die konkreten Ausprägungen des Verhaltens abstrahiert werden. 15. Das IDS muß zumindest eine halbautomatische Unterstützung bei der Erstellung von Benutzerprofilen anbieten. Die folgenden Variablen müssen dabei mindestens berücksichtigt werden: •

vom Benutzer verbrauchte CPU-Zeit

•

System-CPU-Zeit

•

I/O-Zeichenrate

•

Speicherbedarf

•

Seitenfehlerrate

•

typische Anmelde- bzw. Abmeldezeiten

•

Benutzte Dienste (HTTP, FTP, Telnet, X11, NFS, SNMP etc.)

•

Durchsatzquote für jeden Dienst

•

Anzahl der erhaltenen Signale (z.B. kill ) für jede Anwendung

•

der Name des Rechners, auf dem Anwendungen (remote) gestartet wurden

•

Durchschnittsrate der Aktivität auf den Auditdatensätzen innerhalb eines bestimmten Zeitintervalls (1 Min., 10 Min., 60 Min.).

Es muß entweder ein leeres oder ein anderes unspezifisches Profil als Voreinstellung (“Default-Profil”) für neue Benutzer definierbar sein. Falls die Zielumgebung die Definition von Benutzergruppen unterstützt, so muß das Standardprofil die Profildaten der Benutzergruppen, denen ein neuer Nutzer angehört, an das Nutzerprofil vererben. Eine manuelle Änderungsmöglichkeit des Default-Profils ist ebenfalls sinnvoll. 4.2.1.3 Präsentation der Auditdaten 16. Das IDS muß die Erstellung von Berichten unterstützen, die Zusatzinformation zu den gesammelten Auditdaten enthalten.

Das IDS muß in der Lage sein, die Gründe, die zu einem Alarm führten, hinreichend genau darzustellen und zu erklären. 17. Das IDS muß eine umfangreiche Anzahl von Aktivitätsberichten unterstützen.

Unterschiedliche Ansichten (Views) auf die gesammelten Auditdaten ermöglichen dem Sicherheitsbeauftragten, sich schnell eine Übersicht über die Systemaktivität zu verschaffen. Dabei sollten Views vordefiniert sein, die die beobachtete Aktivität nach Zeitpunkten, Benutzern, Netzadressen etc. sortiert darstellen. 12.07.2000

debis IT Security Services

Seite 158

Grundlagen, Forderungen und Marktübersicht für Intrusion Detection Systeme (IDS) und Intrusion Response Systeme (IRS)

Anforderungskatalog an ein ID-System

18. Das IDS muß in der Lage sein, Berichte über seine Konfigurationsdaten zu erstellen.

Diese Berichte sollen es ermöglichen, die Konfigurationen des IDS (Konfiguration der Analysekomponente, Konfiguration des Sniffers etc.) getrennt darzustellen. 19. Das IDS muß über Methoden verfügen, die Auditdaten so aufzubereiten, daß diese trotz ihres großen Volumens noch sinnvoll manuell verarbeitet werden können.

Die Fähigkeit, gesammelte Daten zu sortieren, nach Begriffen zu Suchen etc., ist wesentlich für die tägliche Arbeit mit einem IDS, welches große Datenmengen sammelt und verarbeitet. 20. Abstrakte Aktivitätszusammenfassungen, welche das IDS für eine Übersichtspräsentation gesammelt hat, müssen bei Bedarf durch Expansion so verfeinerbar sein, daß die Weiterverarbeitung möglich ist (beispielsweise durch ein „Data Mining”-Werkzeug).

Sobald ein Alarm ausgelöst wird, muß der Sicherheitsbeauftragte vom IDS bei seiner weiteren Arbeit (Erforschung des Angriffs, Einleitung von Gegenmaßnahmen etc.) unterstützt werden. 21. Das IDS muß in der Lage sein, den Datensatz darzustellen, der den Alarm auslöste.

Um den betreffenden Angriff genauer untersuchen zu können, werden die exakten, reinen Auditdaten benötigt, die zum Auslösen des Alarms geführt haben. 22. Das IDS muß ad-hoc-Anfragen unterstützen.

Falls der Sicherheitsbeauftragte den Verdacht hat, daß jemand einen Angriff gegen das zu schützende System plant, so muß das System in der Lage sein, Fragen nach dem lokalen Sicherheitsstatus oder den gesammelten Auditdaten, beantworten zu können. 23. Das IDS muß die Fähigkeit besitzen, Teilergebnisse einer laufenden Angriffsuntersuchung protokollieren zu können oder zumindest entsprechende Werkzeuge zu unterstützen.

Die Untersuchung eines Angriffs kann sich über einen längeren Zeitraum hinziehen; es können auch mehrere Sicherheitsbeauftrage daran beteiligt sein. Es ist sinnvoll, daß Zwischenergebnisse, Verdachtsmomente auf bestimmte Sicherheitsschwachstellen und Hinweise darauf, was in einem bestimmten Fall zu tun ist etc. direkt im IDS abgelegt werden können. Selbst Bemerkungen wie “Paßt auf Fred auf – er wurde zum Quartalsende gefeuert und ist nicht glücklich über die Chefetage” können sinnvolle Sicherheitshinweise sein. 24. Die Konsole des ID-Systems muß eine adäquate graphische Benutzeroberfläche (GUI) unterstützen, so daß die zu überwachenden Systeme gut beobachtet werden können.

12.07.2000

debis IT Security Services

Seite 159

Grundlagen, Forderungen und Marktübersicht für Intrusion Detection Systeme (IDS) und Intrusion Response Systeme (IRS)

Anforderungskatalog an ein ID-System

Die Darstellung sicherheitskritischer Ereignisse beeinflußt in entscheidendem Maße die Effektivität des IDS, den SSO bei der manuellen Angriffserkennung zu unterstützen. 4.2.1.4 Ereignisauswahl für Auditdaten 25. Das IDS muß die dynamische Einstellung der Auditdaten-Granularität bei einem vermuteten Angriff ermöglichen.

Die Menge der vom IDS produzierten Ausgabedaten muß – insbesondere während eines vermuteten Angriffs – einstellbar sein, um so die entstehende Datenmenge für den SSO noch handhabbar zu halten. 26. Das IDS muß so konfigurierbar sein, daß der SSO temporär die Systemeinstellungen ändern kann.

In Ausnahmesituationen, in denen bekannt ist, daß autorisierte Aktivität zu Alarmen führt, kann es sinnvoll sein, die Einstellungen des ID-Systems so zu verändern, daß temporär kein Alarm ausgelöst wird. 4.2.1.5 Speicherung von Auditdaten 27. Das IDS muß die Authentizität der Auditdaten sicherstellen.

Die Authentizität der Audit- bzw. Nutzungsdaten muß durch ein zertifiziertes Auditsystem gewährleistet werden, welches Daten verfälschungssicher festhält. Kann dies nicht gewährleistet werden, so können die Auditdaten gegen einen Angreifer rechtlich nicht verwendet werden. 28. Das IDS muß die Integrität der Auditdaten sicherstellen.

Dazu können entweder nicht manipulierbare WORM-Speicher (Write Once, Read Multiple; Beispiel: einmal beschreibbare CD-Recordable) oder auch Programme zur Integritätsüberprüfung verwendet werden. Diese Maßnahmen stellen sicher, daß die reinen Auditdaten nicht manipuliert werden. 29. Die Überwachungsfähigkeit des IDS darf nicht durch Überflutungsversuche eingeschränkt werden.

Ein Angreifer kann versuchen, das IDS durch Data Flooding außer Betrieb zu setzen. Das IDS sollte eine ausreichende Robustheit gegenüber solchen Überflutungsangriffen aufweisen. 4.2.1.6 Audit automatic response 30. Das IDS muß in der Lage sein, mehrere gleichzeitige Angriffe geeignet zu priorisieren. 12.07.2000

debis IT Security Services

Seite 160

Grundlagen, Forderungen und Marktübersicht für Intrusion Detection Systeme (IDS) und Intrusion Response Systeme (IRS)

Anforderungskatalog an ein ID-System

Es ist wichtig, daß der SSO sich zunächst um die gefährlicheren Angriffe kümmert, um so den Erfolg eines Mehrfrontenangriffs zu verhindern. 31. Die IDS-Konsole muß die Gefährlichkeit eines Angriffs visuell darstellen können.

Mittels farblicher Darstellung, Pop-Up-Meldungen, Fontcharakteristiken etc. ist es möglich, den SSO auf die Systemaktivität hinzuweisen, die ein sofortiges Einschreiten erfordert. 32. Die IDS-Konsole muß die Gefährlichkeit eines Angriffs akustisch darstellen können.

Mittels entsprechender Warntöne, aufgezeichneter Audionachrichten etc. ist es möglich, den SSO auf die Systemaktivität hinzuweisen, die ein sofortiges Einschreiten erfordert. 33. Die IDS-Konsole muß Möglichkeiten bieten, die dem SSO erklären, warum ein Angriff gegenüber einem anderen als gefährlich eingestuft wurde.

Ein SSO muß in Angriffsfall nachvollziehen können, warum eine Aktivität als Angriff gewertet wurde und warum ihr ein entsprechender Gefährlichkeitsstatus zugeordnet wurde. 4.2.2 Wartungsunterstützung Das IDS muß im Hinblick auf zukünftige Angriffe und Angriffstaktiken erweiterbar sein. Daher muß die Signaturdatenbank erweiterbar sein. Bei den Benutzerprofilen müssen zusätzliche Merkmale (neben CPU-Zeit, Seitenwechselrate etc.) hinzugefügt werden können. Auch die IDS-Analysekomponente (IDS-Kernel) muß skalierbar sein. Hier sind schnellere Netze, Vergrößerung der Knotenmenge und neue Protokolle zu berücksichtigen. Ein schlecht skalierbares IDS wird zum Flaschenhals, sobald die externen Anforderungen zunehmen. Die Einführung eines neuen Protokolls macht ein IDS sogar vollkommen nutzlos, falls eine entsprechende Erweiterung nicht unterstützt wird. 4.2.2.1 Architektur und Upgrade (IDS-Kernel) 34. Das IDS muß aus sich ergänzenden Komponenten bestehen, • die Audit- und Netzdaten sammeln, • die diese Daten so aufbereiten, daß eine Integration in andere Komponenten (z.B. Analysekomponente) möglich ist, • die die Signaturanalyse bzw. Anomalieerkennung durchführen, • die eine Analyse des Angriffs erlauben und • die eine Behebung der entstandenen Schäden ermöglichen.

Diese Art der Modularität stellt die Skalierbarkeit und Erweiterbarkeit des Systems sicher. 12.07.2000

debis IT Security Services

Seite 161

Grundlagen, Forderungen und Marktübersicht für Intrusion Detection Systeme (IDS) und Intrusion Response Systeme (IRS)

Anforderungskatalog an ein ID-System

35. Das IDS muß offene Standards im ID/IR-Bereich unterstützen, sobald diese verfügbar sind.

Falls sich ein ID-Hersteller dazu entscheiden sollte, das Format seiner Signaturdatenbank zu veröffentlichen, sollte ein IDS dieses Format unterstützen, um so Signaturdaten, die in diesem Format vorliegen, verarbeiten zu können. Ein Beispiel für ein sich momentan noch in der Entwicklung befindliches Austauschformat ist das Common Intrusion Detection Format (CIDF). Information dazu kann unter http://seclab.cs.ucdavis.edu/cidf/ gefunden werden. 36. Das IDS muß in der Lage sein, verschiedene Standard-Auditdatenformate zu verarbeiten.

Das IDS soll mit Systemen kooperieren können, deren Auditdatenformat akzeptierten Standards entspricht. Falls das auf einem System verwendete Auditdatenformat unzureichend ist, um die Sicherheitsmerkmale des Systems zu beschreiben, so kann nicht erwartet werden, daß das IDS erfolgreich dieses System schützt. Viele Systeme sind in der Lage, Auditdaten zu erzeugen, die TCSEC C2konform sind. Darüber hinaus sollte das IDS auch in der Lage sein, die von Applikationen (z.B. trusted DBMS) erzeugten Auditdaten zu verarbeiten. Beispiele für de-facto Standards von Auditdatenformaten sind syslog, SVR4+. 37. Das IDS muß die Erweiterbarkeit in Hinblick auf neue Netzprotokolle unterstützen.

Die Einführung neuer Protokolle erfordert, daß das Design des ID-Systems flexibel genug ist, neue Standards zu unterstützen. Beispiele für neue Protokolle, die in naher Zukunft relevant sein werden, sind IPSEC und IPv6. 38. Das IDS muß im Hinblick auf eine wachsende Anzahl von Eingabequellen skalierbar sein.

Eine große Anzahl verschiedener Überwachungsstationen kann die Gesamtsystemaktivität auf sämtlichen Granularitätsebenen bzw. Detaillierungsstufen beobachten. Die Anzahl der verschiedenen Auditdatenquellen in einem eingesetzten ID-System kann sehr groß sein. 39. Das IDS muß auf den maximalen Durchsatz des zu schützenden Rechnernetzes skalierbar sein.

Die Menge an den von Rechnern, Sniffern, Sicherheitsmechanismen erzeugten Auditdaten wird sehr groß sein. Das IDS muß im Hinblick auf Umgebungen skalierbar sein, in denen in Streßsituationen große Auditdatenmengen generiert werden. Unterstützen die Netzkomponenten wie Router beispielsweise eine Bandbreite von 100 Mbit/s, so muß die Leistung des ID-Systems mit solchen Geschwindigkeiten mithalten können. 40. Das Design des IDS muß auf gute Wartbarkeit und benutzerfreundliches Update ausgelegt sein. 12.07.2000

debis IT Security Services

Seite 162

Grundlagen, Forderungen und Marktübersicht für Intrusion Detection Systeme (IDS) und Intrusion Response Systeme (IRS)

Anforderungskatalog an ein ID-System

Die IDS-Technik entwickelt sich ständig weiter. Daher ist es wichtig, daß das IDS im Hinblick auf erhöhte Funktionalität, bessere Integration mit anderen AntiIntrusion-Techniken etc. erweiterbar ist. 4.2.2.2 Architektur und Upgrade (Datenbanken) 41. Das IDS muß die schnelle Erweiterbarkeit seiner Signaturdatenbank mit neuen Signaturen ermöglichen.

Eine Signaturdatenbank muß ständig auf dem neuesten Stand gehalten werden, um so neuen Angriffen, Varianten alter Angriffe etc. adäquat entgegnen zu können. Das Einspielen der neuen Signaturdaten soll so einfach wie möglich gehalten werden. Nach Möglichkeit soll eine Aktualisierung (Update) erfolgen können, ohne daß dafür die Abschaltung des IDS notwendig ist. 42. Das IDS soll ein vom Hersteller initiiertes Update-Verfahren unterstützen, um so auf aktuelle Angriffe schnell reagieren zu können.

Der Viren-Scanner von McAfee (jetzt: Network Associates, www.nai.com) unterstützt eine sogenannte Push-Technik bei neuen Virensignaturen. Ein ähnliches Verfahren ist für ID-Systeme denkbar. 43. Das IDS muß es dem lokalen Sicherheitsteam erlauben, eigene Angriffssignaturen zu entwickeln.

Um einer größeren Gruppe als nur dem Hersteller des IDS die Entwicklung von Signaturen zu erlauben, müssen das Format und die Semantik der Signaturdatenbank bekannt sein. Dies verhindert eine zu starke Abhängigkeit des Anwenders eines ID-Systems vom entsprechenden Hersteller. 44. Aktivität, die nicht als Angriff gewertet wird, muß vom IDS dynamisch dazu verwendet werden, die Benutzerprofile zu trainieren.

Die Benutzerprofile müssen sich selbständig erneuern und weiterentwickeln, um sich so geändertem Verhalten anzupassen. 45. Das IDS muß die leichte Deaktivierung von Profilen derjenigen Benutzer erlauben, deren Account auf dem System gelöscht wurde oder die aus bestimmten Benutzergruppen entfernt wurden.

Das Löschen von Profilen erfordert unter Umständen Aktivitäten, die über das Löschen eines einzelnen Datensatzes hinausgehen. Das Entfernen mehrerer Benutzer aus einer Gruppe führt möglicherweise zu einem nicht mehr gültigen Gruppenprofil.

12.07.2000

debis IT Security Services

Seite 163

Grundlagen, Forderungen und Marktübersicht für Intrusion Detection Systeme (IDS) und Intrusion Response Systeme (IRS)

Anforderungskatalog an ein ID-System

4.2.3 Identifizierung und Authentifizierung Das IDS muß Mechanismen vorsehen, die es nur dem SSO erlauben, auf die gesammelten Auditdaten, Systemkonfigurationsdateien etc. zuzugreifen. Diese Maßnahmen sind ein Teil der allgemeinen Schutzmaßnahmen für das IDS. 46. Die IDS-Konsole muß der einzige Zugang zu sicherheitsrelevanten Funktionen der IDS-Analysekomponente sein.

Remote Login und Telnet, FTP bzw. TFTP dürfen nicht erlaubt sein. 47. Die Konsole soll mit dem IDS über einen vertrauenswürdigen Pfad (trusted path) verbunden sein.

Dies kann durch eine verschlüsselte Verbindung oder ein eigenständiges Netzsegment geschehen. 4.2.4 Schutz der Sicherheitsfunktionen Jedes IDS besitzt bestimmte Sicherheitsfunktionen, die alle geschützt werden müssen. Es gibt verschiedene Möglichkeiten, ein ungenügend geschütztes IDS in einen unbrauchbaren Zustand zu versetzen: •

Angriff auf eine Komponente (z.B. Überwachungskomponente) eines verteilten IDS, um so Teile des IDS abzuschneiden,

•

Ausnutzen einer Systemschwachstelle, um das IDS beispielsweise durch einen Pufferüberlauf zum Absturz zu bringen,

•

Außerkraftsetzung der IDS-Analysekomponente z.B. durch gezielten Angriff auf die Lernkomponente der Anomalieerkennung: Hierbei erzwingt der Angreifer, daß die Lernkomponente Angriffsverhalten als normales Verhalten lernt und so nicht mehr zwischen einem Angriff und normalem Verhalten unterscheiden kann.

4.2.4.1 Schutz interner ID-Mechanismen 48. Aktivität, die vom IDS als Angriff gewertet wird, darf nicht zur Erneuerung der Benutzerprofile verwendet werden.

Ein Benutzer- oder Gruppenprofil mit für Angriffsverhalten spezifischen Daten bzw. Datensätzen zu vermischen, stellt eine Verunreinigung eines solches Profils dar und ist letztendlich kontraproduktiv. 49. Die Lernkomponente des IDS muß sowohl kurzfristige Aspekte (aktuelles Benutzerverhalten) als auch langfristige Aspekte über einen größeren Aktivitätszeitraum miteinbeziehen.

12.07.2000

debis IT Security Services

Seite 164

Grundlagen, Forderungen und Marktübersicht für Intrusion Detection Systeme (IDS) und Intrusion Response Systeme (IRS)

Anforderungskatalog an ein ID-System

Die aktuelle Benutzeraktivität kann vom Verhalten über den gesamten beobachteten Zeitraum hinweg abweichen, ohne daß ein Angriffsverhalten vorliegt. Genauso kann das aktuelle Benutzerverhalten konform mit dem Verhalten über den gesamten Zeitraum hinweg sein, aber vom Verhalten in den letzten zwei Stunden deutlich abweichen, ohne daß ein Angriff vorliegt. Das Verhalten muß also immer im Hinblick auf verschiedene Zeiträume analysiert werden. 50. Das IDS muß die Analysekomponente vor Mißbrauch schützen.

Es dürfen keine nicht-autorisierten Zugriffe auf Benutzerprofile, Signaturdaten etc. erfolgen. Dazu kann das IDS auf einem dedizierten Rechner betrieben werden. Auch sollte auf diesem Rechner das IDS durch Integritätsüberprüfungen gesichert werden. Die Kommunikation mit diesem Rechner sollte auf das Notwendigste beschränkt werden. 51. Das IDS muß die Monitoreinstellungen vor unberechtigten Zugriffen schützen.

Ein Angreifer könnte versuchen, Komponenten der Datensammlungsstationen beispielsweise durch Ändern der Konfigurationsdateien so zu manipulieren, daß danach ein Angriff nicht mehr erkannt wird. 52. Das IDS muß die Echtheit und Unverfälschtheit der gesammelten Auditdaten sicherstellen.

Die gesammelten Auditdaten müssen vor Verfälschung gesichert werden. Dazu können diese beispielsweise verschlüsselt werden. 4.2.4.2 Vertrauenswürdige Wiederherstellung (Trusted Recovery) 53. Bei unerwartetem Ausfall der IDS-Analysekomponente muß das IDS vorher genau beschriebene Aktivitäten ausführen, um die Sicherheitsvorgaben umzusetzen.

Die Zielumgebung soll durch den unerwarteten Ausfall des IDS nicht unsicherer werden als ohne seine Installation. Die Folgen eines IDS-Ausfalls müssen klar sein. Bei der Umsetzung des in den Sicherheitsrichtlinien vorgegebenen Notfallplans darf es keine unerwünschten Nebeneffekte geben. 54. Die Recovery-Maßnahmen nach einem IDS Ausfall müssen das IDS in einen stabilen und sicheren Zustand versetzen.

Die Recovery-Maßnahmen sind nur dann akzeptabel, wenn sie den unsicheren Zustand vollkommen beheben. Im Falle einer nicht erfolgreichen Recovery muß das IDS in einen sicheren Default-Zustand übergehen. 4.2.4.3 Reference Mediation 55. Das IDS muß schon dann einen Alarm auslösen, wenn bei einer seiner Komponenten ein Funktionsausfall droht. 12.07.2000

debis IT Security Services

Seite 165

Grundlagen, Forderungen und Marktübersicht für Intrusion Detection Systeme (IDS) und Intrusion Response Systeme (IRS)

Anforderungskatalog an ein ID-System

Dies soll das IDS vor Denial-of-Service-Angriffen schützen. 56. Der Wiederherstellungsvorgang (Recovery) nach einer unterbrochenen Verbindung zwischen IDS-Komponenten muß sicherstellen, daß keine Daten verlorengehen. Dies gilt sowohl für Daten, die von der Datensammlungsstation zur Analysestation übertragen werden, als auch für Daten, die von den Monitoren gesammelt werden müssen.

Ein Angreifer, der seine Tätigkeit zu verbergen sucht, indem er die Kommunikationsverbindung zwischen Monitor und Analysestation stört, darf nicht den Verlust der Aufzeichnungsdaten herbeiführen können. 4.2.5 Vertraulichkeit (Privacy) Hier kommen datenschutzrechtliche Aspekte zum Tragen. Die Aufzeichnungspraktiken des IDS müssen mit dem in der Bundesrepublik Deutschland geltenden Datenschutzrecht vereinbar sein. 57. Pseudonymisieren der Nutzungsdaten

Die Pseudonymisierung ist oftmals notwendig, um von Instanzen wie z.B. der Arbeitnehmervertretung die Zustimmung zur Aufzeichnung von Benutzerdaten zu erhalten. 4.3 Vertrauenswürdigkeit (Assurance) Neben den oben beschriebenen, rein funktionalen Aspekten eines IDS sollen die unter diesem Abschnitt aufgeführten Punkte das Vertrauen in die Implementierung stärken. Eine ausführliche Dokumentation und eine effiziente Benutzerführung gehören zu den Punkten, die für das Vertrauen in ein Sicherheitsprodukt maßgeblich sind. Ein IDS ist nahezu unbrauchbar, sofern es nicht über eine gute Dokumentation verfügt. Diese sollte nicht nur in Form eines ausgedruckten Handbuchs vorliegen, sondern auch als Online-Hilfe. Die Online-Hilfe muß den SSO bei der Interpretation der Analyseergebnisse unterstützen. Sie muß darüber hinaus eine gute Entscheidungshilfe zur Einleitung von Sofortmaßnahmen bereitstellen. Ein IDS ohne gut gestaltete Benutzerschnittstelle (HumanComputer-Interface, HCI) verhindert ein effizientes Arbeiten ebenso wie ein IDS, welches zu viele Systemressourcen benötigt. 58. Das Dateneingabeformat sämtlicher ID-Komponenten muß so dokumentiert sein, daß eine Verarbeitung zusätzlicher Auditdaten möglich ist.

Idealerweise soll das IDS Daten aus allen möglichen in einem Netz vorkommenden Auditquellen verarbeiten können. Dies wird in der Praxis allerdings kaum der Fall sein. Um jedoch die Verarbeitung von Daten aus unterschiedlichen Auditquellen

12.07.2000

debis IT Security Services

Seite 166

Grundlagen, Forderungen und Marktübersicht für Intrusion Detection Systeme (IDS) und Intrusion Response Systeme (IRS)

Anforderungskatalog an ein ID-System

zu ermöglichen, ist eine genaue Beschreibung der Schnittstellen zum IDS erforderlich. 59. Die IDS-Dokumentation soll die einfache Installation und den Betrieb des IDS umfassend darstellen. Darüber hinaus soll sie den Administrator in die Lage versetzen, zu verstehen, • welcher Angriff gegen das System gefahren wird, •

wie gefährlich dieser Angriff ist,

•

welche manuellen Gegenmaßnahmen getroffen werden müssen und

•

welche Recovery-Maßnahmen einzuleiten sind.

Eine unvollständige oder unverständliche Dokumentation verhindert den effizienten Einsatz des IDS. 60. Das IDS soll eine angemessene Online-Hilfe zur Unterstützung des Administrators zur Verfügung stellen.

Ein Nachschlagen in der Dokumentation ist in konkreten Angriffsfällen zu umständlich. Der Einsatz von Hypertextsystemen hat sich bei vielen Softwareprodukten bewährt. 61. Die Dokumentation soll eine hinreichende Einführung in die effiziente Nutzung des IDS bieten. Dies kann wahlweise auch durch ein Tutorensystem oder durch Veranstaltungen beim Hersteller (Schulungsprogramme) geschehen.

Die erfolgreiche Benutzung des IDS setzt eine gute Schulung der Administratoren voraus. 62. Das IDS soll so entworfen sein, daß auch ein Anwender ohne spezielle Kenntnisse im Bereich „IT-Sicherheit” in der Lage ist, die grundlegenden Funktionen des IDS zu nutzen.

Wie in Kapitel 2 erwähnt, ist es häufig der Fall, daß der Betrieb von ID-Systemen nicht nur von Sicherheitsexperten aufrechterhalten wird. Das IDS soll seine Grundfunktionen automatisch erfüllen. Im Falle eines Angriffs muß das IDS eine effiziente Reaktion auch seitens eines Administrators ermöglichen, der kein Sicherheitsexperte ist. 63. Die Fähigkeit des IDS, seine Grundfunktionalität auch durch Sicherheitslaien verwalten zu lassen, darf den Experten nicht in seiner Aufgabe behindern, weitergehende Funktionen effizient zu nutzen.

Das IDS soll seine erweiterte Funktionalität denjenigen Administratoren zu Verfügung stellen, die diese Möglichkeiten nutzen möchten. Fortgeschrittenen Benutzern soll die schnelle Nutzung des IDS – beispielsweise mittels sogenannter Tastatur-Shortcuts – möglich sein. 64. Das IDS darf nicht unnötigerweise die Zielumgebung belasten.

Sicherheit, die nur aufgrund zu großer Einschränkungen der normalen Benutzerumgebung gewonnen wird, wird als zu belastend empfunden und die 12.07.2000

debis IT Security Services

Seite 167

Grundlagen, Forderungen und Marktübersicht für Intrusion Detection Systeme (IDS) und Intrusion Response Systeme (IRS)

Anforderungskatalog an ein ID-System

entsprechende Funktionalität wird abgestellt oder umgangen. Ein IDS darf das Betriebsmittelkontingent nicht unnötigerweise belasten. 65. Das IDS darf keinen unnötigen Administrationsaufwand verursachen.

Dies bedeutet auch, daß sämtliche Funktionen des IDS übersichtlich dargestellt sein müssen. 66. Das IDS darf die Benutzer in ihren normalen Aktivitäten nicht einschränken.

Benutzer dürfen in ihren eigentlichen Arbeiten nicht vom IDS behindert werden. Dies gilt insbesondere für ausgelöste Fehlalarme. 4.4 Bemerkungen Von den Punkten „Funktionalitätskriterien“ (vgl. Abschnitt 4.2) und „Vertrauenswürdigkeit“ nicht erfaßt sind organisatorische Maßnahmen, die jedoch zusätzlich von den ITSECKriterien gefordert werden. Diese organisatorischen Maßnahmen betreffen die Einhaltung datenschutzrechtlicher Bestimmungen. 67. Aufklärungspflicht über die Aufzeichnung personenbezogener Daten

Falls personenbezogene Auditdaten auch nur temporär festgehalten werden, muß der Benutzende über diesen Sachverhalt aufgeklärt werden (beispielsweise beim Einrichten des Accounts, Besuch des Web-Servers etc.). 68. Löschung der personenbezogenen Nutzungsdaten spätestens nach Beendigung der Nutzung

Dies erfordert u.U. die Definition geeigneter administrativer Maßnahmen zur Kontrolle des Vorgangs.

12.07.2000

debis IT Security Services

Seite 168

Grundlagen, Forderungen und Marktübersicht für Intrusion Detection Systeme (IDS) und Intrusion Response Systeme (IRS) Anforderungskatalog für ein Intrusion Response System (IRS)

5. Anforderungskatalog für ein Intrusion Response System (IRS) Der folgende Abschnitt beschreibt in Analogie zum vorherigen einen Sicherheitsanforderungskatalog an ein IR-System. Die entsprechenden Anforderungen sind so formuliert worden, daß sie sich einer Teilmenge der abstrakten Kategorien zuordnen lassen, die bereits für ID-Systeme entwickelt wurden. 5.1 Ziel Ein IRS ist ein reaktives System, welches auf der Grundlage von IDS-Nachrichten geeignete „Intrusion Response“-Maßnahmen auswählt und durchführt. Entdeckt das IDS beispielsweise einen IP Spoofing-Angriff und meldet diesen an das IRS, so kann das IRS u.a. entscheiden, den betroffenen Port zu deaktivieren, indem es den externen Router oder die Firewall rekonfiguriert. Die allgemeinen Ziele eines IRS Systems sind: •

Untersuchung der vom IDS übermittelten Gegenmaßnahmen auszuführen,

•

aktiver Schutz gegen einen Angreifer,

•

Aufrechterhaltung der Verfügbarkeit von Diensten, die nicht vom Angriff betroffen sind und

•

Selbstschutz gegen Angriffe.

Angriffsdiagnose,

um

geeignete

5.2 Ein Prototyp für eine IRS Funktionalitätsklasse

5.2.1 Sicherheitsaudit Die Hauptfunktion des IRS ist es, Gegenmaßnahmen zu einem durchgeführten Angriff einzuleiten, die im Hinblick auf die Sicherheitsziele adäquat sind. Aus dieser Hauptfunktionalität ergeben sich mehrere Anforderungen bezüglich der Sicherheit der Audit Automatic Response.

5.2.1.1 Audit Automatic Response 1. Das IRS muß im Alarmfall geeignete eigenständige Gegenmaßnahmen gegen (fortgeführte) Angriffe zur Verstärkung des vorhandenen Schutz-Potentials durchführen.

Das Hauptziel eines IRS ist es, solche Gegenmaßnahmen einzuleiten, deren manuelle Durchführung durch den SSO zu ineffizient wäre.

12.07.2000

debis IT Security Services

Seite 169

Grundlagen, Forderungen und Marktübersicht für Intrusion Detection Systeme (IDS) und Intrusion Response Systeme (IRS) Anforderungskatalog für ein Intrusion Response System (IRS)

2. Das Auslösen eines Alarms muß das unmittelbare Auswählen und Einleiten von Gegenmaßnahmen durch das IRS zur Folge haben.

Das Auslösen eines Alarms darf nur im Falle einer eindeutig unerwünschten Aktion erfolgen, die keiner weiteren Analyse bedarf und sofortige Gegenmaßnahmen erfordert. 3. Das IRS muß Gegenmaßnahmen zu Angriffen in Echtzeit durchführen können.

Das IRS muß in der Lage sein, so schnell wie möglich auf einen Alarm zu reagieren. 5.2.2 Wartungsunterstützung Da die vom IRS zu ergreifenden Gegenmaßnahmen stark von den Analyseergebnissen des IDS abhängen, muß das IRS genauso wie das IDS an neue Angriffe angepaßt werden können. 4. Das IRS muß im Hinblick auf gute Wartbarkeit und Aktualisierbarkeit (UpgradeFähigkeit) entworfen sein.

Die IRS-Technik ist in ständiger Weiterentwicklung. Es ist daher wichtig, daß das IRS Möglichkeiten zur Erweiterung der Funktionalität, zur besseren Integration mit anderen Anti-Intrusion-Werkzeugen oder neue Angriffssignaturen bietet. 5. Das IRS muß die Möglichkeit zur Integration mit dem ID-System der Zielumgebung bieten.

ID- und IR-Fähigkeiten können jeweils in einem einzelnen Werkzeug untergebracht sein, welches eine enge Zusammenarbeit mit dem jeweils anderen Werkzeug erlaubt. Falls unterschiedliche Werkzeuge kooperieren sollen, müssen die Schnittstellen offengelegt sein. 5.2.3 Schutz der Sicherheitsfunktionen Um den ordnungsgemäßen Betrieb des IRS sicherzustellen, muß es gegen Angriffe geschützt werden. 6. Das IRS muß seine Analysekomponente vor Mißbrauch schützen.

Die Analysekomponente des IRS entscheidet über den Zeitpunkt und die Art der auszuführenden Gegenmaßnahmen. Es muß sichergestellt werden, daß niemand unautorisierte Änderungen an Teilen der Analysekomponente vornimmt. 7. Das IRS muß seine externen Alarmmechanismen vor Mißbrauch schützen.

Es muß sichergestellt werden, daß diese Alarmmechanismen nicht unautorisiert verändert werden mit der Folge, daß Fehlalarme ausgelöst werden oder Angriffe für das IRS unbemerkt bleiben. 12.07.2000

debis IT Security Services

Seite 170

Grundlagen, Forderungen und Marktübersicht für Intrusion Detection Systeme (IDS) und Intrusion Response Systeme (IRS) Anforderungskatalog für ein Intrusion Response System (IRS)

5.2.4 Verfügbarkeit der Dienste Sobald ein Angriff vom IDS entdeckt und gemeldet wurde, beginnt das IRS mit der Suche nach Gegenmaßnahmen. Wenn das IRS eine geeignete Maßnahme ermittelt hat, beginnt es mit ihrer Ausführung. Die zu wählenden Gegenmaßnahmen reichen vom Deaktivieren eines Dienstes für einzelne Benutzer oder Benutzergruppen bis hin zur Entkopplung des betroffenen Rechners vom Netz. Die Maßnahmen zum Abschalten von Diensten führen zu einer Liste von Anforderungen an den Datenfluß (Information Flow Control). Die Maßnahmen zur Entkopplung induzieren Anforderungen zum Sperren der Sitzung (Session Locking).

5.2.4.1 Information Flow Control 8. Das IRS muß in der Lage sein, bei Bedarf einzelne Dienste auf einem Zielsystem abschalten zu können.

Falls das IDS einen Angriff auf einen bestimmten Port meldet, muß das IRS als Gegenmaßnahme diesen Port blockieren können. Idealerweise darf der Port nur für die angreifende IP-Adresse gesperrt werden, indem beispielsweise die Firewall oder ein Router rekonfiguriert wird. 9. Das IRS muß ein IDS bei der Reaktion auf als Angriff gewertete Aktionen unterstützen.

Intrusion Detection ist klassischerweise definiert als die Fähigkeit, Angriffe zu erkennen und diese dem SSO zu melden. Das IRS bietet darüber hinaus die Funktionalität, auf gemeldete Angriffe offensiv oder auch defensiv zu reagieren. 10. Das IRS muß so konfigurierbar sein, daß prioritätsgesteuert auf die möglichen Angriffe reagiert werden kann.

Das IR-System muß angemessen auf einen Angriff reagieren, das heißt, es darf nicht über- oder unterreagieren. Das IRS muß die Möglichkeit zu gewichteten Gegenmaßnahmen vorsehen, um sich dem Gefährlichkeitsgrad des Angriffs anzupassen. Falls eine getroffene Gegenmaßnahme sich als zu schwach erweist, so ist sie im nächsten Schritt durch eine stärkere zu ersetzen. 11. Das IRS muß in der Lage sein, die Auditmaßnahmen im Falle unerwünschter Aktivität zu erhöhen.

Eine erste Maßnahme bei entdeckter unerwünschter Aktivität ist es, den Auditmechanismus so einzustellen, daß z.B. mehr Ereignistypen protokolliert werden oder auch das gesamte Eingabeverhalten des Benutzers festgehalten wird. 12. Das IRS muß in der Lage sein, eine erneute Authentisierung (reauthentication) des Benutzers als Maßnahme auf einen Angriff zu veranlassen.

12.07.2000

debis IT Security Services

Seite 171

Grundlagen, Forderungen und Marktübersicht für Intrusion Detection Systeme (IDS) und Intrusion Response Systeme (IRS) Anforderungskatalog für ein Intrusion Response System (IRS)

Eine Gegenmaßnahme, die nicht unentdeckt bleibt, ist es, den Benutzer dazu aufzufordern, Benutzernamen und Paßwort erneut einzugeben, um seine Authentizität sicherzustellen. 13. Das IRS muß in der Lage sein, als Gegenmaßnahme gegen einen Angriff die Antwortzeiten der Systemdienste zu verlängern.

Der Vorteil dieser Gegenmaßnahme ist es, daß sie dem Angreifer nicht als Gegenmaßnahme erscheint, da sie ihm lediglich eine größere Systemlast vorspiegelt. Sie kann in zeitkritischen Situationen angewendet werden, etwa um den Standort des angreifenden Rechners ausfindig zu machen. 14. Das IRS muß in der Lage sein, die vom Angreifer erwartete Reaktion des angegriffenen Systems vorzutäuschen, während tatsächlich alle angriffsspezifischen Daten aufgezeichnet werden.

Diese Gegenmaßnahme versucht, sich gegenüber dem Angreifer zu verschleiern, um so unentdeckt weitere Information über ihn sammeln zu können. Dies soll jedoch so geschehen, daß kein tatsächlicher Schaden für das angegriffene System entsteht. 15. Das IRS muß in der Lage sein, das angegriffene System im Bedarfsfall herunterzufahren.

Diese drastische Maßnahme ist kritischen Situationen vorbehalten, in denen der Angreifer versucht, irreparable Systemschäden herbeizuführen. 16. Das IRS muß in der Lage sein, externe Zielsysteme wie Router oder Gateways nach Spuren abzusuchen, die der Angreifer dort hinterlassen hat.

Maßnahmen, die Systeme außerhalb des zu schützenden Objekts betreffen, stoßen neben generellen auch auf juristische Bedenken. Diese Forderung bezieht sich hauptsächlich auf öffentlich verfügbare Informationen und hat das Ziel, die Administratoren der externen Systeme darüber zu informieren, daß ihr System als Sprungbrett für einen Angriff mißbraucht wurde. 17. Das IRS muß die enge Zusammenarbeit mit einer Firewall erlauben.

Eine mögliche Gegenmaßnahme bei einem Angriff ist das Deaktivieren einzelner Dienste für eine spezielle IP-Quelladresse. Die enge Zusammenarbeit mit einer Firewall soll dies ermöglichen; später wird der entsprechende Dienst wieder für die betreffende Adresse freigeschaltet. Diese Gegenmaßnahme betrifft Aktivität, die zwar unerwünscht, jedoch nicht besonders gefährlich ist. 5.2.4.2 Sperrung von Benutzersitzungen (Session Locking) 18. Das IRS muß in der Lage sein, Benutzersitzungen im Alarmfall automatisch zu beenden.

12.07.2000

debis IT Security Services

Seite 172

Grundlagen, Forderungen und Marktübersicht für Intrusion Detection Systeme (IDS) und Intrusion Response Systeme (IRS) Anforderungskatalog für ein Intrusion Response System (IRS)

Diese Gegenmaßnahme wirkt gegen sogenannte Session-Level-Angriffe, bei denen der Benutzer unautorisiert unter einer falschen Kennung arbeitet oder eine Sitzung übernommen hat. 19. Das IRS muß in der Lage sein, im Angriffsfall einen Benutzer-Account zu sperren.

Falls der Angreifer einen Account kompromittiert hat und diesen für weitere Angriffe nutzt, so muß er gesperrt werden können. 20. Das IRS muß in der Lage sein, im Alarmfall das geschützte Netz vom ungeschützten Netz zu trennen.

Diese drastische Maßnahme ist für kritische Situationen vorgesehen, in denen der alleinige Zugang zum internen Netz dem Angreifer ein Fortsetzen der Angriffe ermöglicht. Zur Umsetzung dieser Maßnahme kann eine Firewall dazu veranlaßt werden, keine eingehenden Pakete durchzulassen. Darüber hinaus hat die Maßnahme den Vorteil, daß sie alle internen Rechner auf einmal vor weiteren Angriffen schützt, anstatt auf jedem Rechner eine gesonderte Maßnahme anstoßen zu müssen. 5.3 Vertrauenswürdigkeit Das gesamte IR-System soll seine gute Bedienbarkeit nachweisen. 21. Das IRS muß nach Angriffsversuchen, die das Ziel, haben Gegenmaßnahmen zu provozieren, schnell in einen normalen Zustand zurückkehren.

Automatische Gegenmaßnahmen bieten Angriffsfläche für Mißbrauch. Falls der Angreifer einen neutralen Rechner als Sprungbrett für seine Angriffe benutzt, kann er IR-Maßnahmen gegen diesen Rechner provozieren, die evtl. dazu führen, daß keine IP-Pakete von diesem Rechner mehr angenommen werden. Der Angreifer kann so ein Denial-of-Service erzwingen. Das IRS darf keine unangemessenen Gegenmaßnahmen ergreifen. 22. Das IRS soll leicht und ohne unnötige Ausfallzeiten für die zu schützenden Systeme installierbar sein.

Die Installation des IRS soll aus der Perspektive der zu schützenden Systeme möglichst transparent sein.

12.07.2000

debis IT Security Services

Seite 173

Grundlagen, Forderungen und Marktübersicht für Intrusion Detection Systeme (IDS) und Intrusion Response Systeme (IRS)

Literaturverzeichnis

6. Literaturverzeichnis Anderson, D. et al.: Detecting Unusual Program Behaviour Using the Statistical Component of NIDES, Technical Report SRI-CSL-95-06, SRI International, 1995. Anderson, D. et al.: SAFEGUARD FINAL REPORT - Detecting unusual behaviour using the NIDES statistical component, SRI International, 1993. Anderson, D., Frivold, T. and Valdes A.: Next Generation Intrusion Detection Expert-System (NIDES) - A Summary, Technical Report SRI-CSL-95-07, SRI International, 1995. Aslam, T.: A Taxonomy of Security Faults in the Unix Operating System, Dep. of Comp., Purdue University, http://www.cs.purdue.edu/coast/coast-library.html, 1995. Banning, D.: A Prototype Distributed Audit System, Proc. 16th National Computer Security Conference, 1993. Banning, D., Ellingwood, G., Franklin, C., Muckenhirn C. and Price D.: Auditing of Distributed Systems, Proc. 14th National Computer Security Conference, 1991 Bergmann, F. and Noll, H.: Mathematische Logik mit Informatik-Anwendungen, Springer Verlag, Berlin, 1980. Cannady, J. and Harrel J.: A Comparative Analysis of Current Intrusion Detection Technologies, Proc. TISC 1996, Houston, http://iw.gtri.gatech.edu/Papers/ids_rev.html, 1996. CMAD III: Presentations from the Third Workshop on Future Directions in Computer Misuse and Anomaly Detection, Sonoma, CA, January 10-13, 1995. Crosbie, M.: Applying genetic programming to intrusion detection in Proceedings of 1995 AAAI Fall Symposium on Genetic Programming, 1995. Denault, M., Gritzalis, D., Karagiannis, D. and Spirakis, P.: Intrusion Detection: Approach and Performance Issues of the SECURENET System, in Computers and Security, Vol 13, 1994. Denning, D.: An Intrusion Detection Model, in IEEE Transaction on Software Engineering, 1987. Denning, D.: Protection and Defense of Intrusion, http://guru.gosc.georgetown.edu/, 1996. Dowell, C. and Ramstedt, P.: The Computerwatch Data Reduction Tool, Proc. 13th National Computer Security Conference, 1990. Fox, K., Henning, R and Reed, J.: A Neural Network Approach Towards Intrusion Detection, Proc. 13th National Computer Security Conference, 1990. 12.07.2000

debis IT Security Services

Seite 174

Grundlagen, Forderungen und Marktübersicht für Intrusion Detection Systeme (IDS) und Intrusion Response Systeme (IRS)

Literaturverzeichnis

Halme, L. and Bauer, R.: AINT misbehaving - a taxonomy of anti-intrusion techniques, Proc. 18th National Information Systems Security Conference, 1995. Halme, L. and Van Horne, J.: Automated analysis of computer system audit trails for security purposes, Proc. 9th National Computer Security Conference, 1986. Halme, L. and Kahn, B.: Building a security monitor with adaptive user work profiles, Proc. 11th National Computer Security Conference, 1988. Handel, T and Sandford, M.: Hiding Data in the OSI Model, Los Alamos National Laboratory, Technical Report LS-95-4445-UR, Los Alamos, 1996. Harris, Inc.: StakeOut: Network Surveillance White Paper, http://www.stakeout.harris.com/, 1997. Haystack, Inc.: Stalker and WebStalker Product Description, http://www.haystack.com, 1997. Heady, R. et al.: The architecture of a network level intrusion detection system, Technical Report CS90-20, Department of Computer Science, University of New Mexico, 1990. Heberlein, T. et al.: A network security monitor, Proc. 1990 IEEE Symposium on Research in Security and Privacy, 1990. Heberlein, T., Levitt, K. and Mukherjee, B.: A Method to Detect Intrusive Activity in a Networked Environment, Proc. 14th National Conference on Computer Security, 1991. Heberlein, T., Mukherjee, B. and Levitt, K. Internetworking Security Monitor: An Intrusion Detection System for Large Scale Networks, 15th National Conference on Computer Security, 1992. Helman, P. et al.: Foundations of Intrusion Detection in Proc. 5th Computer Security Workshop, 1992. Hochberg, J. et al.: NADIR – An Automated System for Detecting Network Intrusion and Misuse, in Computers and Security, Vol. 12, 1993. Hubbard, B. et al.: Computer System Intrusion Detection, Technical Report RADC-TR-90413, Trusted Information Systems Inc., 1990. Ilgun, K.: USTAT – A Real-time Intrusion Detection System for Unix, University of California Santa Barbara, Dept. of Computing Science, 1992. InternetWeek: High-Tech Burglar Alarms Expose Intruders, InternetWeek, 22. September 1997. ISS, Inc.: Real-time attack recognition and response, RealSecure™ White Paper, http://www.iss.net, 1997. 12.07.2000

debis IT Security Services

Seite 175

Grundlagen, Forderungen und Marktübersicht für Intrusion Detection Systeme (IDS) und Intrusion Response Systeme (IRS)

Literaturverzeichnis

Jackson, K. Dubois, D. and Stallings C. An Expert System Application for Network Intrusion Detection, Proc. 16th National Computer Security Conference, 1993. Javitz, H. and Valdes, A.: The SRI IDES Statistical anomaly detector, http://www.csl.sri.com/ nides/. Javitz, H. and Valdes, A.: The NIDES Statistical Component: Description and Justification, SRI International, 1993. Karagiannis, D, Telesko R, and Mayr, C. A DSS-Model for attack detection, Proc. 11th IEEE Annual Computer Security Conference, 1995. Kuhn, J.: Research toward intrusion detection through automated abstraction of audit data, Proc. 9th National Computer Security Conference, 1986. Kumar, S.: Classification and Detection of Computer Intrusions, PhD Thesis, Purdue University, 1995. Kumar, S. and Spafford, E.: A pattern matching model for misuse intrusion detection, Proc. 17th National Computer Security Conference, 1994. Kumar, S. and Spafford, E.: A Software Architecture to Support Misuse Intrusion Detection, Technical Report CSD-TR-95-009, Dept. of Comp. Science, Purdue University, 1995. Lane, T. and Brodley, C.: Sequence Matching and Learning in Anomaly Detection for Computer Science, AAAI-97 Workshop on AI Approaches to Fraud Detection and Risk Management, 1997. Lane, T. and Brodley, C.: An Application of Machine Learning to Anomaly Detection, Proc. 20th Annual National Information Systems Security Conference, 1997. Lankewicz, L. and Nenard, M.: A Nonparametric Pattern Recognition Approach To Intrusion Detection, Technical Report TUTR 90-106, Tulane University, 1990. Lichtmann, Z. and Kimmins, J.: An Audit Trail Reduction Paradigm Based on Trusted Processes, Proc. 13th National Computer Security Conference, 1990. Liepins, G. and Vaccaro, H.: Intrusion Detection: Its Role and its Validation, in Computers & Security, Vol 11, 1992. Liepins, G. and Vaccaro, H.: Anomaly detection: Purpose and framework, Proc. 12th National Computer Security Conference, 1989. Luckhardt, N.: Nicht ganz dicht – Jugendliche Hacker knacken T-Online, c’t S. 62-65 Ausgabe 7/1998. Lunt, T. and Jagannathan, R.: A prototype real-time intrusion-detection expert system, Proc. IEEE Symposium on Security and Privacy, 1988. 12.07.2000

debis IT Security Services

Seite 176

Grundlagen, Forderungen und Marktübersicht für Intrusion Detection Systeme (IDS) und Intrusion Response Systeme (IRS)

Literaturverzeichnis

Lunt, T.: A Survey of Intrusion Detection Techniques, Computers and Security, Vol 12, 1993. Lunt, T et al.: A Real-Time Intrusion Detection Expert System (IDES), Technical Report SRICSL-92-05, SRI International, 1992. Lunt, T. and Anderson, D.: Next Generation Intrusion Detection Expert System, Software Requirements Specification, SRI International, 1993. Lunt, T. Automated Audit Trail Analysis and Intrusion Detection: A Survey, Proc. 11th National Computer Security Conference, 1988. Lunt, T.: Detecting Intruders in Computer Systems, Proc. Conference on Auditing and Computer Technology, 1993. MacCabe, A. et al.: Learning How to Characterise Normal Behaviour in Local Area Networks Marshall, V.: Intrusion detection in computers, Booz, Allen & Hamilton Inc., Summary of the Trusted Information Systems (TIS) Report on Intrusion Detection Systems, 1991. Meyer, K., Schaeffler, S. and Baker, D.: Addressing Threats in WWW Technology, Proc. 11th IEEE Annual Computer Security Conference, 1995. Mounji, A. and Le Charlier, B.: Continuous assessment of a Unix configuration: Integrating intrusion detection and configuration analysis, Proc. ISOC 1997 Symposium On Network and Distributed System Security, 1997. Mounji, A. et al.: Distributed audit trail analysis, Proc. ISOC ‘95 Symposium on Network and Distributed System Security, 1995. Nelson, R., Becker, D, Brunnell, J, Heimann, J.: Mutual Suspicion for Network Security, Proc. 13th National Computer Security Conference, 1990. Neuman, M.: Monitoring and Controlling Suspicious Activity in Real-Time with IP-Watcher, Proc. 11th IEEE Annual Computer Security Conference, 1995. Neumann, P. and Parker, D.: A summary of computer misuse techniques, Proc. 12th National Computer Security Conference, 1989. Olnes, J.: Development of Security Policies, in Computers and Security, Vol 13, 1994. PC Week: Facing up to Security Technology, PC Week, 12. Januar 1998. Pearl, J.: HEURISTICS: Search strategies of computer problem solving, Addison-Wesley Pub. Company, Boston, 1984. Pfleeger, C.: Security in Computing, 2nd Edition, Prentice-Hall, London, 1997.

12.07.2000

debis IT Security Services

Seite 177

Grundlagen, Forderungen und Marktübersicht für Intrusion Detection Systeme (IDS) und Intrusion Response Systeme (IRS)

Literaturverzeichnis

Porras, P.: STAT: A state Transition Analysis Tool for Intrusion Detection, Master Thesis, University of California, Santa Barbara, 1992. Porras, P. and Neumann P.: EMERALD: Event Monitoring Enabling Response to Anomalous Live Disturbances, Proc. 20th National Information System Security Conference, 1997. Proctor, P.: Audit reduction and misuse detection in heterogeneous environments: Framework and applications, Proc. 10th Annual Computer Security Applications Conference, 1994. Schaefer, L.: Employee Privacy and Intrusion Detection Systems: Monitoring on the Job, Proc. 15th National Computer Security Conference, 1992. Sebring, M., Shellhouse, E., Hanna, M. and Whitehurst, R.: Expert systems in intrusion detection: A case study, Proc. 11th National Computer Security Conference, 1988. th Smaha, S. Haystack: An Intrusion Detection System, Proc. 4 Aerospace Computer Security Conference, 1988.

Snapp, S. et al.: DIDS – Motivation, Architecture and an Early Prototype, Proc. 14th National Conference on Computer Security, 1991. Snapp, S. et al.: A system for distributed intrusion detection, in COMPCOM Spring ‘91 Digest of Papers, 1991. Sobirey, M., Richter, B. and Konig, H.: The intrusion detection system AID, Proc. IFIPTC6/TC11 International Conference on Communications and Multimedia Security, Chapman & Hall, London, 1996. Staniford-Chen, S. et al.: GrIDS – A Graph Based Intrusion Detection System for Large Networks, Proc. 19th National Information System Security Conference, 1996. Stoll, C: The Cuckoo’s Egg, Doubleday, 1989. Vaccaro, H. and Liepins, G.: Detection of anomalous computer session activity, Proc. IEEE Symposium on Research in Security and Privacy, 1989. Valiant, L.: A theory of the learnable, Communications of the ACM, 27(11):1134-1142, November 1984. Wee, C.: Policy Directed Auditing and Logging, PhD Thesis, UC Davis, Dept. of Comp. Science, 1996. Weiss, W. and Baur, A.: Analysis of Audit and Protocol Data Using Methods from AI, Proc. 13th National Computer Security Conference, 1990.

12.07.2000

debis IT Security Services

Seite 178

Grundlagen, Forderungen und Marktübersicht für Intrusion Detection Systeme (IDS) und Intrusion Response Systeme (IRS)

Literaturverzeichnis

WheelGroup, Inc.: NetRanger™ Overview and White Paper, http://www.network.com/ Products/Security/NetRanger, 1997. White, G. et al.: Cooperating security managers: A peer-based intrusion detection system, IEEE Network, 10(1), 1996. White, G. and Pooch, V.: Cooperating Security Managers: Distributed Intrusion Detection Systems, Computers and Security, Vol 15(5), 1996. Winkler, J.: A Unix Prototype for Intrusion and Anomaly Detection in Secure Networks, Proc. 13th National Computer Security Conference, 1990. Yuriev, A.: Detection and Prevention of Electronic Intrusion, CIS Laboratories, Temple University, Philadelphia, http://www.aoy.com/Papers/sas96.html, 1996.

12.07.2000

debis IT Security Services

Seite 179