AnmeldenProof of Concept: Mit Ansible das Advanced Intrusion Detection Environment (AIDE) steuern
Dies ist der Folgeartikel, den ich in der Einführung in das Advanced Intrusion Detection Environment (AIDE) versprochen hatte. Es handelt sich hierbei um einen Proof of Concept (PoC), der zeigt, wie AIDE mithilfe einer Ansible-Rolle ferngesteuert werden kann. Die Einführung wird als bekannt vorausgesetzt.
Grundlegende Ansible-Kenntnisse, wie die Verwendung von Ansible-Rollen und das Ausführen von Playbooks werden ebenfalls als bekannt vorausgesetzt. Wer Ansible nicht kennt, sei an die offizielle Dokumentation verwiesen.
Welche Aufgaben sind mit Ansible zu lösen?
- Das Paket
aideist auf den Zielsystemen installiert - Die optionale Generierung und Verteilung der Konfigurationsdatei
aide.conf - Die Initialisierung der AIDE-Datenbank
- Zentrale Speicherung der AIDE-Datenbanken aller verwalteter Hosts auf dem Ansible Control Node (ACN)
- Durchführung von Integritäts-Checks
- Aktualisierung der AIDE-Datenbanken und erneute Speicherung auf dem ACN
Durch die Speicherung der AIDE-Datenbanken und -Konfigurationsdateien auf dem ACN sind diese gegen Veränderung auf einem kompromittierten Host geschützt. Gegen Veränderungen auf dem ACN selbst sind die Dateien nur mit Unix-Dateiberechtigungen geschützt. Doch wenn der ACN kompromittiert ist, hat man eh ein ganz anderes Problem, als sich um AIDE Sorgen zu machen.
Labor-Umgebung
Meine Labor-Umgebung für diesen PoC besteht aus den vier Hosts:
- ansible-ctrl (RHEL 8 mit installiertem
ansible-core) - rhel7
- rhel8
- rhel9
Der ACN kann sich via SSH zu den Zielsystemen (rhel{7,8,9}) verbinden und dort Programmcode mit erhöhten Rechten ausführen.
Die von mir für diesen PoC entwickelte Ansible-Rolle gibt es unter der URL: https://github.com/Tronde/aide
Beschreibung der Ansible-Rolle aide
Die Rolle ist nicht idempotent. Sie ruft das Programm aide auf den Zielsystemen mit verschiedenen Optionen auf und verarbeitet deren Ausgabe. Dazu macht die Rolle Gebrauch des Moduls ansible.builtin.command.
Gesteuert wird die Rolle über Ansible-Tags. Wird die Rolle in einem Playbook ohne Angabe von Tags ausgeführt, werden keinerlei Veränderungen an den Zielsystemen vorgenommen.
Der folgende Code-Block zeigt ein Beispiel-Playbook zum Aufruf der Rolle. Die Tags und die Variable aide_db_fetch_dir werden im Anschluss erläutert.
# SPDX-License-Identifier: MIT
---
- name: Example aide role invocation
hosts: targets
tasks:
- name: Include role aide
tags:
- install
- generate_config
- init
- check
- update
vars:
aide_db_fetch_dir: files
ansible.builtin.include_role:
name: aide- install – Bei Angabe dieses Tags stellt die Rolle sicher, dass das Paket
aideauf den Zielsystemen installiert ist - generate_config – Generiert die Datei
/etc/aide.confunter Nutzung vontemplates/aide.conf.j2; das Template ist an die individuellen Bedürfnisse anzupassen; Details siehe nächster Abschnitt - init – Hiermit wird die AIDE-Datenbank initialisiert, welche als Referenzdatenbank für zukünftige Checks dient
- check – Führt einen Integritäts-Check unter Verwendung der Referenzdatenbank durch
- update – Führt einen Integritäts-Check durch und erzeugt eine neue AIDE-Datenbank, welche zukünftig als Referenz dient
Die Variable aide_db_fetch_dir erwartet im Auslieferungszustand das Verzeichnis files parallel zum Playbook. In diesem Verzeichnis werden Unterverzeichnisse für jeden Host erstellt, in denen die AIDE-Datenbank der verwalteten Systeme gespeichert wird. Soll ein anderer Speicherort verwendet werden, ist der Wert dieser Variablen entsprechend anzupassen. Die AIDE-Datenbanken werden mit dem Ansible-Module ansible.builtin.fetch von den verwalteten Systemen geholt.
Nutzung für die verschiedenen Anwendungsfälle
In diesem Abschnitt beschreibe ich die fünf Anwendungsfälle für den PoC. Alle Anwendungsfälle wurden gegen RHEL 7, RHEL 8 und RHEL 9 getestet. Für diesen Blog beschränke ich mich jedoch auf Tests gegen RHEL 9, um die Übersichtlichkeit der Ausgaben zu verbessern.
Es wird stets das Playbook aus dem Abschnitt Beschreibung der Ansible-Rolle aide verwendet und mit unterschiedlichen Tags ausgeführt.
Anwendungsfall 1: Installation von AIDE
Um AIDE nutzen zu können, muss es zuerst installiert sein. Dies wird mit folgendem Playbook-Aufruf festgestellt:
[root@ansible-ctrl ansible]# ansible-playbook aide.yml --tags install
PLAY [Example aide role invocation] ********************************************
TASK [Gathering Facts] *********************************************************
ok: [rhel9]
TASK [Include role aide] *******************************************************
TASK [aide : Ensure required packages are installed] ***************************
changed: [rhel9]
PLAY RECAP *********************************************************************
rhel9 : ok=2 changed=1 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0Für diesen Anwendungsfall arbeitet die Rolle idempotent. Bei einer zweiten Ausführung werden keine weiteren Änderungen am System vorgenommen:
[root@ansible-ctrl ansible]# ansible-playbook aide.yml --tags install
PLAY [Example aide role invocation] ********************************************
TASK [Gathering Facts] *********************************************************
ok: [rhel9]
TASK [Include role aide] *******************************************************
TASK [aide : Ensure required packages are installed] ***************************
ok: [rhel9]
PLAY RECAP *********************************************************************
rhel9 : ok=2 changed=0 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0Anwendungsfall 2: Generierung der Datei /etc/aide.conf
Zusammen mit der Rolle wird die Datei templates/aide.conf.j2 ausgeliefert. Dabei handelt es sich um die Standardkonfigurationsdatei aus einer RHEL9-Installation, in welcher zusätzlich der Pfad /root/.ansible* von der Überwachung ausgenommen wurde, um falsch positive Ergebnisse zu vermeiden.
Diese Datei ist an die individuellen Bedürfnisse anzupassen. Wer Hilfe zum Templating mit Jinja2 benötigt, findet in der Ansible-Dokumentation einen Einstieg.
Ausgerollt wird die Konfigurationsdatei dann wie folgt:
[root@ansible-ctrl ansible]# ansible-playbook aide.yml --tags generate_config
PLAY [Example aide role invocation] ********************************************
TASK [Gathering Facts] *********************************************************
ok: [rhel9]
TASK [Include role aide] *******************************************************
TASK [aide : Generate /etc/aide.conf] ******************************************
changed: [rhel9]
PLAY RECAP *********************************************************************
rhel9 : ok=2 changed=1 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0Auch mit diesem Tag arbeitet die Rolle idempotent.
Wird dieser Schritt ausgelassen, wird in allen folgenden Anwendungsfällen die Standardkonfigurationsdatei verwendet, welche bei der Installation des Pakets aide mitinstalliert wurde.
Anwendungsfall 3: Initialisierung der AIDE-Datenbank
Um Integritäts-Checks durchführen zu können, muss zuerst die AIDE-Datenbank initialisiert werden. Dies geschieht mit dem folgenden Aufruf:
[root@ansible-ctrl ansible]# ansible-playbook aide.yml --tags init
PLAY [Example aide role invocation] ********************************************
TASK [Gathering Facts] *********************************************************
ok: [rhel9]
TASK [Include role aide] *******************************************************
TASK [aide : Initialize AIDE database] *****************************************
changed: [rhel9]
TASK [aide : Fetch AIDE database] **********************************************
changed: [rhel9]
TASK [aide : Remove remote AIDE database file] *********************************
changed: [rhel9]
PLAY RECAP *********************************************************************
rhel9 : ok=4 changed=3 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0Nach der Initialisierung der AIDE-Datenbank wird diese auf den ACN kopiert und von den verwalteten Systemen entfernt. Dies hat den Hintergrund, dass es sich beim ACN um ein sehr gut gesichertes System handelt und die Datenbanken hier am besten vor einer Kompromittierung geschützt sind.
Wird der Standardwert der Variable aide_db_fetch_dir verwendet, findet sich die AIDE-Datenbank jetzt im Pfad files/rhel9/var/lib/aide/aide.db.new.gz. Dabei entspricht rhel9 in der Pfadangabe dem inventory_hostname des jeweiligen Zielsystems.
Dieser Teil der Rolle ist nicht idempotent. Wird das Playbook erneut ausgeführt, wird eine neue AIDE-Datenbank erstellt, auf den ACN heruntergeladen und vom Zielsystem gelöscht.
Anwendungsfall 4: Ausführung einer Integritätsprüfung
Der nun folgende Code-Block zeigt den Playbook-Aufruf zur Integritätsprüfung. Hier wird zuerst die AIDE-Datenbank auf das Zielsystem kopiert, anschließend ein AIDE-Check ausgeführt. Da im folgenden Beispiel keine Änderungen detektiert wurden, besitzt der Task „[aide : Check against AIDE reference database]“ den Status „ok“.
[root@ansible-ctrl ansible]# ansible-playbook aide.yml --tags check
PLAY [Example aide role invocation] ********************************************
TASK [Gathering Facts] *********************************************************
ok: [rhel9]
TASK [Include role aide] *******************************************************
TASK [aide : Copy AIDE reference database to remote] ***************************
changed: [rhel9]
TASK [aide : Check against AIDE reference database] ****************************
ok: [rhel9]
PLAY RECAP *********************************************************************
rhel9 : ok=3 changed=1 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0Dieser Teil der Rolle ist nicht idempotent. Bei jedem Aufruf wird ein neuer Integritäts-Check ausgeführt.
Ich habe die Datei /etc/hosts auf dem Zielsystem manipuliert, um auch den Fall zu zeigen, wenn eine Änderung erkannt wurde.
Zu Beginn der folgenden Ausgabe ist zu erkennen, dass der Task „[aide : Copy AIDE reference database to remote]“ den Status „ok“ besitzt. Ansible hat erkannt, dass die AIDE-Datenbank bereits in unverändertem Zustand auf dem Zielsystem existiert, und hat sie deshalb nicht erneut übertragen. Der Task „[aide : Check against AIDE reference database]“ schlägt nun allerdings fehl (Status: „fatal“), da Veränderungen erkannt wurden. Die zugegeben etwas unübersichtliche Ausgabe enthält die Nachricht, dass die Datei /etc/hosts verändert wurde.
[root@ansible-ctrl ansible]# ansible-playbook aide.yml --tags check
PLAY [Example aide role invocation] ********************************************
TASK [Gathering Facts] *********************************************************
ok: [rhel9]
TASK [Include role aide] *******************************************************
TASK [aide : Copy AIDE reference database to remote] ***************************
ok: [rhel9]
TASK [aide : Check against AIDE reference database] ****************************
fatal: [rhel9]: FAILED! => {"changed": true, "cmd": ["aide", "--check"], "delta": "0:00:27.177397", "end": "2024-03-29 05:16:50.682795", "msg": "non-zero return code", "rc": 4, "start": "2024-03-29 05:16:23.505398", "stderr": "", "stderr_lines": [], "stdout": "Start timestamp: 2024-03-29 05:16:23 -0400 (AIDE 0.16)\nAIDE found differences between database and filesystem!!\n\nSummary:\n Total number of entries:\t45541\n Added entries:\t\t0\n Removed entries:\t\t0\n Changed entries:\t\t1\n\n---------------------------------------------------\nChanged entries:\n---------------------------------------------------\n\nf ... .C... : /etc/hosts\n\n---------------------------------------------------\nDetailed information about changes:\n---------------------------------------------------\n\nFile: /etc/hosts\n SHA512 : YobgpcvAMPey0QX1lK4K+5EFySF1xrB/ | 7nIivvNa5ozfhOqSFLmPIiu6g04Wbx1n\n 9FRzTCPNC93+13Y5/lm2inC4x4rydlf2 | iGNf0/QTgFjaMGug8HywxTiO2PREZRNS\n EcvonCf3pHuXj6lEmAjBnw== | 3qNEi4Qm6an5inSY72sjfA==\n\n\n---------------------------------------------------\nThe attributes of the (uncompressed) database(s):\n---------------------------------------------------\n\n/var/lib/aide/aide.db.gz\n MD5 : gMgRyMOExVAdOAvdgt4QDA==\n SHA1 : w7tmPKNvRYggY/JZ5wv+7ZdcSZM=\n RMD160 : CO0pK5tfg66MaO17YB8eaRuyyMw=\n TIGER : n8UbZJNt9gL672+pR9IPjoyhpAsUJ46O\n SHA256 : k8UHnv2CK4zYrfZN+bDp6SCcLkx21px6\n GNZlwySPKcY=\n SHA512 : DFw5wlBoJQOBCrs0ulvVxaMvoQk/oBEQ\n TkOmhfHAdevUWNAgCJ0KH0q26LsynEMj\n MWQpsGf7v12iACc4SP9ANA==\n\n\nEnd timestamp: 2024-03-29 05:16:50 -0400 (run time: 0m 27s)", "stdout_lines": ["Start timestamp: 2024-03-29 05:16:23 -0400 (AIDE 0.16)", "AIDE found differences between database and filesystem!!", "", "Summary:", " Total number of entries:\t45541", " Added entries:\t\t0", " Removed entries:\t\t0", " Changed entries:\t\t1", "", "---------------------------------------------------", "Changed entries:", "---------------------------------------------------", "", "f ... .C... : /etc/hosts", "", "---------------------------------------------------", "Detailed information about changes:", "---------------------------------------------------", "", "File: /etc/hosts", " SHA512 : YobgpcvAMPey0QX1lK4K+5EFySF1xrB/ | 7nIivvNa5ozfhOqSFLmPIiu6g04Wbx1n", " 9FRzTCPNC93+13Y5/lm2inC4x4rydlf2 | iGNf0/QTgFjaMGug8HywxTiO2PREZRNS", " EcvonCf3pHuXj6lEmAjBnw== | 3qNEi4Qm6an5inSY72sjfA==", "", "", "---------------------------------------------------", "The attributes of the (uncompressed) database(s):", "---------------------------------------------------", "", "/var/lib/aide/aide.db.gz", " MD5 : gMgRyMOExVAdOAvdgt4QDA==", " SHA1 : w7tmPKNvRYggY/JZ5wv+7ZdcSZM=", " RMD160 : CO0pK5tfg66MaO17YB8eaRuyyMw=", " TIGER : n8UbZJNt9gL672+pR9IPjoyhpAsUJ46O", " SHA256 : k8UHnv2CK4zYrfZN+bDp6SCcLkx21px6", " GNZlwySPKcY=", " SHA512 : DFw5wlBoJQOBCrs0ulvVxaMvoQk/oBEQ", " TkOmhfHAdevUWNAgCJ0KH0q26LsynEMj", " MWQpsGf7v12iACc4SP9ANA==", "", "", "End timestamp: 2024-03-29 05:16:50 -0400 (run time: 0m 27s)"]}
PLAY RECAP *********************************************************************
rhel9 : ok=2 changed=0 unreachable=0 failed=1 skipped=0 rescued=0 ignored=0An dieser Stelle wurde gezeigt, dass sowohl unveränderte Systeme als auch Systeme mit Veränderungen erkannt und gemeldet werden. Dabei muss natürlich niemand die Standardausgabe beobachten. Stattdessen kann Logging für Ansible Ausgaben konfiguriert werden.
Anwendungsfall 5: Update der AIDE-Datenbank
Dieser Anwendungsfall nimmt an, dass erfolgte Änderungen legitim sind und in die AIDE-Referenzdatenbank aufgenommen werden sollen. Dies geschieht wie folgt:
[root@ansible-ctrl ansible]# ansible-playbook aide.yml --tags update
PLAY [Example aide role invocation] ********************************************
TASK [Gathering Facts] *********************************************************
ok: [rhel9]
TASK [Include role aide] *******************************************************
TASK [aide : Update AIDE database] *********************************************
changed: [rhel9]
TASK [aide : Fetch AIDE database] **********************************************
changed: [rhel9]
TASK [aide : Remove remote AIDE database file] *********************************
changed: [rhel9]
PLAY RECAP *********************************************************************
rhel9 : ok=4 changed=3 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0Nachdem die Referenzdatenbank aktualisiert wurde, wird diese wieder auf den ACN kopiert und vom Zielsystem entfernt.
Das folgende Beispiel zeigt, dass auf dem Zielsystem der AIDE-Check nun ohne Fehler absolviert wird:
[root@ansible-ctrl ansible]# ansible-playbook aide.yml --tags check
PLAY [Example aide role invocation] ********************************************
TASK [Gathering Facts] *********************************************************
ok: [rhel9]
TASK [Include role aide] *******************************************************
TASK [aide : Copy AIDE reference database to remote] ***************************
changed: [rhel9]
TASK [aide : Check against AIDE reference database] ****************************
ok: [rhel9]
PLAY RECAP *********************************************************************
rhel9 : ok=3 changed=1 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0Ansible hat erkannt, dass die AIDE-Datenbank auf dem Zielhost nicht mit der aktuellen Referenzdatenbank übereinstimmt und hat letztere daher auf das Zielsystem übertragen. Die Überprüfung endet mit dem Status „ok“. Das System entspricht dem Soll-Zustand.
Zusammenfassung
Der Proof of Concept hat gezeigt, dass AIDE mit der verwendeten Ansible-Rolle ferngesteuert genutzt werden kann. AIDE-Datenbank und Konfigurationsdatei werden dabei getrennt von den verwalteten Systemen gespeichert und sind daher gegen Veränderung bei Kompromittierung der Zielsysteme geschützt. Bei Bedarf, wenn Ansible Abweichungen des Ist- zum Soll-Zustand erkennt, werden diese Dateien auf die Zielsysteme übertragen.
Der größte Arbeitsaufwand steckt in der Erstellung einer oder mehrerer AIDE-Konfigurationsdateien, die optimal zur eigenen Umgebung passen und möglichst keine falsch positiven Ergebnisse erzeugen. Dieser Aufwand besteht jedoch auch, wenn man AIDE ohne Ansible einsetzt.
Einen Punkt hat dieser PoC unberücksichtigt gelassen. Es nützt natürlich nichts, wenn man die Ausgaben der Playbooks nur protokolliert, die Protokolle jedoch nicht analysiert, um entsprechende Alarme in Monitoring- oder Ticket-Systemen zu erzeugen. Dies sei den Anwendern zur selbstständigen Übung überlassen. ;-)
