Dies ist eine alte Version des Dokuments!


Host based Intrusion Detection System mit AIDE unter Arch Linux

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 Betrachungsweisen/-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 Netzwerk based Intrusion Detection System. Im Gegensatz dazu spricht man von einem HIDS Host based Intrusion Detection System, 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 Intrusion Prevention System aktiv daran, Bedrohungen zu blockieren und den Benutzerzugriff zu überprüfen.

Weiterführende Informationen rund um Intrusion-Detection-Systeme findet man im BSI-Leitfaden zur Einführung von Intrusion-Detection-Systemen bzz im Orientation Guide to Using Intrusion Detection Systems (IDS).

Eine der Herausforderungen bei der Verwendung von HIDS besteht darin, dass es auf jedem einzelnen Host installiert, konfiguriert und entsprechende Berichte bzw. Logdateien dann auch bewertet werden muss, der vor Eindringlingen geschützt werden soll. Dies kann je nach zur Verfügung stehender Ressourcen zu einer Verlangsamung der Leistung des Hosts und eines eingesetzten HIDS führen. Wir werden uns später daher die Installation und Konfiguration mit Hilfe von Ansible vornehmen. Zur Auswertung der Logmeldungen greifen wir in unserer Umgebung auf graylog zurück.

AIDE (Advanced Intrusion Detection Environment) ist ein HIDS, ein Programm zur Erkennung von Eindringlingen, indem es die Integrität von Verzeichnissen und Dateien überwacht.

Hierzu erstellt AIDE auf Basis seiner Konfiguration bei der Erstinitialisierung oder bewusst nach Änderungen am System durch einen entsprechenden Programmaufruf, eine Datenbank des aktuellen Systems. In dieser AIDE-Datenbank werden verschiedene Verzeichnis- und Dateiattribute gespeichert, darunter:

  • Berechtigungen
  • Inode-Nummern
  • Benutzer
  • Gruppen
  • Dateigrössen
  • mtime
  • ctime
  • atime
  • wachsende Grösse
  • Anzahl von Links
  • Linknamen

AIDE erstellt ausserdem eine kryptografische Prüfsumme oder einen Hash jeder Datei unter Verwendung eines oder einer Kombination der folgenden Message-Digest-Algorithmen:

  • sha1
  • sha256
  • sha512
  • md5
  • rmd160
  • tiger
  • gost und whirlpool können kompiliert werden, sofern mhash-Unterstützung verfügbar ist.

Darüber hinaus können die erweiterten Attribute verwendet werden, sofern sie während der Kompilierung explizit aktiviert werden:

  • acl
  • xattr
  • selinux

Wichtig
AIDE führt auf dem System selbst nur Dateiintegritätsprüfungen durch! Es sucht nicht nach rootkits oder analysiert Protokolldateien auf verdächtige Aktivitäten!

AIDE ist ein Fork des bekannten HIDS 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 hier zu finden. Die aktuelle Version von AIDE wird derzeit auf 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 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.

ACHTUNG:
Ein Admin muss sich aber auch im Klaren sein, dass auch mit AIDE keine absulute Sicherheit gewährleistet werden kann, denn wie alle anderen Systemdateien können auch die Binär- und/oder Datenbankdateien von AIDE komprommitiert werden können!

Ebenso ist vor allem in orchestrierten Umgebungen (Puppet) darauf zu achten, dass nicht etwa ein gerade initiierter Datenbank-Update durch einen Puppet-Agent Lauf abgebrochen wird. So stünde im Extremfall keine aktuelle und valide Datenbank für spätere Systemchecks zur Verfügung, was zu unzähligen false-positive Meldungen führen würde. Die Reputation des HIDS bei den Administratoren wäre in einem solch einem Fall dahin und der erhoffte bzw. geforderte Erfolg mehr als fraglich!

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 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 Hannes von Haugwitz in unserem Keyring vorhanden ist. Hierzu importieren wir zuerst den betreffenden Public-Key von Hannes:

 $ gpg --recv-key 18EE86386022EF57
gpg: key F6947DAB68E7B931: public key "Hannes von Haugwitz <hannes@vonhaugwitz.com>" imported
gpg: Total number processed: 1
gpg:               imported: 1

Mit Hilfe von $ gpg --list-keys können wir uns bei Bedarf vergewissern, ob der Schlüssel von Hannes vorliegt:

 $ gpg --list-keys
...

pub   rsa4096 2011-06-28 [C] [expires: 2026-06-27]
      2BBBD30FAAB29B3253BCFBA6F6947DAB68E7B931
uid           [ unknown] Hannes von Haugwitz <hannes@vonhaugwitz.com>
uid           [ unknown] Hannes von Haugwitz <hvhaugwitz@debian.org>
sub   rsa3072 2011-06-28 [E] [expires: 2025-06-27]
sub   rsa3072 2011-06-28 [A] [expires: 2025-06-27]
sub   rsa3072 2011-06-28 [S] [expires: 2025-06-27]

Installation von AIDE mit Hilfe von Pikaur

Darf man aus Sicherheitsgründen auf allen Zielsystemen keine Kompilierwerkzeuge vorhalten, so holt man sich das vom eigenen Maintainer erstellen Paketes vom eigenen internen Repo-Server und installiert das Paket mit Hilfe von pacman lokal wie folgt:

Lokale Installation von AIDE mit Hilfe von Pacman

Bevor das Programm AIDE gestartet werden kann muss es allerdings konfiguriert werden!

Die Dokumentation von AIDE findet man in der Datei README im Git Repository.

Paketinfo

Was uns das Paket alles ins System gebracht hat finden wir am einfachsten mit Hilfe von pacman -Qil heraus.

Ausgabe der Befehls pacman -Qil aide

Programminfo

