Von Betriebssystemen, Firewalls und Intrusion-Detection-Mechanismen prasseln riesige Mengen sicherheitsrelevanter Logeinträge auf den Admin ein. Das kommerzielle Neusecure unterstützt ihn dabei, aus dieser Flut wichtige Spuren herauszufischen und damit auch gut getarnte Angriffe aufzudecken.

Bei jeder Linux-Installation jenseits simpler Heimsysteme scheitert manuelle Logfile-Kontrolle an der Masse: Netzwerkadministratoren leiden nie unter Arbeitsmangel, sich mehrere Stunden täglich durch Logfiles zu wühlen ist unmöglich. Aus diesem Bedarf ist eine neue Disziplin entstanden, die sich auf Neudeutsch Security Information Management (SIM) nennt. Der Computer übernimmt dabei Aggregation (Abbildung 1), Korrelation und Analyse der Logdaten und alarmiert den Admin, wenn er etwas Ungewöhnliches bemerkt.

IDS als SIM

Viele SIM-Lösungen basieren auf klassischen Intrusion-Detection-Systemen. Sie beschränken sich aber meist auf die eigenen IDS-Sensorendaten. Eine Zusammenfassung des Zoos auflaufender Rohdaten leisten nur wenige, etwa das im Folgenden vorgestellte Neusecure [1]. Dieses SIM-System gehört mittlerweile zu IBMs Tivoli-Familie. Ursprünglich entwickelte Guarded Net (eine Firma aus Atlanta) das Programm. Im Jahr 2005 erwarb Micromuse die Software und später schluckte IBM Micromuse mitsamt Neusecure. Das System ist derzeit in Version 3.0.0SP2 für Solaris 9 und Red Hat Enterprise Linux 3 verfügbar.

Komponenten

Die Logdaten stammen aus unterschiedlichen Quellen. Unix-Systeme benutzen für fast alles Syslog oder Syslog-NG. Firewalls der Firma Checkpoint haben ein eigenes, offen gelegtes Protokoll, um die Logdaten binär abzugreifen. Intrusion-Detection-Systeme schreiben zum Teil in SQL-Datenbanken. Windows-Systeme legen ihre Logs im eigenen proprietären Event-Format ab und geben sie über Microsoft-RPC-Aufrufe wieder preis. Andere Applikationen schreiben lokale Textdateien oder erzeugen pro Event ein File.

Die erste Aufgabe lautet somit: Alle Events einsammeln und so weit wie möglich normalisieren, damit eine einheitliche Tabelle entsteht. Die kann der Admin selbst durchsuchen, sie dient aber primär als Datenbasis für die Korrelation. Um das Einsammeln kümmert sich das so genannte Event Aggregation Module (EAM, Abbildung 1), mit seinen Anschlussmöglichkeiten für Checkpoint, Syslog, E-Mail, SNMP, etwas ältere Cisco-IDS-Systeme sowie einer Java-basierten XML-Schnittstelle. Diese Unterprogramme heißen Conduits.

Abbildung 1: Am Anfang steht die Aggregation. Das Event Aggregation Module von Neusecure sammelt Ereignisse (Logdaten) aus vielen Quellen und speichert sie einheitlich formatiert in der zentralen Datenbank. Auf dieser Basis gelingen die nachfolgenden Schritte Korrelation und Analyse.

Das Checkpoint-Conduit verbindet sich per LEA-Protokoll (Logfile Export Architecture) an einen Checkpoint-Management-Server und zieht dort die Logfiles ab. Für das Syslog-Conduit senden die Maschinen ihre Syslog-Meldungen direkt an den Rechner, auf dem das Conduit läuft. Es liest die Daten dann aus einer Logdatei. Leider lässt sich nur eine einzelne Datei angeben, daher sollte die Syslog-Konfiguration des Conduit-Rechners alle Events in einer gemeinsamen Datei ablegen. Beim E-Mail- und SNMP-Conduit wartet das System, auf dem das EAM läuft, ebenfalls auf Neueingänge.

Sonderfall XML

Eine Sonderstellung nimmt das XML-Conduit ein. Zu diesem gehört ein vom Hersteller bereitgestelltes Programm, das Universal Collection Module. Dieses Java-Tool sammelt Logdaten ein, die in Dateien auf beliebigen Rechnern im Netz liegen oder sich in einer Datenbank befinden. Der Java-Prozess kommuniziert mit dem XML-Conduit und leitet die Daten weiter.

