Entwicklerdokumentation Java Intrusion Detection System

Java Intrusion Detection SystemEntwicklerdokumentation

Bundesamt für Sicherheit in der InformationstechnikPostfach 20 03 6353133 BonnTel.: +49 22899 9582-5599E-Mail: [email protected]: http://www.bsi.bund.de© Bundesamt für Sicherheit in der Informationstechnik 2009

Inhaltsverzeichnis1 Paketstruktur des Java IDS.........................................................................................................51.1 Paketstruktur des IDS Sensors...........................................................................................................51.2 Plugin Paketstruktur........................................................................................................................211.3 Namespacestruktur des JVMTI Agent.............................................................................................24

2 Entwicklung eigener Plugins....................................................................................................372.1 IDS Connector.................................................................................................................................372.2 Persistence Connector.....................................................................................................................38

3 Anmerkungen............................................................................................................................39

4 Erfahrungen aus dem Bau der Anwendung..............................................................................40

5 Nutzung der Anwendung..........................................................................................................415.1 IDS Sensor......................................................................................................................................415.2 JVMTI Agent..................................................................................................................................415.3 statlGUI...........................................................................................................................................41

6 Kommunikation zwischen IDS Sensor und JVMTI Agent.......................................................426.1 Anmeldung des JVMTI Agent am IDS Sensor................................................................................426.2 Abmelden des JVMTI Agent am IDS Sensor..................................................................................446.3 IDS Sensor sendet Informationen zu einem JVMTI Agent..............................................................456.4 JVMTI Agent sendet Informationen zum IDS Sensor.....................................................................45

7 Beispiel einer XML-Datei zur Beschreibung eines STAT-Szenarios.......................................507.1 STAT Szenario in STAL.................................................................................................................507.2 Visualisierung des STAT Szenario..................................................................................................527.3 Überführung des STAT-Szenarios in XML.....................................................................................52

8 Entwicklungsrichtlinen.............................................................................................................548.1 Java..................................................................................................................................................548.2 C++.................................................................................................................................................54

9 Entwicklungsumgebung............................................................................................................569.1 Externe Bibliotheken.......................................................................................................................569.2 Hilfsmittel.......................................................................................................................................57

10 Links..........................................................................................................................................58

AbbildungsverzeichnisAbbildung 1: Paketstruktur der IDS Sensor Anwendung.....................................................................6

Abbildung 2: Objekte zum Starten des IDS Sensors............................................................................6

Abbildung 3: Standardexceptions der IDS Sensor Anwendung...........................................................7

Bundesamt für Sicherheit in der Informationstechnik 3

Abbildung 4: Klassenübersicht des Paketes de.bsi.selkie.ids...............................................................8

Abbildung 5: JVMEvent Objektstruktur Teil 1....................................................................................9

Abbildung 6: JVMEvent Objektstruktur Teil 2..................................................................................10

Abbildung 7: JVMConfig Objektstruktur..........................................................................................11

Abbildung 8: JVMMessage Objektstruktur........................................................................................12

Abbildung 9: Kernklassen des Pakets de.bsi.selkie.net......................................................................13

Abbildung 10: Klassen zum Senden von Daten an einen JVMTI Agenten.......................................14

Abbildung 11: Hilfsklassen innerhalb des Paketes de.bsi.selkie.net..................................................15

Abbildung 12: Objektstruktur des Paketes de.bsi.selkie.persistence..................................................16

Abbildung 13: ObjektStruktur des Paketes de.bsi.selkie.response.....................................................17

Abbildung 14: Kernklassen des Paketes de.bsi.selkie.stat (Teil 1)....................................................17

Abbildung 15: Kernklassen des Paketes de.bsi.selkie.stat (Teil 2)....................................................18

Abbildung 16: Kernklassen des Paketes de.bsi.selkie.statParser (Teil 1)..........................................19

Abbildung 17: Kernklassen des Paketes de.bsi.selkie.statParser (Teil 2)..........................................20

Abbildung 18: Objekte innerhalb des Paketes de.bsi.selkie.util.........................................................21

Abbildung 19: Klassen innhalb des de.bsi.selkie.ids.connector.prelude Paketes...............................22

Abbildung 20: Klassen innhalb des de.bsi.selkie.persistence.connector.mysql Paketes....................23

Abbildung 21: Datenbank-Schema des MySQL Connector Plugins.................................................24

Abbildung 22: Namespace Struktur der JVMTI Agent Anwendung.................................................25

Abbildung 23: Objektstruktur des Namespaces de::bsi::selkie::config (Teil 1).................................26

Abbildung 24: Objektstruktur des Namespaces de::bsi::selkie::config (Teil 2).................................27

Abbildung 25: Kernklassen configuration Modules...........................................................................28

Abbildung 26: Konstanten innerhallb des JVMTI Agent...................................................................29

Abbildung 27: Kernklassen des Namespaces de::bsi::selkie::core.....................................................30

Abbildung 28: Objektstruktur des JVMTIProcessor Klassen (Teil 1)...............................................31

Abbildung 29: Objektstruktur des JVMTIProcessor Klassen (Teil 2)...............................................32

Abbildung 30: : Objektstruktur des Namespaces de::bsi::selkie::data...............................................33

Abbildung 31: c..................................................................................................................................34

Abbildung 32: Objekte innerhalb des Namespaces de::bsi::selkie:util..............................................35

Abbildung 33: Objektstruktur des Namespaces de::bsi::selkie::xml..................................................36

Abbildung 34: Visualisierung eines STAT Szenarios durch die statlGUI.........................................52

4 Bundesamt für Sicherheit in der Informationstechnik

Paketstruktur des Java IDS

1 Paketstruktur des Java IDSDas Java IDS ist modular aufgebaut und kann in folgende Paket- bzw. Namespacestruktur unterteilt werden:

1.1 Paketstruktur des IDS Sensors

Der IDS Sensor ist modular aufgebaut und lässt sich in folgenden Abschnitte unterteilen:• Exception• IDS• InfrastructureData• Net• Persistence• Response• STAT• STATParser• Utils

Das Paket de.bsi.selkie stellt das Basis-Paket aller Klassen des IDS Sensors dar und beinhaltet zudem die Klassen zum Starten der Anwendung. Abbildung 1 visualisiert noch einmal die Paketstruktur.



Abbildung 1: Paketstruktur der IDS Sensor Anwendung