Bei Bedarf können wir uns alle Optionen mit denen das AIDE-Binary gebaut wurde zusammen mit den Default Konfigurationsparametern, den verfügbaren einkompilierten Attributen, den verfügbaren Hass-Attributen sowie den defaultmässigen Compound Groups uns anzeigen lassen.

Ausgabe der Befehls aide -v

Manpages

Manual-Page aide

Manual-Page aide.conf

Die Konfiguration wird über die Dateien /etc/aide/aide.conf vorgenommen. Um später Änderungen und Neuerungen bei Paketupdates besser verfolgen zu können kopieren wir uns als erstes die mitgelieferte Konfigurationsdatei aide.conf.

 # cp -av /etc/aide/aide.conf /etc/aide/aide.conf.orig

So können wir später leichter Änderungen mit Hilfe von vimdiff vergleichen!

Anpassungen und Änderungen an der Konfiguration nehmen mit mit dem Editor unserer Wahl , wie z.B. vim vor.

 # sudo vim /etc/aide/aide.conf
/etc/aide/aide.conf
# Example configuration file for AIDE.
# More information about configuration options available in the aide.conf manpage.
# Inspired from https://src.fedoraproject.org/rpms/aide/raw/rawhide/f/aide.conf
 
# ┌───────────────────────────────────────────────────────────────┐
# │ CONTENTS OF aide.conf                                         │
# ├───────────────────────────────────────────────────────────────┘
# │
# ├──┐VARIABLES
# │  ├── DATABASE
# │  └── REPORT
# ├──┐RULES
# │  ├── LIST OF ATTRIBUTES
# │  ├── LIST OF CHECKSUMS
# │  └── AVAILABLE RULES
# ├──┐PATHS
# │  ├──┐EXCLUDED
# │  │  ├── ETC
# │  │  ├── USR
# │  │  └── VAR
# │  └──┐INCLUDED
# │     ├── ETC
# │     ├── USR
# │     ├── VAR
# │     └── OTHERS
# │
# └───────────────────────────────────────────────────────────────
 
# ################################################################ VARIABLES
 
# ################################ DATABASE
 
@@define DBDIR /var/lib/aide
@@define LOGDIR /var/log/aide
 
# The location of the database to be read.
database_in=file:@@{DBDIR}/aide.db.gz
 
# The location of the database to be written.
#database_out=sql:host:port:database:login_name:passwd:table
#database_out=file:aide.db.new
database_out=file:@@{DBDIR}/aide.db.new.gz
 
# Whether to gzip the output to database
gzip_dbout=yes
 
# ################################ REPORT
 
# Default.
log_level=warning
report_level=changed_attributes
 
report_url=file:@@{LOGDIR}/aide.log
report_url=stdout
#report_url=stderr
#NOT IMPLEMENTED report_url=mailto:root@foo.com
#NOT IMPLEMENTED report_url=syslog:LOG_AUTH
 
# ################################################################ RULES
 
# ################################ LIST OF ATTRIBUTES
 
# These are the default parameters we can check against.
#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 (must be enabled at compilation time)
#xattrs:        Extended file attributes
 
# ################################ LIST OF CHECKSUMS
 
#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)
 
# ################################ AVAILABLE RULES
 
# These are the default rules
#R:             p+i+l+n+u+g+s+m+c+md5
#L:             p+i+l+n+u+g
#E:             Empty group
#>:             Growing logfile p+l+u+g+i+n+S
 
# You can create custom rules - my home made rule definition goes like this 
ALLXTRAHASHES = sha1+rmd160+sha256+sha512+whirlpool+tiger+haval+gost+crc32
ALLXTRAHASHES = sha1+rmd160+sha256+sha512+tiger
# Everything but access time (Ie. all changes)
EVERYTHING = R+ALLXTRAHASHES
 
# Sane, with multiple hashes
# NORMAL = R+rmd160+sha256+whirlpool
# NORMAL = R+sha256+sha512
NORMAL = p+i+l+n+u+g+s+m+c+sha256
 
# For directories, don't bother doing hashes
DIR = p+i+n+u+g+acl+xattrs
 
# Access control only
PERMS = p+i+u+g+acl
 
# Logfile are special, in that they often change
LOG = >
 
# Just do sha256 and sha512 hashes
FIPSR = p+i+n+u+g+s+m+c+acl+xattrs+sha256
LSPP = FIPSR+sha512
 
# Some files get updated automatically, so the inode/ctime/mtime change
# but we want to know when the data inside them changes
DATAONLY = p+n+u+g+s+acl+xattrs+sha256
 
# ################################################################ PATHS
 
# Next decide what directories/files you want in the database.
 
# ################################ EXCLUDED
 
# ################ ETC
 
# Ignore backup files
!/etc/.*~
 
# Ignore mtab
!/etc/mtab
 
# ################ USR
 
# These are too volatile
!/usr/src
!/usr/tmp
 
# ################ VAR
 
# Ignore logs
!/var/lib/pacman/.*
!/var/cache/.*
!/var/log/.*  
!/var/log/aide.log
!/var/run/.*  
!/var/spool/.*
 
# ################################ INCLUDED
 
# ################ ETC
 
