© AllzweckJack, Photocase.com

Das hybride Security-Information-Management-System (SIM) Prelude empfängt sowohl Host- als auch Netzwerk-basierte IDS-Meldungen und zeigt diese in einem übersichtlichen Webinterface an. Selbst komplexe, korrelierte Alarme von unterschiedlichen Endgeräten mit eigenen Plugins sind da kein Problem.

Im richtigen Moment reagieren können – das kann manchmal lebenswichtig sein. Systeme für Intrusion Detection und Prevention (IDS/IPS) helfen in modernen Rechenzentren den Administratoren dabei, Protokolldateien und Meldungen zahlreicher, meist unterschiedlicher Geräte und Betriebssysteme auszuwerten, Eindringlingen schnell auf die Schliche zu kommen und die richtigen Aktionen anzuleiern.

Host- und Netzwerk-basiert: Prelude

Prinzipiell zu unterscheiden sind dabei Host-basierte IDS (HIDS), die in der Regel nur Dateien auswerten und lokale Angriffe erkennen können, etwa Tripwire, sowie Netzwerk-basierte IDS (NIDS) wie Snort, die Spuren von Hackern auch im Netzwerktraffic suchen.

Prelude ([1], [2]) als hybrides IDS vereint die Vorteile von HIDS und NIDS und bringt dabei zahlreiche Funktionen mit, zum Beispiel eine schicke Weboberfläche für die Administration und zahlreiche Agenten für Clients.

Die Entwickler haben Prelude in den letzten Jahren vorangetrieben, es ist ausgereift und bewährt sich in großen Szenarien. Mit seiner Plugin-Architektur und Features wie der Korrelator-Engine programmieren findige Admins auch eigene flexible Addons, die ihnen die tägliche Arbeit erleichtern.

Das Libprelude-API

Die Prelude-Bibliothek gestattet es darüber hinaus, vorhandene Programme an Prelude anzubinden: Die Libprelude stellt ein API für diverse Programmiersprachen, unter anderem C++, Python, Perl und Ruby, bereit [3]. Eine wichtige Hilfe ist dabei auch das von der Intrusion Detection Working Group (IDWG) entwickelte Intrusion Detection Message Exchange Format (IDMEF, [4]). Es bietet ein standardisiertes Format für IDS-Meldungen, die mit Hilfe von Software wie den Tools des Libprelude-API in einer zentralen SQL-Datenbank landen.

Für den Admin entfällt so das Zusammentragen der Logeinträge des Netzwerks, weil die zahlreichen verfügbaren Prelude-Agenten ihre Daten über verschlüsselte SSL-Verbindungen zum zentralen Manager schicken. Der hinterlegt diese in Echtzeit in der Datenbank und stellt sie für Anfragen bereit. Heartbeats zu den Agenten informieren ihn dabei fortlaufend, ob deren Verbindung noch intakt ist. Bei Unterbrechungen halten die Agents nicht übertragene Einträge im Cache vor, um diese bei bestehender Verbindung nachzureichen.

Agenten gibt es unter anderem für folgenden Plattformen:

• Für das Netzwerk-basierte IDS-System Snort ([5], [6]).
• Für das Host-basierte Open Source Security, Host-based Intrusion Detection System (Ossec, [7]).
• Für die Linux System Logs über Prelude-LML [8].
• Für die PAM-Authentifizierung.

Zudem kann das Security-Information-Management-System (SIM) alle Logs der üblichen Hardware-Appliances und Dienste analysieren, darunter diverse Cisco-Appliances, Exim, Microsoft SQL, Clam AV, Nessus, Apache, Tripwire, Netfilter, IPchains und IPfw.

Über Ossec kommen Features wie Rootkit-Erkennung, Windows-Registry-Überwachung und Datei-Integritätsüberprüfung ins Spiel. Das klappt dann weitgehend plattformunabhängig für Linux, Windows, VMware ESX, BSD, Solaris, AIX, HP-UX und Mac OS X. Remote-Syslog bindet Hardware-Appliances wie Cisco PIX/ASA, Juniper Netscreen und Sonic Wall Firewalls an.