Abbildung 2 zeigt die Klassen zum Starten des IDS Sensors. Die Klassen ApplicationStarter beinhaltet hierbei die Kernlogik des Starten und Stoppens der Anwendung. Die Klasse GUIStarter stellt auf dieser Basis eine Benutzeroberfläche bereit.

Abbildung 2: Objekte zum Starten des IDS Sensors



1.1.1 Exception

In diesem Paket sind alle Exception-Klassen untergebracht die in der gesamten Anwendung verwendet werden. Alle benutzerdefinierten Exception-Klassen innerhalb der IDS Sensor Anwendung erben von der Klasse de.bsi.selkie.exception.IDSSensorException. Auf diese Art und Weise ist es möglich, das Exception-Handling spezifizierter aufzusetzen, so dass eine Unterscheidung zwischen Standard Java Exceptions, Exceptions externer Bibliotheken und eigenen Exceptions möglich wird.

Abbildung 3: Standardexceptions der IDS Sensor Anwendung

Innerhalb des Paketes sollten nur solche Exceptions abgelegt werden, die innerhalb der gesamten Anwendung verwendet werden. Spezialisierte Exception-Klassen sollten in dem jeweiligen Paket abgelegt werden, zu dem sie inhaltlich gehören. Als Beispiel sei an dieser Stelle die PersistenceException genannt, welche Ausnahmezustände oder Fehler innerhalb der persistenten Speicherung signalisiert. Es ist jedoch Pflicht auch diese Exceptions von der Basisklasse IDSSensorException erben zu lassen.

1.1.2 ids

Das ids Paket beinhaltet alle Klassen, die für die Anbindung des IDS Sensors an einen IDS Manager notwendig sind. Der IDS Sensor macht an dieser Stelle keine Annahme darüber, welcher IDS Manager dies ist. Die konkreten Anbindung eines IDS Manager, wie z.B. Prelude, wird mittels eines Plugin-Konzeptes realisiert, welches in Abschnitt 1.2.1 detailierter beschrieben ist.



Abbildung 4: Klassenübersicht des Paketes de.bsi.selkie.ids

1.1.3 infrastructureData

Dieses Paket beinhaltet alle Datenobjekte die innerhalb der Anwendung in allgemeiner Weise genutzt werden. Dies sind zum einen Klassen, welche Informationen über JVM Event beinhalteten. Die Klasse JVMEvent stellt hierbei die Basisklasse dieser Objektstruktur dar, welche in Abbildung5 und Abbildung 6 zu sehen ist.

Des Weiteren sind in diesem Paket Klassen zur Konfiguration des JVMTI Agenten abgelegt. Basisklasse für diese Objektstruktur stellt die Klasse JVMConfig dar. Die Objektstruktur ist in Abbildung 7 zu sehen.

Daneben beinhaltet dieses Paket auch jene Klassen, welche Informationen beinhalten, die als Nachricht zum JVMTI Agenten zurück gesendet werden sollen. Hierbei agiert die Klasse



JVMMessage als Basisklasse. Die Klassen JVMCommand ist die Basisklasse für alle Befehle, und wird innerhalb der Klasse JVMMessage genutzt. Die Objektstruktur ist in Abbildung 8 zu sehen.

Abbildung 5: JVMEvent Objektstruktur Teil 1



Abbildung 6: JVMEvent Objektstruktur Teil 2



Abbildung 7: JVMConfig Objektstruktur



Abbildung 8: JVMMessage Objektstruktur



1.1.4 net

Das net Paket beinhaltet alle Klasse, welche auf Seiten des IDS Sensors für die Kommunikation mit dem JVMTI Agenten zuständig sind.

Abbildung 9: Kernklassen des Pakets de.bsi.selkie.net

Abbildung 9 zeigt die Struktur der Kernklassen innerhalb des net-Pakets. Innerhalb dieses Pakets ist die eigentliche Implementierung, welche die Kommunikation mit dem JVMTI Agenten herstellt durch die Interfaces IPCID und IPCCallcackID gekapselt. Dies ermöglicht es, die Kommunikation mit dem JVMTI Agenten anzupassen, ohne Änderungen am Design des IDS Sensors oder des net-Modules vornehmen zu müssen. Die aktuelle Implementierung nutzt einen TCP Socket-Server, der die Daten am XML-Stream überträgt und im Gegenzug die Daten als XML empfängt.



Abbildung 10: Klassen zum Senden von Daten an einen JVMTI Agenten

Abbildung 10 zeigt die Klassen, welche für das Senden von Informationen zum JVMTI Agenten zuständig sind. Hierbei sei erwähnt, dass das Modul-Design so gewählt und realisiert wurde, dass die Basis dafür geschaffen wurde, um mehrere JVMTI Agenten mit einem IDS Sensor interagieren zu lassen. Pro JVMTI Agenten, der sich am IDS Sensor anmeldet, wird eine Instanz der SendWorkerQueue Klasse erstellt, welche mit einem JVMTIAgentConfiguration-Objekt parametrisiert wird.



Abbildung 11: Hilfsklassen innerhalb des Paketes de.bsi.selkie.net

Abbildung 11 zeigt Hilfsklassen, die ausschließlich innerhalb des net-Paketes genutzt werden. Dies ist zum einen die modulinterne IPCException, sowie Klassen zur Generierung von eindeutigen JVMTI IDs sowie TCP Ports, unter denen ein JVMTI Agent kontaktiert werden kann (JVMTIIDGenerator, JVMTIPortGenerator).

1.1.5 persistence

Das persistence-Paket beinhaltet alle Klassen des IDS Sensors die für die persistente Speicherung der vom JVMTI Agenten empfangenen Daten genutzt werden. Parallel zum ids-Paket wurde das Design dieses Moduls so gewählt, dass der IDS Sensor keine Angaben oder Annahmen über die tatsächliche Art und Weise der persistenten Speicherung macht. Innerhalb des IDS Sensors wird lediglich die Grundstruktur für diese Aufgabe gelegt. Die eigentliche persistente Speicherung wird in Form eines Plugins realisiert, das von der Grundstruktur genutzt wird. Die Hauptklassen des Plugin-Konzeptes sind die Interfaces PersistenceConnectorIF und PersistenceConnectorInstanceIF. Details zum Plugins-Konzept des Persistence Modules sind in Abschnitt 1.2.2 zu finden.



Abbildung 12: Objektstruktur des Paketes de.bsi.selkie.persistence

1.1.6 response