Viele Datenbanken

Dem EAM liegt eine lokale Datenbank (MySQL 4.1.14) zugrunde, die Administration erfolgt über ein Webinterface. Die Meldungen aller Datenquellen landen zunächst in einer Tabelle dieser lokalen Datenbank. Ein weiterer Prozess leitet aus dieser Tabelle die Events zur zentralen Verarbeitung weiter. Sollte diese Verbindung abbrechen, puffert das EAM die Daten lokal.

Eine Neusecure-Installation kann mehrere EAMs besitzen. Als verbindende Komponente dient das Herzstück mit dem missverständlichen Kürzel CMS: Das Akronym steht hier für Central Management System. Zu seinen Aufgaben gehören vor allem:

• Normalisierte Logdaten aller EAMs entgegennehmen.
• Daten statistisch korrelieren.
• Benutzerdefinierte Regeln auf die hereinströmenden Daten
  anwenden.
• Daten in einer zentralen Datenbank ablegen.
• Benutzerinterface für die Admins anbieten (Suche und
  Anzeige von Gefahrenpotenzialen in Echtzeit).

Neben den EAMs basiert auch das CMS auf Datenbanken; es speichert darin praktisch alle Informationen. Für Konfigurations- und Nutzdaten besteht die Wahl zwischen Oracle 9 und MySQL. Zusätzlich fordert das CMS eine MySQL-Datenbankinstanz für Laufzeitdaten (siehe auch Kasten “Installation”).

Reporter inklusive

Zum System gehört zudem ein Reportgenerator. Der Trainer in einer Schulung zur Version 2.0 formulierte treffend: “For the comic level of management”, also für Vorstände, die bunte Bilder brauchen, um zu verstehen, dass die Mitarbeiter ihren Job wirklich erledigen.

Der Reportgenerator basiert auf dem zugekauften Modul J-Reports. Neusecure liefert bereits eine Reihe von Reports mit. Über den Designer ist es leicht, beliebige Reports zu erzeugen, um auch ausgefallene Bilderwünsche zu befriedigen. Das Erstellen und Ausliefern der Reports ist automatisiert möglich; Neusecure stößt den Vorgang regelmäßig an und speichert die Daten entweder auf dem Server oder verschickt sie per E-Mail. Als Ausgabeformate sind unter anderem PDF, HTML und XML möglich.

Die EAMs sammeln die Logdaten und analysieren die sehr unterschiedlichen Formate (allein bei Syslogs für Firewall-Regelverstöße unterscheiden sich Linux, FreeBSD, Cisco PIX und Netscreen erheblich). Sie ermitteln normalisierbare Daten wie Quell- und Zieladresse sowie Ports, Datum, Uhrzeit und gegebenenfalls Benutzernamen.

Außerdem ordnen die EAMs jeder Meldung einen Typ zu, zum Beispiel Firewall-Drop oder Login-Success. Alle übrigen Daten landen in einer Spalte namens »Info«, um bei der weiteren Auswertung verfügbar zu bleiben. Diese Daten schicken alle EAMs an das CMS.

Bevor das CMS Daten korreliert, kategorisiert es sie weiter. Hierfür gibt es zwei Konzepte:

• Security-Domains trennen Bereiche des Netzes wie DMZ,
  Büronetz und Außenwelt.
• Watchlists fassen beliebige Komponenten nach Funktion zusammen,
  zum Beispiel alle internen und externen Webserver.

Security-Domains sind hierarchisch nach Netzblöcken geordnet. Wenn das Netz 192.168.1.0 bis 192.168.1.255 die DMZ bildet, zählt das CMS automatisch alle Hosts aus diesem Bereich auch zur DMZ. Der Admin kann dies für einzelne Rechner aber manuell überschreiben.

Private Netzblöcke erfahren im CMS eine Sonderbehandlung. Da bei größeren Netzwerken eventuell ein RFC-1918-Netzblock [2] mehrfach existiert (etwa nach einer Firmenfusion), erlaubt es die Konfiguration, diese Blöcke mehrfach mit unterschiedlichen Namen anzulegen. Wer einen Sensor oder einen Host in einem solchen Netzblock anlegt, muss zusätzlich angeben, welchem der Blöcke diese Datenquelle angehört. Nur so gelingt eine korrekte Zuordnung eines Events zum Netzblock. Watchlists sind frei in ihrer Zugehörigkeit und eignen sich etwa, um funktionale Gruppen zusammenzufassen oder suspekte Benutzergruppen hervorzuheben.

