tool um die "base" zu md5-hashen

lockdoc

lockdoc

Well-Known Member
Ich bin grad mal wieder auf der Suche um meine Server ein wenig sicherer zu machen und da kam mir die Idee:

Nach der Installation (oder Welterschaffung) ueber alle Binaries und sonstigen Systembedingten Libs, etc (alles was sich nicht veraendert) jeweils einen MD5 Hash rueber zu packen und periodisch zu checken ob noch alles beim alten ist.

Jetzt waer natuerlich ein automatisches tool ganz schick.

Um das noch in die Hoehe zu treiben, koennte man auch beim oeffnen/laden der bin/lib checken, ob der md5 hash mit dem aus dem Datenbestand uebereinstimmt.

Die Datenbank mit den Hashes braeuchte theoretisch selbst eine Art verschluesselung, damit nicht jeder einfach mal schnell einen neuen Hash eintraegt.


Gibt es bereits so etwas, oder so etwas aehnliches?
 
Der Rootkithunter (in den Ports unter security/rkhunter) legt auch einen Hash wichtiger Systemdateien an, wenn ich mich recht erinnere. Allerdings ist das natürlich nur ein Teil von dem, was Dir vorschwebt.
 
Auf der Suche nach HIDS:

security/samhain
security/tripwire
security/ossec-hids-local
security/aide
security/fcheck
 
Zuletzt bearbeitet:
Hi

wie wärs mit nem Script.
Erforderliche Ports: Bash, gsed


check_system.sh
Code: 
#!/usr/local/bin/bash -f

MAILTO="blub@blubblub.de"
[ `type -p md5sum 2>/dev/null` ] && MD5='md5sum' || MD5='md5'

find / '(' -path '*/sbin/*' -o -path '*/bin/*' -o -path '*/etc/*' ')' \
  -type f -print | xargs "$MD5" | gzip -9c | mmencode -b | gsed "1i\\
To: $MAILTO\\
Subject: System Checksum `date`\\
MIME-Version: 1.0\\
Content-Type: multipart/mixed; boundary=__grenze__\\
\\
--__grenze__\\
Content-Type: application/x-gzip; name=\"chksum.txt.gz\";\\
Content-Transfer-Encoding: base64\\
Content-Disposition: attachment; file_name=\"chksum.txt.gz\"\\

\$a\\
--__grenze__--
" | sendmail -t
 
seven0fx schrieb:
Vlt. genügt ja auch freebsd-update mit IDS deinen Ansprüchen.
Zum Vergrößern anklicken....

Uii das kannte ich ja gar nicht... wenn man das Handbuch nicht auswendig lernt, dann bleiben solche Features immer unbemerkt. :-)


Nukama schrieb:
security/samhain
security/tripwire
security/ossec-hids-local
security/aide
Zum Vergrößern anklicken....

Diese 4 hoeren sich ja gut an. Leider konnte ich bei denen nichts finden, dass sie ein check "on-load" machen. Darum wuerd ich eventuell zu einer Combination von eines der tools mit etwas selbstgebasteltem greifen.

Kann ich mich denn irgendwo dazwischen schalten, wenn Programme, Module, Libraries in den RAM geladen werden? Ich wuerde denn gerne an dieser Stelle einen passiven Check anbinden, der nochmal die bin/lib/etc/config (im Dateisystem) auf md5 prueft (also nichts blockiert, sondern unabhaengig checkt).

Wie sieht es aus mit dem ganzen Kram der bereites geladen ist, kann ich mir das irgendwo anzeigen lassen und kann ich auf die im RAM befindlichen Dinge auch zugreifen, dass man darauf periodisch einen Check macht?

Ich haette noch daran gedacht eine white-list zu erstellen mit den ganzen Kram was irgendwie ueberhaupt geladen werden darf (nur passiv, was dann die geladenen Module mit der Liste periodisch abcheckt).

Nun weiss ich ja noch nicht genau wieviel das System immer so an Lade-Operation abwickelt, eventuell entwickelt sich dass ganze auch zu einem totalem Overhead.


Leider aendern sich halt die Zeiten und wenn wenn die Leute Bundestrojaner und Co. loslassen muss man sich ja vorbereiten. xD
 
Mit mtree aus dem Basissystem sollte ein HIDS auch realisierbar sein. Das Prüfen der Binaries und Libs vorm Ausführen dürfte nicht ganz trivial werden. NetBSD hat so ein Feature, heißt dort veriexec.

c.
 
Hallo lockdoc,

lockdoc schrieb:
...
Zum Vergrößern anklicken....

Die einfachste Methode, Dein System vor Manipulationen an Utilities und Libraries zu schützen ist, dass man schon bei der Installation folgende Regel beachtet:
(*) Separate Partitionen für / und /usr/local anlegen
(*) diese Partitionen readonly mounten, sobald das System fertig installiert und konfiguriert ist
(*) Monitoring-Software wie Monit zur Überwachung installieren
(*) Root-Passwort mit maximaler Stellenzahl auswählen und von apg generieren lassen oder noch besser: One-Time-Passwörter wählen
(*) Secure-Levels studieren und anwenden

Ich denke, dass Du damit schon 99% Sicherheit erreicht hast. Du darfst nicht vergessen: Je mehr Tools und Maßnahmen Du zur Überwachung installierst und ergreifst, desto höher ist die Wahrscheinlichkeit von Konfigurationsfehlern und dadurch entstehenden Sicherheitslücken. Um das letzte Prozent auch noch abzusichern, mußt Du einen gewaltigen Aufwand treiben oder den Rechner vom Internet abkoppeln:D

JueDan
 
@oenone
und wie ist deine bevorzugte Herangehensweise bzw. wie genau setzt du bitte ein Passwort als invalid ?
 
metro: pw schreibt in master.passwd for den Passworthash LOCK. Damit ist die Zeile ungültig und der User gesperrt. Das hindert aber niemanden mit daran dieser User zu werden, wenn er an der Passwortabfrage vorbei kommt.
 
Das ist unter FreeBSD aber problematisch, weil sudo nicht im Basisystem ist und man sich irgendwie die sudoers zerschiesst. Außerdem kann man dann nicht mehr in der /etc/ttys die console auf "insecure" setzen, weil man dann beim Starten des Single-User-Modus das Root-Passwort eintippen muss.
 
Hi,


jetzt mal ganz einfach:

mach ein chflags -R schg auf die Base Verzeichnisse,
dann setzt das securelevel auf 1 und gut ist.
oder änder die fstab so ab das ALLE mounts ro sind :-), bis auf home und var.

Aber das Hashen von den Files und das prüfen von Änderungen würd ich per HIDS wie aide machen.

mfg
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben