IT-Forensik Wiki - Benutzerbeiträge [de]

LogMining

2020-02-22T18:44:46Z

St161253:

'''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 [https://de.wikipedia.org/wiki/ACID 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 & DML|(DDL und ändernde DML)]] parallel in ein Transaktionsjournal, den so genannten Redo-Logs.

Diese [[Redo Logs|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|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 Log|Redo-Logs]]-Einträge erneut abgearbeitet (redo) werden.

'''Was sind archivierte Transaktionsjournale (archivelogs)?'''
Die [[Redo Logs|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 Log|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|Redo-Logs]] in ein spezielles "FRA" Verzeichnis (Fast Recovery Area) weggeschrieben wurden, spricht man anstelle von [[Redo Logs|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:
[[Datei:ORACLE SQL DELETE FROM PROFESSOREN.png|mini|Abb.1: Löschen unliebsamer Professoren]]
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.
 

[[Datei:ORACLE SQL START LOGMINER.png|mini|Abb. 2: Starten des Oracle LogMiners]]
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.
 

[[Datei:ORACLE SQLMINER DELETES FOUND.png|mini|Das Bild zeigt die Löschung meiner Datensätze. Zusammen mit einem Zeitstempel und dem Bentzer]]
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.

Redo Logs

2020-02-22T18:42:00Z

St161253:

Redo-Logs stellen einen Kern-Bestandteil einer Oracle Datenbank dar. Das Redo-Log ermöglicht die Wiederherstellung einer Datenbank, indem es alle Datenänderungen protokolliert. Es werden also alle Änderungen der Festplatte sequentiell in das Redo-Log geschrieben. Dadurch ist es möglich - vorausgesetzt man besitzt Zugriff auf die vollständigen Redo-Logs - jeden beliebigen Stand der Datenbank, seit Erstellung, wiederherzustellen (roll-forward Funktionalität).
Ist das Redo-Log nicht vorhanden, so bedeutet ein Absturz der Oracle-Instanz meist den Datenverlust.
Das Redo-Log enthält jedoch nicht nur sämtliche Änderungen, sondern auch Informationen zu diesen Änderungen, wie z.B.

• Wer hat die Änderung durchgeführt?
• Wann wurde die Änderung durchgeführt?
• Welche Daten waren vor Löschung vorhanden (before Image)

Mit Tools wie bspw. [[LogMining|Logminer]] können Informationen aus dem Redo-Log lesbar und somit auch auswertbar gemacht werden. Für forensische Auswertungen können die im Redo-Log gespeicherten Daten von größter Bedeutung sein.

https://www.informatik-aktuell.de/betrieb/datenbanken/oracle-redo-logs-informationen-soweit-der-logminer-reicht.html
https://docs.oracle.com/cd/B28359_01/server.111/b28310/onlineredo001.htm#ADMIN11305

LogMining

2020-02-22T18:04:34Z

St161253:

'''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 [https://de.wikipedia.org/wiki/ACID 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 & DML|(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-Log-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-Log-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:
[[Datei:ORACLE SQL DELETE FROM PROFESSOREN.png|mini|Abb.1: Löschen unliebsamer Professoren]]
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.
 

[[Datei:ORACLE SQL START LOGMINER.png|mini|Abb. 2: Starten des Oracle LogMiners]]
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.
 

[[Datei:ORACLE SQLMINER DELETES FOUND.png|mini|Das Bild zeigt die Löschung meiner Datensätze. Zusammen mit einem Zeitstempel und dem Bentzer]]
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.

LogMining

2020-02-22T15:40:40Z

St161253:

Dieser Artikel beschäftigt sich mit dem 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 [https://de.wikipedia.org/wiki/ACID 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-Log-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-Log-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:
[[Datei:ORACLE SQL DELETE FROM PROFESSOREN.png|mini|Abb.1: Löschen unliebsamer Professoren]]
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.
 

[[Datei:ORACLE SQL START LOGMINER.png|mini|Abb. 2: Starten des Oracle LogMiners]]
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.
 

[[Datei:ORACLE SQLMINER DELETES FOUND.png|mini|Das Bild zeigt die Löschung meiner Datensätze. Zusammen mit einem Zeitstempel und dem Bentzer]]
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.

LogMining

2020-02-16T21:56:55Z

St161253: Screenshot eingefügt der das Ergebnis eines LogMining-Prozesses darstellt.

Dieser Artikel beschäftigt sich mit dem 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 oder einer gecrashten Platte 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-Log-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-Log-Datei beschädigt wurde.

Die Transaktions-Journale werden in einem s.g. Ring-Speicher abgebildet. Konkret handelt es sich um min. drei Redo-Log-Gruppen, die abwechselnd (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 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:
[[Datei:ORACLE SQL DELETE FROM PROFESSOREN.png|mini|Abb.1: Löschen unliebsamer Professoren]]
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.
 

[[Datei:ORACLE SQL START LOGMINER.png|mini|Abb. 2: Starten des Oracle LogMiners]]
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.
 

[[Datei:ORACLE SQLMINER DELETES FOUND.png|mini|Das Bild zeigt die Löschung meiner Datensätze. Zusammen mit einem Zeitstempel und dem Bentzer]]
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.

Datei:ORACLE SQLMINER DELETES FOUND.png

2020-02-16T21:56:03Z

St161253:

Das Bild zeigt, welche Datensätze gelöscht wurden

LogMining

2020-02-16T20:34:07Z

St161253: Ergänzung erster Absätze als Beispiel

Dieser Artikel beschäftigt sich mit dem 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 oder einer gecrashten Platte 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-Log-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-Log-Datei beschädigt wurde.

Die Transaktions-Journale werden in einem s.g. Ring-Speicher abgebildet. Konkret handelt es sich um min. drei Redo-Log-Gruppen, die abwechselnd (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 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:
[[Datei:ORACLE SQL DELETE FROM PROFESSOREN.png|mini|Abb.1: Löschen unliebsamer Professoren]]
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.
 

[[Datei:ORACLE SQL START LOGMINER.png|mini|Abb. 2: Starten des Oracle LogMiners]]
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.

TOFILL

Datei:ORACLE SQL START LOGMINER.png

2020-02-16T20:28:41Z

St161253:

Abb. 2 - Aktivierung des LogMiners

Datei:ORACLE SQL DELETE FROM PROFESSOREN.png

2020-02-16T20:16:56Z

St161253:

Abb. 1 - Löschen unliebsamer Professoren

LogMining

2020-02-16T19:48:15Z

St161253: Die Seite wurde neu angelegt: „Dieser Artikel beschäftigt sich mit dem LogMining in Oracle Datenbanken. Im Kontext von Oracle Datenbanken, versteht man unter der Terminologie LogMining die…“

Dieser Artikel beschäftigt sich mit dem 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 oder einer gecrashten Platte 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-Log-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-Log-Datei beschädigt wurde.

Die Transaktions-Journale werden in einem s.g. Ring-Speicher abgebildet. Konkret handelt es sich um min. drei Redo-Log-Gruppen, die abwechselnd (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 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.

TOFILL

Hauptseite

2020-01-26T15:43:23Z

St161253:

Willkommen beim IT-Forensik-Wiki der Hochschule Wismar. Hier werden wesentliche Begriffe zum Thema „Digitale Forensik“ erläutert.

== Literatur ==

[[Projektarbeiten]]

[[Abschlussarbeiten im Bachelor Studiengang "IT-Forensik"]]

[[Abschlussarbeiten im Master Studiengang "IT-Sicherheit und Forensik"]]

[[Forensik in DB]]

== Stichworte IT-Forensik ==
=== A ===
[[Angriffe auf Forensik-Software]]

[[Algorithmus]]

[[Anti-Forensik]]

[[Asset Relocation]]

=== B ===
[[Bundesdatenschutzgesetz (BDSG)]]

[[Betriebssystem]]

[[Broken Authentication]]

[[BSI-Vorgehensmodell]]

=== C ===
[[Cache]]

[[CERT-Taxonomie]]

[[Chain of Custody]]

[[Chip-Off]]

[[Computer Sabotage]]

[[Cross Site Scripting (XSS)]]

[[CryptoLocker]]

=== D ===
[[Darknet]]

[[Dateiheader]]

[[Datenanalyse]]

[[Datenbankforensik]]

[[Datenschutz in der IT-Forensik]]

[[Datenvernichtung]]

[[Datensammlung]]

[[DDL & DML]]

[[Deep Web]]

[[Diff]]

[[Digitale Forensik]]

[[DLL (.dll Dateien)]]

[[Dokumentation]]

[[Doxing]]

[[Dual Use Software]]

=== E ===
[[Ermittlungsprozess]] 

[[Exploit]] 

[[Error Based SQL Injection]]

=== F ===
[[File Carving]]

[[Flüchtige Daten]]

[[Forensic Data Mining]]

[[Forensischer Koffer]]

[[Fragmentierung]]

=== G ===
[[Geotag]]

[[GeoIP-Datenbank]]

[[Gerichtsfestigkeit]]

=== H ===
[[Hashwert]]

[[Hilfstatort]]

[[Hardware-Sicherheitsmodul]]

[[Hashcat]]

[[Honeypot]]

=== I ===
[[Image]]

[[Imaging]]

[[Incident-Response-Team]]

[[Indicator of Compromise]]

[[Integrität]]

[[IT-Forensik]]

=== J ===
[[Jailbreak]]

=== K ===

[[Installieren eines Live-Kali-Linux-System auf USB-Stick]]

[[Kausalität in der Forensik]]

[[Korrelation]]

=== L ===
[[Lateral Movement]]

[[Live-Forensik]]

[[Locard'sche Regel]]

[[Log-File]]

=== M ===
[[Magnet Axiom]]

[[Metadaten]]

[[Mobiltelefon-Forensik]]

=== N ===
[[Netflow]]

[[Never-Touch-Original]]

=== O ===
[[Online-Forensik]]

[[Offline-Forensik]]

[[OS Fingerprinting]]

[[OSINT-Werkzeug]]

=== P ===
[[Partition]]

[[P2P (Peer-to-Peer) Software / Netzwerke]]

[[Post-Mortem-Analyse]]

[[Prozess der Mobiltelefon Forensik]]

[[Prüfsumme]]

[[PCMCIA]]

[[Penetrationstest]]

=== R ===
[[Rainbow Table]]

[[Registry]]

[[Remote Access Trojaner (RAT)]]

[[Replay Attack]]

[[Reverse Engineering]]

[[Rootkit]]

=== S ===
[[SAP-Modell]]

[[Sandbox]]

[[Security Information and Event Management (SIEM)]]

[[Skimming]]

[[Slack Space]]

[[Sniffing]]

[[SQL Injection]]

[[SQLite Datenbanken auslesen mittels Python]]

[[Sealbag]]

[[SpiderFoot]]

[[Spuren]]

=== T ===
[[Tatort]]

[[Timeline]]

[[Trugspur]]

=== U ===
[[Unallocated Data (Nicht zugeordnete Daten)]]

=== V ===
[[Verfügbarkeit]]

[[Vertraulichkeit]]

[[Vorsorge für die IT-Forensik]]

[[Video-Forensik]]

=== W ===
[[W-Fragen]]

[[Watering-Holes]]

[[Why-Because-Analyse (WBA)]]

[[Windows-RAM auslesen]]

[[Wiping]]

[[Write Blocker]]

=== X ===
[[Xmount]]

=== Z ===
[[Zeit]]

[[Zenmap]]

[[Ziele einer forensischen Untersuchung nach A. Geschonneck]]

== Interessante Links ==

Tsurugi Forensik-Linux https://tsurugi-linux.org

Abhören von Smarthome-Geräten https://srlabs.de/bites/smart-spies/

== Fernstudiengänge an der Hochschule Wismar (berufsbegleitend) ==

[https://www.wings.hs-wismar.de/de/fernstudium_bachelor/it_forensik IT-Forensik, Bachelor]

[https://www.wings.hs-wismar.de/de/fernstudium_master/it_sicherheit_und_forensik/ IT-Sicherheit und Forensik, Master]

== Starthilfen ==

* Hilfe zur Benutzung und Konfiguration der Wiki-Software finden Sie im [https://www.mediawiki.org/wiki/Special:MyLanguage/Help:Contents Benutzerhandbuch]
* [https://www.mediawiki.org/wiki/Special:MyLanguage/Manual:Configuration_settings Liste der Konfigurationsvariablen]
* [https://www.mediawiki.org/wiki/Special:MyLanguage/Manual:FAQ MediaWiki-FAQ]
* [https://lists.wikimedia.org/mailman/listinfo/mediawiki-announce Mailingliste neuer MediaWiki-Versionen]
* [https://www.mediawiki.org/wiki/Special:MyLanguage/Localisation#Translation_resources Übersetze MediaWiki für deine Sprache]
* [https://www.mediawiki.org/wiki/Special:MyLanguage/Manual:Combating_spam Erfahre, wie du Spam auf deinem Wiki bekämpfen kannst]

Hauptseite

2020-01-26T15:43:07Z

St161253:

Willkommen beim IT-Forensik-Wiki der Hochschule Wismar. Hier werden wesentliche Begriffe zum Thema „Digitale Forensik“ erläutert.

== Literatur ==
test
[[Projektarbeiten]]

[[Abschlussarbeiten im Bachelor Studiengang "IT-Forensik"]]

[[Abschlussarbeiten im Master Studiengang "IT-Sicherheit und Forensik"]]

[[Forensik in DB]]

== Stichworte IT-Forensik ==
=== A ===
[[Angriffe auf Forensik-Software]]

[[Algorithmus]]

[[Anti-Forensik]]

[[Asset Relocation]]

=== B ===
[[Bundesdatenschutzgesetz (BDSG)]]

[[Betriebssystem]]

[[Broken Authentication]]

[[BSI-Vorgehensmodell]]

=== C ===
[[Cache]]

[[CERT-Taxonomie]]

[[Chain of Custody]]

[[Chip-Off]]

[[Computer Sabotage]]

[[Cross Site Scripting (XSS)]]

[[CryptoLocker]]

=== D ===
[[Darknet]]

[[Dateiheader]]

[[Datenanalyse]]

[[Datenbankforensik]]

[[Datenschutz in der IT-Forensik]]

[[Datenvernichtung]]

[[Datensammlung]]

[[DDL & DML]]

[[Deep Web]]

[[Diff]]

[[Digitale Forensik]]

[[DLL (.dll Dateien)]]

[[Dokumentation]]

[[Doxing]]

[[Dual Use Software]]

=== E ===
[[Ermittlungsprozess]] 

[[Exploit]] 

[[Error Based SQL Injection]]

=== F ===
[[File Carving]]

[[Flüchtige Daten]]

[[Forensic Data Mining]]

[[Forensischer Koffer]]

[[Fragmentierung]]

=== G ===
[[Geotag]]

[[GeoIP-Datenbank]]

[[Gerichtsfestigkeit]]

=== H ===
[[Hashwert]]

[[Hilfstatort]]

[[Hardware-Sicherheitsmodul]]

[[Hashcat]]

[[Honeypot]]

=== I ===
[[Image]]

[[Imaging]]

[[Incident-Response-Team]]

[[Indicator of Compromise]]

[[Integrität]]

[[IT-Forensik]]

=== J ===
[[Jailbreak]]

=== K ===

[[Installieren eines Live-Kali-Linux-System auf USB-Stick]]

[[Kausalität in der Forensik]]

[[Korrelation]]

=== L ===
[[Lateral Movement]]

[[Live-Forensik]]

[[Locard'sche Regel]]

[[Log-File]]

=== M ===
[[Magnet Axiom]]

[[Metadaten]]

[[Mobiltelefon-Forensik]]

=== N ===
[[Netflow]]

[[Never-Touch-Original]]

=== O ===
[[Online-Forensik]]

[[Offline-Forensik]]

[[OS Fingerprinting]]

[[OSINT-Werkzeug]]

=== P ===
[[Partition]]

[[P2P (Peer-to-Peer) Software / Netzwerke]]

[[Post-Mortem-Analyse]]

[[Prozess der Mobiltelefon Forensik]]

[[Prüfsumme]]

[[PCMCIA]]

[[Penetrationstest]]

=== R ===
[[Rainbow Table]]

[[Registry]]

[[Remote Access Trojaner (RAT)]]

[[Replay Attack]]

[[Reverse Engineering]]

[[Rootkit]]

=== S ===
[[SAP-Modell]]

[[Sandbox]]

[[Security Information and Event Management (SIEM)]]

[[Skimming]]

[[Slack Space]]

[[Sniffing]]

[[SQL Injection]]

[[SQLite Datenbanken auslesen mittels Python]]

[[Sealbag]]

[[SpiderFoot]]

[[Spuren]]

=== T ===
[[Tatort]]

[[Timeline]]

[[Trugspur]]

=== U ===
[[Unallocated Data (Nicht zugeordnete Daten)]]

=== V ===
[[Verfügbarkeit]]

[[Vertraulichkeit]]

[[Vorsorge für die IT-Forensik]]

[[Video-Forensik]]

=== W ===
[[W-Fragen]]

[[Watering-Holes]]

[[Why-Because-Analyse (WBA)]]

[[Windows-RAM auslesen]]

[[Wiping]]

[[Write Blocker]]

=== X ===
[[Xmount]]

=== Z ===
[[Zeit]]

[[Zenmap]]

[[Ziele einer forensischen Untersuchung nach A. Geschonneck]]

== Interessante Links ==

Tsurugi Forensik-Linux https://tsurugi-linux.org

Abhören von Smarthome-Geräten https://srlabs.de/bites/smart-spies/

== Fernstudiengänge an der Hochschule Wismar (berufsbegleitend) ==

[https://www.wings.hs-wismar.de/de/fernstudium_bachelor/it_forensik IT-Forensik, Bachelor]

[https://www.wings.hs-wismar.de/de/fernstudium_master/it_sicherheit_und_forensik/ IT-Sicherheit und Forensik, Master]

== Starthilfen ==

* Hilfe zur Benutzung und Konfiguration der Wiki-Software finden Sie im [https://www.mediawiki.org/wiki/Special:MyLanguage/Help:Contents Benutzerhandbuch]
* [https://www.mediawiki.org/wiki/Special:MyLanguage/Manual:Configuration_settings Liste der Konfigurationsvariablen]
* [https://www.mediawiki.org/wiki/Special:MyLanguage/Manual:FAQ MediaWiki-FAQ]
* [https://lists.wikimedia.org/mailman/listinfo/mediawiki-announce Mailingliste neuer MediaWiki-Versionen]
* [https://www.mediawiki.org/wiki/Special:MyLanguage/Localisation#Translation_resources Übersetze MediaWiki für deine Sprache]
* [https://www.mediawiki.org/wiki/Special:MyLanguage/Manual:Combating_spam Erfahre, wie du Spam auf deinem Wiki bekämpfen kannst]

Benutzer:St161253

2020-01-26T15:36:58Z

St161253: Test

Dies ist ein Test