Prelude-Manager

Als Zentrale der vier Prelude-Komponenten (Manager, Sensoren, Libprelude, Webinterface) nimmt der Manager die Daten entgegen, die die Sensoren über die von der Libprelude-Bibliothek verwalteten Verbindungen übertragen. Der Prelude-Manager ist unter Debian schnell installiert, einem »aptitude install prelude-manager libprelude« folgt ein Configure-Dialog von Dpkg mit der Auswahl der Datenbank (MySQL oder PostgreSQL) und der Eingabe des SQL-Rootpassworts. Anschließend generiert das System noch den SSL-Key.

Ist die DB fertig und das Managerprofil erzeugt, lässt sich die Konfiguration in der Datei »/etc/prelude-manager/prelude-manager.conf« anpassen. Hier sollte der Admin den »listen« -Eintrag auf seine Bedürfnisse korrigieren, am besten ersetzt er die Loopback-Adresse 127.0.0.1 durch seine IP, damit der Rechner später auch Logs von entfernten Agenten empfangen kann.

Meist hat er hier auch die SQL-Konfiguration unter »[db]« zu ändern:

[db]
type = mysql
host = localhost
port = 3306
name = Datenbankname
user = Benutzername
pass = Passwort

Unter Debian GNU Linux muss er noch die Variable »RUN« in »/etc/default/prelude-manager« auf »YES« setzen, dann startet der Prelude-Manager mit »/etc/init.d/prelude-manager start« .

Prewikka

Die umfangreichen Informationen der bisweilen recht vielen Agenten stellt das Prelude-Webinterface Prewikka übersichtlich dar (Abbildung 1, [9]). Installiert ist es unter Debian mit »aptitude install prewikka« und ein wenig Konfigurationsarbeit. Zum Beispiel ist eine Datenbank nötig, die der Admin mit dem Skript »/usr/share/prewikka/database/mysql.sql« einspielt.

Abbildung 1: Das Webinterface von Prelude hört auf den Namen Prewikka. In einer tabellarischen Übersicht zeigt es alle Ereignisse an, die die verschiedenen Agenten gemeldet haben.

Abschließend findet sich die Prewikka-Konfigurationsdatei in »/etc/prewikka/prewikka.conf« , hier sind die Variablen »software« , »place« und »title« nach Belieben zu setzen, zum Beispiel:

software: Prewikka
place: dotlike.net
title: Preludeconsole

Den Datenbankzugriff von Prewikka regelt der folgenden Abschnitt in der Konfigurationsdatei:

[database]
type: mysql
host: localhost
user: prewikka
pass: Passwort
name: prewikka

In der Regel hat bereits die Debian-Paketkonfiguration alles ordnungsgemäß befüllt. Nun kann »prewikka-httpd« das Webinterface mit dem eingebauten Webserver auf Port 8000 starten. Anwender, die lieber eine bestehende Apache-Installation verwenden, finden im Kasten “Prewikka als virtueller Host” eine kurze Anleitung.

<VirtualHost 192.168.0.1:80>
 ServerName preludehost
 ErrorLog /var/log/apache2/error_log
 CustomLog /var/log/apache2/access_logU combined
  <Location "/">
   AllowOverride None
   Options ExecCGI
   <IfModule mod_mime.c>
     AddHandler  cgi-script .cgi
   </IfModule>
   Order allow,deny
   Allow from all
  </Location>
Alias /prewikka/ /usr/share/prewikka/Uhtdocs/
ScriptAlias / /usr/share/prewikka/Ucgi-bin/prewikka.cgi
</VirtualHost>