# Check only permissions, inode, user and group for /etc, but cover some important files closely.
/etc                               PERMS
/etc/aliases                       FIPSR
/etc/at.allow                      FIPSR
/etc/at.deny                       FIPSR
/etc/audit/                        FIPSR
/etc/bash_completion.d/            NORMAL
/etc/bashrc                        NORMAL
/etc/cron.allow                    FIPSR
/etc/cron.daily/                   FIPSR
/etc/cron.deny                     FIPSR
/etc/cron.d/                       FIPSR
/etc/cron.hourly/                  FIPSR
/etc/cron.monthly/                 FIPSR
/etc/crontab                       FIPSR
/etc/cron.weekly/                  FIPSR
/etc/cups                          FIPSR
/etc/exports                       NORMAL
/etc/fstab                         NORMAL
/etc/group                         NORMAL
/etc/grub/                         FIPSR
/etc/gshadow                       NORMAL
/etc/hosts.allow                   NORMAL
/etc/hosts.deny                    NORMAL
/etc/hosts                         FIPSR
/etc/inittab                       FIPSR
/etc/issue                         FIPSR
/etc/issue.net                     FIPSR
/etc/ld.so.conf                    FIPSR
/etc/libaudit.conf                 FIPSR
/etc/localtime                     FIPSR
/etc/login.defs                    FIPSR
/etc/login.defs                    NORMAL
/etc/logrotate.d                   NORMAL
/etc/modprobe.conf                 FIPSR
/etc/nscd.conf                     NORMAL
/etc/pam.d                         FIPSR
/etc/passwd                        NORMAL
/etc/postfix                       FIPSR
/etc/profile.d/                    NORMAL
/etc/profile                       NORMAL
/etc/rc.d                          FIPSR
/etc/resolv.conf                   DATAONLY
/etc/securetty                     FIPSR
/etc/securetty                     NORMAL
/etc/security                      FIPSR
/etc/security/opasswd              NORMAL
/etc/shadow                        NORMAL
/etc/skel                          NORMAL
/etc/ssh/ssh_config                FIPSR
/etc/ssh/sshd_config               FIPSR
/etc/stunnel                       FIPSR
/etc/sudoers                       NORMAL
/etc/sysconfig                     FIPSR
/etc/sysctl.conf                   FIPSR
/etc/vsftpd.ftpusers               FIPSR
/etc/vsftpd                        FIPSR
/etc/X11/                          NORMAL
/etc/zlogin                        NORMAL
/etc/zlogout                       NORMAL
/etc/zprofile                      NORMAL
/etc/zshrc                         NORMAL
 
# ################ USR
 
/usr                               NORMAL
/usr/sbin/stunnel                  FIPSR
 
# ################ VAR
 
/var/log/faillog                   FIPSR
/var/log/lastlog                   FIPSR
/var/spool/at                      FIPSR
/var/spool/cron/root               FIPSR
 
# ################ OTHERS
 
/boot                              NORMAL
/bin                               NORMAL
/lib                               NORMAL
/lib64                             NORMAL
/opt                               NORMAL
/root                              NORMAL

Wie eigentlich immer bei der Konfiguration von neuen Programmen lohnt es sich die zugehörige Konfigurationsdatei - in unserem Falle von AIDE die /etc/aide.conf einmal komplett zu lesen! So erhält man einen Überblick welche Einstellungsoptionen uns AIDE grundsätzlich bietet.

  • Die ersten Einstellungen die man sich überlegen sollte, wären wo die Datenbanken erstellt und vorgehalten werden sollen und ob diese gepackt werden sollen.
  • Anschließend sollte man sich Gedanken machen, welche Hashingalgorithmen verwendet werden sollen. In den Standardeinstellungen bildet AIDE sieben verschiedene Checksummen 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 solten 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 individiuelle Rule-Sets definiert werden. Folgende Parameter können dabei bei der Bewertung und Überwachung herangezogen werden:
    • p: Überprüfen Sie die Dateiberechtigungen der ausgewählten Dateien oder Verzeichnisse.
    • i: Überprüfen Sie die Inode-Nummer. Jeder Dateiname hat eine eindeutige Inode-Nummer, die sich nicht ändern sollte.
    • n: Überprüfen Sie die Anzahl der Links, die auf die betreffende Datei verweisen.
    • u: Überprüfen Sie, ob sich der Eigentümer der Datei geändert hat.
    • g: Überprüfen Sie, ob sich die Gruppe der Datei geändert hat.
    • s: Überprüfen Sie, ob sich die Dateigröße geändert hat.
    • b: Prüfen, ob sich die von der Datei verwendete Blockanzahl geändert hat.
    • m: Prüfen, ob sich das Änderungsdatum der Datei geändert hat.
    • c: Prüfen, ob sich die Zugriffszeit der Datei geändert hat.
    • S: Auf eine geänderte Dateigröße prüfen.
    • I: Änderungen des Dateinamens ignorieren.
      Folgende Hash-Werte können bei der berechnung der Prüfsummen verwendet werden:
    • md5: md5 Prüfsumme (Die Verwendung von sha256 oder sha512 ist hier empfohlen.)
    • sha1: sha1 Prüfsumme (Die Verwendung von sha256 oder sha512 ist hier empfohlen.)
    • sha256: sha256 Prüfsumme
    • sha512: sha512 Prüfsumme
    • rmd160: rmd160 Prüfsumme
    • tiger: tiger Prüfsumme
    • haval: haval Prüfsumme (MHASH only)
    • gost: gost Prüfsumme (MHASH only)
    • crc32: crc32 Prüfsumme (MHASH only)
    • whirlpool: whirlpool Prüfsumme (MHASH only)
  • Zum Schluß muss man sich noch Gedanken machen welche Dateien und Verzeichniss ggf. ausgenommen werden sollen und welche Dateien und Verzeichnisse man in welcher Tiefe überwachen möchte. Die manpage zu aide.conf liefert hierzu wertvolle und tiefergehende Informationen!

Ist man mit der Konfiguration von AIDE soweit zufrieden und fertig, ist man gut beraten mit Hilfe der Option --config-check oder kurz -D einen Syntax-Check der Konfigurationsdatei vorzunehmen.

 # aide --config-check

AIDE Command Options

Bevor wir nun die AIDE-Datenbank initial erstellen, werfen wir noch kurz einen Blick auf die Optionen, die bei Aufruf von aide bei Bedarf verwendet werden können.

 # aide --help
AIDE 0.18.8 

Usage: aide [options] command

