Server sendet Spam?!

[Huschi]

Wenn man beim Systemstart nicht von einem sicheren System ausgehen kann sind alle IDS-Systeme bereits von vornerein zum Untergang verdammt.

Da hast Du absolut recht. Aber auch ich meine dass eine verschlüsselte HD wie Du es beschreibst, dazu keine Bereicherung ist. Insbesondere wenn die Boot-Partition unverschlüsselt vorliegt, auf der meistens auch das Kernel-Image liegt.
Ein Angriff findet meistens im laufenden Betrieb statt, wenn die Platte "aufgeschlossen" ist.

Hättest Du gesagt, die Boot- und Binary-Partition wird lediglich Read-Only gemountet und ein read-write-Remount würde erst die eine erneute Eingabe des Schlüssels erfordern, wäre dies etwas Anderes.

Das Thema ist aber - glaub ich - erschöpfend ausdiskutiert.
Folgen wir doch mal der eigentlichen Frage:

Auch wenn man über "Selbstbau-IDS" nicht reden sollte

Ein Vor-/Nachteil von Selbstbau vs. fertiger Applikation sind:
a) Selbstbau-Software muss ein Angreifer erst finden, erkennen, nachvollziehen wie sie funktionieren. Das kostet häufig Zeit, die er nicht immer hat.
b) Fertige Applikationen können leichter von mehrere Admins betreut werden.
Sie werden auch häufiger auf Lücken getestet und weiter entwickelt.

Aber das nur am Rande, ohne Diskussionsbedarf. Soll nur andeuten, dass beide Varianten ein Berechtigungsdasein haben.

vor einem neuen "Prüflauf" wird ein statistisch gelinktes md5sum-Binary von S2 auf S1 in ein temporäres Verzeichnis auf S1 kopiert und dort ausgeführt.

Grundsätzlich ist das Prinzip von zwei Servern sinnvoll. Auch dass Du an ein eigenes md5sum-Programm gedacht hast.
Aber wie stellst Du sicher, dass auf dem zweiten Server alles Ok ist?

Wie schon angedeutet, geht es auch manchmal darum einen Angreifer zu verschleiern, wie die Integrität gesichert werden soll. Hast Du auch dazu eine Idee?

Dann folgt natürlich der praktische Teil:
- Wie werden Änderungen in den md5-Summen reported?
- Wie werden Änderungen in den md5-Summen upgedated?
- Welche Dateien willst Du alle überwachen?

huschi.

 

[d4f]

Ein letzter Gedanke:

Ein Vor-/Nachteil von Selbstbau vs. fertiger Applikation sind:

Eine Kombination aus beiden zusammen waere eventuell interessant.
Grund: der Angreifer freut sich eventuell nach dem Unschaedlich-machen der ihm bekannten IDS-Software zu frueh und wird unvorsichtig; die Eigenbauloesung kann brav Alarm geben und somit der Angriff gestoppt werden.
Allerdings muss nach jedem Angriff die Methode der Eigenbauloesung geaendert werden da nicht bekannt ist wieweit ein Angreifer Kenntnisse ueber die eigene Systeme erlangt hat (hoffentlich bleibt es aber bei 0 erfolgreichen Angriffen )

Man muss auf die Methode des Alarms ebenfalls acht geben. Sollte die Software eine Email raushauen wollen ist das Risiko gross dass ein Ueberwachungsprogramm des Angreifers dieses pattern erkennt.
Eine -moegliche- Alternative waere dass der Status in einen shared memory space geschrieben und von im x-Sekundentakt gepollten Skript auf einem Webserver ausgegeben wird - somit sollte es im ueblichen Webtraffic untergehen. Da wir von security by obscurity reden ist die langsamere Reaktionsmethode und eine weitere Schwachstelle - Webserver und Skript - weniger von Belang als eine zu verraeterische Informierung.

 

[Huschi]

Nur bevor es falsch verstanden wird:
Sowohl regelmäßige md5-Überprüfung als auch Tripwire sind keine "Alarmanlagen".
(Wer möchte schon seinen Load durch ein ständiges md5sum erhöhen und dadurch den Festplattendurchsatz als auch die Effektivität eine HD-Caches verringern?)
Die wenigsten Hostbased-IDS sind zur direkten Entdeckung eines Einbruchs geeignet. Sie stellen lediglich ein Hilfsmittel dar, um nachträglich ein korrumpiertes System zu überprüfen.

huschi.