Der Standardbenutzername wie auch dessen Passwort lauten bei Prewikka »admin« . Das sollte dieser unbedingt nach der ersten Anmeldung unter dem Menüpunkt »Settings | My Account« ändern, wo er auch die Sprache auf Deutsch setzt. Das Webinterface ist intuitiv gehalten und stellt Alarme übersichtlich dar. Alle Felder bieten Filtermöglichkeiten wie Quelle, Ziel, Analyzer oder Klassifikation. Das Menü rechts unten setzt Zeitraum und Anzahl der Ereignisse pro Seite.

Prelude-Sensoren: LML

Einer der für Linux-Admins wichtigsten Prelude-Sensoren ist Prelude Log Monitoring Lackey (LML, [8]). Er arbeitet als Host-basiertes IDS und beobachtet definierte Logdateien und sendet Ereignisse an den Prelude-Manager. Die Installation erfolgt unter Debian mit »aptitude install prelude-lml« .

Danach registriert der Admin jeden Sensor am Prelude-Manager über eine verschlüsselte Verbindung, bei Prelude-LML zum Beispiel mit:

prelude-admin register prelude-lml ?
"idmef:w admin:r" Listen_IP_des_?Prelude-Managers -uid 0 -gid 0

Nach einer kurzen Wartezeit fordert Prelude den Admin auf, den Befehl »prelude-admin registration-server prelude-manager« in einer zweiten Shell auszuführen. Der stellt ein Einmal-Passwort (One-Shot-Passwort) bereit, mit dem sich der Sensor in der vorherigen Konsolensitzung authentifiziert. Danach erhält der Admin in der Konsole, in der dieser Befehl läuft, die mit [Y] zu bestätigende Ausgabe:

Approve registration? [y/n]: y

Das Ändern der Serveradresse in der Konfigurationsdatei »/etc/prelude/default/client.conf« (in der Zeile »server-addr = IP« ) sorgt dafür, dass die lokalen Agenten künftig ihre Daten an den angegebenen Server senden.

Snort

Wer die etablierte Network-Intrusion-Detection-Software Snort an Prelude anbindet, kann die Netzwerkangriff-Erkennung per Signatur aktivieren. Da die Entwickler dessen Regelwerk stetig erweitern, sollte der Admin seine Angriffsignaturen immer auf dem aktuellen Stand halten. Über eine kostenlose Registrierung auf der Webseite von Snort [5] erhält er einen Code für automatische Signatur-Updates, die für 30 Tage nach der offiziellen Veröffentlichung verfügbar sind. Drittsoftware wie Oinkmaster [10] oder Pulled Pork erlauben es, diese Signaturen mit einem Cronjob automatisiert zu beziehen.

Eine Alternative zu den offiziellen Snort-Regeln, die in ähnlicher Form auch die kommerziellen Sourcefire-Appliances [11] verwenden, bietet Bleeding Snort [12]. Die Webseite des Projekts veröffentlicht kontinuierlich Snort-Regeln von Netzwerk- und Sicherheitsspezialisten. Auch einer Kombination der Regelsätze steht nichts im Wege.

Die Installation von Snort klappt mit einer MySQL-Datenbank im Hintergrund mit »aptitude install snort-mysql« , als Startmethode empfiehlt sich »Systemstart« , der »Promiscuous Mode« sollte angeschaltet bleiben. In diesem Modus überprüft Snort alle Pakete, auch wenn sie nicht direkt an die IP-Adresse des Netzwerkinterface gerichtet sind. Die E-Mail-Protokollierung bleibt optional und als Protokoll-Datenbank soll jetzt Prelude dienen.

Schnüffler-Konfiguration

In der Konfigurationsdatei »/etc/snort/snort.conf« muss der Admin jetzt einige Änderungen durchführen: Um Snort aufzufordern, seine Daten an Prelude zu senden, bedarf es dort noch des folgenden Abschnitts:

output alert_prelude: profile=snort

Das zu überwachende Netzwerk definieren folgende Einstellungen:

