Intrusion-Detection auf virtuellem Server

[jeltsch]

Hallo,

ich habe einen virtuellen Server und möchte auf diesem Intrusion-Detection betreiben. Bislang habe ich hierfür Tripwire und Snort ins Auge gefasst. Zunächst habe ich zu diesen beiden da einige Fragen.

Zu Tripwire:

• In einem Beitrag auf einem Tripwire-Forum schrieb ein gewisser Bob Mahan u.a.:

  Store the passphrases in a secure location. There is no way to remove encryption from a signed file if you forget your passphrase. If you forget the passphrases, the files are unusable. In that case you must reinitialize the baseline database.

  Ich verstehe nicht, warum hier wie auch in den Tripwire-Manpages immer von Signaturen und Verschlüsselung (signatures and encryption) gesprochen wird. Das mit den Signaturen sehe ich ein – verschiedene wichtige Dateien werden unter Verwendung eines privaten Schlüssels signiert, sodass später die Integrität mit dem zugehörigen öffentlichen Schlüssel überprüft werden kann. Aber wie ist das mit der Verschlüsselung gemeint? Verschlüsselt wird normalerweise mit einem öffentlichen Schlüssel. Aber das würde bedeuten, dass jeder von Tripwire durchgeführte Test den privaten Schlüssel benötigen würde, um gewisse Dateien, wie z.B. die Policy-Datei, zu entschlüsseln. Das wiederum würde bedeuten, dass es unmöglich ist, einen Tripwire-Test als cron-Job laufen zu lassen, da man, um den privaten Schlüssel zu benutzen, die Passphrase braucht. Wenn mit "Verschlüsselung" aber in Wirklichkeit nur Signierung gemeint sein sollte, sehe ich nicht ein, wieso dann bei Verlust der Passphrase die Dateien unbrauchbar sein sollen.
• Ich frage mich auch, warum es für jedes Schlüsselpaar ("local" und "site-wide") nur eine Datei gibt. Werden jeweils beide Schlüssel – privat und öffentlich – in der gleichen Datei gespeichert? Das würde bedeuten, dass jeder Nutzer den privaten Schlüssel lesen könnte, da die Schlüsseldateien für alle lesbar sind. Ist das beabsichtigt?
• Einige Quellen empfehlen, die Tripwire-Datenbank auf einem nur lesbaren Medium zu speichern. Aber ist das wirklich erforderlich? Ich dachte eigentlich, dass immer, wenn ein Tripwire-Kommando die Policy-Datei oder die Datenbank liest, es die Integrität dieser Datei durch Prüfen der Signatur testet. Wenn das so ist, würde ja eine Modifikation dieser Dateien von Tripwire erkannt werden. Es wäre natürlich schön, wenn die Modifikation schon rein hardwaretechnisch nicht möglich wäre. Ist das der Hintergrund der Nur-Lese-Medium-Empfehlung? Auf einem virtuellen Server habe ich nun kein Nur-Lese-Medium zur Verfügung. Heißt das, dass Tripwire für einen V-Server eine schlechte Wahl ist?
• Was ist eigentlich, wenn ein Angreifer Root-Zugriff bekommt und die Tripwire-Binaries ändert, sodass sie keine Angriffe mehr melden? Wie kann ich mich vor so etwas schützen? Sollte man auf einem virtuellen Server Tripwire-Test von einem Rettungssystem aus durchführen?

Zu Snort:

• Wie gut ist die Kollektion von Intrustion-Detection-Regeln, die das Paket snort-rules-default von Debian woody zur Verfügung stellt. Reicht die für den normalen V-Server-Betrieb aus?
• Ist es empfehlenswert, sich (bei Benutzung von Debian woody) das Paket oinkmaster zu installieren?

Was für sinnvolle Alternativen zu Tripwire und Snort gibt es im V-Server-Bereich?

Vielen Dank an jeden, der diesen Beitrag bis hierhin durchgelesen hat! Ich hoffe, ihr könnt mir in diesen Fragen weiterhelfen.

Viele Grüße
Wolfgang

[donald]

Zu Snort:

1. Meine Versuche Snort auf einem V-Server zu betreiben sind fehlgeschlagen, da Snort die Netzwerkkarte nicht bedienen konnte. Snort liest hier die Daten in einem speziellen RAW Modus (auch wenn der promiscous Mode nicht verwendet wird).

2. Eine Anpassung der Snort-Regeln würde ich auf jeden Fall empfehlen, zumindest das Aussortieren von Regeln, die man nicht benötigt. Bei mir waren die meisten erkannten Angriffe (>80%) MS-SQL Wurm, obwohl ich keinen MS-SQL Server betreibe, also brauche diese Hinweise nicht.

3. Bei einem manuellen Updates der Rules kommt auch immer eine neue conf Datei mit, die dann wieder gemäß den alten Einstellungen angepaßt werden muss. Daher ist es durchaus sinnvoll mit automatisierten Skripten wie Oinkmaster zu arbeiten.