Das response-Paket beinhaltet alle Klassen, die sich primär um das Senden von Nachrichten vom IDS Sensor an den JVMTI Agenten kümmern. Die aktuelle Implementierung besitzt hierbei noch keine ausgefeilte Logik, sondern Delegiert die JVMMessage-Objekte unbearbeitet an die ConnectionDelegate-Klasse des net-Pakets weiter. Sinn und Zweck dieses Paketes ist es nichts desto weniger zu verdeutlichen, dass eine Verarbeitung der Responses durchaus gewünscht sein kann und zweckdienlich ist. Hierfür ist mit der aktuellen Implementierung der Grundstein gelegt.



Abbildung 13: ObjektStruktur des Paketes de.bsi.selkie.response

Abbildung 13 zeigt die Objekte des response-Pakets.

1.1.7 stat

Das stat-Paket enthält alle Klassen, die sich mit dem Entscheidungsprozess um die JVMEvents befassen. Dazu halten sie die vorgegebenen STATSzenarien vor, durch die sie bei der Suche nach einer passenden Transition iterieren. Dabei werden die JVMEvents mit den Eintrittswerten der Szenarien verglichen.

Abbildung 14: Kernklassen des Paketes de.bsi.selkie.stat (Teil 1)



Abbildung 15: Kernklassen des Paketes de.bsi.selkie.stat (Teil 2)



1.1.8 statparser

Der statParser parst die STATSzenarien in XML und wandelt sie in Plain Old Java Objects um. Zur Erstellung des Parsers wurde JavaCC genutzt, weshalb die Hälfte der Klassen automatisch generiert sind.

Abbildung 16: Kernklassen des Paketes de.bsi.selkie.statParser (Teil 1)



Abbildung 17: Kernklassen des Paketes de.bsi.selkie.statParser (Teil 2)



1.1.9 util

Das util-Paket beinhaltet Hilfsklassen, die in der gesamten Anwendung genutzt werden. Die ApplicationSettings-Klasse kapselt den Zugriff auf die Konfiguration des IDS Sensors.

Abbildung 18: Objekte innerhalb des Paketes de.bsi.selkie.util

NumberRange ermöglicht das verwalten einer Menge von Zahlen und wird z.B. von der Klassen de.bsi.selkie.net.JVMTIPortGenerator genutzt (Siehe Abschnitt 1.1.4). Der AtomicObjectConverter überführt als String vorliegende Werte in das jeweilige Java Datenobjekt.

1.2 Plugin Paketstruktur

Das Design des IDS Sensors sieht für die Anbindung eines IDS Managers sowie die persistente Speicherung eine Pluginstruktur vor. Diese wird im Folgenden kurz erläutert.



1.2.1 IDS Manager Anbindung

Die Realisierung eines Plugins zur Anbindung eines IDS Managers an den IDS Sensor sollte alle Java Klassen unterhalb des Paketes de.bsi.selkie.ids.connector platzieren. Um einzelne Plugins eindeutig identifizieren zu können, sollte die Paketstruktur zusätzlich erweitert werden. Für die aktuelle Realisierung wurde eine Anbindung an Prelude umgesetzt, so dass alle Klassen des Plugins unterhalb des Pakets de.bsi.selkie.ids.connector.prelude platziert wurden.

Abbildung 19: Klassen innhalb des de.bsi.selkie.ids.connector.prelude Paketes

Abbildung 19 zeigt die Klassen, die eine Anbindung des IDS Sensors an Prelude ermöglichen.

Die eigentliche Kommunikation findet in der selbst erstellten shared library libpreludeconnector.so statt. Dieser werden die IDMEF Werte und der Prelude Profilname übergeben, um sie anschließend über Nutzung der Prelude API, mittel PreludeEasy, an Prelude zu versenden. Die Methoden der shared library werden durch die Klasse JNICaller definiert.

Zur Entwicklung des Plugins wurde eine separate Prelude Installation erstellt. Die folgenden Links liefern Information rund um das Thema Prelude und erleichtern einen Einstieg in die Prelude Client Agent Entwicklung:

o http://www.prelude-ids.com

o https://trac.prelude-ids.org/wiki/DevelAgentBuilding

o https://trac.prelude-ids.org/trac/libprelude/

o https://trac.prelude-ids.org/wiki/ManualUser



1.2.2 Persistente Speicherung

Die Realisierung eines Plugins zur persistenten Speicherung von Informationen einer Java Virtual Machine sollte alle Klassen unterhalb des Paketes de.bsi.selkie.persistence.connector platzieren. Um einzelne Plugins eindeutig identifizieren zu können, sollte die Paketstruktur zusätzlich erweitert werden. Für die aktuelle Realisierung wurde eine Anbindung an eine MySQL Datenbank umgesetzt, so dass alle Klassen des Plugin unterhalb des Pakets de.bsi.selkie.persistence.connector.mysql platziert wurden.

Abbildung 20: Klassen innhalb des de.bsi.selkie.persistence.connector.mysql Paketes

Abbildung 20 zeigt die Klassen, die eine Anbindung des IDS Sensors an eine MySQL Datenbank ermöglichen. Die Aktuelle Implementierung nutzt eine MySQL 5 Datenbank sowie den Java MySQL Connector in der Version 5.1.6.



Abbildung 21: Datenbank-Schema des MySQL Connector Plugins

1.3 Namespacestruktur des JVMTI Agent

Der JVMTI Agent besitzt ähnlich wie der IDS Sensor einen modularer Aufbau. Da die Realisierung in C++, und nicht wie beim IDS Sensor in Java erfolgte, wird im folgenden die Namespacestruktur der Anwendung erläutert.

Der Namespace de.bsi.selkie stellt den Stammnamespace aller Klassen des JVMTI Agenten dar. Unterhalb dessen befinden sich folgende Namespaces:



• config• constants• core

o jvmti• data• net• util

• xml

Abbildung 22: Namespace Struktur der JVMTI Agent Anwendung



Abbildung 22 zeigt die Namespacestruktur innerhalb des JVMTI Agenten. Alle Klassen befinden sich unterhalb des Namespaces de::bsi::selkie. Einzige Ausnahme stellt die Deklaration der JMVTI Callback-Funktionen in der Datei Starter.h da.

1.3.1 config

Der Namespace config beinhaltet alle Klassen, die für die Verarbeitung und das bereitstellen der Konfiguration innerhalb der Anwendung notwendig sind.

Abbildung 23: Objektstruktur des Namespaces de::bsi::selkie::config (Teil 1)



Abbildung 23 und Abbildung 24 zeigen die Objektstruktur der Klassen, die für die Verarbeitung der Konfiguration zuständig sind, die vom IDS Sensor empfangen wurde. Basisklasse für diese Verarbeitung ist die Klasse CConfigurationHandler.