# für IPv4:
var HOME_NET 192.168.0.0/24
# mit IPv6 USE flag:
ipvar HOME_NET 192.168.69.0/24
# Das externe Netz kann auf any bleiben
var EXTERNAL_NET any

Viele Präprozessoren sind für die Funktionsweise von Snort verantwortlich, etwa für die Erkennung von Portscans. Sie lassen sich mit detaillierten Feineinstellungen optimieren. Es ist durchaus sinnvoll, dazu die Konfigurationsdatei einmal in voller Länge durchzugehen.

Auch Snort braucht jetzt ein Prelude-Profil:

prelude-admin register snort "idmef:w?
 admin:r" Listen_IP_des-Prelude-Managers?
 -uid 0 -gid 0

Und schon klappt die Zusammenarbeit zwischen Snort und Prelude.

Ossec

Wer Wert auf Plattformunabhängigkeit legt, verwendet das Host-basierte IDS Ossec. Dessen aktuelle Version findet sich auf [7], »aptitude install libprelude-dev« installiert die fürs Kompilieren notwendigen Entwicklerbibliotheken von Prelude. Nach dem Entpacken des Tarballs ins Unterverzeichnis »src« aktiviert dort »make setprelude« die Prelude-Unterstützung, »install.sh« startet die Installation. Die angebotene lokale Installation reicht für Anwender aus, die keine Anbindung von Hardware-Endgeräten oder anderen Clients planen. In der Regel sollte der Admin hier jedoch »server« wählen und den Integrity Check Daemon sowie die Rootkit Detection Engine aktivieren. Gegen Brute-Force-Attacken hilft es, durch Active Response und Firewall-Drop die attackierenden Hosts automatisch zu blockieren, je nach System via IPtables, IPchains oder IPfw (Abbildung 2).

Abbildung 2: Das Installations- und Konfigurationstool von Ossec übernimmt auch fortgeschrittene Einstellungen, zum Beispiel die Kombination mit Firewalls und Active Response.

Damit False Positives nicht zu Problemen im Netzwerk führen, hilft eine Whitelist mit IP-Adressen. Im darauf folgenden Schritt kann der Admin den Empfang von Syslog-Nachrichten aktivieren, wenn er zum Beispiel plant Hardware-Appliances per Syslog anzubinden.

Jetzt korrigiert er noch die Datei »/var/ossec/etc/ossec.conf« , damit Ossec die Informationen an Prelude übergibt:

<ossec_config>
<global>
<email_notification>no</email_notification>
<prelude_output>yes</prelude_output>
</global>

Zu guter Letzt muss der Admin auch Ossec in Prelude registrieren:

prelude-admin register OSSEC "idmef:w ?
 admin:r" Listen-IP_des_Prelude-Managers?
 -uid ossec -gid ossec

Hier muss er bei UID und GID »ossec« verwenden, da der Analysedienst unter diesem Benutzeraccount läuft. Nach der Installation startet das HIDS-System mit »/var/ossec/bin/ossec-control start« .

Bevor sich ein Agent an Ossec anbinden lässt, muss der Admin ihn auf dem Server registrieren. Das erledigt der Befehl »/var/ossec/bin/manage_agents« mit einem tastaturgesteuerten Konsolenmenü (siehe Abbildung 3).

Abbildung 3: Das Skript »manage_agents« stellt ein einfaches Menü zur Verfügung, mit dem Admins die Client-Agenten auf dem Server registrieren.

Nach der Angabe des Namens gibt der Admin hier die IP-Adresse ein. Ist die dynamisch vergeben, gibt er das Klasse-C-Netzwerk an, in dem sich der Agent befindet (zum Beispiel 10.21.81.0/24). Dann wählt er eine ID für den Agenten, wobei er den Standardvorschlag für den ersten Agenten »001« ohne Weiteres beibehalten kann. Um ihn am Endgerät anzubinden, ist noch ein Authentifikationsschlüssel notwendig. Den gibt es mit »/var/ossec/bin/manage_agents -e 001« .

