Ü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