Abbildung 24: Objektstruktur des Namespaces de::bsi::selkie::config (Teil 2)

Jede Kindklasse ist hierbei für Verarbeitung eines bestimmten Konfigurationsabschnitts zuständig. Welche Kindklasse für welchen Abschnitt der Konfiguration zuständig ist, wird anhand des Names des DOM-Knotens ermittelt, der Kindknoten des jvmticallbacks Knotens innerhalb der JVMTI Agent Konfiguration ist. Jede CConfigurationHandler Kindklasse definiert hierbei über die Konstante sName, für welchen Knoten sie zuständig ist. Über die Factory Klasse CConfigurationHandlerFactory findet letztendlich das Mapping zwischen DOM Knotenname und CConfigurationHandler statt. Während der Verarbeitung der Konfiguration wird hierbei definiert welche CJVMTIProcessor Klassen aktiviert und wie diese entsprechend parametrisiert werden.



Dieser Prozess wird innerhalb der Klasse CConfiguration (Abbildung 25) durchgeführt. Diese erhält die empfangenen XML Daten und stellt sie, in aufbereiteter Form, allen Modules innerhalb des JVMTI Agenten bereit.

Abbildung 25: Kernklassen configuration Modules



1.3.2 constants

Der constants Namespace dient der Gruppierung, der innerhalb der Anwendung global genutzten Konstanten, welche in Abbildung 26 zu sehen sind.

Abbildung 26: Konstanten innerhallb des JVMTI Agent



1.3.3 core

Der core Namespace beinhaltet alle Klassen, welche die eigentliche Logik der Anwendung beinhalten. Die Klasse CJVMTIManager stellt hierbei den zentralen Anlaufpunkt da. Die koordiniert die Aktivitäten der einzelnen Module und ist für den Start- und Endeprozess der Anwendung verantwortlich. Des Weiteren sind in diesem Namespace die Klassen zur Verarbeitung der vom JVMTI Agent empfangenen Nachrichten untergebracht. Hierfür zeichnet sich die Klasse CResponseDispatcher zuständig. Im Gegensatz zu anderen Modulen, in denen zu verarbeitende Daten und Aktionen gepuffert werden, um sie asynchron zu verarbeiten, werden innerhalb des CResponseDispatcher alle eingehenden Daten direkt verarbeitet. Dies geschieht, da empfangene Nachrichten mit höherer Priorität behandelt werden als zu versendende Nachrichten. Zudem ist in diesem Prozess, im Gegensatz zur Verarbeitung von JVMTI Callback Aufrufen, die zu überwachende Anwendung nicht eingebunden, so dass deren Verarbeitung hiervon ungestört weiter laufen kann.

Abbildung 27: Kernklassen des Namespaces de::bsi::selkie::core

Die Klassen CEventQueueScheduler, CEventQueueWorker und CEventQueue dienen der Pufferung der Informationen, die von den CJVMTIProcessor-Klassen ermittelt wurden und kümmern sich zudem um das Senden dergleichen.

Abbildung 27 visualisiert noch einmal die Objektstruktur des core Namespaces.



1.3.3.1 jvmti

Unterhalb des core Namespaces befindet sich der jvmti Namespace. In diesem sind jene Klassen platziert, welche die JVMTI API nutzen. Basisklasse dieser Objektstruktur ist die Klasse CJVMTIProcessor. Deren Kindklassen werden durch die Konfiguration erzeugt und parametrisiert. Beim Start der Anwendung registrieren sich die aktiven CJVMTIProcessor-Klassen an der JVMTI API und verarbeiten die empfangenen Daten um sie letztendlich dem CEventQueueScheduler zu übergeben. Für jede Callback-Funktionalität ist ein CJVMTIProcessor zuständig. Dieses Design wurde gewählt, um den Überblick der Codes zu gewährleisten und eine klare Trennung der Zuständigkeiten zu erreichen. Auf diese Art und Weise ist es zudem leicht möglich, weitere Funktionalität durch die Implementierung weiterer CJVMTIProcessor-Klassen zu realisieren ohne das Gesamtsystem unnötig anpassen zu müssen.

Abbildung 28 und Abbildung 29 zeigt die Objektstruktur der CJVMTIProcessor Klassen.

Abbildung 28: Objektstruktur des JVMTIProcessor Klassen (Teil 1)



Abbildung 29: Objektstruktur des JVMTIProcessor Klassen (Teil 2)



1.3.4 data

Innerhalb des data Namespaces sind alle Datenobjekte untergebracht, die gesammelte Informationen speichern. Basisklasse für diese Objektstruktur ist die Klasse CJVMEvent. Alle Klassen in diesem Namespace beinhalten keine Logik.

Abbildung 30: : Objektstruktur des Namespaces de::bsi::selkie::data

Sie kapseln lediglich den Prozess, wie die gesammelten Informationen in XML zu überführen sind. Abbildung 30 zeigt die Objektstruktur dieses Namespaces.



1.3.5 net

Der net Namespace beinhaltet alle Klassen, die für die Kommunikation mit dem IDS Sensor notwendig sind. Hierbei wird die eigentliche Art und Weise wie mit dem IDS Sensor kommuniziert wird durch die abstrakten Klassen IFIPC und IFIPCCallback gekapselt (vgl. Abschnitt 1.1.4).

Abbildung 31: c

Hierdurch ist es möglich, die Kommunikation zwischen IDS Sensor und JVMTI Agent einfach anzupassen, ohne die Logik des Moduls oder Anwendung ändern zu müssen. Die aktuelle Implementierung nutzt einen TCP Socket Server, der die Informationen als XML überträgt.



1.3.6 Util

Der util Namespace gruppiert Hilfsklassen, die innerhalb der gesamten Anwendung genutzt werden. Abbildung 32 zeigt die Objekte innerhalb dieses Namespaces.

Abbildung 32: Objekte innerhalb des Namespaces de::bsi::selkie:util



1.3.7 xml

Während der Entwicklung des JVMTI Agent ist man auf das Problem gestoßen, dass im Gegensatz zu Java die Xerces Bibliothek ausschließlich für lesende Zugriffe und die Xalan Bibliothek ausschließlich für schreibende Zugriffe auf XML Daten zuständig ist. Innerhalb des xml Namespaces sind daher Klassen untergebracht, die den lesenden und schreibenden Prozess auf XML Daten abstrahieren und dem Entwickler eine Schnittstelle für diese Aktion zur Verfügung stellen.