Korrelation der Daten

Die so kategorisierten Daten verwendet das CMS für seine Korrelationen. Hier ist primär die statistische Korrelation von Belang. Anhand einer gewichteten Summe berechnet das System aus den Events einen so genannten Threatlevel. Es summiert nach Quelle und Ziel des Events getrennt (sowie nach Watchlists und Domains). Als Gewichtung dient bei Adressen und Adressbereichen sowie bei Event-Typen (Firewall-Drops, Firewall-Accepts …) ihr jeweiliger Grad an Gefährlichkeit. Neusecure gibt bereits sinnvolle Gewichtungen vor, der Admin kann sie bei Bedarf aber anpassen. Im Gegensatz zu rein Pattern-basierten Systemen erkennt Neusecure so auch Abweichungen von normalerweise legalem Verkehr, etwa wenn alle Clients im Netz ungewöhnlich viele Webzugriffe auf einen Host durchführen.

Als nächste Stufe folgt die Regel-Engine. Es lassen sich Regeln definieren, die eine Aktion auslösen, wenn eine gewisse Reihenfolge von Events eintritt. Möglich sind einfache Regeln, etwa drei fehlgeschlagene Login-Versuche innerhalb eines festgelegten Zeitraums auf den gleichen Account, aber auch komplexere Abläufe, etwa erlaubter Webzugriff durch die Firewall mit nachfolgender Meldung vom IDS und einem Log-Eintrag des Webservers. Leider fehlt der Regel-Engine derzeit ein logisches Nicht.

Die Neusecure-Datenbank importiert auf Wunsch auch Ergebnisse von Verwundbarkeits-Scannern wie Nessus oder dessen kommerziellen Cousins. Auch dies taugt als Entscheidungsgrundlage für die Regel-Engine, etwa wenn das IDS einen Microsoft-IIS-Angriff auf einen Apache-Server meldet, ist dies kein Grund zur Sorge. Ist das Ziel aber ein IIS, der diese Verwundbarkeit laut Scan besitzt, sollte der Admin in Aktion treten.

Trifft eine Regel zu, kann sie Aktionen ausführen. Zur Wahl stehen E-Mails, lokale Alarme oder lokale Tickets im Neusecure-System, externe Shellskripte oder Meta-Events. Diese Events können Informationen aus den auslösenden Events enthalten. Dazu dienen Platzhalter in der Definition der Aktion.

Eigenes Ticketsystem

Neusecure bringt ein eigenes Ticketsystem mit, mit dessen Hilfe Admins Events und deren Folgen dokumentieren und organisieren. Besonders praktisch: Dank der Integration in die lokale Datenbank führt ein Klick auf die Logmeldungen den Admin direkt zum jeweiligen Ticket. Mittels Shellskript ist es möglich, beliebige Aktionen anzustoßen. Aber Vorsicht: Die Programme sollten nicht zu lange laufen, der Rest des Systems wartet auf den erfolgreichen Abschluss, es kommt leicht zu einem Stau.

Besonders interessant sind Meta-Events, die erst in der Neusecure-Version 3.0 hinzukamen. Sie erzeugen einen neuen Event, den sie mit Informationen aus den auslösenden Events füllen und dann für eine weitere Regel benutzen. Damit gelingen beliebige Abstraktiosstufen. Als abschließenden Schritt der Event-Bearbeitung schreibt eine Komponente namens Archiver alle Ereignisse dauerhaft in die Datenbank.

Konfigurieren

In der neuesten Neusecure-Version sind alle Konfigurationsarbeiten über ein Webinterface zu erledigen. Für die EAM-Komponenten reicht ein Browser mit Javascript-Unterstützung, das CMS verlangt zudem Java ab Version 1.4.2. Der Hersteller nennt als unterstützte Browser sowohl Mozilla Firefox ab 1.0 als auch den Internet Explorer 5.5 oder höher. Zwischen Linux und Windows sind im Browser keine Unterschiede festzustellen. Die Java-Komponente funktioniert leider nicht auf Mac OS X, dagegen arbeitete im Test der alte Mozilla 1.7.12 zusammen mit einer aktuellen Java-Version zuverlässig.

