Jeder Eindringling auf einem Computersystem hinterlässt Spuren. Diese zu erkennen und entsprechende Massnahmen zu ergreifen, ist Aufgabe eines Intrusion-Detection-Systems wie dem Advanced Intrusion Detection Environment (AIDE). Anhand einer Musterdatenbank kann AIDE Veränderungen an Systemobjekten leicht feststellen und unmittelbar Alarm schlagen.

Auch Linux-Spezialisten sind vor unerwünschten Besuchern auf ihren Computersystemen nicht immer geschützt, wie der Einbruch in einige zentrale Fedora-Server letztes Jahr beweist. Ein Intrusion Detection System (IDS) kann helfen, solche unerwünschten Besuche zu entdecken und nicht-autorisierte Veränderungen am System festzustellen. Schließlich möchte man als Administrator doch ganz gerne erfahren, wenn wichtige Dateien oder Programme durch modifizierte Versionen ausgetauscht wurden.

IDS-Typen

Im Open-Source-Umfeld existieren eine ganze Reihe solcher Intrusion-Detection-Systeme, die sich grundsätzlich in zwei Gruppen einteilen lassen. So gleichen die Host-basierten Intrusion-Detection-Systeme (HIDS) anhand einer Datenbank den Soll-Zustand des Servers mit dem Ist-Zustand ab. Ergibt sich eine Differenz, deutet dies auf Veränderungen am System hin. Ob diese gewollt oder ungewollt sind, ist im Einzelfall vom Administrator zu entscheiden.

Auf der anderen Seite stehen die so genannten Netzwerk-basierten Intrusion Detection Systeme (NIDS). Wie der Name vermuten lässt, durchsuchen solche Systeme anhand einer Signatur-Datenbank den Netzwerkverkehr nach auffälligen IP-Paketen. Jeder bekannte Angriff auf ein Computersystem ist durch eindeutige Merkmale in den Netzwerkpaketen zu erkennen. Ähnlich wie ein Antiviren-Programm kennt ein NIDS diese eindeutigen Merkmale und untersucht jedes Netzwerkwerkpaket auf diese bekannten Eigenschaften. Wird ein verdächtiges Paket gefunden, so schlägt das IDS Alarm. Listing 1 zeigt beispielsweise eine solche Signatur wie sie das Snort-IDS verwendet, um IP-Pakete eines Angriffs durch den berühmten Conficker-Wurm zu erkennen.