Abbildung 33: Objektstruktur des Namespaces de::bsi::selkie::xml

Abbildung 33 zeigt die Objekte innerhalb dieses Namespaces. Die Klasse CXMLAccess stellt hierbei das Herzstück dieser Struktur dar.


Entwicklung eigener Plugins

2 Entwicklung eigener Plugins

2.1 IDS Connector

Zur Entwicklung eines eigenen IDS Connector Plugins ist es notwendig, die Bibliothek idsconnector-develop-1.0.0.0.jar in das eigene Projekt einzubinden. Dieses beinhaltet alle benötigten Klassen und Interfaces, die für eine Entwicklung notwendig sind. Zusätzlich sollte die Bibliothek log4j-1.2.15.jar eingebunden werden. Diese wird aktuell vom IDS Sensor genutzt und ermöglicht ein Logging innerhalb des Plugins unter Nutzung der Infrastruktur des IDS Sensors.

Das Plugin muss die folgenden beiden Interfaces implementieren:

• de.bsi.selkie.ids.IDSConnectorIF• de.bsi.selkie.ids.IDSConnectorInstanceIF

Informationen zu den Schnittstellen finden sich in der JavaDoc Dokumentation, welche in der JAR-Datei enthalten ist.

Die Nutzung des Plugins wird über die Konfigurationsdatei des IDS Sensors gesteuert (selkieprefs.pref). Hier sind mindestens folgende Werte einzutragen:

• IDSConnector.JarFile• IDSConnector.IDSConnectorIFClass• IDSConnector.InitialWorkerPoolSize

Der Eintrag IDSConnector.JarFile definiert den Namen der JAR-Datei, welche alle Klassen des Plugin beinhaltet. Die JAR-Datei selbst muss im Unterordner plugins der IDS Sensor-Anwendung platziert werden. IDSConnector.IDSConnectorIFClass definiert die Klasse innerhalb der JAR-Datei, welche das IDSConnectorIF-Interface realisiert. IDSConnector.InitialWorkerPoolSize definiert die Anzahl an Threads die initial innerhalb des IDS Modules gestartet werden, um Nachrichten an einen IDS Manager unter Nutzung des Plugins zu versenden.

Zusätzlich können in dieser Datei Plugin-spezifische Einstellungen hinterlegt werden, die vom Plugin ausgewertet werden können. Für die aktuelle Implementierung ist hier der Eintrag IDSConnector.Prelude.ProfileName zu nennen, der den Profilnamen definiert, der für die Kommunikation mit dem Prelude IDS Manager genutzt werden soll. Der Zugriff auf diese Einstellungen erfolgt über das ApplicationSettings Objekt, welches dem Plugin beim Aufruf der doInitialization(..) Methode übergeben wird.


Entwicklung eigener Plugins

2.2 Persistence Connector

Zur Entwicklung eines eigenen Persistence Connector-Plugins ist es notwendig, die Bibliothek persistenceconnector-develop-1.0.0.0.jar in das eigene Projekt einzubinden. Dieses beinhaltet alle benötigten Klassen und Interfaces, die für eine Entwicklung notwendig sind. Zusätzlich sollte die Bibliothek log4j-1.2.15.jar eingebunden werden.

Das Plugin muss die folgenden beiden Interfaces implementieren:

• de.bsi.selkie.persistence.PersistenceConnectorIF• de.bsi.selkie.persistence.PersistenceConnectorInstanceIF

Informationen zu den Schnittstellen finden sich in der JavaDoc Dokumentation, welche in der JAR-Datei enthalten ist.

Die Nutzung des Plugins wird über die Konfigurationsdatei des IDS Sensors gesteuert (selkieprefs.pref). Hier sind mindestens die folgenden Werte einzutragen:

• PersistenceConnector.JarFile• PersistenceConnector.ConnectorInstanceIFClass• PersistenceConnector.InitialWorkerPoolSize

Der Eintrag PersistenceConnector.JarFile definiert den Namen der JAR-Datei, welche alle Klassen des Plugin beihaltet. Die JAR-Datei selbst muss im Unterordner plugins der IDS Sensor Anwendung platziert werden. PersistenceConnector.ConnectorInstanceIFClass definiert die Klasse innerhalb der JAR-Datei, welche das PersistenceConnectorIF Interface realisiert. PersistenceConnector.InitialWorkerPoolSize definiert die Anzahl an Threads die initial innerhalb des IDS Modules gestartet werden, um Nachrichten an einen IDS Manager unter Nutzung des Plugins zu versenden.

Zusätzlich können in dieser Datei Plugin-spezifische Einstellungen hinterlegt werden, die vom Plugin ausgewertet werden können. Für die aktuelle Implementierung ist hier der Eintrag PersistenceConnector.MySQL.Database zu nennen, der den Datenbanknamen definiert, innerhalb derer die Informationen persistent gespeichert werden. Der Zugriff auf diese Einstellungen erfolgt über das ApplicationSettings Objekt, welches dem Plugin beim Aufruf der doInitialization(..) Methode übergeben wird.


Anmerkungen

3 Anmerkungen

Für die aktuelle Implementierung des Java IDS gelten folgenden Anmerkungen:

• Innerhalb des JVMTI-Agenten werden z.B. für die METHOD_ENTRY bzw. METHOD_EXIT-Events nur die Werte von atomaren Datentypen, d.h. int, long, boolean, etc., ausgewertet. Die Auswertung von z.B. benutzerspezifischen Objekten ist nicht möglich.

• Durch die Nutzung von Prelude als IDS Manager gilt es zu beachten, dass sich aktuell nur eine ObjectID innerhalb einer STATInstance gemerkt wird.

• Folgende Werte sind im STAT-Szenario möglich, sonst kommt es beim Erstellen einer IDMEF Nachricht zu einem Fehler. Dies ist entsprechend bei der Erstellung eines STAT-Szenarios in der statlGUI für die Felder Attack-Details zu berücksichtigen. Die Werte orientieren sich an den von Prelude akzeptierten Werten.

• attackcompletition

• failed

• succeeded

• attackseverity

• info

• low

• medium

• high

• attacktype

• admin

• dos

• file

• recon

• user

• other


Erfahrungen aus dem Bau der Anwendung

4 Erfahrungen aus dem Bau der Anwendung

• Die aktuelle Version von Java, 6.0, ist u.a. notwendig zur automatischen Generierung von Java-Klassen zur Laufzeit. Diese Funktionalität wurde erst mit dieser Version eingeführt und hat die Umsetzung der Szenarien als POJOs erst möglich gemacht.