Commands:
  -i, --init		Initialize the database
  -n, --dry-init	Traverse the file system and match each file against rule tree
  -C, --check		Check the database
  -u, --update		Check and update the database non-interactively
  -E, --compare		Compare two databases

Miscellaneous:
  -D,			--config-check			Test the configuration file
  -p FILE_TYPE:PATH	--path-check=FILE_TYPE:PATH	Match file type and path against rule tree
  -v,			--version			Show version of AIDE and compilation options
  -h,			--help				Show this help message

Options:
  -c CFGFILE	--config=CFGFILE	Get config options from CFGFILE
  -l REGEX	--limit=REGEX		Limit command to entries matching REGEX
  -B "OPTION"	--before="OPTION"	Before configuration file is read define OPTION
  -A "OPTION"	--after="OPTION"	After configuration file is read define OPTION
  -L LEVEL	--log-level=LEVEL	Set log message level to LEVEL
  -W WORKERS	--workers=WORKERS	Number of simultaneous workers (threads) for file attribute processing (i.a. hashsum calculation)

Datenbank erstellen

Zunächst erstellen wir initial unsere AIDE Datenbank entsprechend unserer zuvor definierten Parameter.

[django@pml010074 ~]$ sudo aide --init
Start timestamp: 2025-02-09 13:17:55 +0100 (AIDE 0.18.8)
AIDE successfully initialized database.
New AIDE database written to /var/lib/aide/aide.db.new.gz

Number of entries:	470065

---------------------------------------------------
The attributes of the (uncompressed) database(s):
---------------------------------------------------

/var/lib/aide/aide.db.new.gz
 MD5       : akLMQIg8ljGsrqITWUMmXQ==
 SHA1      : uobft85sR3iSd/wzsu4PniRHjeM=
 SHA256    : X5dNJKwN1CMso7uEyG3Kl0HhINFukXYU
             nYBsXz2aSMo=
 SHA512    : DLG7d3whDo3s70PJZi4URK3ci/rScE9t
             YBrKfqpm/AjNnQywrQPv8AcjX7/TOMAH
             8ihTjdCy5LAD3ZlfdJYC7g==
 RMD160    : zKkglTAFd6tCn+zxVzNTjeegJG0=
 TIGER     : Hj2m4H+yydhksoj0wMAAE5CWQu1TqXHz
 CRC32     : fv1+yQ==
 WHIRLPOOL : IgsuYwxy+0OvCYShwQsQmpC/V0ibURuy
             +U3PpE0jtafK8ct3zRj+1wP6L8qSBecU
             uR+4N66Mn7NBhJl8+GkmEw==
 GOST      : 8jdDWTrwWuHxDouI5CKySf8zrAyt5jem
             jUXKnFWkCeo=
 STRIBOG256: /FuAlw3yffSGNWpoUwfKO/wgYkrbZ02U
             NEbUlsM1RX8=
 STRIBOG512: c2uv2hcchsbSE681IRNXu78ntDz2ZF60
             XoxZNbkLev2ZUkvGPhfhxvFWomZfSXiW
             /fnsqLQg6W/kSikrQJrHIw==


End timestamp: 2025-02-09 13:22:34 +0100 (run time: 4m 39s)

positive Prüfen des Filesystems gegen die Datenbank

Mit der Option --check bzw. -C könne wir nun eine Überprüfung des Dateisystems gegen die zuvor erstellte AIDE-Datenbank durchführen.

[django@pml010074 ~]$ sudo aide --check
Start timestamp: 2025-02-09 16:47:30 +0100 (AIDE 0.18.8)
AIDE found NO differences between database and filesystem. Looks okay!!

Number of entries:	470065

---------------------------------------------------
The attributes of the (uncompressed) database(s):
---------------------------------------------------

/var/lib/aide/aide.db.gz
 MD5       : jyY8ktcG+E5Kq0AtGA5YGQ==
 SHA1      : KogexIU6LuOslIB81mGvMSL1rYo=
 SHA256    : QyabDWuO37ZO+xzXmPF28qT7t5WJdSB2
             EwwNVmU1Rlc=
 SHA512    : LrcRp1//aeMxufbKBbodCM1YA0NU5EtP
             QdriP1Uh+A7qFULU4WjK9qolnNfZLuDY
             kIPg9LY+g0q1j75Z44T1dA==
 RMD160    : 51KDSlTiMtIXqe+VQ6A3pDN/uZ8=
 TIGER     : 8A61b3JqbPNltkAPxvVgQ7UON2AlRn3q
 CRC32     : IpaktA==
 WHIRLPOOL : dcQVsfrdV7TGbpAyhNATDGFQ8c7mBG4O
             cX7ZufgFpa8seOIs+gyWHjeWUq4FCsk4
             U0qZ+Ela67DDrsVkN5xGCA==
 GOST      : ltIg5YJ+6BFVE5kbORVh3gRGbwJ4EP0/
             8iJY8o51fUo=
 STRIBOG256: lmE/qdAVUeE4zEbd7WBISCDXWsUb1bGJ
             FxSlN0RABQ4=
 STRIBOG512: Ox8c77PeIe0dCgFLPawLqWYzMK/9inc4
             FPH6aHMBchh4ctW71d4wZwy3/f42ZUG6
             xz7VX4MQ+X0SFz28//jSsg==


End timestamp: 2025-02-09 16:53:10 +0100 (run time: 5m 40s)

Die Zeile:

AIDE found NO differences between database and filesystem. Looks okay!!

zeigt uns an, dass es keine Änderungen im und am System gab.

negative Prüfen des Filesystems gegen die Datenbank

Im nächsten Beispiel kompromittieren wir unser System, in dem wir von einem bestehenden Binary einen vermeintlichen bösen Klone erstellen:

 # cp /usr/bin/sg /usr/bin/sg_evil_copy

Führen wir erneut eine Überprüfung unseres Systems aus, sollte die neue unbekannte Datei entsprechend detektiert werden.

