Kernel - Änderungen erkennen

[Los_Andros]

Hallo zusammen,
ich habe hier eine einfach klingende Anforderung:

Prüfung auf Veränderungen des Kernels (Kerneldatei)
Prüfung der Veränderungen der Kernelmodule (Moduldateien)

Wir haben dafür eine Art Monitor gebaut, der uns alle sin eine MYsql Datenbank schreibt und wir dann mit "Soll-Werten" vergleichen.


Mit den beiden Anforderungen tue ich mich aber schwer, besonders, wenn man es gescheit machen will.

Weil:
Wie bekomme ich vernünftig raus, welche Kerneldatei zum aktuell laufenden Kernel gehört? Sie liegen zwar "gewöhnlich" unter /boot und heißen so wie der Kernel, aber wenn jemand einen veränderten Kernel irgendwo ablegt und dann per grub den neuen Kernel lädt, läßt sich dies kaum feststellen.

Hat da jemand eine Idee?


Genauso verhält es sich mit den Kernel-Modulen. "lsmod" liefert mir zwar die Kernelmodule, aber nicht welche (vollqualifizierter Pfad) er wirklich verwendet.



Für Anregungen bin ich dankbar, ich tappe etwas auf der grünen Wiese.

[psy]

Schau dir doch mal Tripwire (http://sourceforge.net/projects/tripwire/) an.

[Los_Andros]

das kenne ich schon, ich nutze aide dafür, aber grundsätzlich weiß ich ja nicht welche Kerneldatei geladen wurde, das ist mein Problem. Wie bekomme ich das heraus?

Es könnte ja wie erwähnt jemand einfach einen anderen Kernel mit der selben Kernel-Versions-Nummer starten, der aber modifiziert ist.

[zyrusthc]

... aber grundsätzlich weiß ich ja nicht welche Kerneldatei geladen wurde, das ist mein Problem. Wie bekomme ich das heraus?.
Mit modinfo bekommste das raus:

modinfo aes
filename: /lib/modules/2.6.17-14mdv/kernel/crypto/aes.ko.gz
description: Rijndael (AES) Cipher Algorithm
license: Dual BSD/GPL
vermagic: 2.6.17-14mdv SMP mod_unload 686 gcc-4.1
depends:


Greeez Oli

[psy]

Es könnte ja wie erwähnt jemand einfach einen anderen Kernel mit der selben Kernel-Versions-Nummer starten, der aber modifiziert ist.

Ne, kann er nicht, Tripwire würde das ja anhand der veränderten Prüfsumme merken.
Oder versteh ich gerade nicht was du willst?

[Los_Andros]

@oli
danke, das hilft mir bei den Module, cool

@psy
ja klar, tripwire erkennt, dass beispielsweise /boot/vmlinuz-2.6.18-53 verändert wurde. Tripwire erkennt aber nicht ob dieser Kernel überhaupt geladen wurde. Per Grub kann ich auch einfach /home/haumichtot/mein-gehackter-kernel-2.6.18-53 booten.

Das würde tripwire nicht merken.

Ich würde gerne wissen, welche Kerneldatei bei diesem Bootvorgang aktiv war und ob der Hashwert mit meinem Soll übereinstimmt. Dafür kann man dann wieder tripwire hernehmen, aber für das Feststellen welche Kerneldatei zum Booten verwendet wurde habe ich noch keinen Weg gefunden.

[403]

Als Kruecke koennte man sicherlich eine Checksumme von /proc/cmdline machen und
Bootpasswoerter verwenden. Letzteres involviert dann immer lokalen Zugriff :rolleyes:

Besser:
Du muesstest eine individuelle Aenderung am gestarteten Kernel vornehmen, den gebooteten Kernel im Speicher suchen, und dort Deine Aenderung finden. Das Problem:
Wie kann man diese Aenderung vor einem Angreifer 'verstecken'? Eigenes Kernel Modul bauen?

Wenn du den Kernel von einem read-only medium startest und irgendwie den Bootpfad
(via proc?) hinterlegen kannst sollte man relativ sicher sein. Dann schaust du nach, ob
der Kernel via diesem Bootpfad gestartet wurde.

[Los_Andros]

Hmmmmm, also das mit /proc/cmdline ist schonmal ein Anfang,
vielleicht kann man über grub noch ein wenig mehr erfahren.

Ganz gefällt mir das aber noch nicht.

Trotzdem schonmal danke

[Los_Andros]

tja ..... hab da sogar was gefunden.
cat /proc/kcore |grep --binary-file=text `uname -r`

liefert eine MEnge, unter anderem auch das entsprechende File in /boot/ welches gestartet wurde.

Aber ist halt binärewr Schrott dazwischen. Die Informationen stehen aber also im Speicher, ich müsste die jetzt nur gezielt auslesen. Hat da jemand eine Idee wie das geht? Wie könnte ich gezielt Infos aus /proc/kcore, also dem Speicher herausziehen?

[403]

naja grep -f sucht nach fixen Strings. Aber hat man denn das Kriterium dass der Speicher nach Reboot vollstaendig ueberschrieben wird? (Ich habe mal gehoert, dass nein) Was nuetzt es wenn du einmal den richtigen Kernel gestartet hast und diese 'Spur' sich im Speicher befindet?!

Man braucht den passenden Timestamp. Vielleicht kann man das Datum einfach am Bootprompt von Grub mituebergeben? Bei lilo war das jedenfalls so dass den Kernel irgendwelche foo=bar Variablen nicht gestoert haben ;)

Wenn die Standard Tools versagen musst du dich wohl durch Memory Management durcharbeiten:
Understanding_the_Linux_Virtual_Memory_Manager_gor man_book.pdf

Gruss
403

EDIT: Dein obiger Ausdruck findet immer den schon gestarteten Kernel, oder?

[403]

Wie weit bist du denn gekommen? Gibts was neues?

[Los_Andros]

Naja, es gibt keinen direkten Weg, leider.
Ich habe es wie schon oben angedacht gelöst.

- Boot Passwort (grub md5 Passwort), das verhindert, dass beim Booten eine andere Kerneldatei ausgewählt werden kann, als die eingetragenen

- auditd so konfiguriert, dass Zugriffe auf /etc/grub.conf und /boot/grub/menu.lst audit-logs erzeugen. Damit registriert man jede Änderung an der grub Konfiguration (falls jemand das Boot Passwort entfernen will)

- aide (vgl. tripwire) so konfiguriert, dass Änderungen an den oben genannten Dateien gelogt werden. Damit bekomme ich einen Checksummen-Vergleich, nur als Zusatz zum audit.log

- auditd und aide auf die in /boot/grub/menu.lst eingetragenen Kerneldateien. Damit bekomme ich zum Einen Änderungen (Zugriffe auf die Kerneldatei) und eine Veränderung an sich (andere Checksumme der Kerneldatei) mit.

Bin gerade dabei etwas tiefer in die selinux und apparmor Welt einzusteigen. Darüber könnte man den Zugriff auf die Kerneldateien nochmal zusätzlich absichern, so dass auch der root User nicht einfach Zugriff auf die Dateien bekommt. Das kommt aber noch (wenn ich etwas Zeit habe).


p.s. das greppen auf vmcore hat nur unter meinem opensuse hier funktioniert, auf einem rhel oder centos leider nicht.