• Parserbau mit JavaCC scheint am Anfang relativ simpel, zeigte aber im Zeitverlauf hohe Komplexität. Die erstellten Parser sind sehr fragil, da ein einzelnes, unvorhergesehenes Zeichen den Parser zum Absturz bringt.

• Es kann nur ein JVMTI-Agent pro Java-Prozess geladen werden. Es ist momentan nicht klar, was geschieht, wenn ein Programm schon einen anderen Agenten nutzt.

• BCI ist hoch komplex, so dass die Implementierung ohne Hilfsmittel über Gebühr aufwändig ist. Die Lösung ist die Nutzung eines Frameworks, so dass eine API zur Manipulation des Bytecodes zur Verfügung steht.

• Die Anwendung beschäftigt sich mit einem sehr breiten Themengebiet, für das mit der aktuellen Implementierung die Grundlage geschaffen wurde.

• Es wurde Anwendungsforschung mit nicht weit verbreiteten Technologien (STAT, JVMTI, BCI, …) betrieben, die diese Gebiete voranbringen kann. Beispiele sind zum Beispiel die notwendigen Anpassungen an das STAT-Format, um es an die gegebenen Bedingungen anzupassen.

• Für Version 2.0• Code & Design-Refactoring,• Profiler zur Performance Analyse,• Evtl. anderen Compiler verwenden (überwiegend für C++ Code),• Implementierung eines Schemas zur Validierung der XML-Daten,• SSL für die Kommunikation zwischen JVMTI Agent und IDS Sensor verwenden, falls die

Hardwareressourcen hierdurch nicht allzu sehr belastet werden,• Eine Response zum JVMTI Agenten sollte nicht nur im "final state" eines Szenarios gesendet

werden.• type-Attribute im STAT-Szenario (io, net, etc.) zur Kategorisierung der zu überwachenden

Events einführen• Die Umsetzung der ‚consuming’ Transitions kann noch konsequenter durchgeführt werden.

Dazu muß jedem State ein Schalter mitgegeben werden (boolean consuming;), der darauf verweisenden Transitions dynamisch mitteilt, ob dieser Status schon verbraucht ist.

• Innerhalb der JVMEvent Datenobjekte soll sowohl im JVMTI Agenten als auch im IDS Sensor die Verarbeitung von komplexen Datentypen ermöglicht werden. Aktuell können nur atomare Datentypen verarbeitet werden.

• Jeder JVMTI Agent erhält eine eindeutige ID, sofern er sich am IDS Sensor anmeldet. Meldet er sich am IDS Sensor wieder ab oder wird der IDS Sensor neu gestartet, können die gleichen IDs vergeben werden, so dass eine Zuordnung von ID zu JVMTI Agent nicht mehr eindeutig möglich ist. Daher sollte der Logon- bzw. Logoff-Prozess eines Agenten protokolliert werden, um u.a. eine saubere, nachträgliche Analyse der vom IDS Sensor empfangenen Daten zu ermöglichen.


Nutzung der Anwendung

5 Nutzung der Anwendung

5.1 IDS Sensor

Die IDS Sensor Anwendung kann über das zugehörige ANT mittels run target gestartet werden. Die Parameter des Skriptes sind bei Bedarf den lokalen Gegebenheiten der Systemumgebung anzupassen. Es ist darauf zu achten, dass die Shared Library PreludeEasy.so in einem Verzeichnis vorhanden ist, in dem die JVM nach System-Bibliotheken sucht.

Sollte der IDS Sensor auf eine andere Art und Weise gestartet werden, müssen folgende Punkte beachtet werden:

- Zur Nutzung des Prelude Connector-Plugins muss der Order des Dateisystems definiert werden in dem sich die Shared Library libpreludeconnector.so befindet. Dies geschieht über den JVM Startparameter –Djava.library.path

5.2 JVMTI Agent

Der JVMTI Agent kann nicht ohne eine Anwendung gestartet werden, die er überwachen soll. Als Beispiel steht die Testanwendung „JVM Test Application“ zur Verfügung. Diese kann mittels des zugehörigen ANT Skriptes gestartet werden.

Soll der JVMTI Agent in einer anderen Anwendung genutzt werden, so sind dem Java-Prozess folgenden Parameter mitzugeben:

- agentlib=<Pfad zu libjvmtiagent.so>=idssensensorip:<IP des IDS Sensors>, idssensorport:<Port des IDS Sensors>,modeonconnectorfailure:<1|2>

5.3 statlGUI

Die statlGUI kann innerhalb der OpenSuSE VMWare mittels des vorhandenen Tomcat 6.0 gestartet werden. Der WebServer ist anschließend über http://localhost:8080/statlGUI zu erreichen.

Alternativ kann das WAR-Archiv der Anwendung in einem eigenen Servlet Container ausgegeben werden.


Kommunikation zwischen IDS Sensor und JVMTI Agent

6 Kommunikation zwischen IDS Sensor und JVMTI Agent

Im folgenden Abschnitt ist die Kommunikation des IDS Sensors mit dem JVMTI Agent dargestellt. Hierbei wird die XML-Struktur der Daten erläutert und mit Beispielen verdeutlicht

6.1 Anmeldung des JVMTI Agent am IDS Sensor

Meldet sich eine JVMTI Agent am IDS Sensor an, sendet er initial folgende Nachricht:<message type="configuration request"></message>

Die direkte Antwort des IDS Sensor beinhaltet die komplette Konfiguration für den JVMTI Agenten:

<message type="configuration response"><jvmtiagentid>...</jvmtiagentid><jvmtiagentport>...</jvmtiagentport><jvmticallbacks>

::

</jvmticallbacks></message>

Hierbei wird neben ID und TCP Port, unter dem der JVMTI Agent vom IDS Sensor erreicht werden kann, die Konfiguration übertragen, welche Ereignisse vom JVMTI Agenten überwacht werden sollen. Diese Konfiguration beinhaltet sich unterhalb des DOM Knotens jvmticallbacks. Hierbei sind aktuell folgende Konfigurationen möglich:

Laden einer Klasse in den Speicher der JVM<classload>

<classname> Lde/bsi/selkie/DummyClass;</</classname></classload>

Werfen einer Exception<exception>

<classname>Lde/bsi/selkie/DummyException;</classname></exception>



Fangen einer Exception<exceptioncatch>

<classname>Lde/bsi/selkie/DummyException;</classname></exceptioncatch>

