Zuverlässigkeit AIDE/Tripwire auf kompromittiertem System?
Hallo, angenommen ein System wurde kompromittiert. Nun wird die (extern gelagerte AIDE/Tripwire) Datenank auf den Rechner überspielt sowie das AIDE/Tripwire Paket neu installiert. Wie verlässlich ist dann der Aufruf innerhalb des kompromittierten Systems? Hintergrund: Einsatz auf einem Webserver. Die verlässlichste Methode: das System über Rettungssystem neu zu starten, die jeweiligen Partitionen Read-Only zu mounten und dann über das Rettungssystem die AIDE/Tripwire Datenbank "drauf los" zu lassen ist dort (da Webserver meist im Rechenzentrum steht und nicht für jedermann zugänglich ist) häufig nicht vernünftig realisierbar. Auch das Spiegeln (bei Ignorieren der Inodes) via rsync oder tar (und nachträgliches, lokales Read-Only mounten über Rettungssystem) erscheint mir in diesem Zusammenhang wenig verlässlich. Wie seht ihr das? Ist Einsatz von AIDE / Tripwire auf einem Webserver verlässlich realisierbar (auch wenn man nicht vor Ort ist) und zu welcher Methodik würdet Ihr greifen? greetinXs, Michael Hilscher -- Would Mozart have been more productive if he had scribes to help him, a secretary and a CEO to lead his way? -- Linus Torvalds
Hy, Am 02/12/25@18:30 schrieb Michael Hilscher:
angenommen ein System wurde kompromittiert. Nun wird die (extern gelagerte AIDE/Tripwire) Datenank auf den Rechner überspielt sowie das AIDE/Tripwire Paket neu installiert. Wie verlässlich ist dann der Aufruf innerhalb des kompromittierten Systems?
Ich denke schon das Du Dich darauf verlassen kannst. Ich kenne zwar aide/tripwire nicht, aber als security tool, sollten sie eigentlich keine anderen tools benoetigen, die Arbeit (md5sum etc.) selbst erledigen und statisch gelinkt sein. -- bye maik
On Wed, 25 Dec 2002 18:30:52 +0100 Michael Hilscher
Hintergrund: Einsatz auf einem Webserver. Die verlässlichste Methode: das System über Rettungssystem neu zu starten, die jeweiligen Partitionen Read-Only zu mounten und dann über das Rettungssystem die AIDE/Tripwire Datenbank "drauf los" zu lassen ist dort (da Webserver meist im Rechenzentrum steht und nicht für jedermann zugänglich ist) häufig nicht vernünftig realisierbar.
Why not? Eine CDROM o.ä. doch überall vorhanden sein.
Wie seht ihr das? Ist Einsatz von AIDE / Tripwire auf einem Webserver verlässlich realisierbar (auch wenn man nicht vor Ort ist) und zu welcher Methodik würdet Ihr greifen?
Tripwire auf einem kompromitierten System _kann_ bedeuten, daß Tripwire vom System gefakte Angaben zu den Dateien geliefert werden. Du kannst ja prinzipiell von CDROM booten, als erstes einen Tripwirecheck fahren (z.B. gegen eine per ftp runtergeladene db), Ergebnisse auf ein externes System schreiben und danach den Webserver regulär von HD booten. Noch besser wäre es wohl, den CDROM-Boot bis zu einer sshd-Initialisierung zu fahren, dieses an ein externes System signalisieren, daß sich dann per ssh einloggt, die tripwire-db scp't und anschließend tripwire-checkt. Danach dann regulärer Webserver-Boot. Gruß, Tobias.
On Sat, Jan 11, 2003 at 03:31:51AM +0100, Tobias Crefeld wrote:
Hintergrund: Einsatz auf einem Webserver. Die verlässlichste Methode: das System über Rettungssystem neu zu starten, die jeweiligen Partitionen Read-Only zu mounten und dann über das Rettungssystem die AIDE/Tripwire Datenbank "drauf los" zu lassen ist dort (da Webserver meist im Rechenzentrum steht und nicht für jedermann zugänglich ist) häufig nicht vernünftig realisierbar.
Why not? Eine CDROM o.ä. doch überall vorhanden sein. Vielleicht bist Du nicht vor Ort, weil der Webserver garnicht in der Firma steht sondern bei XY?
Wie seht ihr das? Ist Einsatz von AIDE / Tripwire auf einem Webserver verlässlich realisierbar (auch wenn man nicht vor Ort ist) und zu welcher Methodik würdet Ihr greifen?
Tripwire auf einem kompromitierten System _kann_ bedeuten, daß Tripwire vom System gefakte Angaben zu den Dateien geliefert werden. Wenn Tripwire neu installiert wird ebenfalls? Ist Tripwire also nicht statisch gelinkt? Oder spielst Du auf "einen Kernel Hack" an?
Du kannst ja prinzipiell von CDROM booten, als erstes einen Tripwirecheck fahren (z.B. gegen eine per ftp runtergeladene db), Ergebnisse auf ein externes System schreiben und danach den Webserver regulär von HD booten. Denkbare Lösung für den Notfall. Jedoch wirst Du bei 1&1, Server 4 Free und Co. kaum jemand finden der Dir eine entsprechende CDROM ins Laufwerk schiebt ...
Noch besser wäre es wohl, den CDROM-Boot bis zu einer sshd-Initialisierung zu fahren, dieses an ein externes System signalisieren, daß sich dann per ssh einloggt, die tripwire-db scp't und anschließend tripwire-checkt. Danach dann regulärer Webserver-Boot. Nicht wirklich. Wie häufig denkst Du denn, dass ein Webserver neu statet? Nein, interessant ist dies nur für den Notfall. Und dann über eine RettungsCD, die auf Wunsch gebootet oder chrooted wird (wobei "Kernel Hacks" dann als Risikoquelle noch verbleiben würden).
greetinXs, Michael Hilscher -- Would Mozart have been more productive if he had scribes to help him, a secretary and a CEO to lead his way? -- Linus Torvalds
Hi, 0n 03/01/11@12:39 Michael Hilscher told me:
On Sat, Jan 11, 2003 at 03:31:51AM +0100, Tobias Crefeld wrote:
Tripwire auf einem kompromitierten System _kann_ bedeuten, daß Tripwire vom System gefakte Angaben zu den Dateien geliefert werden.
Wenn Tripwire neu installiert wird ebenfalls? Ist Tripwire also nicht statisch gelinkt? Oder spielst Du auf "einen Kernel Hack" an?
Tripwire an sich ist wohl statisch, aber ich weiss nicht genau ob es zum Beispiel Systemtools wie md5sum benutzt, die dann Ihrerseits versaut sein koennten. Vielleicht bringt tripwire auch seine eigenen md5sums mit. Falls nicht wuerde ich die md5sum von md5sum ;) sicher wegpacken.
Nicht wirklich. Wie häufig denkst Du denn, dass ein Webserver neu statet? Nein, interessant ist dies nur für den Notfall. Und dann über eine RettungsCD, die auf Wunsch gebootet oder chrooted wird (wobei "Kernel Hacks" dann als Risikoquelle noch verbleiben würden).
Wie meinst Du das mit den kernel-hacks? Auf der RettungsCD? Wenn der ISP mit kompromitierten RettungsCDs arbeitet, ist sicher die IDS Verlaesslichkeit das kleiner Problem ;). -- bye maik
On Sat, 11 Jan 2003 12:39:56 +0100 Michael Hilscher
On Sat, Jan 11, 2003 at 03:31:51AM +0100, Tobias Crefeld wrote:
Wie seht ihr das? Ist Einsatz von AIDE / Tripwire auf einem Webserver verlässlich realisierbar (auch wenn man nicht vor Ort ist) und zu welcher Methodik würdet Ihr greifen?
Tripwire auf einem kompromitierten System _kann_ bedeuten, daß Tripwire vom System gefakte Angaben zu den Dateien geliefert werden. Wenn Tripwire neu installiert wird ebenfalls?
Ja!
Ist Tripwire also nicht statisch gelinkt?
Ist egal.
Oder spielst Du auf "einen Kernel Hack" an?
Ja, natürlich auch! Du weißt nie, ob und wenn ja, welcher Art der Hack ist. Selbst wenn die tripwire-binaries unverändert auf das System gelangen, kann ein Programm installiert sein, daß tripwire die Originaldateien liefert, aber veränderte ausführt.
Du kannst ja prinzipiell von CDROM booten, als erstes einen Tripwirecheck fahren (z.B. gegen eine per ftp runtergeladene db), Ergebnisse auf ein externes System schreiben und danach den Webserver regulär von HD booten. Denkbare Lösung für den Notfall. Jedoch wirst Du bei 1&1, Server 4 Free und Co. kaum jemand finden der Dir eine entsprechende CDROM ins Laufwerk schiebt ...
Erstens ist das selbstverständlich möglich. You get what you pay for. Zweitens kann die CDROM ständig drin sein.
Noch besser wäre es wohl, den CDROM-Boot bis zu einer sshd-Initialisierung zu fahren, dieses an ein externes System signalisieren, daß sich dann per ssh einloggt, die tripwire-db scp't und anschließend tripwire-checkt. Danach dann regulärer Webserver-Boot. Nicht wirklich. Wie häufig denkst Du denn, dass ein Webserver neu statet?
Kommt auf den Betreiber und auf die Häufigkeit der Bugfixes an. Uptime
2 Monate ist üblich.
Nein, interessant ist dies nur für den Notfall. Und dann über
Ja und wann ist der Notfall? Wenn nix mehr geht? Wenn Dein System von anderen ISP wegen Teilnahme an DDOS abgeklemmt wurde? Dann ist es schon lange zu spät.
eine RettungsCD, die auf Wunsch gebootet oder chrooted wird (wobei "Kernel Hacks" dann als Risikoquelle noch verbleiben würden).
Vielleicht solltest Du managed-Webservice buchen. Gruß, Tobias.
On Sun, Jan 12, 2003 at 05:00:26AM +0100, Tobias Crefeld wrote:
Vielleicht solltest Du managed-Webservice buchen. LOL
Ich bin mir sicher, dass ich meine Maschine weit besser warten und kontrollieren kann, als der Service eines Massenhosters. Und eine Managed Maschine ermöglicht Dir (in der Regel nicht) als Root den Rechner so anzupassen wie man das auch braucht. Die Idee mit der RettungsCD auf dem AIDE / Tripwire installiert wird, gefällt mir an sich sehr gut und sollte tatsächlich bei besseren Anbietern auch realisierbar sein. greetinXs, Michael Hilscher -- Would Mozart have been more productive if he had scribes to help him, a secretary and a CEO to lead his way? -- Linus Torvalds
participants (3)
-
Maik Holtkamp -
Michael Hilscher -
Tobias Crefeld