Überblicken statt Überlesen Grafische Ansätze zur Logfile-Analyse

Ordnungsmerkmale

erschienen in: <kes> 2003^#3, Seite 64

Zusammenfassung: Wer die Stecknadel im Heuhaufen sucht, sollte einen verdammt starken Magneten haben. Oder auf Logfiles übertragen: Mit der richtigen Technik lässt sich auch in unübersichtlichen Datenmengen der entscheidende Eintrag finden. Sehr hilfreich kann dabei die grafische Repräsentation und Korrelation sein.

Autor: Von Andreas Wagner, Duisburg

Logfiles sind zahlreich, groß, für den Menschen schwer "lesbar" oder zumindest unübersichtlich und die meisten Einträge sind für sich genommen nicht interessant. Allzu oft sind Protokolldateien nicht richtig auswertbar, da das menschliche Gehirn ab einer bestimmten Informationsmenge nicht mehr in der Lage ist, Vorgänge miteinander in Beziehung zu setzen – erst recht nicht über mehrere Systeme hinweg. Gerade das wäre aber sinnvoll, wenn nicht sogar notwendig, um festzustellen, was in einem Intrusion Detection System (IDS) Alarm ausgelöst hat, ob wirklich eine Attacke vorliegt oder der Angreifer womöglich sogar Schäden angerichtet hat, die dem IDS entgangen sind.

Doch schon die isolierte Auswertung des Logfiles eines einzelnen Systems kann sinnvoll sein, um Kommunikationsmuster zu erkennen und Veränderungen aufzuspüren. Auch dabei hilft eine Visualisierung enorm, denn eine passende grafische Darstellung lässt die gesuchten Abweichungen von der Norm hervorstechen. Ein paar einfache Beispiele: Verknüpft man Quell- und Ziel-IP so zeigt sich das Kommunikationsverhalten. Wo liegen Querverbindungen zwischen den "Wolken" einzelner Abteilungen? Oder bei einer grafischen Verbindung von Quell-IP zu Ziel-Ports: Welche Systeme zeigen besonders breit "gefächerte" Kommunikation und haben womöglich Port-Scans durchgeführt? Durch die Relation der Zeit mit einer Ziel-IP zeigt sich schnell, wann am häufigsten kommuniziert wurde – und wo die "Ausreißer" stecken.

Die Liste möglicher Visualisierungen und Ergebnisse lässt sich nahezu beliebig fortführen und ist im Wesentlichen von der Kreativität des Analysten und den Möglichkeiten seines Werkzeugs begrenzt. So könnten beispielsweise Protokollarten für die "Farbe einer Verbindung" sorgen, Zeitangaben die Grafik animieren oder die Häufigkeit eines Kommunikationsmusters (Menge bestimmter Einträge) die Linienstärke bestimmen. Über ein "Wörterbuch" bekannter Quell- und Zieladressen könnte man Knoten aussagekräftige Icons zuweisen, etwa falls 192.168.1.2 ein Mailserver ist, diese IP-Nummer als Briefumschlag darstellen. Vergibt man für alle Knoten, die nicht im Wörterbuch vorhanden sind, ein Warnsymbol wie eine rote Bombe, so springen unbekannte Systeme in der Grafik sofort ins Auge.

Logfiles: erträglich bis grauenvoll

Leider haben es die wenigsten Hersteller von Firewalls, IDS-Lösungen oder Betriebssystemen verstanden, Logfiles klar zu strukturieren und von Überflüssigem freizuhalten. Meistens fehlt auch die Möglichkeit am protokollierenden System von vornherein Einfluss auf das Ausgabeformat zu nehmen oder mit einem Tool Logfiles nachträglich zu beschneiden, um sinnvollere Ergebnisse zu erhalten.

Sieht man sich beispielsweise ein noch relativ gutes Logfile einer Firewall an, zeigen sich sofort bestimmte Probleme:

"Date","Time","Action","FW.Name","Direction","Source","Destination","Bytes","Rules","Protocol"
"datetime=26Aug2001","20:26:02","action=drop","fw_name=nfl-cp.nfl.gov","dir=inbound","src=172.28.0.23","dst=192.168.27.41","bytes=48","rule=29","proto=tcp/http"
"datetime=26Aug2001","20:26:04","action=drop","fw_name=nfl-cp.nfl.gov","dir=inbound","src=10.175.62.222","dst=192.168.20.42","bytes=48","rule=29","proto=tcp/http"

Wenn Zeilen einheitlich formatiert sind und zudem noch eine Kopfzeile exisitert, die angibt an welcher Position welche Information zu finden ist, warum enthält dann jeder Eintrag noch einmal einen entsprechenden Hinweis? Warum wird überhaupt eine Kopfzeile geschrieben, die bei der Auswertung nur stört, da ihre Struktur nicht der aller anderen Zeilen entspricht? Warum entspricht das Datumsformat nicht der normierten ISO-Schreibweise?

Um zu einem besser auszuwertenden (und auch viel speicherplatzfreundlicherem) Ergebnis zu kommen, muss man das Logfile also überarbeiten und auf die wesentlichen Informationen beschränken (falls nur eine Firewall in Frage kommt, könnte man sogar deren Namensangabe noch weglassen):

2001-26-08T20:26:02 drop nfl-cp.nfl.gov in 139.67.8.235 139.203.160.214 48 29 tcp http 
2001-26-08T20:26:04 drop nfl-cp.nfl.gov in 210.22.4.200 139.203.133.42 48 29 tcp http

Noch schlimmer für eine Auwertung ist es, wenn Logfiles von Zeile zu Zeile ihre Struktur ändern, sich Einträge über mehrere Zeilen hinweg erstrecken oder sogar beides der Fall ist. Derartige Protokolldaten in eine auswertbare Form zu bringen erfordert viel Kopfarbeit.

Aufbereitung

Da man Logfiles üblicherweise aus gleichbleibenden Quellen auswertet, empfiehlt es sich, das Umformatieren zu automatisieren. Skript-Programme leisten hier gute Dienste und lassen sich zeitgesteuert (je nach Aktualitätsbedarf stündlich, täglich oder wöchentlich) ausführen.

In der Praxis hat sich für alle, die keine begnadeten Skriptschreiber sind, das Tool Textpipe Pro ( www.crystalsoftware.com.au) bewährt, das gute Dienste bei der Logfile-Manipulation leistet und im Endergebnis auf Wunsch auch ein Skript zur späteren Automatisierung ausgibt. Auch ein Text-Editor, der keine Probleme mit großen Dateien hat und auch Suchen und Ersetzen mit Regular Expressions unterstützt, kann gute Dienste leisten; hier empfiehlt sich beispielsweise Ultraedit ( www.ultraedit.com).

Sehr verbunden

Nimmt man sich beispielsweise ein Firewall-Logfile vor, so sind einzelne Einträge als solche oft wenig aussagekräftig: Sowohl die generell abgewiesenen Verbindungen (Aktion "drop") als auch die zugelassenen (Aktion "accept") sind zunächst nur eine Bestätigung dafür, dass die Firewall-Regeln funktionieren. Interessant wäre es jedoch herauszufinden, ob Quelladressen existieren, die sowohl akzeptiert als auch abgewiesen wurden. Dies ließe darauf schließen, dass entweder ein Angreifer einen offenen Eingang gefunden hat oder sich das Regelwerk im Laufe des Beobachtungszeitraums geändert hat, was auf eine gewünschte oder unerwünschte Manipulation von innen oder außen schließen ließe – auf jeden Fall aber Aufmerksamkeit verdient.

Eine solche Auswertung ließe sich im Prinzip durch die Aufnahme der Protokolldaten in eine Tabelle, das Sortieren nach der Quell-IP und anschließendes manuelles Prüfen der Einträge umsetzen. Allerdings müsste man dabei alle Zeilen durchsehen, um das Vorhandensein von Drop- und Accept-Einträgen für ein- und dieselbe IP zu erkennen – was zeitaufwändig, ermüdend und fehleranfällig ist. Wie leicht übersieht man in einem solchen Datengewimmel genau den einen Eintrag, nach dem man eigentlich Ausschau hält?!