Windows und Syslog

Um einen Windows-Client an Ossec und Prelude anzubinden, bedarf es auf dem System der Libprelude [13]. Deren Installation ist mit wenigen Klicks beendet, wobei der Admin außer »Source Code« alle Komponenten der Software auswählt (Abbildung 4).

Abbildung 4: Bei der Installation des Windows-Agenten für Ossec sollte der Admin alles außer dem Quellcode auswählen.

Im Anschluss führt der Windows-Administrator den Eintrag »Manage Agent« (im Startmenü im Ordner »OSSEC« ) aus. Nach Eingabe der »Ossec Server IP« und des passenden Authentifizierungsschlüssels kann der Windows-Rechner eine Verbindung mit dem Host-basierten IDS-System herstellen.

Ein Klick auf »Save« speichert die angegeben Daten, das Feintuning der Konfiguration findet sich unter »View | Config« (Abbildung 5). Nach dem nächsten Neustart stellt Ossec die Anbindung über einen Windows-Dienst her.

Abbildung 5: Im Gegensatz zur Syslog-Anbindung überträgt der Windows-Agent seine Informationen bereits in der Default-Einstellung sicher verschlüsselt.

Für Hardware-Appliances wie Ciscos PIX-Firewalls eignet sich die Syslog-Funktionalität von Ossec. Zwar ist sie bei der oben beschriebenen Installation aktiviert, doch standardmäßig empfängt der Server keine Syslog-Nachrichten. Vorher müssen die IP-Adressen, von denen ein Empfang dieser Nachrichten erlaubt ist, noch in der Konfigurationsdatei »/var/ossec/etc/ossec.conf« landen:

<remote>
<connection>syslog</connection>
<allowed-ips>10.21.81.4</allowed-ips>
<allowed-ips>10.21.81.9</allowed-ips>
<port>5140</port>
</remote>

In dieser Konfiguration verarbeitet Ossec die Syslog-Nachrichten von 10.21.81.4 und 10.21.81.9.

Besonders hilfreich beim Aufspüren von Angreifern ist die Korrelator-Engine von Prelude [14]. Sie bietet die Möglichkeit, IDMEF-Ereignisse miteinander in Verbindung zu setzen und so einen Korrelations-Alarm zu erzeugen, der alle betreffenden Einzelalarme enthält (Abbildung 6). Die Installation des Prelude-Correlator erfolgt unter Debian mit »aptitude install prelude-correlator« , registrieren lässt sich der Agent mit:

Abbildung 6: Korrelationsalarme erfassen Angriffe auch dann, wenn der Hacker zum Beispiel versucht mehrere unterschiedliche Geräte anzugreifen, hier am Beispiel eines Portscan.

prelude-admin register prelude-correlator?
 "idmef:rw" Listen-IP_des_Prelude-Managers?
 -uid 0 -gid 0

Der Prelude-Correlator liefert bereits einige eigene Plugins mit, sie sind unter Debian im Ordner »/usr/share/pyshared/PreludeCorrelator/plugins/« zu finden und lassen sich über einen Eintrag in »/etc/prelude-correlator/prelude-correlator.conf« aktivieren. Die Zeilen

[BruteForcePlugin]
disable = false

aktivieren beispielsweise das Bruteforce-Plugin. Anschießend startet »/etc/init.d/prelude-correlator start« den Correlator.

Eigene Plugins

Wer selbst Plugins erstellen möchte, braucht Python-Grundkenntnisse und sollte das Kapitel 4.2 des IDMEF-RFC eingehend studieren [1]. Dieser Abschnitt des RFC behandelt die Nachrichtenklassen, die Plugin-Programmierer verwenden dürfen.