[django@pml010074 ~]$ sudo aide --check
Start timestamp: 2025-02-09 18:09:12 +0100 (AIDE 0.18.8)
AIDE found differences between database and filesystem!!

Summary:
  Total number of entries:	470065
  Added entries:		1
  Removed entries:		1
  Changed entries:		5

---------------------------------------------------
Added entries:
---------------------------------------------------

f+++++++++++++++: /usr/bin/sg_evil_copy

---------------------------------------------------
Removed entries:
---------------------------------------------------

f---------------: /root/.cache/vim/swap/%etc%aide.conf.swp

---------------------------------------------------
Changed entries:
---------------------------------------------------

d = ... mc..    : /root
d < ... mc..    : /root/.cache/vim/swap
f > ... mci.H   : /root/.lesshst
f < ... mci.H   : /root/.viminfo
d > ... mc..    : /usr/bin

---------------------------------------------------
Detailed information about changes:
---------------------------------------------------

Directory: /root
 Mtime     : 2025-02-09 13:17:48 +0100        | 2025-02-09 18:04:06 +0100
 Ctime     : 2025-02-09 13:17:48 +0100        | 2025-02-09 18:04:06 +0100

Directory: /root/.cache/vim/swap
 Size      : 36                               | 0
 Mtime     : 2025-02-09 15:17:08 +0100        | 2025-02-09 17:54:25 +0100
 Ctime     : 2025-02-09 15:17:08 +0100        | 2025-02-09 17:54:25 +0100

File: /root/.lesshst
 Size      : 108                              | 120
 Mtime     : 2024-07-23 20:50:00 +0200        | 2025-02-09 18:04:06 +0100
 Ctime     : 2024-07-23 20:50:00 +0200        | 2025-02-09 18:04:06 +0100
 Inode     : 1333674                          | 3542013
 SHA256    : zZOZrRdXCuRtg037QvYWyDbVy3t4W6R7 | n7A97JsrI0Va3lyGTzpL/t81Xvml/inc
             LwOxBOqzgkg=                     | hA9gyl3LPc0=

File: /root/.viminfo
 Size      : 12742                            | 12357
 Mtime     : 2025-02-09 13:17:48 +0100        | 2025-02-09 17:54:25 +0100
 Ctime     : 2025-02-09 13:17:48 +0100        | 2025-02-09 17:54:25 +0100
 Inode     : 3541891                          | 3542007
 SHA256    : mQ8jfMRnqAgFqRmkIexg3hOniGUoY9wm | G0AtQsaESSv2s6mnrPFYR+eIDXkR/G/9
             gGpvrhaO6ZY=                     | Ft44RhULh+Q=

Directory: /usr/bin
 Size      : 65822                            | 65846
 Mtime     : 2025-02-09 13:15:53 +0100        | 2025-02-09 18:05:16 +0100
 Ctime     : 2025-02-09 13:15:53 +0100        | 2025-02-09 18:05:16 +0100


---------------------------------------------------
The attributes of the (uncompressed) database(s):
---------------------------------------------------

/var/lib/aide/aide.db.gz
 MD5       : jyY8ktcG+E5Kq0AtGA5YGQ==
 SHA1      : KogexIU6LuOslIB81mGvMSL1rYo=
 SHA256    : QyabDWuO37ZO+xzXmPF28qT7t5WJdSB2
             EwwNVmU1Rlc=
 SHA512    : LrcRp1//aeMxufbKBbodCM1YA0NU5EtP
             QdriP1Uh+A7qFULU4WjK9qolnNfZLuDY
             kIPg9LY+g0q1j75Z44T1dA==
 RMD160    : 51KDSlTiMtIXqe+VQ6A3pDN/uZ8=
 TIGER     : 8A61b3JqbPNltkAPxvVgQ7UON2AlRn3q
 CRC32     : IpaktA==
 WHIRLPOOL : dcQVsfrdV7TGbpAyhNATDGFQ8c7mBG4O
             cX7ZufgFpa8seOIs+gyWHjeWUq4FCsk4
             U0qZ+Ela67DDrsVkN5xGCA==
 GOST      : ltIg5YJ+6BFVE5kbORVh3gRGbwJ4EP0/
             8iJY8o51fUo=
 STRIBOG256: lmE/qdAVUeE4zEbd7WBISCDXWsUb1bGJ
             FxSlN0RABQ4=
 STRIBOG512: Ox8c77PeIe0dCgFLPawLqWYzMK/9inc4
             FPH6aHMBchh4ctW71d4wZwy3/f42ZUG6
             xz7VX4MQ+X0SFz28//jSsg==


End timestamp: 2025-02-09 18:15:03 +0100 (run time: 5m 51s)

In der Zusammenfassung sehen wir also in Summe 470.065 Datenbankeinträge, sowie von den Einträgen her ein neuer, ein entfernter sowie ein geänderter Eintrag:

Total number of entries:	470065
Added entries:		        1
Removed entries:		1
Changed entries:		5

Die Datei /usr/bin/sg_evil_copy ist neu hinzugekommen sowie die SWAP-Datei /root/.cache/vim/swap/%etc%aide.conf.swp entfernt worden.

Im Abschnitt Changed entries sehen wir:

