AIDE erkennt Server-Einbrüche

Aus ADMIN 03/2009

Lesen Sie dazu auch:

• Das Snort-IDS erkennt Einbruchsversuche

• Intrusion Detection mit Samhain

• Intrusion Detection visualisiert

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.

01 alert tcp any any -> $HOME_NET 445 (msg: "conficker.b shellcode"; content:
02 "|e8 ff ff ff ff c2|_|8d|O|10 80|1|c4|Af|81|9MSu|f5|8|ae c6 9d a0|O|85
03 ea|O|84 c8|O|84 d8|O|c4|O|9c cc|Ise|c4 c4 c4|,|ed c4 c4 c4
04 94|&<O8|92|\;|d3|WG|02 c3|,|dc c4 c4 c4 f7 16 96 96|O|08 a2 03 c5 bc ea
05 95|\;|b3 c0 96 96 95 92 96|\;|f3|\;|24 |i|95 92|QO|8f f8|O|88 cf bc c7 0f
06 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
07 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
08 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
09 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.

01 @@begin_config 27GF0+oKj1CvP4tltuibhu8YGIU=
02 
03 @@define DBDIR /var/lib/aide
04 database=file:@@{DBDIR}/aide.db.gz
05 database_out=file:@@{DBDIR}/aide.db.new.gz
06 gzip_dbout=yes
07 verbose=5
08 report_url=file:/var/log/aide.log
09 report_url=syslog:LOG_AUTH
10 report_url=stdout
11 ALLXTRAHASHES = sha1+rmd160+sha256+sha512+tiger
12 EVERYTHING = R+ALLXTRAHASHES
13 NORMAL = R+rmd160+sha256
14 DIR = p+i+n+u+g+acl+selinux
15 PERMS = p+i+u+g+acl+selinux
16 LOG = >
17 LSPP = R+sha256
18 DATAONLY =  p+n+u+g+s+acl+selinux+md5+sha256+rmd160+tiger
19 /boot   NORMAL
20 /bin    NORMAL
21 /sbin   NORMAL
22 /lib    NORMAL
23 /opt    NORMAL
24 /usr    NORMAL
25 /root   NORMAL
26 !/usr/src
27 !/usr/tmp
28 /etc    PERMS
29 !/etc/mtab
30 
31 @@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.

Ist- und Soll-Zustand vergleichen

Möchte der Admin nun den Ist-Zustand des Systems mit dem Soll-Zustand vergleichen, ruft er ,,aide --check`` auf. AIDE schaut sich dann erneut alle in der Konfigurationsdatei aufgeführten Objekte an und vergleicht deren aktuelle Attribute mit denen in der Soll-Datenbank. Die Differenz zeigt AIDE als Report auf dem Terminal an -- zumindest wenn die Anweisung »report_url=stdout« in der Konfigurationsdatei steht. Das Ergebnis sieht dann in etwa so aus wie in Abbildung 1. Hier stellt AIDE fest, dass sich die Mtime und die Ctime der Datei »/etc/shadow« geändert haben. Ob es sich hierbei um eine nicht autorisierte Änderung handelt, ist vom verantwortlichen Administrator selbst zu entscheiden. AIDE kann lediglich auf diese Änderung hinweisen. Stellt sich heraus, dass es sich um eine autorisierte Änderung handelt, muss der Admin sie natürlich neu in die Datenbank aufnehmen, da AIDE sonst bei jeder weiteren Überprüfung erneut Alarm schlagen würde.

Die Kunst beim Konfigurieren eines Host-basierten Intrusion-Detection-Systems liegt darin, durch mehrere iterative Anpassungen, die Konfigurationsdatei so aufzubauen, dass das IDS keine oder möglichst wenig Falschmeldungen generiert, ansonsten geht die wirklich wichtige Information evtentuell in der Menge der vielen Ausgabeinformationen verloren. Es kann also durchaus einige Durchläufe brauchen, bis die Konfigurationsdatei so angepasst ist, dass AIDE wirklich nur noch in kritischen Fällen Alarm schlägt. Das setzt ein gutes Verständnis der verschiedenen Attribute und der zu überwachenden Objekte voraus. Sind die richtigen Einstellungen gefunden, kann man den Aufruf von »aide --check« automatisiert beispielsweise einmal täglich durch den Cron-Daemon starten.

Abschließend noch einige praktische Hinweise. Sollte das AIDE-System durch einen Angreifer kompromittiert werden, so ist es für diesen natürlich ein Leichtes die bestehende Konfigurationsdatei auszulesen und nach Ordnern zu suchen, die AIDE nicht überprüft. So kann beispielsweise die Installation einer Backdoor vollkommen unbemerkt bleiben. Aus diesem Grunde speichert man die Konfigurationsdatei im besten Falle auf einem Read-Only-Medium, das nur zum Zeitpunkt der Systemüberprüfung bereitsteht. Gleiches gilt auch für die Datenbank selbst. Arbeitet man nicht mit digitalen Signaturen, könnte ein Angreifer ansonsten den Inhalt der Datenbank leicht verändern, um seine Manipulationen am System zu verbergen.

Fazit

AIDE ist eine leistungsfähige Software die sehr leicht zu konfigurieren ist. In kleineren Umgebungen oder auf Einzelsystemen bietet AIDE deshalb Vorteile im Vergleich zu komplexeren Systemen wie Tripwire oder Samhain. Erweiterte Funktionen wie beispielsweise die grafische Aufbereitung von Reports sucht man bei AIDE aber vergebens. (ofr)

Infos

[1] AIDE: [http://sourceforge.net/projects/aide]

[2] Tripwire: [http://sourceforge.net/projects/tripwire]

[3] Samhain: [http://www.la-samhna.de/samhain]

[4] Snortsam: [http://www.snortsam.net]

[5] Prelude: [http://www.prelude-ids.com]