Aufruf einer Methode<methodentry>

<classname>Lde/bsi/selkie/TestApp</classname><method>

<name>Szenario01</name><signature>()V</signature><returntype>int</returntype>

</method></methodentry>

Verlassen einer Methode<methodexit>

<classname>Lde/bsi/selkie/TestApp</classname><method>

<name>Szenario01</name><signature>()V</signature><returntype>int</returntype>

</method></methodexit>

Binden eines nativen Methodenaufrufes innerhalb der JVM<nativemethodbind>

<method><name>OnAgentLoad</name>

</method></nativemethodbind>

Beenden der definierten Klasse als Thread<threadstart>

<classname>Lde/bsi/selkie/DummyThread;</classname>



</threadstart>

Starten der definierten Klasse als Thread<threadstop>

<classname>Lde/bsi/selkie/DummyThread;</classname></threadstop>

JVM ist gestartet und beginnt mit ihrer Initialisierung<vmstart></vmstart>

JVM ist initialisiert und Start nun die Anwendung<vminitialization></vminitialization>

JVM ist herunter gefahren<vmdeath></vmdeath>

Instanzierung eines Java Objektes<objectinstantiation>

<classname>Ljava/lang/String;</classname></objectinstantiation>

6.2 Abmelden des JVMTI Agent am IDS Sensor

Wird die Anwendung die von einem JVMTI Agenten überwacht wird heruntergefahren, sendet meldet sich dieser am IDS Sensor ab. Dieser besitzt somit die Möglichkeit die eigene interne Verwaltungsstruktur aufzuräumen und Ressourcen freizugeben.

<message type="shutdown notification"><jvmtiagentid>4711</jvmtiagentid>

</message>



6.3 IDS Sensor sendet Informationen zu einem JVMTI Agent

Neben dem Informationsaustausch vom JVMTI Agenten zum IDS Sensor, ist auch eine Rückkanal vom IDS Sensor zum JVMTI Agenten möglich. Aktuell wird ist hierfür als einziger Befehl das Beenden eines Thread vorhanden.

<message><type>command</type><jvmtiagentid>4711</jvmtiagentid><command>

<type>THREAD_KILL</type><thread>Thread-17</thread>

</command></message>

6.4 JVMTI Agent sendet Informationen zum IDS Sensor

Wurden vom JVMTI Agenten Informationen ermittelt, sendet dieser sie anschließend zur Verarbeitung an den IDS Sensor. Die Nachrichten besitzen hierbei folgende Struktur:

<message type="event"><jvmtiagentid>...</jvmtiagentid><createtimestamp>...</createtimestamp><eventnumber>...</eventnumber><type>...</type><details>

<source><thread>...</thread>

</source><target>

<thread>...</thread></target>

:</details></message>



Die einzelnen Nachrichtentypen unterscheiden sich lediglich im Wert des type-Attributes und dem Inhalt des details-Knotens. Innerhalb des details-Knotens können Informationen über die Quelle und dem Ziel des Events hinterlegt sein, sofern diese Informationen vorhanden sind. Im Folgenden wird pro Eventtyp nur die Struktur des Inhaltes des details-Knoten dargestellt.

Laden einer Klasse in den Speicher der JVM<details>

:<class>

<type>Lde/bsi/selkie/DummyClass;</type></class></details>

Werfen einer Exception<details>

:<class>

<type>...</type></class>

</details>

Fangen einer Exception<details>

:<class>


</details>

Aufruf einer Methode<details>

:<class>

<type>...</type><identifier>...</identifier>

</class>



<method><name>...</name><parameters>

<parameter position="" type=""><value type="simple">...</value>

</parameter>:

</parameters><return>

<type>...</type></return>

</method></details>

Verlassen einer Methode<details>

:<class>


</class><method>

<name>...</name><parameters>

<parameter position="" type=""><value type="simple">...</value>

</parameter>:

</parameters><return>

<type>...</type><value type="simple">...<value>

</return></method>



</details>

Binden eines nativen Methodenaufrufes innerhalb der JVM<details>

:<method>

<name>...</name></method>

</details>

Beenden der definierten Klasse als Thread<details>

:<class>


</details>

Starten der definierten Klasse als Thread<details>

:<class>


</details>

JVM ist gestartet und beginnt mit ihrer Initialisierung<details></details>

Der details-Knoten ist leer. Das Objekt wird lediglich über den type-Knoten identifiziert und besitzt keine Werte.

JVM ist initialisiert und startet nun die Anwendung<details></details>




JVM ist herunter gefahren<details></details>


Instantiierung eines Java Objektes<details>

:<class>


</class></details>


Beispiel einer XML-Datei zur Beschreibung eines STAT-Szenarios

7 Beispiel einer XML-Datei zur Beschreibung eines STAT-Szenarios

7.1 STAT Szenario in STAL

scenario Testscenario{int counter = 0;initial state s0

{counter += 1;}

state s1{counter += 1;}

state s2{counter += 1;}

transition t0(s0 -> s1)nonconsuming{[ VM_INITIALIZATION ]:()()(



)(counter == 0){}}

transition t1(s1 -> s2)nonconsuming{[ EXCEPTION ]:(name= de.bsi.selkie.test01.Dummy;)(attackseverity = high;attackcompletion = succeeded;attacktype = other;attackinfo = [Finisher...];)(responsetype = THREADKILL;)(counter >= 1){}}

}



7.2 Visualisierung des STAT Szenario

Abbildung 34: Visualisierung eines STAT Szenarios durch die statlGUI

7.3 Überführung des STAT-Szenarios in XML

<?xml version="1.0" encoding="UTF-8"?><scenario><scenarioname>Testscenario</scenarioname> <importstatement /> <scenariodeclaration>int counter =0;</scenariodeclaration><initialstatename>s0</initialstatename><state name="s0"><instruction>counter += 1;</instruction> </state><state name="s1"> <instruction>counter += 1;</instruction> </state> <state name="s2"> <instruction>counter += 1;</instruction> </state>



<transition name="t0"> <source>s0</source> <destination>s1</destination> <type>nonconsuming</type> <assertion>( counter == 0 )</assertion> <event action="VM_INITIALIZATION"><attackdetails attackseverity="" attackcompletion="" attacktype="" attackinfo="" /> <responsedetails responsetype="" responsecommand="" /> <codeBlock /> </event> </transition> <transition name="t1"> <source>s1</source> <destination>s2</destination> <type>nonconsuming</type> <assertion>( counter >= 1 )</assertion> <event action="EXCEPTION" class="de.bsi.selkie.test01.Dummy"> <attackdetails attackseverity="high" attackcompletion="succeeded" attacktype="other" attackinfo="Finisher..." /><responsedetails responsetype="THREADKILL"