d = ... mc..    : /root
d < ... mc..    : /root/.cache/vim/swap
f > ... mci.H   : /root/.lesshst
f < ... mci.H   : /root/.viminfo
d > ... mc..    : /usr/bin
  • In der ersten Spalte kennzeichnet ein d ein Verzeichnis und ein f eine Datei.
  • In der zweiten Spalte wird eine Änderung angezeigt, ob sich die Grösse einer Datei bzw. des Verzeichnisses geändert hat. = bedeutet keine Änderung, > zeigt eine Vergrösserung und < eine Verkleinerung an.
  • Die mit jedem Buchstaben verbundenen Attribute sind wie folgt:
    • l bedeutet, dass sich der Link-Name geändert hat.
    • b bedeutet, dass sich die Blockanzahl geändert hat.
    • p bedeutet, dass sich die Berechtigungen geändert haben.
    • u bedeutet, dass sich die uid geändert hat.
    • g bedeutet, dass sich die gid geändert hat.
    • a bedeutet, dass sich die Zugriffszeit geändert hat.
    • m bedeutet, dass sich die Änderungszeit geändert hat.
    • c bedeutet, dass sich die Änderungszeit geändert hat.
    • i bedeutet, dass sich der Inode geändert hat.
    • n bedeutet, dass sich die Linkanzahl geändert hat.
    • H bedeutet, dass sich eine oder mehrere Prüfsummen geändert haben.
  • Die folgenden Buchstaben sind nur verfügbar, wenn sie explizit mit „configure“ aktiviert werden:
    • A bedeutet, dass sich die Zugriffskontrollliste geändert hat.
    • X bedeutet, dass sich die erweiterten Attribute geändert haben.
    • S bedeutet, dass sich die SELinux-Attribute geändert haben.
    • E bedeutet, dass sich die Dateiattribute auf einem zweiten erweiterten Dateisystem geändert haben.
    • C bedeutet, dass sich die Dateifähigkeiten geändert haben.

Im Abschnitt Detailed information about changes: sehen wir dann jeweils die detaillierten Informationen zu den Änderungen.

Update Database

Nach Änderungen am System, z.B. bei Konfigurationsänderungen, Updates oder Neuinstallationen von Paketen muss zwingend eine Aktualisierung der Datenbank erfolgen. Hier steht uns die Option --update oder kurz -u zu Verfügung.

 $ sudo aide --update

Alternativ kann man auch direkt die Datenbank neu initialisieren:

 $ sudo aide --init

aide --update kombiniert im Grunde einen Check und eine Initialisierung einer neuen Datenbank. Der Vorteil der Verwendung von --update gegenüber --check und --init besteht darin, dass der Bericht und die neue Datenbank immer auf denselben Dateisystemdaten basieren.

Ein anderer Ansatz wäre dann ein --init gefolgt von einem --compare zu verwenden, jedoch ist dabei zum beachten, dass nicht alle Attribute (nämlich „growing“ und „compressed“) im Vergleichsmodus unterstützt werden.

tägliche checks enablen

Wiederkehrende tägliche Checks führt man am besten und einfachsten des sytemd aidecheck.timer aus. Zum Aktivieren dieser zeitgesteuerten Checks verwenden wir folgenden Befehl:

[django@pml010074 ~] $ sudo systemctl enable --now aidecheck.timer
Created symlink '/etc/systemd/system/multi-user.target.wants/aidecheck.timer' → '/usr/lib/systemd/system/aidecheck.timer'.

Den Status können wir wie gewohnt via systemctl abfragen:

[django@pml010074 ~] $ sudo systemctl status aidecheck.timer 

 aidecheck.timer - Aide check every day at 5AM
     Loaded: loaded (/usr/lib/systemd/system/aidecheck.timer; enabled; preset: disabled)
   Active:active (running)since Sun 2025-02-09 13:47:17 CET; 49min ago
 Invocation: 9eb7be3eccc043be82f4dd4e9b5b72ed
    Trigger: Mon 2025-02-10 05:00:00 CET; 14h left
   Triggers: ● aidecheck.service

Feb 09 13:47:17 pml010074 systemd[1]: Started Aide check every day at 5AM.

Natürlich wird man im Jahr 2025 nicht mehr ernsthaft, manuell Server aufsetzen und betreiben wollen. Vielmehr wird man auf ein Orchestrierungswerkzeug wie z.B. Ansible zurückgreifen. Setzen wir einen neue virtuellen Server unter Arch Linux neu auf, oder wollen wir bei einem bestehenden Host die Konfiguration aktualisieren, verwenden wir wie zuvor schon angeschnitten Ansible als Orchestrierungswerkzeug. So ist sichergestellt dass zum einen all unsere Hosts entsprechend gleich aufgebaut, konfiguriert und betrieben werden, es also keine Bastel-/Frickellösung geben wird.

In diesem Konfigurationsbeispiel gehen wir davon aus, dass wir auf zwei Hosts im Intranet AIDE installieren und konfigurieren möchten. Ferner holen wir uns das AIDE-Installationspaket von einem internen Repository-/Spiegelserver, auf dem wir dann auch die generierten AIDE Datenbanken ablegen werden. Somit stehen die Datenbanken manipulationssicher auf den beiden Hosts zur Verfügung, sollte wider erwarten Ein Eindringling auf diesen Maschinen versuchen durch einen manuellen Update der AIDE-Datenbank sein Tun zu verschleiern. AIDE wird bei jedem Check dann via get_url die aktuelle Datenbank holen und das Dateisystem dagegen prüfen.

Wir werden uns nun nachfolgend die Server-Installation und -konfiguration genauer betrachten.

Der ungeduldigen Leser kann auch direkt zur Tat schreiten und das manuelle Anlegen der Inventory-Hülle, des Playbooks und der zugehörigen Rolle überspringen und diese Aufgaben mit folgendem Befehl sozusagen auf einem Rutsch erledigen:

 $ mkdir -p ~/devel/ansible ; wget https://gitlab.nausch.org/django/example_aide/-/archive/main/example_aide-main.tar.gz \
         -O - | tar -xz --strip-components=1 -C ~/devel/ansible

Nach Anpassung der Daten im Inventory kann man anschliessend direkt zur Ausführung schreiten.

Vorbereitung - Daten im Inventory

Bei unserem Konfigurationsbeispiel hier gehen wir von folgenden Parametern aus:

  • group: arch
  • hostname: pml010070
  • hostname: pml010070

