Beide Seiten der vorigen Revision Vorhergehende Überarbeitung Nächste Überarbeitung | Vorhergehende Überarbeitung |
linux:aide [09.04.2025 18:37. ] – Aide v0.19 django | linux:aide [07.09.2025 14:16. ] (aktuell) – [Lösung] Typofixing django |
---|
====== Host based Intrusion Detection System mit AIDE unter Arch Linux ====== | ====== Host based Intrusion Detection System mit AIDE unter Arch Linux ====== |
===== HIDS - was ist das und wozu nutzt man es? ===== | ===== HIDS - was ist das und wozu nutzt man es? ===== |
Die Absicherung von Systemen ist eine der Grund- und Pflichtaufgaben eines jeden verantwortungsbewussten Systemadministrators und Administratorin. Dass dies ist kein einmaliger sondern stetig sich wiederholende Vorgang ist, versteht sich in aller Regel von selbst, so ist es unter anderem wichtig, dass regelmäßig Systemüberprüfungen und Überwachung von Logmeldungen auf verdächtige und ungewöhnliche Ereignisse durchgeführt werden müssen. Zur Absicherung von Computersystem existieren unterschiedliche Ansätze. TLS-Transportverschlüsselung, SecureShell, oder Firewalls wird hier jedem interessierten Admin sofort in den Sinn kommen. Dabei gibt es zwei unterschiedliche Betrachtungsweisen/-richtungen bei den einzelnen Lösungen. Betrachtet und analysiert man in erster Linie Netzwerkverkehr in Netzwerken und/oder Zonengrenzen einzelner Netzwerke und bewertet hierzu entsprechende Protokolle von Netzwerkgeräten wie Switche, Router und Firewalls spricht man von einem **NIDS**, einem **N**etzwerk based **I**ntrusion **D**etection **S**ystem. Im Gegensatz dazu spricht man von einem **HIDS** **H**ost based **I**ntrusion **D**etection **S**ystem, wenn der Blick primär auf einem Host selbst erfolgt und man mit Hilfe lokaler Informationen Bewertungen über zulässige Änderungen am betreffenden System selbst Entscheidungen über (un)zulässige Änderungen treffen muss und möchte. Ein HIDS konzentriert sich dabei auf detailliertere und interne Angriffe, indem es die Überwachung auf Host-Aktivitäten konzentriert. Dabei versucht ein HIDS wie AIDE lediglich, Systemanomalien und somit Eindringlinge zu erkennen und hat nicht zur Aufgabe aktiv mögliche Angreifer und Bedrohungen zu blockieren! Ein Intrusion Detection System (wie AIDE) versucht lediglich, Eindringlinge zu erkennen, arbeitet aber nicht aktiv daran, ihren Zugang von vornherein zu blockieren. Im Gegensatz dazu arbeitet ein **IPS** ein **I**ntrusion **P**revention **S**ystem aktiv daran, Bedrohungen zu blockieren und den Benutzerzugriff zu überprüfen. | Die Absicherung von Systemen ist eine der Grund- und Pflichtaufgaben eines jeden verantwortungsbewussten Systemadministrators und Administratorin. Dass dies ist kein einmaliger sondern stetig sich wiederholende Vorgang ist, versteht sich in aller Regel von selbst, so ist es unter anderem wichtig, dass regelmässig Systemüberprüfungen und Überwachung von Logmeldungen auf verdächtige und ungewöhnliche Ereignisse durchgeführt werden müssen. Zur Absicherung von Computersystem existieren unterschiedliche Ansätze. TLS-Transportverschlüsselung, SecureShell, oder Firewalls wird hier jedem interessierten Admin sofort in den Sinn kommen. Dabei gibt es zwei unterschiedliche Betrachtungsweisen/-richtungen bei den einzelnen Lösungen. Betrachtet und analysiert man in erster Linie Netzwerkverkehr in Netzwerken und/oder Zonengrenzen einzelner Netzwerke und bewertet hierzu entsprechende Protokolle von Netzwerkgeräten wie Switche, Router und Firewalls spricht man von einem **NIDS**, einem **N**etzwerk based **I**ntrusion **D**etection **S**ystem. Im Gegensatz dazu spricht man von einem **HIDS** **H**ost based **I**ntrusion **D**etection **S**ystem, wenn der Blick primär auf einem Host selbst erfolgt und man mit Hilfe lokaler Informationen Bewertungen über zulässige Änderungen am betreffenden System selbst Entscheidungen über (un-)zulässige Änderungen treffen muss und möchte. Ein HIDS konzentriert sich dabei auf detailliertere und interne Angriffe, indem es die Überwachung auf Host-Aktivitäten konzentriert. Dabei versucht ein HIDS wie AIDE lediglich, Systemanomalien und somit Eindringlinge zu erkennen und hat nicht zur Aufgabe aktiv mögliche Angreifer und Bedrohungen zu blockieren! Ein Intrusion Detection System (wie AIDE) versucht lediglich, Eindringlinge zu erkennen, arbeitet aber nicht aktiv daran, ihren Zugang von vornherein zu blockieren. Im Gegensatz dazu arbeitet ein **IPS** ein **I**ntrusion **P**revention **S**ystem aktiv daran, Bedrohungen zu blockieren und den Benutzerzugriff zu überprüfen. |
| |
Weiterführende Informationen rund um Intrusion-Detection-Systeme findet man im **[[https://www.bsi.bund.de/DE/Service-Navi/Publikationen/Studien/IDS02/gr1_htm.html|BSI-Leitfaden zur Einführung von Intrusion-Detection-Systemen]]** bzw. im **[[https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/KRITIS/oh_sza_en.pdf|Orientation Guide to Using Intrusion Detection Systems (IDS)]]**. | Weiterführende Informationen rund um Intrusion-Detection-Systeme findet man im **[[https://www.bsi.bund.de/DE/Service-Navi/Publikationen/Studien/IDS02/gr1_htm.html|BSI-Leitfaden zur Einführung von Intrusion-Detection-Systemen]]** bzw. im **[[https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/KRITIS/oh_sza_en.pdf|Orientation Guide to Using Intrusion Detection Systems (IDS)]]**. |
* ctime | * ctime |
* atime | * atime |
* wachsende Größe | * wachsende Grösse |
* Anzahl von Links | * Anzahl von Links |
* Linknamen | * Linknamen |
| |
AIDE erstellt außerdem eine kryptografische Prüfsumme oder einen Hash jeder Datei unter Verwendung eines oder einer Kombination der folgenden Message-Digest-Algorithmen: | AIDE erstellt ausserdem eine kryptografische Prüfsumme oder einen hash-Wert jeder Datei unter Verwendung eines oder einer Kombination der folgenden Message-Digest-Algorithmen: |
* sha1 (deprecated seit AIDE v0.19, wird in AIDE v0.21 entfernt) | * sha1 (deprecated seit AIDE v0.19, wird in AIDE v0.21 entfernt) |
* sha256 | * sha256 |
**[[https://aide.github.io/|AIDE]]** ist ein Fork des bekannten HIDS **[[https://www.tripwire.com/|Tripwire]]** welches ursprünglich von Rami Lehti und Pablo Virolainen 1999 als freie Alternative zum kommerziellen Produkt Tripwire entwickelt wurde. Zwischen 2003 und 2010 wurde es von Richard van den Berg betreut. Seit Oktober 2010 übernahm Hannes von Haugwitz das Projekt. Die Homepage von AIDE ist **[[https://aide.github.io|hier]]** zu finden. Die aktuelle Version **''[[https://github.com/aide/aide/releases/tag/v0.19|v0.19]]''** von AIDE wird derzeit auf **[[https://github.com/aide/aide|GitHub]]** verwaltet. | **[[https://aide.github.io/|AIDE]]** ist ein Fork des bekannten HIDS **[[https://www.tripwire.com/|Tripwire]]** welches ursprünglich von Rami Lehti und Pablo Virolainen 1999 als freie Alternative zum kommerziellen Produkt Tripwire entwickelt wurde. Zwischen 2003 und 2010 wurde es von Richard van den Berg betreut. Seit Oktober 2010 übernahm Hannes von Haugwitz das Projekt. Die Homepage von AIDE ist **[[https://aide.github.io|hier]]** zu finden. Die aktuelle Version **''[[https://github.com/aide/aide/releases/tag/v0.19|v0.19]]''** von AIDE wird derzeit auf **[[https://github.com/aide/aide|GitHub]]** verwaltet. |
| |
In aller Regel wird ein Admin, nachdem ein neuer Host erstellt wurde, initial eine AIDE-Datenbank auf dem neuen System erstellen, bestenfalls bevor der neue Host produktiv mit dem Netzwerk verbunden wird. Diese initiale AIDE-Datenbank ist eine Momentaufnahme des Systems in seinem Normalzustand und ist der Maßstab, an dem alle nachfolgenden Aktualisierungen und Änderungen gemessen werden. Diese Datenbank sollte Informationen über die wichtigsten Systembinärdateien, Bibliotheken, Header-Dateien und alle Verzeichnisse sowie Dateien enthalten, die im Laufe der Zeit unverändert bleiben sollten. Dateien, welche sich häufig ändern, wie z.B. Log- und Protokolldateien Mail-Spools, proc-Dateisysteme, Home-Verzeichnisse von Benutzern oder temporäre Verzeichnisse, nimmt man in aller Regel nicht in die AIDE-Datenbank auf, das sonst später die Meldungen unnötig durch viele unerwünschte und erwartbare Meldungen überflutet werden würde. | In aller Regel wird ein Admin, nachdem ein neuer Host erstellt wurde, initial eine AIDE-Datenbank auf dem neuen System erstellen, bestenfalls bevor der neue Host produktiv mit dem Netzwerk verbunden wird. Diese initiale AIDE-Datenbank ist eine Momentaufnahme des Systems in seinem Normalzustand und ist der Massstab, an dem alle nachfolgenden Aktualisierungen und Änderungen gemessen werden. Diese Datenbank sollte Informationen über die wichtigsten Systembinärdateien, Bibliotheken, Header-Dateien und alle Verzeichnisse sowie Dateien enthalten, die im Laufe der Zeit unverändert bleiben sollten. Dateien, welche sich häufig ändern, wie z.B. Log- und Protokolldateien Mail-Spools, proc-Dateisysteme, home-Verzeichnisse von Benutzern oder temporäre Verzeichnisse, nimmt man in aller Regel nicht in die AIDE-Datenbank auf, das sonst später die Meldungen unnötig durch viele unerwünschte und erwartbare Meldungen überflutet werden würde. |
| |
Durch erneutes Ausführen von AIDE zur Systemüberprüfung kann ein Systemadministrator Änderungen an systemrelevanten Verzeichnissen und Dateien schnell erkennen und sich ziemlich sicher sein, dass die protokollierten Ergebnisse korrekt sind. | Durch erneutes Ausführen von AIDE zur Systemüberprüfung kann ein Systemadministrator Änderungen an systemrelevanten Verzeichnissen und Dateien schnell erkennen und sich ziemlich sicher sein, dass die protokollierten Ergebnisse korrekt sind. |
| |
==== Installation ==== | ==== Installation ==== |
AIDE kann unter Arch Linux nicht einfach aus dem Core- oder Extras-Repository mit Hilfe des Paketverwaltungswerkzeugs **''pacman''** installiert werden. Jedoch gibt es aus dem **[[https://aur.archlinux.org/packages?O=0&K=aide|Arch User Repository]]** kurz **AUR**, dem Community verwaltetes Repository für Benutzer von Arch Linux, eine Paketbeschreibungen (**''PKGBUILDs''**), mit denen Sie ein Paket aus dem Quellcode mit **''makepkg''** kompilieren und dann über **''pacman''** installieren kann. Möchte man auf den entsprechenden Zielsystemen die hierzu nötigen Kompilierungswerkzeuge nicht vorhalten, so kann man das Paket auch auf einem entsprechenden geschützten Buildhost erstellen und dann lokal, auf dem entsprechendem Zielsystem mit Hilfe von **''pacman''** installieren. | AIDE kann unter Arch Linux __nicht__ einfach aus dem Core- oder Extras-Repository mit Hilfe des Paketverwaltungswerkzeugs **''pacman''** installiert werden. Jedoch gibt es aus dem **[[https://aur.archlinux.org/packages?O=0&K=aide|Arch User Repository]]** kurz **AUR**, dem Community verwaltetes Repository für Benutzer von Arch Linux, eine Paketbeschreibungen (**''PKGBUILDs''**), mit denen Sie ein Paket aus dem Quellcode mit **''makepkg''** kompilieren und dann über **''pacman''** installieren kann. Möchte man auf den entsprechenden Zielsystemen die hierzu nötigen Kompilierungswerkzeuge nicht vorhalten, so kann man das Paket auch auf einem entsprechenden geschützten Buildhost erstellen und dann lokal, auf dem entsprechendem Zielsystem mit Hilfe von **''pacman''** installieren. |
| |
Da bei der Installation bzw. beim Kompilieren die Integrität des Quell-Archives an Hand dessen PGP-Signatur geprüft wird, ist es notwendig dass der PGP-Schlüssel mit der Key-ID **''F6947DAB68E7B931''** von **[[mailto:hannes@vonhaugwitz.com|Hannes von Haugwitz]]** in unserem Keyring vorhanden ist. Hierzu importieren wir zuerst den betreffenden Public-Key von Hannes: | Da bei der Installation bzw. beim Kompilieren die Integrität des Quell-Archives an Hand dessen PGP-Signatur geprüft wird, ist es notwendig dass der PGP-Schlüssel mit der Key-ID **''F6947DAB68E7B931''** von **[[mailto:hannes@vonhaugwitz.com|Hannes von Haugwitz]]** in unserem Keyring vorhanden ist. Hierzu importieren wir zuerst den betreffenden Public-Key von Hannes: |
</WRAP> | </WRAP> |
* Logging : Der Parameter **''report_url''** legt fest wie **AIDE** Ergebnisse seiner Arbeit dokumentieren soll. \\ **''report_url=file:@@{LOGDIR}/aide.log''** definiert z.B. - sofern als **''LOGDIR %%==%% /var/log/''** gesetzt ist, dass die Ergebnisse in der Logdatei **''/var/log/aide.log''** festgehalten werden. \\ **'' | * Logging : Der Parameter **''report_url''** legt fest wie **AIDE** Ergebnisse seiner Arbeit dokumentieren soll. \\ **''report_url=file:@@{LOGDIR}/aide.log''** definiert z.B. - sofern als **''LOGDIR %%==%% /var/log/''** gesetzt ist, dass die Ergebnisse in der Logdatei **''/var/log/aide.log''** festgehalten werden. \\ **'' |
report_url=stdout''** wiederum definiert als Ausgabe die Konsole. Dies kann hilfreich sein, wenn auf einem Host manuell der Aufruf von **''aide''** auf der Konsole ausgegeben werden soll. \\ **''report_url=syslog:LOG_AUTH''** definiert als Logziel das Sys(tem)log|journal. \\ <WRAP center round important 100%>Wenn man sowohl **''report_url = stdout''** als auch **''report_url = syslog''** in der Aide-Konfiguration vermerkt, protokolliert Aide den Bericht sowohl nach **stdout** als auch nach **syslog**. Der systemd-Timer leitet **stdout** normalerweise auch an das Journal weiter, sodass die Berichtsausgabe dabei zweimal in syslog erscheint!</WRAP> | report_url=stdout''** wiederum definiert als Ausgabe die Konsole. Dies kann hilfreich sein, wenn auf einem Host manuell der Aufruf von **''aide''** auf der Konsole ausgegeben werden soll. \\ **''report_url=syslog:LOG_AUTH''** definiert als Logziel das Sys(tem)log|journal. \\ |
* Anschließend sollte man sich Gedanken machen, welche Hashingalgorithmen verwendet werden sollen. In den Standardeinstellungen bildet AIDE sieben verschiedene Prüfsummen für jede überwachte Datei. Zu beachten ist hierbei ggf. ob der bei der Erzeugung der Hash-Werte benötige Rechenaufwand gerechtfertigt ist, oder ob man auf einige davon aus Performancegründen besser verzichtet! In der Regel sollten eigentlich zwei verschiedene Hash-Werte Pro Datei ausreichen. \\ \\ | * Anschließend sollte man sich Gedanken machen, welche Hashingalgorithmen verwendet werden sollen. In den Standardeinstellungen bildet AIDE sieben verschiedene Prüfsummen für jede überwachte Datei. Zu beachten ist hierbei ggf. ob der bei der Erzeugung der Hash-Werte benötige Rechenaufwand gerechtfertigt ist, oder ob man auf einige davon aus Performancegründen besser verzichtet! In der Regel sollten eigentlich zwei verschiedene Hash-Werte Pro Datei ausreichen. \\ \\ |
* Ferner kann über Regelsätze definiert werden welche Eigenschaften (Parameter) von Verzeichnissen und/oder Dateien überwacht werden sollen. Hier können entsprechende Vorgaben in der Default-Konfigurationsdatei übernommen bzw. auch ganz eigene individuelle Rule-Sets definiert werden. Folgende Parameter können dabei bei der Bewertung und Überwachung herangezogen werden: | * Ferner kann über Regelsätze definiert werden welche Eigenschaften (Parameter) von Verzeichnissen und/oder Dateien überwacht werden sollen. Hier können entsprechende Vorgaben in der Default-Konfigurationsdatei übernommen bzw. auch ganz eigene individuelle Rule-Sets definiert werden. Folgende Parameter können dabei bei der Bewertung und Überwachung herangezogen werden: |
-O - | tar -xz --strip-components=1 -C ~/devel/ansible</code> | -O - | tar -xz --strip-components=1 -C ~/devel/ansible</code> |
| |
Nach Anpassung der Daten im Inventory kann man anschließend direkt **[[#ausfuehrung_-_playbooklauf|zur Ausführung schreiten]]**. | Nach Anpassung der Daten im Inventory kann man anschliessend direkt **[[#ausfuehrung_-_playbooklauf|zur Ausführung schreiten]]**. |
</WRAP> | </WRAP> |
| |
* **''group: arch''** | * **''group: arch''** |
* **''hostname: pml010070''** | * **''hostname: pml010070''** |
* **''hostname: pml010070''** | * **''hostname: pml010074''** |
| |
Die Konfigurationsdatei unseres **inventory** in unsere, Ansible-Verzeichnis beinhaltet demnach unter anderem: | Die Konfigurationsdatei unseres **inventory** in unsere, Ansible-Verzeichnis beinhaltet demnach unter anderem: |
===== Fazit und Ausblick ===== | ===== Fazit und Ausblick ===== |
<WRAP center round tip 80%> | <WRAP center round tip 80%> |
Mit **AIDE** haben wir nun ein Instrument an der Hand, mit der wir die Dateisysteme unserer Host einfach auf Anomalien hin überwachen kann. Mit Hilfe unseres Ansible-Playbooks können wir nun auch nicht nur die Installation und Konfiguration des Aide-Daemon erledigen, sondern auch einfach die jeweiligen AIDE-Datenbanken der Hosts nach Änderungen durch den Admin bzw. bei Updates oder Ansible-Läufen, aktualisieren und automatisiert zum zentralen internen Repository-/Spiegelserver transferieren. Somit erübrigt sich ein Aufwändiges Signieren oder Wegsichern der Datenbank auf RO-Devices. Die AIDE-Datenbanken wir somit getrennt von den verwalteten Systemen gespeichert und ist folglich vor ungewollten Änderungen geschützt, sollte ein Remote-System kompromittiert worden sein! | Mit **AIDE** haben wir nun ein Instrument an der Hand, mit der wir in der Lage sind die Dateisysteme unserer Host einfach auf Anomalien hin zu überwachen. Mit Hilfe unseres Ansible-Playbooks können wir nun auch nicht nur die Installation und Konfiguration des Aide-Daemon erledigen, sondern auch einfach die jeweiligen AIDE-Datenbanken der Hosts nach Änderungen durch den Admin bzw. bei Updates oder Ansible-Läufen, aktualisieren und automatisiert zum zentralen internen Repository-/Spiegelserver transferieren. Somit erübrigt sich ein aufwendiges Signieren oder Wegsichern der Datenbank auf **ro**-Devices. Die AIDE-Datenbanken wir somit getrennt von den verwalteten Systemen gespeichert und ist folglich vor ungewollten Änderungen geschützt, sollte ein Remote-System kompromittiert worden sein! |
| |
In diesem Konfigurationsbeispiel wurde lediglich aufgezeigt, wie man einfach mit Hilfe von Ansible installieren, konfigurieren und Datenbanken der Host erstellen und weg sichern kann. Die AIDE-Protokolldateien müssen nun natürlich entsprechend überwacht und ausgewertet werden! Diesen Aspekt werden wir uns noch eingehend bei unserer Installation und Konfiguration eines zentralen Logauswertungstool wie z.B. [[centos:web_c7:graylog2|graylog]] | In diesem Konfigurationsbeispiel wurde lediglich aufgezeigt, wie man einfach mit Hilfe von Ansible installieren, konfigurieren und Datenbanken der Host erstellen und weg sichern kann. Die AIDE-Protokolldateien müssen nun natürlich entsprechend überwacht und ausgewertet werden! Diesen Aspekt werden wir uns noch eingehend bei unserer Installation und Konfiguration eines zentralen Logauswertungstool wie z.B. [[centos:web_c7:graylog2|graylog]] |