Die Konfiguration des Systems beginnt bei den Sensoren der EAMs. Auf dem CMS legt der Admin dafür zunächst den oder die EAMs fest. Bevor er auf dem Manager ebenfalls die Sensoren anlegt, ist etwas Planung notwendig, da jeder Sensor auf dem CMS zu einer der Security-Domains gehört. Es empfiehlt sich, zuerst die Aufteilung des eigenen Netzes in Domains festzulegen und dann erst die Sensoren den entsprechenden Domains zuzuordnen.

Sensoren

Beim Anlegen jedes Sensors sind die RFC-1918-Netze, aus denen er Daten holt, anzugeben. Wer jeden privaten Netzblock maximal einmal nutzt, nimmt die vorgegeben Netznamen. Größere Organisationen vergeben private Blöcke aber gelegentlich mehrfach, dann unterscheiden eigene Namen wie 10-Hamburg und 10-Köln die konkrete Quelle. Vorsicht: Keinen Netznamen zu wählen führt dazu, dass Neusecure Events dieses privaten Netzes ignoriert.

Gibt es mehrere Admins, folgt als nächster Schritt die Benutzerverwaltung. Neusecure verwendet dabei ein rollenbasiertes Konzept. Jeder Admin befindet sich in einer oder mehreren Gruppen. Er besitzt ein Profil, das steuert, wie er zugreifen darf – lesen, schreiben, Objekte erzeugen und Ähnliches.

Die Gruppen bestimmen, wozu der User entsprechend seinem Profil Zugang erhält. So ist es möglich, zu trennen, welcher Benutzer Events aus welchen Security-Domains einsetzt. Passende Konfiguration der Domains vorausgesetzt taugt dies sogar für Mandantenfähigkeit, sprich: Pro Mandant eine Security-Domain anlegen und danach festlegen, welcher Admin für welchen Mandanten verantwortlich zeichnet.

Für Administratoren, die über die Vorgänge in ihrem Netz Bescheid wissen wollen, ist die Java-Komponente des GUI gedacht. Diese enthält die in Tabelle 1 genannten Fenster. Jedes Fenster zeigt einen frei wählbaren Betrachtungszeitraum. Zudem ist es meist möglich, Filter zu setzen, um die Auswahl der präsentierten Daten einzuschränken.

Mächtige Module

Das Powergrid (Abbildung 2) ist die Ansicht mit dem höchsten Zusammenfassungsfaktor. Es lässt auf einen Blick erkennen, wie viele Events pro Zeiteinheit das System gesehen hat. Die erste Spalte entscheidet, nach welchem Feld das Powergrid zählt. Per Drag&Drop mit der Maus ist die Reihenfolge der Spalten änderbar, sodass die gewünschte Ansicht entsteht. Nach kurzer Einarbeitung entwickelt sich ein Gefühl für den Normalzustand und man lernt die Aussagekraft dieses Fensters schätzen. Die Möglichkeit, es als Grafik darzustellen, ist zwar nett gemeint, die Zahlen sind nach Meinung des Autors aber nützlicher.

Abbildung 2: Das Powergrid fasst zusammen, welche Events pro Zeiteinheit von einem Sensor stammen oder wie viele einer Event-Klasse entsprechen. Der in der gelben Spalte angegebene Count bezieht sich auf die Werte in der ersten Tabellenspalte. Die Reihenfolge der Tabellenspalten ist per Drag&Drop zu ändern.

Das Top-Sources-Fenster (Abbildung 3) erweist sich nach entsprechender Konfiguration der Gewichtung von Quellen und Event-Typen als guter Ansatzpunkt, um anomales Verhalten zu erkennen. Wenn dort der Webproxy plötzlich Spitzenplätze erlangt, obwohl ihn der Admin eigentlich runtergereglt hat, ist entweder Fußball-WM oder ein sich über HTTP verbreitender Virus sorgt für untypisches Verhalten.

Abbildung 3: Den ultimativen Überblick über die Bedrohungslage will das Top-Sources-Fenster zusammen mit seiner Threat-Kalkulation geben. Die gefährlichsten Ereignisse färbt es rot und stellt sie an den Anfang.

Der Tester entdeckte durch die Threat-Kalkulation unter anderem einen extrem langsamen Portscan aus China. Auffällig war der sehr hohe Threat-Wert, obwohl die Events pro Minute niedrig blieben.

Alle Details