Die Konfigurationsdatei unseres inventory in unsere, Ansible-Verzeichnis beinhaltet demnach unter anderem:

 $ vim inventories/production/hosts

inventories/production/hosts

Für alle Host aus der Gruppe arch definieren wir nun noch eine Datei mit den Definitionen der Variablen dieser Gruppe.

 $ vim inventories/production/group_vars/arch/aide

inventories/production/group_vars/arch/aide

Die beiden Beispiel-Hosts aus der Gruppe|Zone intra in diesem Inventory symbolisieren folgende zwei Knoten.

  • Der Host pml010070 steht exemplarisch für einen Client im Intranet. In dessen Inventory-File inventories/production/host_vars/pml010070 sind die ihn beschreibenden Daten enthalten.
  • Der Host pml010074 steht exemplarisch für einen Client im Intranet. In dessen Inventory-File inventories/production/host_vars/pml010074 sind die ihn beschreibenden Daten enthalten.

Wir legen uns also nun die Definitionsdateien für die beiden Hosts im SOHO an.

 $ vim inventories/production/host_vars/pml010070

inventories/production/host_vars/pml010070

 $ vim inventories/production/host_vars/pml010074

inventories/production/host_vars/pml010074

Unser Beispiels-Inventory hat also nunmehr folgenden Aufbau:

inventories/production/
├── group_vars
│   └── arch
│       └── aide
├── hosts
└── hosts_vars
    ├── pml010070
    └── pml010074

4 directories, 4 files

Rolle

Für die Installation und Konfiguration von aide verwenden wir eine eigene Rolle hids, die wir bei unserem zuvor angelegten Playbooks später einfach mit aufrufen werden. Hierzu kopieren wir uns zunächst die Mustervorlage common.

 $ cp -avr roles/common/ roles/hids

Ausgabe von cp -avr roles/common/ roles/hids

Bei Bedarf können wir uns später die Struktur, die somit angelegt wurde und die wir nun gleich mit Inhalten befüllen wollen, mit nachfolgendem Befehl anzeigen lassen.

 $ tree roles/hids/

Ausgabe von tree roles/hids/

tasks

Wie wir sehen ist die Rolle durchaus überschaubar, im Task main.yaml verweisen wir lediglich auf die eigentlichen Tasks install, config und transfer

 $ vim roles/hids/tasks/main.yml

roles/hids/tasks/main.yml

Die Installation von AIDE wird in der ersten Task-Gruppe mit dem tag install vorgenommen. In den Variablen der Gruppe arch sind hierbei die Versionsnummer aide_version wie auch Ort und Stelle aide_repo definiert von welchem interen Repo-Server wir uns das aide-Paket zum Installieren holen wollen.

 $ vim roles/hids/tasks/install.yml

roles/hids/tasks/install.yml

Die eigentliche Installation Konfiguration sowie das erstellen der initialen AIDE-Datenbank erfolgt im anschließenden Task config.

 $ vim roles/hids/tasks/config.yml

roles/hids/tasks/config.yml

Was nun noch fehlt ist das Kopieren der erstellten AIDE-Datenbank auf unseren internen Repository-/Spiegel-Server, was im letzten Task transfer erledigt wird. Der interne Repository-Serever wird hierbei über den Host-Alias-NAmen repo angesprochen!

 $ vim roles/hids/tasks/transfer.yml

roles/hids/tasks/transfer.yml

templates

Für die Erstellung der AIDE-Konfigurationsdatei /etc/aide.conf und auch für die Systemd-Timer Defintion von AIDE /etc/systemd/system/aidecheck.timer.d/override.conf - also wann genau der Check des Systems gegen die Datenbank erfolgen soll - brauchen wir nun noch jeweils ein Jinja2 Template. Mit Hilfe dieser beiden Templates aide_config.j2 und der darin enthaltenen Schleifendefinitionen werden dann mit Hilfe der Daten aus dem Inventory die benötigte Konfigurationsdateie erzeugt.

Damit nicht nun später alle unsere 42 VMs zum selben Zeitpunkt mit dem Check des jeweiligen Systems beginnen und somit einen vermeidbaren Peak auf unserem Repository-/Spiegel-Server und auf den jeweiligen Virtualisierungsmaschinen verursachen, gilt es nun die Startzeitpunkte der einzelnen Hosts zu streuen. Wir wollen hier natürlich auch nicht bei jedem Lauf des Playbooks später dann unterschiedliche Zufallswerte Produzieren, was die Idee der Idempotenz auch konterkarieren würde. Wir generieren daher für die Minutenzahl von 00 - 59 basierend auf den Seed des Hostnamens eine statische zufällige Minutenzahl zwischen 00 und 59, die für jeden Host unterschiedlich aber dennoch für diesen gleich bleiben wird. Hierzu Nutzen wir die Ansible-Variable: {{ 59 |random(seed=inventory_hostname) }}. Somit werden später alle Checks der System im Zeitraum von 05:00:00 - 05:59:00 erfolgen.

 $ vim roles/hids/templates/aide_config.j2

roles/hids/templates/aide_config.j2

 $ vim roles/hids/templates/systemd.j2

roles/hids/templates/systemd.j2

handlers

Sollte bei der Abarbeitung des Playbook die individuelle systemd-timer Konfigurationsdatei /etc/systemd/system/aidecheck.timer.d/override.conf verändert werden, ist natürlich hierbei eine entsprechende Information zum Relaod des System-Daemon notwenig. Hierzu verwenden wir die Ansible Playbook Handlers. Diese Handler werden in den beiden Tasks zur Erstellung der aidecheck.timer.d/override.conf-Konfigurationsdateie mit Hilfe eines handler-Calls aufgerufen, sofern sich die Datei verändert hat.

Zu guter Letzt brauchen wir noch eine Konfiguration der Aufgaben die bei einem notify abgearbeitet werden sollen.

 $ vim roles/hids/handlers/main.yml