alert tcp any any -> $HOME_NET 445 (msg: "conficker.b shellcode"; content:
"|e8 ff ff ff ff c2|_|8d|O|10 80|1|c4|Af|81|9MSu|f5|8|ae c6 9d a0|O|85
ea|O|84 c8|O|84 d8|O|c4|O|9c cc|Ise|c4 c4 c4|,|ed c4 c4 c4
94|&<O8|92|\;|d3|WG|02 c3|,|dc c4 c4 c4 f7 16 96 96|O|08 a2 03 c5 bc ea
95|\;|b3 c0 96 96 95 92 96|\;|f3|\;|24 |i|95 92|QO|8f f8|O|88 cf bc c7 0f
f7|2I|d0|w|c7 95 e4|O|d6 c7 17 cb c4 04 cb|{|04 05 04 c3 f6 c6 86|D|fe c4
b1|1|ff 01 b0 c2 82 ff b5 dc b6 1f|O|95 e0 c7 17 cb|s|d0 b6|O|85 d8 c7
07|O|c0|T|c7 07 9a 9d 07 a4|fN|b2 e2|Dh|0c b1 b6 a8 a9 ab aa c4|]|e7 99 1d
ac b0 b0 b4 fe eb eb|"; sid: 2000002; rev: 1;)

Einige Systeme können selbstständig bestimmte Aktionen ausführen, sobald sie ein verdächtiges Paket identifiziert haben. So könnten sie beispielsweise bei einem eindeutigen Angriff ein TCP-RST-Paket an den verdächtigen Absender-Host schicken. Damit würde eine bestehende TCP-Verbindung unmittelbar beendet. Auch das Blocken einzelner IP-Adressen oder ganzer IP-Segmente, von denen verdächtige Pakete stammen, ist mit solchen Systemen möglich. Man spricht in diesem Fall von sogenannten Intrusion -Prevention-Systemen (IPS).

SnortSAM [4] ist beispielsweise ein Plugin für Snort, das entsprechende IPS-Funktionen nachrüstet. SnortSam arbeitet mit einer Vielzahl unterschiedlicher Firewall-Produkte zusammen um die von Snort identifizierten Absendersysteme bereits an zentraler Stelle zu blockieren. Die Palette reicht von Checkpoint-NG-Firewalls, Cisco PIX über Linux Iptables bis hin zum Microsoft ISA-Server. Eine Kombination aus den genannten Varianten stellen die so genannten hybriden Intrusion-Detection-Systeme dar. Hier ist besonders Prelude [5] hervorzuheben. Es aggregiert verschiedene bereits vorhandene Systeme wie beispielsweise Snort oder Samhaim und stellt die Ergebnisse sehr elegant über ein grafisches Frontend dar (Abbildung 1).

Abbildung 1: Prelude als hybrides IDS greift auf vorhandene Intrusion-Detection-Systeme zurück und integriert deren Funktionen.

AIDE fällt in die Gruppe der Host-basierten IDS. Andere Vertreter dieser Gruppe sind beispielsweise das bekannte Tripwire [2] oder Samhain [3]. AIDE ist Bestandteil der meisten großen Linux-Distributionen und lässt sich durch die jeweiligen Paketmanager leicht aus den Software-Repositories heraus installieren. Alternativ findet man unter [1] die jeweils aktuellsten Sourcen, die sich dann über den klassischen Dreisatz »./configure && make && make install« übersetzen und installieren lassen. Dies ist auch für denjenigen sinnvoll, der unbedingt die neuesten Features braucht. So ist es beispielsweise möglich, die AIDE-Datenbank sowie die Konfigurationsdatei digital zu signieren. Dies ist recht sinnvoll, da es ausschließt, dass ein Einbrecher die AIDE-Datenbank und Konfigurationseinstellungen nachträglich verändert.

Kann AIDE die Signatur der Datenbank oder der Konfigurationsdatei nicht verifizieren, so verweigert das Tool den Betrieb und der Admin ist gezwungen auf eine Kopie (am besten von einem Read-Only-Medium) zurückzugreifen. Für solche Funktionen kennt AIDE in der aktuellen Version 0.13 verschiedene Optionen für das Configure-Skript. Ein Aufruf könnte etwa wie folgt aussehen:

./configure --with-confighmactype=sha1 ↩
--with-confighmackey="YWlkZSBhaWRlIGFpZGUgYW↩
lkZQo=" --with-dbhmactype=sha1 --with-↩
dbhmackey="YWlkZSBhaWRlIGFpZGUgYWlkZQo="

Das bestimmt neben einem HMAC-Schlüssel auch den Hash-Algorithmus für die Signatur. Das Beispiel benutzt sowohl für die Datenbank als auch für die Konfigurationsdatei den SHA1-Algorithmus. Die beiden Optionen »--enable-forced_dbmd« und »--enable-forced_configmd« erzwingen eine signierte Datenbank und Konfigurationsdatei. Über den Aufruf von »aide --config-check« kann der Admin dann die eigentliche Signatur erzeugen, die der Admin der Konfigurationsdatei »/etc/aide.conf« entweder manuell oder mit Hilfe des Tools »patch« hinzufügt:

aide --config-check
Config checked. Use the following to patch ↩
your config file.
0a1
> @@begin_config 27GF0+oKj1CvP4tltuibhu8YGIU=
13a15
> @@end_config

Im Anschluss ist die AIDE-Konfigurationsdatei entsprechend anzupassen. Hierbei geht es hauptsächlich darum, welche Datei- und Ordner-Attribute AIDE in der Datenbank speichern soll, die den Soll-Zustand des Systems festlegt. Beispiele für Datei-Attribute sind Zugriffsrechte, die Größe oder die Anzahl der Hardlinks. Weiterhin berechnet AIDE kryptographische Prüfsummen der zu überprüfenden Objekte und speichert sie ebenfalls.

Soll oder Haben

Die Soll-Datenbank muss natürlich einen sicheren Zustand des Systems widerspiegeln. Am besten legt der Admin sie also direkt nach der Betriebssysteminstallation an. Bei der Installation selbst sollte er ebenfalls darauf achten, nur integere Pakete aus vertrauenswürdigen Quellen zu verwenden. Dies gelingt am einfachsten, indem er den Paketmanager anweist, die Signatur jedes einzelnen Pakets vor der Installation zu überprüfen. In der Konfigurationsdatei sollte er als erstes den Speicherort der Soll-Datenbank festlegen. Statt sie im lokalen Dateisystem zu speichern, kann AIDE die Daten auch in einer SQL-Datenbank ablegen. Das ist gerade dann sinnvoll, wenn mehrere Maschinen mit gleichen Eigenschaften auf die Datenbank zurückgreifen sollen.

Die Anweisung »report_url« bestimmt, wie AIDE den Report ausgibt, der die Differenz zwischen dem Soll- und dem Ist-Zustand des Systems anzeigt. Hier ist es durchaus möglich, mehrere Ziele anzugeben, beispielsweise eine Logdatei, das Terminal oder auch einen Syslog-Daemon. Letzteres ist besonders interessant, da man so die Reports mehrerer AIDE-Instanzen verschiedener Hosts auf einem zentralen Logserver sammeln. Voraussetzungen hierfür ist natürlich eine passende Syslog-Konfiguration. Legt der Admin in der Datei »/etc/aide.conf« beispielsweise fest, dass AIDE die Reports unter der Syslog-Facility »AUTH« an den lokalen Syslog-Daemon sendet, so ist »/etc/syslog.conf« der folgende Eintrag notwendig, damit der Syslog-Daemon die Meldungen an einen zentralen Logserver weiterreicht:

auth.*      @logserver.example.com

Auf dem Logserver muss der Admin dafür sorgen, dass Syslog nicht nur auf einem Unix-Domain Socket, sondern auch auf einem Netzwerkport eingehende Logmeldungen entgegen nimmt. Beim Standard-Syslog-Daemon aktiviert beispielsweise die Startoption »-r« diese Funktion. Weitere Informationen liefert die Dokumentation der eingesetzten Linux-Distribution.

Schließlich legt der AIDE-Adminstrator in der Konfigurationsdatei die Objekte und deren Attribute fest die er überwacht haben möchte. Eine Liste der zur Verfügung stehenden Attribute zeigt Tabelle 1. Um die Konfiguration etwas zu vereinfachen, lassen sich mehrere Attribute unter einem frei wählbaren Namen zusammenfassen. Möchte der Admin gewisse Dateien oder Unterverzeichnisse von der Überprüfung ausnehmen, so führt er diese mit einem vorangestellten »!« in der Konfiguration auf. Listing 2 zeigt eine gekürzte Konfigurationsdatei für ein Fedora-System.

@@begin_config 27GF0+oKj1CvP4tltuibhu8YGIU=
@@define DBDIR /var/lib/aide
database=file:@@{DBDIR}/aide.db.gz
database_out=file:@@{DBDIR}/aide.db.new.gz
gzip_dbout=yes
verbose=5
report_url=file:/var/log/aide.log
report_url=syslog:LOG_AUTH
report_url=stdout
ALLXTRAHASHES = sha1+rmd160+sha256+sha512+tiger
EVERYTHING = R+ALLXTRAHASHES
NORMAL = R+rmd160+sha256
DIR = p+i+n+u+g+acl+selinux
PERMS = p+i+u+g+acl+selinux
LOG = >
LSPP = R+sha256
DATAONLY =  p+n+u+g+s+acl+selinux+md5+sha256+rmd160+tiger
/boot   NORMAL
/bin    NORMAL
/sbin   NORMAL
/lib    NORMAL
/opt    NORMAL
/usr    NORMAL
/root   NORMAL
!/usr/src
!/usr/tmp
/etc    PERMS
!/etc/mtab
@@end_config

Schließlich erzeugt der Aufruf »aide --init« die eigentliche Muster- oder Soll-Datenbank erzeugt. AIDE schaut sich nun alle in der Konfigurationsdatei aufgeführten Dateien und Verzeichnisse an und hält die aufgeführten Attribute in einer Datenbankdatei im Verzeichnis »/var/lib/aide« fest. Aus Sicherheitsgründen sollte man stets eine Kopie dieser Datenbankdatei wie auch der Konfigurationsdatei besitzen und sicher lagern.