Eine angemessene Visualisierung lässt solche Einträge jedoch sofort auffallen, ohne dass man den "uninteressanten" Wust durchgehen müsste. Nutzt man (im Beispiel mit dem Tool SilentRunner) die "Quelladresse" und "Aktion" als Knoten und die "Protokoll"-Einträge (http, ftp usw.) als Verbindungen zwischen diesen Knoten, so fallen bei entsprechender Anordnung "doppelt angebundene" Quell-IPs sofort auf (s. Abb. 1). Geeignet wäre hier beispielsweise die Anordnung der Knoten nach "Proximität": Je häufiger eine Aktion von einer Quelladresse ausgelöst wurde, desto näher rückt diese an die Aktion. Alle Quell-IPs, die nur eine Aktion ausgelöst haben, landen im Kreis um die jeweilige Aktion herum, der potenzielle Angreifer, der häufiger (durch mehr als einen Versuch mit mehreren Protokollen) ge-dropped wurde, landet entsprechend näher am Drop-Knoten und fällt dadurch auf – für die Darstellung im Screenshot wurde er bereits manuell separiert und an eine leichter beobachtbare Stelle verschoben.

Abbildung 1 – Visualisierung eines Firewall-Logfiles: Deutlich hebt sich eine einzelne IP-Adresse ab, die sowohl für abgewiesene als auch für akzeptierte Verbindungen gesorgt hat.

Die Grafik zeigt dann eindeutig, ob eine solche Quelladresse beide Aktionen ausgelöst hat, da diese ja sowohl eine Verbindung zur Aktion "Drop" als auch zur Aktion "Accept" erhält. Da das Protokoll dem Link zugeordnet war, lässt sich zusätzlich sofort ablesen, welche Protokolle ein Accept und ein Drop ausgelöst haben. Handelt es sich um verschiedene Protokolle, so könnte immer noch beispielsweise ein legitimer Remote-User aus Schusseligkeit http://... statt ftp://... eingegeben haben und so zu einem "Fehlalarm" führen. Stimmen hingegen – wie im Bild – in beiden Verbindungen Protokolle überein (telnet, smtp), dann ist etwas nicht in Ordnung.

Als verstärkenden Faktor dient bei dieser Visualisierung zudem eine Gewichtung: Die Linienstärke der Verbindungen entspricht der Häufigkeit, mit der eine Aktion von der Quelladresse ausgelöst wurde. Bei "dick angebundenen" Quell-IPs könnte sich ein zweiter, genauerer Blick lohnen...

Bereits mit solchen relativ einfachen Visualisierungen lassen sich viele Auswertungen vollziehen, beispielsweise:

• Verknüpfung von auslösender Quelle (CD-ROM, Server, Eventlog etc.) und Typ (Fehler, Info, Warnung etc.) eines Eintrags im NT/W2000-System- oder Anwendungsprotokoll – Ergebnis: Welche Quellen/Anwendungen haben am häufigsten Meldungen ausgelöst und welche waren das?
• Im NT/W2000-Sicherheitsprotokoll Verknüpfung von Quelle (User, Service etc.) und Typ (Passwortänderung, Logon zurückgewiesen etc.) – Ergebnis: Welche Benutzer oder Dienste verursachen die häufigsten Fehlanmeldungen? Wer ändert besonders häufig oder selten sein Passwort?
• Aus dem DHCP-Log Verknüpfung der Mac-Adressen mit zugewiesenen IP-Adressen – Ergebnis: Welche Mac-Adressen wechseln am häufigsten die IP, werden also vermutlich häufig rebootet? Mittels "Wörterbuch"-Funktion ist zudem das Aufspüren unbekannter Mac-Adressen möglich.

Königsdisziplin Korrelation