responsecommand="" /> <codeBlock /> </event> </transition></scenario>


Entwicklungsrichtlinen

8 Entwicklungsrichtlinen

Das Java IDS wurde konsequent an etablierten Richtlinien der Sicheren Programmierung ausgerichtet, die Programmiersprachen-übergreifend Gültigkeit besitzt. Hiervon sind besonders hervorzuheben.

• Abschottung: Die Komponenten des Systems liegen in separaten Einheiten vor, die sich gegenseitig nicht beeinflussen. Dies ist insbesondere bei der statlGUI und dem Rest der Applikation auffällig.

• Schnittsellen: Es sind nur wenige, dafür aber eng definierte Schnittstellen zwischen den Komponenten vorhanden.

• Geheimnisse: Es wurden keine Geheimnisse wie etwa Datenbankpasswörter in den Code geschrieben.

• Zugriffsschutz durch Parameter: Innerhalb des Quellcodes wurden die Zugriffsberechtigungen auf das Minimum beschränkt. D.h. die so genannten Access Modifier der Methoden und Parameter wurden, soweit dies im Rahmen der Funktionalität möglich war, von public auf protected oder private geändert. Ausgenommen sind die generierten Klassen aus dem STATParser.

• Fehlerbehandlung: Die Fehler der Anwendung werden vollständig abgefangen und führen zu keinen Fehlzuständen, die interne Daten über eine Fehlermeldung an den Benutzer weiterreichen könnte.

• Logging: Innerhalb der gesamten Anwendung wird ein konsequentes Logging eingesetzt, um den Entwicklungsprozess und den Betrieb der Anwendung zu unterstützen.

8.1 Java

Innerhalb des Java Programmcodes wurden die Java Coding Conventions angewandt. Diese sind unter http://java.sun.com/docs/codeconv/ zu finden.

8.2 C++

Innerhalb des C++ Codes wurde folgender Standard zur Benennung von Klassen, und Variablen genutzt.

- Klassen-Name: C<Name>

- Interfaces-Name: IF<Name>

- Aufbau eines Variablennamens <Präfix>_<Type><Name>

Präfix Bedeutung

m_ Klassenvariable

l_ Lokal Variable

p_ Parameter


Entwicklungsrichtlinen

Typen Bedeutung

p Pointer

s std:string

h std:hash

v std:vector

q std:queue

m std::map

I int

l long

o Object

Zusätzlich wurde innerhalb des Codes alle Parameter mit eine [in] bzw. [out] Informationen versehen. [in] bezeichnet Parameter, die vollständig initialisiert sind und innerhalb einer Funktion oder Methode genutzt werden können. [out] Parameter werden von der Funktion, der sie übergeben werden, initialisiert und stellen eine Art „Rückgabewert“ dar.


Entwicklungsumgebung

9 Entwicklungsumgebung

Die Entwicklung der Anwendung erfolgte innerhalb einer OpenSuSE 10.3 VMWare. Die Entwicklung selbst wurde mittels Eclipse in der Version 3.3.2 durchgeführt, welche um das CDT Plugin zur C++ Entwicklung sowie dem Sysdeo Tomcat Launcher-Plugin zur Entwcklung der statlGUI erweitert wurde. Viele Arbeiten wurden mittels ANT-Skripte automatisiert.

Weitere Details sind dem Dokument “VMware-Demonstrator.pdf“ zu entnehmen.

9.1 Externe Bibliotheken

Java

• Log4j 1.2.15

• Logging-Bibliothek

• http://logging.apache.org/log4j/

• Jdom 1.1

• API zur Verarbeitung von XML

• http://www.jdom.org/

• Xerces-J 2.9.1

• XML Parser

• http://xerces.apache.org/xerces-j/

• Xalan-J 2.7.1

• XSLT Prozessor

• http://xml.apache.org/xalan-j/

• MySQL Connector-J 5.1

• JDBC Treiber für eine MySQL Datenbank

• http://dev.mysql.com/downloads/connector/j/5.1.html

C++

• Boost 1.33.1

• Bibliothek zur Generierung von portable C++ für unterschiedliche Anwendungsfälle (Thread, etc.)

• http://www.boost.org/

• Asio 1.0.0

• Plattformübergreifende Netzwerk Bibliothek

• Die Bibliothek ist mittlerweile fester Bestandteil von Boost

• http://tenermerx.com/Asio/


Entwicklungsumgebung

• Log4cxx 0.10.0

• Logging Bibliothek

• http://logging.apache.org/log4cxx

• Xerces-C 2.7.0

• XML Parser

• http://xerces.apache.org/xerces-c/

• Xalan-C 1.10

• XSLT Prozessor und

• http://xml.apache.org/xalan-c/

9.2 Hilfsmittel

9.2.1 ANT-Skripte

Innerhalb der Anwendung stehen für Java-Programmierung ANT-Skripte zur Verfügung. Diese bieten die Möglichkeit immer wiederkehrende Aufgaben zu automatisieren. Alle ANT-Skripte tragen den Namen build.xml und sind in der obersten Ebene des jeweiligen Projektes zu finden.

9.2.2 Makefiles

Für die Entwicklung des C++ Codes wurden makefiles generiert. Diese befinden sich Debug Unterverzeichnis des jeweiligen Projektes. Die makefiles wurden nicht per Hand erstellt, sondern wurden unter Nutzung des Eclipse CDT Plugins, automatisch generiert.


Links

10 Links

[1] Java Virtual Machine Tool Interface (JVM TI)http://java.sun.com/javase/6/docs/technotes/guides/jvmti/

[2] Java Bytecode Instruction (BCI)http://java.sun.com/docs/books/jvms/second_edition/html/VMSpecTOC.doc.html

[3] Java Native Interface (JNI)http://java.sun.com/docs/books/jni/html/jniTOC.htmlhttp://java.sun.com/javase/6/docs/technotes/guides/jni/index.html

[4] STAThttp://www.cs.ucsb.edu/~seclab/projects/stat/doc/STAT/index.html

[5] IDMEFhttp://www.ietf.org/rfc/rfc4765.txt


http://java.sun.com/docs/books/jni/html/jniTOC.html

Entwicklerdokumentation Java Intrusion Detection System

Documents

Transcript of Entwicklerdokumentation Java Intrusion Detection System