Das von dem Autor dieses Artikels extra geschriebene Beispiel-Plugin Portscangeoinfo (Listing 2) steht unter [15] zum Download. Es reagiert auf Portscans, die Snort und Ossec erkannt haben, und macht es möglich, über einen Korrelationsalarm geografische Informationen des Angreifers auszugeben. Damit Snort die Portscans auch erkennt, muss der Portscan-Präprozessor in der »snort.conf« aktiviert sein.

01 # Please download http://geolite.maxmind.com/download/geoip/database/GeoLiteCity.dat.gz and place the content of the archive in /usr/share/GeoIP/ to get more detailled geographical information
02
03 # Please report bugs to rupprechter at dotlike dot net
04 # for more information please visit www.dotlike.net/portscangeoinfo.php
05
06 import os
07 import re
08 import shlex, subprocess
09 import sys
10
11 from PreludeCorrelator.context import Context
12 from PreludeCorrelator.pluginmanager import Plugin
13 from PreludeCorrelator.idmef import IDMEF
14
15 strout = None
16
17 class PortscanGeoinfoPlugin(Plugin):
18 def run(self, idmef):
19 classification = idmef.Get("alert.classification.text")
20
21 NMAPFSCAN = "PSNG_TCP_FILTERED_PORTSCAN"
22 NMAPSCANUDP = "PSNG_UDP_FILTERED_PORTSCAN"
23 NMAPPSNG = "ICMP PING NMAP"
24 TCPPSCAN = "(portscan) TCP Portscan"
25 NMAPSCAN = "PSNG_TCP_PORTSCAN"
26 SSHSCAN = "SSH insecure connection attempt (scan)."
27 SSHSCAN2 = "Possible attack on the ssh server (or version gathering)."
28 if classification != NMAPPSNG and classification != NMAPFSCAN and classification != TCPPSCAN and classification != NMAPSCAN and classification != SSHSCAN and classification != SSHSCAN2 and classification != NMAPSCANUDP:
29 return
30 source = idmef.Get("alert.source(*).node.address(*).address")
31 for saddr in source:
32 ctx = Context(("NETWORK_INFO_PORTSCAN_ATTACKER", saddr), { "expire": 600, "alert_on_expire": True }, update = True, idmef=idmef)
33 if ctx.getUpdateCount() == 0:
34 ctx.Set("alert.correlation_alert.name", "Network scan of host(s) detected" )
35 ctx.Set("alert.classification.text", "Network information for scanning host")
36 ctx.Set("alert.assessment.impact.severity", "high")
37 # only create one alert per source
38 # GeoIP
39 # only do GeoIP lookup if IP address is not private
40 if saddr.find("10.", 0, 4) != -1 or saddr.find("172.", 0, 4) != -1 or saddr.find("192.", 0, 4) == -1:
41 # if GeoIP City Database exists
42 if os.path.exists("/usr/Share/GeoIP/GeoLiteCity.dat") == True:
43 import GeoIP
44 gi = GeoIP.open("/usr/share/GeoIP/GeoLiteCity.dat",GeoIP.GEOIP_STANDARD)
45 geoinfo = gi.record_by_addr(saddr)
46 geo = re.sub(r'\'', r'', re.sub(r': ', r':', str(geoinfo)) )
47 idmef = IDMEF()
48 idmef.Set("alert.classification.text", "Geographical Information for portscanning host")
49 idmef.Set("alert.correlation_alert.name", geo )
50 idmef.Set("alert.assessment.impact.severity", "high")
51 idmef.Set("alert.assessment.impact.description", "Geographical information for portscanning host " + saddr)
52 idmef.alert()
53 ctx.update(idmef=idmef)
54 # else if only GeoIP Country Database exists
55 elif os.path.exists("/usr/share/GeoIP/GeoIP.dat") == True:
56 import GeoIP
57 gi = GeoIP.new(GeoIP.GEOIP_MEMORY_CACHE)
58 idmef = IDMEF()
59 idmef.Set("alert.classification.text", "Geographical Information for portscanning host")
60 idmef.Set("alert.correlation_alert.name", str(gi.country_code_by_addr(saddr)) )
61 idmef.Set("alert.assessment.impact.severity", "high")
62 idmef.Set("alert.assessment.impact.description", "Geographical information for portscanning host " + saddr)
63 idmef.alert()
64 ctx.update(idmef=idmef)

