Wozu das ganze? Tripwire kann doch auch im Gast laufen und die Integrität aller Dateien prüfen?

Stimmt, aber dann ist es von einem Angreifer innerhalb der virtuelle Maschine leicht manipulierbar!
Da unsere Tripwire Binarys und Configs nicht in der virtuelle Maschine liegen, sind sie für einen Angreifer nicht greifbar. Er weiß nicht mal, dass eine Tripwire Installation existiert (es sei denn, er liest diesen Blogpost)!

Wie funktioniert das ganze?
Ein Script fertigt von dem Gastsystem per LVM einen Snapshot an, welcher dann mit kpartx als einzelne Partitionen gemountet wird. Auf dem gemounteten Read-Only Volume wird dann der Integritätscheck ausgeführt.

So (!) macht ein HIDS sinn.
Wir werden das Script weiter entwickeln und erproben und es später zum Download bereit stellen.

Bis vor einiger Zeit, haben auch wir uns diese Frage gestellt und haben auch eine Antwort gefunden:
Linux lagert Standardmäßig alles aus, was eher selten gebraucht wird, vollkommen unabhängig davon, wie viel RAM noch frei ist. Der Sinn dahinter ist der, dass so direkt genug RAM frei ist, wenn er denn mal dringend benötigt wird. Diese beschleunigt zwar Desktopsysteme, sorgt insbesondere bei Datenbankservern aber für Frust.

Linux wäre nicht Linux, wenn man dieses Verhalten nicht steuern könnte.
Über die Systemvariabl vm.swappiness lässt sich das Swapverhalten der Speicherverwaltung regeln.
Standardinstallationen (RHEL, Debian, Ubuntu) haben für die Swappiness einen Wert von 60 vorgesehen, was für Desktopsysteme okay ist.

Kommen wir zur Bedeutung des Wertes.
Die Variable kann Werte zwischen 0 und 100 aufnehmen:

• Null bedeutet: Swappe niemals, wenn es sich vermeiden lässt
• Einhundert bedeutet: Swappe alles, was aktuell nicht benötigt wird

Für Server Empfiehlt sich also immer ein Wert von Null.
Mit der folgenden Anweisung können Sie der Variablen den Wert Null zuweisen:

echo 0 > /proc/sys/vm/swappiness

Achtung: Diese Lösung ist nicht persistent, sodass nach einem Reboot der Standardwert von 60 wieder gesetzt ist.
Um die Einstellung gleich beim booten setzen zu lassen, empfiehlt es sich, das ganze in der Datei /etc/sysctl.conf einzutragen:

vm.swappiness = 0

Obwohl wir auf vielen unserer Server natürlich Linux einsetzen, betreffen uns die meisten Exploits für Linux nicht direkt, da wir einen stark gehärteten Linuxkernel einsetzen. Wir setzen bei allen Systemen, wo Kunden direkten Zugriff auf das System (Shell / CGI) haben auf Grsecurity.

Grsecurity ließ uns bereits im Februar 2008 ruhiger schlafen, als es einen lokalen Rootexploit für Linux gab (Vmsplice Bug). Sämtliche auffindbaren Exploits funktionieren auf unseren Systemen nicht. Und so ist es auch nun wieder: Sämtliche Exploits, die wir für die aktuelle Lücke finden konnten, funktionieren auf unseren Systemen nicht.

Seit heute wollen wir die ganze Welt an unseren Paketen, die für KVM-Gastsysteme mit Debian Lenny konzipiert sind, teilhaben lassen, und stellen die Pakete für amd64 unter http://grsec.multicept.de zur Verfügung. Dass wir für Probleme, die durch unsere Pakete entstehen keinerlei Haftung übernehmen versteht sich von selbst.

Nähere Informationen, was im Kernel enthalten ist, was nicht, sowie signaturen werden in den nächsten Tagen folgen. Es lohnt sich also die Seite regelmäßig aufzurufen.