README zur Benutzung des Linux Live Response Toolkits
======================================================
Das Linux Live Response Toolkit ist zur Sicherstellung der volatilen
Daten eines eingeschalteten Linux-Rechners mit x86-Prozessor unter den
Kernel-Versionen 2.4 und 2.6 gedacht.
Das Ziel des Toolkits ist:
(a) Konzentration auf die rein volatilen Daten (Speicher)
(b) Möglichst wenig Veraenderungen an den Festplattendaten.
Diese Vorgehensweise ergibt nur dann einen Sinn, wenn die Festplattendaten
nach der Aufnahme einer Offline-Analyse zur Verfuegung stehen, d.h. wenn
die Platte nach einem harten Abschalten roh ausgelesen werden kann.
Generelle Verfahrensweise:
– Mounten des Read-Only-Mediums mit dem LLR (CD,DVD, oder USB-Stick)
Dies kann nur mit Bordmitteln des kompromittierten Systems geschehen.
=> Gewnügend Speicherplatz auf dem Aufnahmemedium oder Remote-Rechner
bereithalten – Faustregel: 3 x Arbeitsspeicher
=> Richtiges Filesystem verwenden: FAT32 (USB-Sticks) kann nur Files bis
4GB. Für externe Datentraeger eignet sich am besten ext2/ext3, das
problemlos auch unter Windows lesbar ist.
– Starten der gesicherten Umgebung („start-2.6.sh“ oder „start-2.4.sh“,
je nach Linux-Kernel-Version) als „root“. Das Script startet die
mitgelieferte statisch gelinkte Shell (BASH) mit einem gesaeubertem
„Environment“ und ohne das versehentlich Dateien des Systems gelesen
oder geschrieben werden (z.B. „.profile“, „.bashrc“, „/etc/profile“,
„~/.bash_history“ usw.).
– Aufnahme der Daten mit Hilfe des Scripts „llr.sh“
Die Daten sollten moeglichst ueber Netz (TCP) auf einen anderen Rechner
geschrieben werden, um keine schreibbaren Datentraeger einhaengen zu
muessen und moeglichst wenig im Speicher zu aendern.
Die Daten koennen auch in einer Datei auf einem in das Filesystem
eingehaengten externen Datentraeger (USB-Stick) geschrieben
werden.
– Notfalls koennen haendische Untersuchungen mit Hilfe der statisch
gelinkten Shells und den mitgelieferten Binaries ausgefuehrt werden.
– Nach Aufnahme der Daten sollte der Rechner hart abgeschaltet werden
(Netzstecker ziehen!).
Keinesfalls sollte er per „shutdown“ heruntergefahren werden – eventuell
loest der „Power“-Knopf einen geregelten Shutdown aus.
Danach kann dann ein Abzug der Festplatte „offline“ erstellt werden
(d.h. durch Ausbau und Lesen durch ein Dritt-System ueber eine
Schreibsperre bzw. notfalls online durch Booten von einem externen
Medium).
– Erzeugen der Checksumme (sha256sum) nicht vergessen, wenn das Log auf
einem Remote-Rechner liegt.
WARNUNG
========
Gerade das Auslesen des Kernel- und Prozess-Speichers ist ein Prozess, der
nicht immer einfach funktioniert und das System in seltenen Faellen zum
Absturz bringen kann. Wenn moeglich, sollte das Script an einem gleichartigen
System vorher getestet werden.
Bei dem Auslesen des Prozess-Speichers kommen zwangslaeufig viele Fehler-
meldungen zusammen, da prinzipiell nicht auf alle Daten zugegriffen werden
kann (s.u.).
– Kernel-Speicher (/dev/mem)
Unter Linux 2.6 wird es im allgemeinen nur moeglich sein, das 1. Megabyte
an physischem Speicher auszulesen (wenn ueberhaupt). Insbesondere bei
XEN-Kernel sollte mit Vorsicht gearbeitet werden – dort ist es bei Tests
in einigen Faellen zum Systemabsturz gekommen. Hier empfiehlt sich die
Option „kmemlast“, der den Dump des Kernel-Speichers an das Ende verlegt.
Leider werden zu diesem Zeitpunkt bereits viele urspruengliche Daten
verloren sein.
– Prozess-Speicher
Das Script benutzt fuer die Ausgabe des Prozess-Speichers standardmaessig den
„Process Dumper“ von Tobias Klein
(http://www.trapkit.de/research/forensic/pd/).
Wahlweise kann auch das Tool „pcat“ aus dem Coroners Toolkit TCT
(http://www.porcupine.org/forensics/tct.html) genutzt werden.
Unabhaengig vom Tool ist das Auslesen des Prozess-Speichers eine langwierige
Angelegenheit, bei der verschiedene Fehler auftreten koennen (und werden):
– Prozesse, die bereits mit PTRACE getraced werden, koennen nicht ausgelesen
werden.
РSystemprozesse, die komplett im Kernel laufen, k̦nnen nicht ausgelesen
werden.
– Diese beiden Punkte fuehren zu einer hohen Anzahl von Fehlermeldungen
beim Ausfuehren des Scripts – das ist normal.
– Wenn kein Zugriff ueber /proc/pid/mem verfuegbar ist, werden die Prozesse
mittels PTRACE angehalten – dies kann bei X-Servern in seltenen Faellen zum
Absturz fuehren.
Der „Process Dumper“ hat gegenueber „pcat“ den Vorteil, das es die Meta-Daten
zum Prozess in einem maschinenlesbaren Format mit abspeichert und so eine
einfache Auswertung erlaubt. Die Auswertung des Prozessspeichers kann
allerdings nur mit dem Windows-basierten „Memory Parser (MMP)“ vom selben
Autor erfolgen (URL siehe oben).
Was wird auf dem Zielsystem geaendert?
=======================================
Jede Untersuchung hinterlaesst eigene Spuren,
Vom Linux Live Response Script werden nur die minimal noetigen Dateien auf dem
zu untersuchenden Host-System angefasst. Das Script liest oder schreibt in
keine weiteren Dateien (virtuell oder echt) auf dem Zielsystem (nicht einmal
/dev/null).
Benoetigte „Dateien“ (hauptsaechlich das /proc-Filesystem):
/proc Ohne das /proc-Filesystem koennen praktisch keine
relevanten Daten aufgenommen werden.
Sollte das /proc-Filesystem nicht eingehaengt sein, kann
es mit folgendem Befehl gemountet werden:
# mount -n -t proc none /proc
/dev/mem Diese Device bietet Zugriff auf den physischen Speicher
des Systems. Wenn es nicht existiert, fehlt der Speicher-
auszug (unkritisch). Auf einigen 2.6-Systemen kann sowieso
nur das erste Megabyte des Speicher gelesen werden.
Speicherdumps der einzelnen Prozesse sind trotzdem
moeglich.
Gelesene „echte“ Dateien:
/etc/passwd Diese Dateien werden fuer die User-Zuordnung und die
/var/run/utmp Liste der letzten Logins sowie gerade angemeldeten
/var/log/wtmp Benutzer benoetigt.
Bestandteile:
==============
llr.sh Live-Response-Script zur Aufnahme volatiler Daten
auf dem Zielrechner vor dem Abschalten.
Nimmt die volatilen Daten auf dem System auf und schreibt
die Ergebnisse ueber TCP an den angegebenen Host oder in
eine lokale Ausgabedatei. Die Ausgabedatei sollte
unbedingt auf einem externen Medium mit genuegend
Speicherplatz liegen. Der Speicherbedarf liegt bei
ca. 1-3 x (RAM-Groesse) des zu untersuchenden Rechners.
Aufruf (wenn bereits die statische Bash von der CD
laeuft):
./llr.sh (host) (port)
./llr.sh (ausgabedatei)
Aufruf (wenn die Host-Shell laeuft):
bin-x86-2.6/bash ./llr.sh (host) (port)
bin-x86-2.6/bash ./llr.sh (ausgabedatei)
Fuer die Ausgabe auf einem externen Host sollte auf diesem
ein Netcat gestartet werden:
nc -l [-p] (port) > (ausgabedatei)
oder
nc -l [-p] (port) | tee (ausgabedatei)
Nach der Ausfuehrung des Befehls sollte unbedingt SOFORT
eine Checksumme erstellt werden:
sha256sum (ausgabedatei) > (ausgabedatei).sha256sum
Bei der Speicherung in einer Datei wird diese Checksumme
automatisch erzeugt.
start-2.4.sh Startet interaktive „bash“ mit dem Pfad
start-2.6.sh „./bin-x86-2.X/bash“. Ignoriert Startup-Dateien
.bashinit (/etc/profile, ~/.bashrc usw.) und vermeidet das Schreiben
der Bash-History in das Home-Directory.
bin-x86-2.4/ Verzeichnis mit statischen Binaries fuer Linux-Systeme
mit 2.4.x-Kernel auf x86-Plattformen.
Die Binaries laufen groesstenteils auch mit hoeheren
Kernel-Versionen.
bin-x86-2.6/ Verzeichnis mit statischen Binaries fuer Linux-Systeme
mit 2.6.x-Kernel auf x86-Plattformen.
tools/ Mit llr-extract.pl wird der lesbare HTML-Report erzeugt.
llr-extract.pl und die Memory Dumps werden als Datei herausgeschrieben.
Aufruf:
…/extract.pl (logdatei)
Aus den Logdaten wird ein HTML-Report unter dem Namen
(logdatei).html erzeugt. Alle im Log enthaltenen Dateien
(Memory Dumps) werden im Verzeichnis (logdatei).d abgelegt
und sind im HTML-Report verlinkt.
Das Script ueberschreibt keine Dateien, sondern bricht ab,
falls Dateien gleichen Namens bereits vorliegen.
Beispiel
=========
Beispiel fuer einen Rechner mit Linux 2.6-Kernel, bei dem die Daten auf
den Logrechner mit der IP 10.2.2.2 auf Port 3333 geschrieben werden sollen.
Auf dem zu untersuchenden Rechner:
1. CD-ROM-Mounten
Dies geht nur mit dem Systembefehlen des zu untersuchenden Systems bzw.
per Automount.
> # mount -r -n /dev/xxx /mnt/cdrom
2. Starten der statischen Shell:
> # cd /..<pfad zum cdrom>../llr
> # ./start-2.6.sh
== BASH: /mnt/cdrom/llr/bin-x86-2.6/bash
== HOME: /mnt/cdrom/llr/
== PATH: /mnt/cdrom/llr/bin-x86-2.6
bin-x86-2.6/bash ~ # _
Nun steht eine statisch gelinkte Bash zur Verfuegung, die nur Binaries
aus dem entsprechenden Pfad auf der CD benutzt. Ab jetzt werden keine
Dateien auf dem zu untersuchenden System benutzt.
3. Starten des Scripts
> bin-x86-2.6/bash ~ # ./llr.sh 10.2.2.2 3333
=== Start of llr.sh Version 0.4 $Revision: 1.18 $
Available options:
checksum Checksum every external command with ’sha256sum -b‘ (which is
also external) before running it.
date Run ‚date‘ before every command to log exact start times. If
not set, only start and end times of the script will be logged.
kmem Dump kernel memory from /dev/kmem (may not work, may only dump
the first Mbyte, may in rare cases hang the system)
kmemlast The kernel memory dump may hang in rare cases, until now only
seen on XEN kernels. With this option, it is executed last. Use
with XEN kernels.
procmem Dump process memory. Takes a long time. May hang in rare cases
if executed under X11.
pcat Use pcat (from The Coroners Toolkit) instead of pd (process
dumper from trapkit.de)
Current options: >checksum date procmem kmem<
> Enter option to toggle or press enter to continue>
4. Optionen waehlen
Optionen koennen an- und abgewaehlt werden, indem ihr Name eingegeben wird.
Abschliessen mit <Enter>
=== Start of llr.sh Version 0.4 $Revision: 1.18 $
=== CMD: ./llr.sh 10.2.2.2 3333
=== BASH: /mnt/cdrom/llr/bin-x86-2.6/bash
=== PATH: /mnt/cdrom/llr/bin-x86-2.6
=== SCRIPTDIR: ./
=== OPTIONS: checksum date procmem kmem
=== OUTPUT: remote /dev/tcp/10.2.2.2/3333
Start TCP listener on target host 10.2.2.2 port 3333:
e.g.: # nc -l [-p] 3333 | tee logfile.out
Press Enter to start>
Auf dem Logrechner:
4. Starten des Netcat-Kommandos:
> $ nc -l 3333 > logfile.out
Hinweis: Es gibt zwei Versionen des Netcat-Kommands, eine benoetigt fuer
den Port die Option „-p“, die andere kennt diese Option nicht.
Vorher ausprobieren!
5. Nach erfolgreichem Lauf: Checksumme erzeugen!
> $ sha256sum logfile.out > logfile.out.sha256sum
6. Mit dem Perl-Script „tools/llr-extract.pl“ wird dann ein HTML-Report aus
dem Log erzeugt.
> $ …/extract.pl logfile.out
Alle Memory Dumps und Binaerdateien werden herausgeschrieben und sind
im HTML-Report verlinkt.
Hinweis zur Auswertung
=======================
Die HTML-Ausgabe ist relativ einfach und funktioniert zumindest mit Firefox,
Mozilla und Safari, im Internet-Explorer nur mit Abstrichen in der Navigation.
Das Script benutzt fuer die Ausgabe des Prozess-Speichers standardmaessig den
„Process Dumper“ von Tobias Klein (http://www.trapkit.de/research/forensic/pd/).
Wahlweise kann auch das Tool „pcat“ aus dem Coroners Toolkit TCT
(http://www.porcupine.org/forensics/tct.html) genutzt werden.
Updates
========
http://computer-forensik.org/tools/ix
http://ewers.net/llr
Enno Ewers 2008/08