LogMining
LogMining in Oracle Datenbanken
Im Kontext von Oracle Datenbanken, versteht man unter der Terminologie LogMining die nachträgliche Aufbereitung und Einsichtnahme von aktuellen oder archivierten Transaktionsjournalen.
Was sind Transaktionsjournale (redologs)? Sobald eine Oracle Datenbank Daten in ihrem Bestand modifizieren, anlegen oder löschen soll, führt Oracle diese Anweisung im schnellen Arbeitsspeicher (SGA) durch und übernimmt diese Änderungen zeitversetzt in den Datendateien (datafiles). Dieses Vorgehen an sich ließe sich nicht mit den ACID Anforderung an relationale Datenbanken vereinbaren, da das RDBMS zu jederzeit sicherstellen muss, dass durchgeführte Transaktionen auch persistiert sind - selbst wenn das System im nächsten Moment durch einen Stromausfall ausfallen sollte. Oracle schreibt daher sämtliche Änderungen (DDL und ändernde DML) parallel in ein Transaktionsjournal, den so genannten Redo-Logs.
Diese Redo-Logs protokollieren sinngemäß, durch welche Operationen der Datenbestand der Datenbankdatei zu modifizieren ist, um den aktuellen Zustand im Arbeitsspeicher zu entsprechen. Eine Transaktion wird also erst gegenüber dem Client als abgeschlossen bestätigt (commit), wenn dessen Operationen in den Redo-Logs niedergeschrieben sind. Sollte es im nächsten Moment zum Ausfall kommen, kann beim Hochfahren des Datenbanksystems der Datenbestand im Arbeitsspeicher wiederhergestellt werden, indem die Datenbankdateien eingelesen und die ausstehenden Redo-Logs-Einträge erneut abgearbeitet (redo) werden.
Was sind archivierte Transaktionsjournale (archivelogs)? Die Redo-Logs sind zur Sicherstellung der Konsistenz einer Oracle Datenbank von entscheidender Bedeutung. Daher werden diese Dateien zeitgleich i.d.R. min. zweimal geschrieben. Hierbei sollten zwei verschiedene Speicher eingesetzt werden.
Sollte ein Journal beschädigt werden (z.B. weil das zugrunde liegende Dateisystem beschädigt wurde), kann Oracle mit der bzw. den verbleibenden Kopien die Fortsetzung des Betriebs sicherstellen. Die beiden Kopien werden im Oracle Terminologie Redo-Log-Gruppe bezeichnet. Für den Forensiker sind die Kopien also lediglich von Bedeutung, wenn der Verdacht im Raum steht, dass ein einzelne Redo-Logs-Datei beschädigt wurde.
Die Transaktions-Journale werden in einem Ring-Speicher abgebildet. Konkret handelt es sich um min. zwei, i.d.R. drei Redo-Log-Gruppen, die abwechselnd (Der Übergang heißt "log switch") beschrieben werden. Es gibt eine aktuelle Redo-Log-Gruppe und außerdem aktive und inaktive Redo-Log-Gruppen. Aktuelle und aktive Redo-Log-Gruppen benötigt Oracle im Falle eines Ausfalls für eine Wiederherstellung (Instance Recovery). Die inaktive Redo-Log-Gruppe wartet lediglich auf die Verwendung nach dem log switch.
Sobald der Archive-Log-Modus aktiv ist, werden genutzte Redo-Logs nach einem log switch weggesichert. Sobald diese gesicherten Redo-Logs in ein spezielles "FRA" Verzeichnis (Fast Recovery Area) weggeschrieben wurden, spricht man anstelle von Redo-Logs von s.g. Archive-Logs.
Letztere erlauben es im laufenden Betrieb den kompletten Datenbestand der Oracle Datenbank atomar - als Transaktion für Transaktion - zu sichern. Das ist sogar möglich während das System online ist. Benötigt werden hierfür, neben den Control-Files - die hier aber nicht weiter erläutert werden - die Datenbankdateien (datafiles) und alle folgenden Redo-Logs, um Voll-, kommulative oder inkrementielle Backups zu erstellen. Derartige Backups sollen jedoch hier nicht weiter vertieft werden. Lediglich von dessen Existenz sollte ein Datenbank-Forensiker gehört haben.
Wie kann ich Oracle LogMiner forensisch nutzen? Wenn ein Forensiker Zugang zu den redo- oder archivelogs erhält, kann er sämtliche Anweisungen der Vergangenheit, - quasi soweit die Backups es erlauben - nachvollziehen und strukturiert aufarbeiten. Hierzu bietet Oracle PLSQL-Pakete (PLSQL steht im übrigen für procedural language/structured query language ) an, die wiederum im Verwaltungswerkzeug „Enterprise Manager“ in einer Weboberfläche angeboten werden.
Es ist auch möglich die Redo-Logs in Gänze oder per SQL gefiltert in eine Textdatei auszuleiten, um sie mit anderen Tools auszuwerten. Es ist also möglich sämtliche unbeabsichtigten oder schädliche Systemmanipulationen (z.B. SQL-Injektions) auch dann nachzuvollziehen, wenn zuvor das Audit-Logging nicht aktiviert wurde. Letzteres arbeitet innerhalb der Datenbankinstanz und generiert eigene Strukturen auf Basis ausgewählter Operationen und erlauben einem Administrator wesentlich feingranularer einzustellen, welche Operationen protokolliert werden. Ferner bietet es insbesondere auch die Möglichkeit Abfragen (z.B. falls der Verdacht im Raum steht, Daten würden ausgespäht werden) nachzuvollziehen. Daher ist das Auditing aufgrund des LogMinings nicht obsolete! Jedoch ist es für den Forensiker nur dann von Interesse, wenn dieses (auf Verdacht) vor oder während eines Angriffs eingeschaltet wird. Dies ist in der Praxis oft nicht der Fall, da das Schreiben der Audit-Logs eben eigenes Transaktionsvolumen benötigt und damit die Performance des Gesamtsystems beeinträchtigen kann.
Letztlich ist es sogar möglich, anhand der Redo-Logs eines Fremdsystems Transaktionen nachzuvollziehen. Hierfür wird jedoch auch das s.g. Data-Dictionary des Quell-Systems benötigt, um etwa Benutzerkennungen oder Tabellen-Namen - die Oracle intern als kryptische ID-Referenz verwaltet - auflösen zu können, so dass wieder die eigentlichen Objektnamen (z.B. Benutzernamen oder Tabellennamen) erscheinen.
Wenn ein Angriff stattgefunden hat und klar ist, dass die Datenbank-Instanz betroffen ist, findet man über Session-Traces, AWR Reports oder andere Tools explorativ die bösartigen Objekte im System. Von diesen ausgehend, kann dann in den Redo-Logs rekonstruiert werden, wie diese dahin kamen und insbesondere wer diese wann und wo angelegt hat.
Das Oracle Datenbanksystem erlaubt es sogar, einzelne Anweisungen aus der Vergangenheit unwirksam zu machen. Wie weit dies jedoch in den Datenbestand der Gegenwart durchgereicht wird, ist von verschiedenen Faktoren abhängig, die hier nicht weiter betrachtet werden.
Beispiel:
Um ein ungewolltes Verhalten einzuschleusen löscht ein "frustrierter Student" ;-) als Benutzer „DBUSER“ einige unliebsame Professoren aus der Datenbank. Über die folgende Übung mit dem LogMiner wird diese Manipulation dann offengelegt.
Nun teilt man dem LogMiner mit, welche Archive- oder Redo-Logs er lesen soll. Ich wähle nur die aktuellen REDO-Logs, da auf meiner Demo-Umgebung keine Archive-Logs vorliegen und meine Redo-Log-Gruppen noch nicht durchgeswitcht sind.
Die letzte Anweisung startet den LogMiner. Hierbei wird dem LogMiner über einem Parameter mitgeteilt, dass er als Dictionary den Online Katalog nutzen soll.
Nun kann über den nebenstehenden Befehl ermittelt werden, was der Anwender "DBUSER" in der letzten Zeit so angestellt hat. Hier wird nach der Aktivität innerhalb der letzten Stunde gefragt, aber natürlich sind auch andere Abfragen möglich.