Das am wenigsten komplexe Fenster enthält die meisten Daten: die Event-Console (Abbildung 4). Ohne Filter ist sie das grafische Äquivalent zu einem »tail -f« auf eine einheitliche Messagedatei. Ihre zahlreichen Filtermöglichkeiten (Abbildung 5) helfen dem Admin bei der Beantwortung von Fragen wie: “Ich komme nicht von 1.2.3.4 nach 5.6.7.8, woran hängt es?”

Abbildung 4: Die Event-Console listet in Echtzeit alle Ereignisse (Logmeldungen), die im Neusecure-CMS eintreffen. Durch die Normalisierung sind die Zeilen einheitlich, unabhängig vom Format der Event-Quelle.

Abbildung 5: Per Filter schaffen es Admins, in der Flut an Event-Meldungen den Überblick zu behalten und sich auf Ereignisse zu konzentrieren, die den angegebenen Kriterien entsprechen. Leider fehlen in den Filterregeln wichtige logische Operationen, zum Beispiel das Nicht.

Wenn zwischen diesen beiden Adressen vier Firewalls unterschiedlicher Hersteller hängen, müsste sich der Netzverantwortliche normalerweise durch viele Files hangeln. Jetzt setzt er einen Filter auf Quell- und Zieladresse und sieht alle relevanten Einträge.

Wird eine IP-Adresse besonders auffällig, dann möchte man als Admin mehr über seinen Gegner wissen. Ist die Adresse in der Vergangenheit bereits aufgefallen? Mit wem wollte sie reden? Solche Fragen klärt das Host Investigation Toolkit (HIT, Abbildung 6). Dieses Fenster öffnet sich nach einem Doppelklick auf die Adresse. Ein weiterer Klick ändert das Zeitfenster, in dem das Toolkit Events anzeigt, oder führt zu allen Events des Netzwerks, aus dem die Adresse stammt, oder löst einen Portscan aus. Weitere Tools lassen sich frei konfigurieren. Im HIT-Fenster sind auch die Ergebnisse von Vulnerability-Scans einsehbar, wenn sie in der Neusecure-Datenbank stehen.

Abbildung 6: Das Host Information Toolkit zeigt sehr umfassend alle wichtigen Daten zu einem auffällig gewordenen Rechner. Ein Klick auf die Adresse dieser Maschine in einem der Protokollfenster führt hierher.

Viel Funktionalität

Neusecure bietet eine ganze Menge an Funktionalität, was sich auch in dem stolzen Preis spiegelt (siehe Kasten “Neusecure” auf der ersten Seite). Das Tool vereinfacht aber die Arbeit chronisch überlasteter Netzwerk- und Firewalladmins spürbar. Es ist sicherlich kein Produkt für eine Umgebung mit nur einer Firewall und einem Server. Die Liste der unterstützen Datenquellen überzeugt – neben vielen Closed-Source-Produkten enthält sie auch Linux und IPtables sowie etliche BSD-Derivate und deren Firewall-Logs.

An einigen Stellen bleibt dennoch Raum für Verbesserungen. So ist es unverständlich, warum das logische Nicht bei den Regeln fehlt. Das verhindert einige sinnvolle Anwendungen. Auch ist es nicht in allen Feldern möglich, ein logisches Oder zu verwenden, sodass dem Admin nichts anderes bleibt, als stur mehrere Regeln zu verwenden. Für die nächste Major-Release will der Hersteller die Regel-Engine allerdings stark erweitert, um auch komplexe logische Regeln zu ermöglichen.

Bei einer ausreichend dimensionierten und performanten Datenbank kommt das System auch mit zweistelligen Millionen an Events pro Tag zurecht. Ist die Datenbank lahm, macht sich dies in sehr zähem Verhalten des Java-GUI bemerkbar. Ansonsten zeigt sich die Oberfläche von ihrer guten Seite. Beim Logout speichert sie sogar die – vom Admin meist angepasste – Anordnung der Fenster sowie die Filtereinstellungen. Im Test fielen jedoch ein paar »core«-Dateien an. Für den Betrieb waren die Abstürze, die zu den Coredumps geführt hatten, aber offenbar nicht störend.

Für heterogene Umgebungen mit verschiedenen Event-Formaten ist Neusecure eine wahre Arbeitserleichterung. Das mitgelieferte Reporting stellt auch die Wünsche des Managements zufrieden. Die statistische Anomalie-Erkennung über Threat-Berechnungen erweist sich als guter Ansatz, um Dinge zu erkennen, von denen noch kein Intrusion-Detection-System weiß. (fjl)