Re: Prüfsummenüberwachung für

From: Marc Santhoff <M.Santhoff(at)web.de>
Date: Sat, 05 Sep 2015 18:31:55 +0200

On Sa, 2015-09-05 at 17:38 +0200, Oliver Fromme wrote:
> Hi Marc,

Hallo Olli,

> Marc Santhoff wrote:
> > Ich möchte auf einem Rechner den unveränderlichen Teil der Systemdateien
> > gegen Veränderung schützen bzw. wenigstens gewarnt werden.
>
> Dazu muss man sich zuerst überlegen, wogegen man sich damit
> absichern möchte. Dateimodifikationen können verschiedene
> Ursachen haben:

ja, Dateisystem gegen fehlerhafte Programme absichern.

> - Versehentliche Änderungen, d.h. man selbst (als Admin) oder
> ein Amok-laufendes Programm hat irgendwelche Dateien
> überschrieben oder gelöscht. Dazu gehören natürlich auch
> Änderungen von Metadaten, z.B. ein versehentliches chmod -r
> an der falschen Stelle kann großen Schaden anrichten.
>
> - Änderungen durch Hardwaredefekte, z.B. die berüchtigten
> "gekippten Bits" auf der Festplatte oder im RAM.
>
> - Änderungen, die auf Einwirkungen durch Hacker zurückzuführen
> sind, d.h. ausgetauschte Binaries mit Backdoor, Root-Kits,
> modifizierte Konfigurationsdateien und/oder Permissions usw.
>
> Danach richten sich dann auch die Maßnahmen. Um z.B. Hacker
> abzuwehren, muss man mehr Aufwand treiben: Die Prüfsummen
> sollten kryptographisch sicher sein und auf einem sicheren,
> schreibgeschützten Medium abgelegt werden.

Nein. Obwohl Punkt eins intressant wird, wenn man mit Jails rumhantiert,
da habe ich mir auch schon mittels Symlinks in den Fuß geschossen.

> Will man sich dagegen nur gegen Tippfehler oder Defekte
> absichern, genügen auch "old school" MD5-Checks, die nicht
> speziell gesichert sein müssen.

Genau.

> Last but not least muss man natürlich auch ein verlässliches
> und sicheres Backup haben. Denn es genügt ja nicht, wenn man
> Änderungen feststellen kann. Man muss dann auch in der Lage
> sein, die Originaldateien wiederherzustellen.

Ist gegeben, doppelt extern. Sogar mir regelmäßiger örtlicher
Auslagerung.

> > Nachdem neulich gdb zweimal sehr hart gegen die Wand gefahren ist und
> > die Dateisysteme diverse Schäden hatten, sollen als Sicherheitsgurt
> > Prüfsumme von /, /usr und /usr/local jeweils ohne ./etc und home
> > erstellt werden. Das bedeutet, daß beim Einschalten des Rechners
> > und/oder immer nach Änderungen (ports installieren z.B.) die Prüfsummen
> > ermittelt und überprüft werden müssen. Außerdem muß man natürlich nach
> > Ereignissen wie spontanem reboot nochmal gezielt prüfen können.
>
> Ein einfaches Programm für solche Prüfsummen findet man bereits
> im Basis-System von FreeBSD: mtree. Wirf mal einen Blick in
> die mtree(8)-Manpage, speziell unter dem Suchbegriff "digest".
> Möglicherweise erfüllt das bereits den Zweck für Dich.

Klar kenne ich mtree, aber ich wollte am liebsten was fertiges, aus
einem Guß sozusagen. Skripte schreiben wollte ich möglichst nicht, die
müssen dannn langwierig entwanzt und getestet werden.

> Ansonsten ist der Klassiker Tripwire (ports/security/tripwire).
> Wenn Du in der Ports-Collection nach Tripwire suchst, findest
> Du auch diverse Alternativen, wie z.B. AIDE und yafic:
>
> http://www.secnetix.de/tools/porgle/?w=ncd&q=tripwire

Aha, da kommt ja mit anderen Suchworten nochmal ein kleines Universum
dazu. ;)

> Im professionellen Bereich kommen auch häufig Samhain + Beltane
> zum Einsatz. Sind nicht in der Ports-Collection, laufen aber
> auch unter FreeBSD. Beltane ist ein hübschens Web-Frontend.
> Das Duo eignet sich gut für Teams; für den privaten Einsatz ist
> es wohl eher Overkill. Ich erwähne es nur der Vollständigkeit
> halber.
>
> > Alternativ könnten die betreffenden Dateisysteme r/o montiert werden,
> > das funktioniert mit erhöhtem ja auch und ist sicherer, da der Schaden
> > theoretisch garnicht erst auftreten kann. Da weiß'ich aber nicht, ob
> > spontanes rebooten oder ein wildgewordener Zeiger im Programm nicht doch
> > Schaden anrichten kann.
>
> Es hilft zumindest gegen den ersten der obigen drei Punkte.
> Obgleich es natürlich theoretisch denkbar ist, dass ein
> wildgewordenes Skript ein Dateisystem r/w-remountet. Aber
> das halte ich schon für eher unwahrscheinlich.

Denke ich auch, wobei mich ein Reboot durch gdb-Benutzung nicht weniger
gewundert hat. Shit happens.

> > Sollte ich bei r/o-Dateisystemenzusätzlich eine Prüfsumme vergleichen?
>
> Gute Frage. Schaden würde es sicherlich nicht. Und wenn Du
> ohnehin ein HIDS installierst, dann kannst Du es auch auf
> r/o-Dateisysteme loslassen. Das ist ja dann kein nennenswerter
> Zusatzaufwand.

Werde ich dann so durchziehen, r/o von allem wo es möglich ist, bei
Änderungen einmal die Prüfsummen ziehen.

> Übrigens ist es empfehlenswert, das Basis-System auf eine SSD
> (oder ein RAID-1 aus zwei verschiedenen SSDs) zu legen. Gerade
> ein HIDS-Check profitiert massiv davon. Auf meiner Workstation
> daheim habe ich das Basis-System auf eine SSD gelegt (/, /usr,
> /var, /usr/local), und den ganzen Rest auf eine normale, große
> Festplatte (im wesentlichen /home). Das beschleunigt auch den
> Boot-Vorgang und Updates erheblich. Ein HIDS-Check des Basis-
> Systems ist in wenigen Sekunden durch.

Läuft hier so, schon so lange, daß die erste SSD jetzt ausgewechselt
wird. Insbesondere bei fetten Programmen wie firefox, evolution,
openoffice, etc. und natürlich beim Einschalten war das anfangs echt
beeindruckend. Das hilft auch bei r/o-mount, weil die Dateisysteme
gleich passend organisiert sind.

Für home überlege ich noch, ob und wie man da die nötigsten Dateien
schützen kann. Konfigurationsdateien etwa, solange sie nicht vom
Programm im Betrieb geändert werden. Ist aber erstmal nicht so brisant,
weil da sowieso regelmäßig cpdup drauf läuft.

Danke sehr,
Marc

-- 
Marc Santhoff <M.Santhoff(at)web.de>
To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message
Received on Sat 05 Sep 2015 - 18:33:58 CEST

search this site