Memory Dump erstellen und analysieren

[sysrq]

Bevor ich mir meinen ersten Root-Server kaufe, möchte ich mir Pläne/Prozesse zurecht legen, die ich abarbeiten kann wenn es zu einer Ausnahmesituation kommt. Eine solche Ausnahmesituation wäre es z.B. wenn eine fremde Person einen root account auf dem Server erstellen konnte, oder aber wenn mein Rechner Spam verschicken würde.
Das schlimmste wäre es wenn ein solcher Fall eintritt, ich in Panik gerate und nicht weiß was ich tun soll.

In einigen 'Hilfe ich wurde gehackt'-Threads wird ja empfohlen einen memory dump vom Hauptspeicher, und ein mage dump von der Festplatte zu erstellen. Und das möglichst bevor der Rechner neugestartet oder heruntergefahren wurde. Dann kann damit der Angriff analysiert werden und beim nächsten Aufsetzen des Systems entsprechend besser konfiguriert werden.

Die Theorie hört sich plausibel, richtig und gut an. Nun sitze ich vor meiner Linux-Maschine und wollte das alles mal üben. Aber leider weiß ich nicht wie das in der Praxis aussieht. Daher meine Fragen:
1. Wie erstelle ich ein memory dump und ein image dump? Was muss ich berücksichtigen?
2. Wie sieht eine Analyse aus? Wie ist das Vorgehen, welche Tools gibt es? Vor allem wie das beim memory dump aussieht.

Ich habe auch Probleme zu verstehen wie überhaupt ein memory dump erstellt werden kann. Der Hauptspeicher wird ja ständig verwendet und laufend verändert durch read und write Operationen. Wie ist es also in einer solchen Umgebung möglich einen snapshot/dump der Hauptspeichers zu erstellen? Werden dazu etwa alle laufenden Prozesse, und Threads in diesen Prozessen, kurz eingefroren um ein konsistentes Hauptspeicherabbild erstellen zu können?

Im /proc und den einzelnen /proc/<prozess_id>/ Ordner befinden sich ja sehr viele Informationen zu laufenden Prozessen. Werden diese Informationen bei einem memory dump auch gesichert bzw. erhält ein memory dump äquivalente Informationen? Oder ist es sogar notwendig den Inhalt von /proc einmal komplett auszulesen, damit keine wichtigen Informationen verloren gehen?

[daemotron]

Lies Dir mal http://www.kernel.org/doc/man-pages/onl ... mem.4.html durch - vielleicht hilft Dir das bei der Frage zum Memory Dump weiter...

http://linux.die.net/man/1/dd und http://www.kernel.org/doc/man-pages/onl ... /sd.4.html sind aufschlussreich, wenn es um die Erstellung von Festplatten-Images geht.

[sysrq]

Nun sitze ich vor meiner Linux-Kiste und wollte einen memory dump von /dev/mem erstellen, aber ich stecke fest wegen einem 'Operation not permitted'. Und das ist der Hintergrund:

Habe ein wenig recherchiert. Viele Distributionen unterdrücken das Lesen von /dev/mem um das System vor rootkit Attacken zu schützen. Dazu zählen wohl auch Debian und Ubuntu:
https://wiki.ubuntu.com/Security/Featur ... protection
http://forums.anandtech.com/showthread.php?t=2035534

Erreicht wird dies CONFIG_STRICT_DEVMEM, einer neuen Option für den Kernel, die wohl schon zur compile time gesetzt wird, und daher während dem laufenden Betrieb nicht mehr angepasst werden kann.

Tja, so wie es aussieht muss man sich entscheiden:
1. Die Möglichkeit ein memory dump zu machen, aber Gefahr zu laufen, dass ein rootkit /dev/mem ausnutzt
2. /dev/mem mit CONFIG_STRICT_DEVMEM absichern, aber dafür kann man dann keine memory dumps mehr erstellen

Ich denke ich entscheide mich für 2., da ich ein System möglichst absichern möchte.

Lies Dir mal http://www.kernel.org/doc/man-pages/onl ... mem.4.html durch - vielleicht hilft Dir das bei der Frage zum Memory Dump weiter...

Danke für den Link jfreund, auch wenn schon etwas verstaubt, da es von 1992 ist.
Sehe ich es richtig, dass du auf FreeBSD setzt jfreund? Wenn ja, hast du wahrscheinlich nicht das 'Problem' mit CONFIG_STRICT_DEVMEM, oder? Wobei man ja hier eher weniger von einem Problem, sondern eher von einem sinnvollen Sicherheitsfeature reden sollte.


Das ist jetzt aber ein Dilemma. Was wenn mein Server wirklich ein gehackt wird und ich möglichst viele Informationen zusammentragen muss, um zukünftige Angriffe zu verhinder? Einen memory dump kann ich nun vergessen. Dieser scheint aber sehr wichtig zu sein, da ich diesen Rat bei so gut wie jedem 'Hilfe, ich wurde gehackt'-Thread gelesen habe.

