Viele kennen das …
Man betreibt ein kritisches IT System, setzt Härtungsmaßnahmen für Netzwerk, Hardware, OS, Software und Dienste um, damit der Angriffsvektor möglichst gering bleibt. Allerdings stellen sich mir u.a. folgende Fragen:
- Wie werde ich informiert, wenn das System doch kompromittiert wird und diese Schutzmechanismen ausgehebelt werden?
- Wie werden Änderungen auf dem System erkannt?
Eine Möglichkeit ist es, Dateien und Verzeichnisse auf ihre Integrität zu prüfen. Dabei wird ein Sollzustand definiert und regelmäßig mit dem Istzustand verglichen. Aber wie setze ich das um? Muss ich mir selber ein Programm schreiben, welches die Anforderungen umsetzt?
Nein… zum Glück nicht, allerdings habe ich in der Vergangenheit schon mehrmals erlebt, dass Kollegen aus der IT viel Zeit und Mühe in Eigenentwicklungen investiert haben. Am Ende scheiterte das Vorhaben an der Pflege und somit verlief die Umsetzung im Sande.
Zum Glück bieten zahlreiche Linux Distributionen (u.a. Red Hat/Centos, Debian usw.) schon von Haus aus passende Tools an. Einem davon widme ich diesen Artikel.
Nutzen Sie die Vorteile der Cloud und sichern Sie die Compliance für Ihre Business-Applikationen.
Advanced Intrusion Detection Environment (AIDE)
AIDE ist ein Intrusion Detection System, welches Dateien und Verzeichnisse auf Integrität prüft. Dabei wird initial eine Datenbank mit allen Prüfsummen erstellt, gegen die dann der aktuelle Systemzustand verglichen wird.
Was machts?
In der Konfiguration gibt man an, welche Dateien und Verzeichnisse und welche Attribute geprüft werden sollen. Nach der Initialisierung wird eine Datenbank angelegt, die den Sollzustand pro Host definiert. Außerdem erstellt AIDE kryptografische Checksummen, die ebenfalls in der Datenbank abgelegt werden.
Durch ein sogenannten “rebase” lässt sich dieser Sollzustand manuell aktualisieren. Das ist dann sinnvoll, wenn z.B. geplante Änderungen am System stattfinden.
Der Administrator kann nun beliebig oft (im besten Fall automatisiert) den Check starten und sich über Änderungen am System informieren lassen.
Attribute
Die folgenden Attribute können für die Prüfungen verwendet werden:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 |
#p: permissions #i: inode: #n: number of links #u: user #g: group #s: size #b: block count #m: mtime #a: atime #c: ctime #S: check for growing size #acl: Access Control Lists #selinux SELinux security context #xattrs: Extended file attributes #md5: md5 checksum #sha1: sha1 checksum #sha256: sha256 checksum #sha512: sha512 checksum #rmd160: rmd160 checksum #tiger: tiger checksum #haval: haval checksum (MHASH only) #gost: gost checksum (MHASH only) #crc32: crc32 checksum (MHASH only) #whirlpool: whirlpool checksum (MHASH only) |
Zur Praxis
Zur Installation gehört nicht viel dazu, denn AIDE ist schon in den Standard-Repositories vieler Distributionen (u.a. RHEL, Centos, Debian, u.s.w) enthalten.
|
1 |
~]# yum install aide |
Nach der Installation muss AIDE initialisiert werden, damit die Datenbank angelegt wird, die den Sollzustand pro Host darstellt.
|
1 2 3 4 5 |
~]# aide --init AIDE, version 0.15.1 ### AIDE database at /var/lib/aide/aide.db.new.gz initialized. |
Die Hostprüfung kann mit dem Parameter –check gestartet werden. Es ist ratsam, diese Prüfung regelmäßig zu starten, um Veränderungen am System rechtzeitig zu erkennen.
|
1 |
~]# aide check |
Die Konfiguration ist ebenfalls kein Hexenwerk. Man gibt lediglich an, in welchem Verzeichnis die Datenbank abgelegt werden soll, stellt das Logging ein, definiert Regelwerke und erstellt eine Liste von Verzeichnissen und Dateien, die geprüft werden sollen. Natürlich lassen sich aus Ausnahmen einstellen, um einzelne Unterverzeichnisse oder Dateien nicht zu prüfen.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 |
### Configuration file for AIDE. # Verzeichnisse definieren @@define DBDIR /var/lib/aide @@define LOGDIR /var/log/aide database=file:@@{DBDIR}/aide.db.gz database_out=file:@@{DBDIR}/aide.db.new.gz report_url=file:@@{LOGDIR}/aide.log report_url=stdout # Regelwerke erstellen (Beispiele) FIPSR = p+i+n+u+g+s+m+c+acl+selinux+xattrs+sha256 ALLXTRAHASHES = sha1+rmd160+sha256+sha512+tiger EVERYTHING = R+ALLXTRAHASHES NORMAL = sha256 DIR = p+i+n+u+g+acl+selinux+xattrs PERMS = p+u+g+acl+selinux+xattrs STATIC = p+u+g+acl+selinux+xattrs+i+n+b+c+ftype LOG = p+u+g+n+acl+selinux+ftype CONTENT = sha256+ftype CONTENT_EX = sha256+ftype+p+u+g+n+acl+selinux+xattrs DATAONLY = p+n+u+g+s+acl+selinux+xattrs+sha256 # Dateien und Verzeichnisse definieren (Beispiele) /etc/hosts$ CONTENT_EX /etc/passwd$ CONTENT /etc/gshadow$ CONTENT /etc/shadow$ CONTENT /etc/skel/ CONTENT_EX /etc/firewalld/ CONTENT_EX /etc/resolv.conf$ DATAONLY # Ausnahmen definieren (Beispiele) !/var/log/.* !/var/spool/.* |
Nachdem das Regelwerk angepasst wurde, muss man die AIDE Datenbank aktualiseren.
|
1 |
~]# aide --update |
Abschließend muss man die neue DB Datei im Datenbankverzeichnis (z.B. /var/lib/aide/aide.db.new.gz) mit der bestehenden Datenbank überschreiben.
Fazit
AIDE ist für mich eine einfache Möglichkeit zur Prüfung von Änderungen auf Zielsystemen. Die Umsetzung ist rasch erfolgt und zeitaufwändige Konfiguration bleibt uns erspart.
Durch die Integration von CI Tools (z.B. Jenkins mit Kombination Ansible) lässt sich die Installation, Konfiguration und die Steuerung zentral erledigen.
Kollegen gesucht:
Hier geht es zu den aktuellen Stellenausschreibungen für IT Operations
Mit über 15 Jahren Erfahrung als System Engineer und System Architekt bin ich die “Allzweckwaffe” im Kampf gegen Bugs und Performanceprobleme. Den Rest meiner Arbeitszeit verwende ich zur Verbesserung unseres Monitoringsystems und des Netzwerks in unseren Rechenzentren.