Besonders interessant ist es jedoch, Logfiles verschiedener Quellen miteinander zu verbinden, gemeinsam darzustellen und gewünschte Ergebnisse zu extrahieren. Ein großes Problem dabei ist es, wenn die Quellen nicht exakt zeitsynchron arbeiten, sodass man auf einen anderen kleinsten gemeinsamen Nenner – meist IP-Nummern von Quelle oder Ziel – zurückgreifen muss. Daher der dringende Rat: wo irgend möglich mit einer einzigen Zeitquelle synchronisieren, um Analysen zu erleichtern.

Als Beispiel zur Korrelation soll die Analyse einer Attacke von Angreifern aus dem Internet dienen. Das IDS sollte zwar alle Angreifer und Opfer klar identifiziert haben, aber hier bleibt immer ein gewisser Unsicherheitsfaktor, den es auszuräumen gilt. Die Firewall war so eingestellt, dass sie bestimmte Zugriffe durchlässt, um Daten von Hosts in der DMZ per HTTP für das Intranet bereitzustellen. In diesem Fall stehen angenommenerweise drei Datenquellen zur Analyse bereit:

• das IDS-Protokoll mit seinen Alarmen, IP-Nummern der Angreifer und Opfer (Quelle/Ziel),
• das Firewall-Logfile mit seinen Verbindungsdaten und dem Status "accepted" und "rejected" nach Quell- und Zieladresse,
• aufbereitete Daten aus einem Netzwerk-Mitschnitt (TCP-Dump), der nach ersten Alarm noch während der Angriffe aufgezeichnet wurde – die Aufbereitung berücksichtigt Session-Inhalte mit Quell- und Zieladresse.

An Vorarbeiten fallen an:

• Umformatieren der Logfiles per Skript, um ein "sauberes" Format zu erhalten,
• (einmaliges) Erstellen von so genannten Profiles, damit selbsterklärende Icons bei der Beurteilung helfen,
• (je Logfile einmaliges) Erstellen eines so genannten Spec-Files, das dem Analysesystem erörtert, welche Information im Logfile wo zu finden sind.

Abbildung 2 – Visualisierung eines IDS-Logfiles: Erkannten Angreifern und Opfern wurden spezielle Icons zugeordnet.

Nacheinander werden die Logfiles nun grafisch dargestellt, wobei die erste Grafik (IDS Alarme) die führende Rolle übernimmt, da hier (initale) Angreifer und Opfer erkannt wurden (s. Abb. 2). Um weitere Beteiligte zu identifizieren, fügt man nun die Informationen der beiden anderen Logfiles hinzu. Anhand von Quell- und Zieladresse lassen sich die Daten miteinander korrelieren (bei SilentRunner geht das mithilfe der so genannten Overlay-Funktion). Zunächst ergibt sich aufgrund der Datenfülle ein schwer zu überblickendes Gebilde (s. Abb. 3) – schon jetzt fallen aber einige wenige Querverbindungen zwischen den Systemen der akzeptierten und abgelehnten Verbindungen deutlich auf und die "abgewiesenen" Knoten sind durch Anordnung bereits gruppiert.

Abbildung 3 – Gemeinsame Visualisierung von IDS- und Firewall-Logfiles: Auch in großen Datenbeständen fallen einzelne Links zwischen den beiden Systemen akzeptierter und abgewiesener Verbindungen sofort auf – potenzielle Angreifer sind zudem durch ihre Positionierung vorsortiert, sodass man sich zunächst IP-Nummern genauer ansehen kann, die entsprechend hervorstechen.

Aus dieser Gesamtsicht gilt es es nun, die unnötigen Elemente zu entfernen: Da die vom IDS erkannten Angreifer und Opfer im zuvor erstellten Profil spezielle Icons zugewiesen bekommen haben, geschieht dies anhand einer Icon-Liste. Zur Selektion dieser IPs ergänzt man dann alle "Nachbarn" der Angreifer, also jeden Knoten, der mit den bekannten Angreifer-IPs über einen Link verbunden ist. Alle anderen Objekte interessieren nicht und werden (durch Umkehr der Selektion) gelöscht. In der Grafik befinden sich nun erkannte Opfer, erkannte Angreifer, von erkannten Angreifern angesprochene IP-Nummern sowie die Session-Informationen dieser Verbindungen.