roles/hids/handlers/main.yml

Playbook

Unser Playbook zum Installieren und Konfigurieren unseres HIDS auf Basis AIDE, ist wie immer schlank, unscheinbar und unspektakulär, beinhaltet aber Hinweise zur Aufgabe und wie es aufzurufen ist.

 $ vim playbooks/arch_hids.yml

playbooks/arch_hids.yml

Ausführung - Playbooklauf

Die orchestrierte Variante der Installation und Konfiguration unseres AIDE-Daemons gestaltet sich ab sofort sehr einfach, brauchen wir doch lediglich die Konfigurationswerte im Inventory zu hinterlegen und zu pflegen und letztendlich das Playbook entsprechend aufzurufen, wenn z.B. gewollte Änderungen an einem System durch einen Admin bzw. durch den Lauf eines der Ansible-Playbooks erfolgten.

In nachfolgendem Beispiel installieren wir nun unseren AIDE-Daemon auf dem Host pml010070:

 $ ansible-playbook playbooks/arch_hids.yml --limit pml010070

[14:38:36] Gathering Facts
↳  pml010070 | SUCCESS | 1.18s
[14:38:37] hids : Installation von AIDE/HIDS.
↳  pml010070 | SUCCESS | 8ms
[14:38:37]     ↳ install: Aktuelles AIDE Paket vom internen Mirror holen.
↳  pml010070 | CHANGED | 500mss
[14:38:37]     ↳ install: AIDE-Paket installieren.
↳  pml010070 | CHANGED | 2.00s
[14:38:39]     ↳ install: Temporäre lokale Paketdatei löschen.
↳  pml010070 | CHANGED | 389ms
[14:38:40] hids : Konfiguration von AIDE/HIDS.
↳  pml010070 | SUCCESS | 7ms
[14:38:40]     ↳ config: Checken ob es bereits eine Backupdatei der aide.conf gibt.
↳  pml010070 | SUCCESS | 356ms
[14:38:40]     ↳ config: Backupdatei der aide.conf Konfigurationsdatei erstellen.
↳  pml010070 | CHANGED | 338ms
[14:38:40]     ↳ config: AIDE Konfigurationsdatei erzeugen.
↳  pml010070 | CHANGED | 634ms
[14:38:41]     ↳ config: Verzeichnis für lokale override timer erzeugen.
↳  pml010070 | CHANGED | 251ms
[14:38:41]     ↳ config: Systemd Timer für AIDE Daemon erzeugen.
↳  pml010070 | CHANGED | 478ms
[14:38:42]     ↳ config: AIDE Datenbank erstellen.
↳  pml010070 | SUCCESS | 1m40s
[14:40:22] hids : AIDE-Datenbank auf Reposerver transferieren.
↳  pml010070 | SUCCESS | 10ms
[14:40:22]     ↳ transfer: Temporäre lokale Aide-Datenbank Datei löschen.
↳  pml010070 | SUCCESS | 368ms
[14:40:23]     ↳ transfer: Temporäre remote Aide-Datenbank Datei löschen.
↳  pml010070 | SUCCESS | 1.24s
[14:40:24]     ↳ transfer: AIDE-Datenbank lokal kopieren.
↳  pml010070 | CHANGED | 511ms
[14:40:25]     ↳ transfer: AIDE-Datenbank auf Repository-Server kopieren.
↳  pml010070 | SUCCESS | 1.63s
[14:40:27]     ↳ transfer: AIDE-Datenbank ins Repo verschieben.
↳  pml010070 | CHANGED | 5.14s
[14:40:32]     ↳ transfer: Temporäre lokale Aide-Datenbank Datei löschen.
↳  pml010070 | CHANGED | 317ms
[14:40:32]     ↳ transfer: Temporäre remote Aide-Datenbank Datei löschen.
↳  pml010070 | CHANGED | 861ms
triggering handler | hids : Reload aidecheck
↳  pml010070 | CHANGED | 1.21s
[14:40:33] system
-- Play recap --
pml010070                  : ok=21   changed=12    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0

Bei einem Blick in unser System-Journal finden wir nun unter anderem zunächst einmal das Setzen des systemd-timers täglich um 05:51:00 für unseren Host

 # journalctl
Mar 14 14:40:36 pml010070 systemd[1]: Reloading finished in 162 ms.
Mar 14 14:40:36 pml010070 systemd[1]: Started Aide check every day at 05:51:00.
Mar 14 14:40:36 pml010070 systemd[1]: Started Aide Check.

Desweiteren finden wir auch Informationen zum initialen Erstellen der Aide-Datenbank.

 # journalctl

journal bei Erstellung der initialen Datenbank

Täglich um 05:01 Uhr wird nun unser Host die aktuelle Datenbank gegen die bestehende AIDE-Datenbank auf unserem internen Repository-/Spiegelserver holen und diese beim Check des Dateisystems verwenden.

 # journalctl

journal beim täglichen check um 05:51 Uhr dieses Hosts

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, aktuualisieren und automatisiert zum zentralen internen Repository-/Spiegelserver transverieren. 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!

In diesem Konfigurationsbeispiel wurde lediglich aufgezeigt, wie man einfach mit Hilfe von Ansible installieren, konfigurieren und Datenbanken der Host erstellen und wegsichern 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. graylog noch im Detail ansehen!

Links

Diese Website verwendet Cookies. Durch die Nutzung der Website stimmen Sie dem Speichern von Cookies auf Ihrem Computer zu. Außerdem bestätigen Sie, dass Sie unsere Datenschutzbestimmungen gelesen und verstanden haben. Wenn Sie nicht einverstanden sind, verlassen Sie die Website.Weitere Information
  • linux/aide.1741963509.txt.gz
  • Zuletzt geändert: 14.03.2025 14:45.
  • von django