Abbildung 7: Erkennt das System einen Portscan von Snort oder Ossec, dann erhält der Admin wenig später in der Liste der Alarme den Eintrag »Geographical Information for portscanning host«.

Der Korrelationsalarm »Network Information for scanning host« enthält sowohl die Geo-IP-Informationen als auch die zugehörigen Alarme der Snort-Ossec-Sensoren. Das Plugin wartet 5 Minuten, sammelt alle Portscan-Ereignisse innerhalb dieses Zeitraums und packt sie gesammelt in einen Korrelationsalarm. Damit das klappt, muss der Admin vorher mit »aptitude install geoip-python libgeoip1« Geo-IP für Python installieren. Wer sich mit den Länderinformationen nicht zufriedengibt, dem hilft die Geo-IP-City-Lite-Datenbank von [16] weiter.

Der Aufbau eines Plugin

Jedes Korrelations-Plugin enthält eine Datei namens »setup.py« , die für die Installation des Plugin verantwortlich ist. Listing 1 zeigt den Inhalt der Datei. Um ein eigenes Plugin zu erstellen, braucht der Admin lediglich die Namen »PortscanGeoinfoPlugin« und »portscangeoinfoplugin« anzupassen, optional korrigiert er auch die Felder »description« , »author« und »version« . Im Beispiel liegt der Code des Plugin im Ordner »portscangeoinfoplugin« . Hier akzeptiert das Skript auch Platzhalter: Wer in das Setupskript die Zeile

01 From setuptools import setup, find_packages
02 setup(
03 name='PortscanGeoinfoPlugin',
04 version='1.0',
05 description="Geographical information for portscanning hosts",
06 author="David Rupprechter",
07 packages=find_packages(),
08 entry_points='''
09   [PreludeCorrelator.plugins]
10   PortscanGeoinfoPlugin = portscangeoinfoplugin:PortscanGeoinfoPlugin
11     '''
12 )

Pluginname = Directory:My_plugin

einfügt, verweist auf das Plugin »My_plug- in« im Verzeichnis »Directory« , »python setup.py build« und »python setup.py install« installieren es schließlich.

Jetzt sind noch folgende Zeilen in die Datei »/etc/prelude-correlator/prelude-correlator.conf« einzufügen, um das Plugin beim Start des Korrelators zu aktivieren:

[PortscanGeoinfoPlugin]
disable = False

Im so gewählten Plugin-Ordner liegen die Dateien »init.py« und »main.py« (Listing 2). Die Datei »init.py« enthält nur eine Zeile mit dem Namen des Plugin:

from main import PortscanGeoinfoPlugin

Das Plugin Portscangeoinfo zeigt die großen Möglichkeiten, die die Korrelator-Engine von Prelude bietet: Die Popen-Funktion bindet Konsolenprogramme und deren Ausgaben ein.

Volle Netzwerkkontrolle

Mit Hilfe der beschriebenen Kombination von NIDS und HIDS als Sensoren von Prelude lassen sich alle Informationen des Netzwerks, darunter auch die von Syslog-fähigen Endgeräten, über ein zentrales Webinterface analysieren. Egal ob Windows, Cisco oder der Linux-Server, alle Maschinen im Rechenzentrum lassen sich damit in die zentrale Überwachung integrieren. Wer dann noch mit individuellen Plugins die Informationen gesammelt in übersichtlichen Korrelationsalarmen in Prewikka darstellen lässt, macht es jedem Angreifer schwer, unbemerkt zu bleiben. (mfe)