Überlegungen zu chkrootkit und Automatisierung

Jan-Benedict Glaw jbglaw at lug-owl.de
Fri Feb 6 12:12:18 CET 2004


On Fri, 2004-02-06 12:02:44 +0100, Stefan Ulrich Hegner <stefan at hegner-online.de>
wrote in message <1076065363.2721.272.camel at hegi.bogus.heginet.local>:
> 1. Verwendung von geschützten Binaries
> 2. Art des periodischen Aufrufs
> 
> zu 1:
> Sicher ist es eine relativ sichere Methode was die Datenintegrität
> angeht die binaries von chkrootkit und der benötigten anderen Progs
> (awk, cut, echo, egrep, find, head, id, ls, netstat, ps, strings, sed,
> uname) auf eine CD zu backen und die im Rechner zu lassen.
> 
> Hier kann ein potentieller Angreifer zwar nicht die Binaries verändern.
> - Er könnte aber am den Mountpoint was anderes hängen mit korrupten
> Binaries.

Schlimmer - er könnte ein Kernel-Modul installieren, daß "ls" immer
abfängt (egal, ob Du "ls" oder "/mnt/cdrom/known_good_binaries/ls"
eingibst) und seine Version davon ausführt.

> ... Ist also auch nicht sooooo sicher. Außerdem wär' es mir lieber statt

Es ist nicht sicher. Er kann's so subtil machen, daß Du nichts merkst:)

> ein CD Laufwerk zu blockieren, das irgendwie anders zu regeln. Nur wenn
> ich USB-Sticks verwende oder die Dateien doch irgendwo auf einer Platte
> im Filesystem habe kann ich mir bezügl. der Datenintegrität nicht so
> sicher sein.

Du hast keine "sicheren" Binaries. Nirgends.

> Mich würd' interessieren, ob von Euch sich hierzu schon mal Gedanken
> gemacht hat und zu passablen Ergebnissen gekommen ist.

Dagegen hilft nur, immer sofort Security-Updates einzuspielen und nichts
laufen zu lassen, was nicht absolut notwendig ist.

> zu 2:
> Sicher ist es das einfachste, den Aufruf von chkrootkit über cron zu
> machen. - Nur wenn ich der Angreifer wäre, wär die crontab eine der
> Dateien, die ich mir relativ zuerst anschauen würde. Und wenn dort
> (direkt oder über ein shellscript) chkrootkit aufgerufen würde wär das
> etwas, woran ich zuerst "arbeiten" würde. Ob das crontab eines
> nichtprivilegierten Users da so viel besser ist ... weiß nicht. Auch der
> at-daemon scheint keine wirkliche Alternative zu sein.

chkrootkit kann man bestimmt hintergehen:)

> Mit meinem derzeitigen Erkenntnisstand würde ich die Sache vermutlich so
> angehen: 
> - binaries in ein loop-fs container packen, den mit gpg signen

Bringt Dir nur sehr begrenzt etwas...

> - ein script mit "harmlosem Namen" basteln welches die Integrität des
> containers mittels gpg prüft ihn als loop-fs mountet und dann chkrootkit
> anstubst und die Ergebnisse in eine Mail packt

Security by obscurity.

> - dieses script vom root-crontab (wg. mount - ich will nix in die fstab
> eintragen müssen) aus aufrufen, getarnt mit ein paar unverfänglichen
> Kommentaren 

Dito.

> ... wirklich "wasserdicht" ist das sicher nicht ... aber eine wesentlich

ACK.


> ... schreibt mir doch mal, wie Ihr sowas anpackt!

Schneller sein :)

MfG, JBG

-- 
   Jan-Benedict Glaw       jbglaw at lug-owl.de    . +49-172-7608481
   "Eine Freie Meinung in  einem Freien Kopf    | Gegen Zensur | Gegen Krieg
    fuer einen Freien Staat voll Freier Bürger" | im Internet! |   im Irak!
   ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lug-owl.de/pipermail/linux/attachments/20040206/d53f1109/attachment.sig>


More information about the Linux mailing list