Was kann ich jetzt tun? Wo soll ich mir die nötigen Informationen zusammensuchen? Oder wird die Bedeutung eines memory dump sogar überschätzt? Ist die Analyse eines memory dump überhaupt effizient durchführbar, und bringt es erheblich mehr im Vergleich zu anderen log files etc.? Ich habe leider noch nie einen memory dump analysiert, und mir fehlt daher die Erfahrung für eine objektive Meinung.

[daemotron]

Tja, so wie es aussieht muss man sich entscheiden:
1. Die Möglichkeit ein memory dump zu machen, aber Gefahr zu laufen, dass ein rootkit /dev/mem ausnutzt
2. /dev/mem mit CONFIG_STRICT_DEVMEM absichern, aber dafür kann man dann keine memory dumps mehr erstellen

Ich denke ich entscheide mich für 2., da ich ein System möglichst absichern möchte.

Die Entscheidung kann ich nur unterstützen - mit einem Memory Dump können nur geübte Forensiker etwas anfangen, und bei den heutigen RAM-Größen wird es zunehmends schwierig, überhaupt etwas sinnvolles aus einem Memdump zu extrahieren. Die meisten Exploits (Buffer Overflow oder Format String) manifestieren sich nur mit einigen wenigen Bytes, und um die zu finden, muss man abgrenzen können, wofür welcher Speicherbereich jeweils gerade genutzt wurde.

Lies Dir mal http://www.kernel.org/doc/man-pages/onl ... mem.4.html durch - vielleicht hilft Dir das bei der Frage zum Memory Dump weiter...

Danke für den Link jfreund, auch wenn schon etwas verstaubt, da es von 1992 ist.

Tja, das ist nunmal die aktuelle Man Page zu /dev/mem - die wurde seit damals nicht mehr angepackt. Probier's mal aus und gib auf einem Linux-System 'man mem' ein

Sehe ich es richtig, dass du auf FreeBSD setzt jfreund? Wenn ja, hast du wahrscheinlich nicht das 'Problem' mit CONFIG_STRICT_DEVMEM, oder? Wobei man ja hier eher weniger von einem Problem, sondern eher von einem sinnvollen Sicherheitsfeature reden sollte.

Korrekt. Meine Server laufen mit FreeBSD, und dort gibt es besagte Kernel-Option nicht (dafür andere Mechanismen, wenn man denn möchte).

Das ist jetzt aber ein Dilemma. Was wenn mein Server wirklich ein gehackt wird und ich möglichst viele Informationen zusammentragen muss, um zukünftige Angriffe zu verhinder? Einen memory dump kann ich nun vergessen. Dieser scheint aber sehr wichtig zu sein, da ich diesen Rat bei so gut wie jedem 'Hilfe, ich wurde gehackt'-Thread gelesen habe.

Wie schon gesagt - ein Memory Dump ist für Forensiker interessant. Wenn Du nach einem Hack z. B. Strafverfolgungsbehörden hinzuziehen möchtest, könnte ein Memory Dump interessant sein. Allerdings haben Memory Dumps im Laufe der Zeit auch an Relevanz eingebüßt. Früher wurden Server fast ausschließlich durch Schwachstellen in Anwendungen gehackt, die in kompilierter Form vorlagen. Solchen Einbrüchen kommt man mit Memdumps noch auf die Schliche. Heute dominieren aber Angriffe auf in Skriptsprachen verfasste Programme (PHP, Perl, Python & Co). Meist geht es dabei nicht um Speichermanipulation, sondern um Ausnutzung von Programmierfehlern auf viel höherer Ebene (SQL injection, X-Site Scripting, ...). Im Speicherabbild würde man nur erkennen, dass der Interpreter richtig gearbeitet hat - dass er ein inhaltlich "falsches" Skript dabei ausgeführt hat, kann man aus einem Memdump so gut wie gar nicht herauslesen.

Was kann ich jetzt tun? Wo soll ich mir die nötigen Informationen zusammensuchen? Oder wird die Bedeutung eines memory dump sogar überschätzt? Ist die Analyse eines memory dump überhaupt effizient durchführbar, und bringt es erheblich mehr im Vergleich zu anderen log files etc.? Ich habe leider noch nie einen memory dump analysiert, und mir fehlt daher die Erfahrung für eine objektive Meinung.

Wichtiger als ein Memory Dump sind intakte Logfiles - häufig rotieren, vor unbefugten Zugriffen schützen, wenn möglich an eine zweite Maschine übertragen - und natürlich sehr regelmäßig kontrollieren, damit man einen gerade stattfindenden Angriff überhaupt bemerkt. Darüber hinaus ist es hilfreich, eine Liste mit Checksummen aller Dateien auf dem System zu führen (natürlich außerhalb aufbewahren) und diese regelmäßig abzugleichen - auch das ist ein guter Weg, um Manipulationen auf die Schliche zu kommen.