Das Verknüpfen von IDS- und Firewall-Log hat hierbei bewirkt, dass für Angreifer und Opfer alle von der Firewall protokollierten Verbindungen enthalten sind, und nicht nur die Verbindungen, welche Alarme ausgelöst haben. Durch die Nachbar-Selektion blieben zusätzlich die Verbindungen von den erkannten Angreifern auf weitere potenzielle Opfer im Bild, die möglicherweise keinen IDS-Alarm ausgelöst hatten. Anhand der blauen Icons "unbekannter Systeme" und der grünen "accept"-Linien aus dem Firewall-Logfile zeigt sich – nach einer Neuorganisation der Darstellung – klar, dass dem IDS einige unrechtmäßige Zugriffe entgangen waren (s. Abb. 4).

Abbildung 4 – Ergebnis der Angriffs-Analyse Angriffs durch Korrelation von IDS- und Firewall-Logfiles

Der zusätzliche Import der Session-Informationen aus dem TCP-Dump spielt eine wichtige Rolle bei der Abschätzung der Tragweite des Angriffs: Erst hiermit lässt sich darstellen, ob im Zuge der Attacke tatsächlich Daten transferiert worden sind und welchen Inhalt diese Transfers hatten. Die Auswertung dieser Grafiken hat gezeigt:

• Es handelte sich um ein kollektives Vorgehen verschiedener Angreifer.
• Die Firewall ließ Verbindungen auf Angreifer-IPs zu, die vom IDS nicht erkannt wurden (grüne Linie in der Grafik, ohne dass das Zielsystem als "Opfer" markiert ist).
• Ein unerkanntes Opfer wurde sogar von zwei Angreifern attackiert.
• Von einem als Opfer erkannten System wurden tatsächlich Daten an zwei Angreifer übertragen. Die Session-Information zeigte bei näher gehender Analyse, dass die Daten in http-Paketen übermittelt wurden.

Fazit dieses Szenarios: Ohne Visualisierung wäre es wohl kaum möglich gewesen, diesen Angriff in dieser Klarheit zu erkennen. Doch mit Korrelation lässt sich noch viel mehr erreichen. Stünden zusätzlich noch Längen- und Breitengrad des letzten Routers vor dem Angreifer bereit (manche Provider stellen diese Informationen für ihre Router zur Verfügung), so könnte die Grafik auch auf eine Landkarte projiziert werden, um eine eventuelle geographische Konzentration von Angreifern zu ermitteln.

Anwendungsgebiete

Durch die Vielseitigkeit einer derartigen Visualisierung kommt diese Technik in allen möglichen Bereichen zum Einsatz, unter anderem:

• Netzwerk-Forensik, zur Untersuchung von Vorfällen und Anomalien,
• Kriminalistik, zur Darstellung von Täter- und Fallprofilen,
• Security-Management, um Sicherheitssysteme besser einstellen zu können,
• Netzwerk-Management, um die Zustände der Systeme besser zu verstehen.

Die Techniken der Visualisierung sind einfach zu erlernen und sparen eine Menge Zeit bei der Bewertung von Systemen und dem Erkennen von Sicherheitsproblemen. Auch IDS-Fehlalarme lassen sich minimieren, da aus den Erkenntnissen durch die Visualisierung das IDS genauer eingestellt werden kann. Falls die notwenigen Ressourcen oder das Know-how im eigenen Hause fehlen, können Visualisierungen mittlerweile auch von verschiedenen Systemhäusern als Dienstleistungen eingekauft werden.

Andreas Wagner (awagner@asapso.de) ist Technischer Direktor bei ASAP IT-Services und Senior Security Consultant für  SilentRunner Europe.

zurück zum Inhalt
© SecuMedia-Verlags-GmbH, 55205 Ingelheim (DE),
<kes> 2003^#3, Seite 64