↓ Skip to main content
Le Site de François
  1. Index/

AIDE (Advanced Intrusion Detection Environment)

Security Linux Integrity Monitoring Rhel Compliance

AIDE (Advanced Intrusion Detection Environment) is a host-based intrusion detection tool that implements file integrity monitoring (FIM): it builds a baseline database capturing cryptographic hashes and metadata for every file it is configured to watch, and on subsequent runs compares the live filesystem against that database, reporting anything that has been added, removed, or changed. Its security premise is detection after the fact: AIDE does not prevent modifications (that is the role of fapolicyd, SELinux, and IMA), but it provides a reliable, auditable record that modifications occurred, when a check was run, and which specific attributes changed. An attacker who compromises a system and modifies a binary, a configuration file, a cron job, or an SSH authorized_keys file will leave a fingerprint in the next AIDE check — provided the database has not also been compromised, which is the central operational concern the tool’s deployment model must address.

AIDE’s configuration file (/etc/aide.conf on RHEL) defines the monitoring scope and the attribute groups to record. Each rule maps a path (literal or regular expression) to a named attribute group — a bitmask of properties to capture. The standard RHEL groups include: p (permissions), i (inode number), n (number of hard links), u (user/UID), g (group/GID), s (size), b (block count), m (mtime), c (ctime), a (atime), sha256 and sha512 (content hashes), acl (POSIX ACLs), xattrs (extended attributes including SELinux labels), and e2fsattrs (ext2/4 filesystem flags like immutable). A typical RHEL default rule watches /etc with all attributes including SHA-256 hash, /usr similarly, /boot fully, /var/log for additions only (since log files are expected to grow), and excludes high-churn directories like /var/spool, /tmp, and /proc to suppress noise. The attribute selection is a deliberate trade-off: capturing atime records every file read (very noisy, rarely useful), while capturing SHA-256 records content changes precisely at the cost of a full file read during each check run. The three-command operational lifecycle is: aide --init (build the baseline database at /var/lib/aide/aide.db.new.gz; the file is renamed to aide.db.gz before checks begin), aide --check (compare current filesystem against aide.db.gz and produce a report), and aide --update (re-scan and replace the database after legitimate changes have been reviewed and accepted). Checks are typically scheduled via cron or a systemd timer, and the resulting report sent to a central log or SIEM system.

AIDE’s fundamental weakness is its offline, retrospective nature and the database trust problem. Unlike IMA, which uses the TPM to accumulate a tamper-evident runtime measurement log that cannot be silently modified without breaking the PCR chain, AIDE’s database is a file on the same filesystem it protects — an attacker with root access can modify the database to match their changes and the next AIDE check will report nothing. Mitigating this requires storing the reference database off-system: on a read-only NFS mount, in a version-controlled repository, on a write-once object store, or burned to optical media at baseline time, so that the comparison at check time uses a copy the attacker cannot reach. Similarly, AIDE cannot detect compromises that occurred before the baseline was captured: if the system was already tampered with at aide --init time, the database records the tampered state as the baseline. AIDE also does not detect in-memory-only attacks or modifications to files it is not configured to watch. These limitations define AIDE’s correct positioning in a defence stack: it is a scheduled, retrospective, file-level detection control that complements IMA’s continuous, TPM-anchored, runtime measurement, fapolicyd’s execution-time allowlisting, and SELinux’s behavioural confinement — each covering a different dimension of the same integrity problem. AIDE is a STIG and CIS Benchmark requirement for RHEL servers, satisfying NIST SP 800-53 SI-7 (Software, Firmware, and Information Integrity) and PCI DSS Requirement 11.5, and is configurable at fleet scale via the aide RHEL Ansible system role.

Related

fapolicyd (File Access Policy Daemon)

Security Linux Rhel Allowlisting Integrity Policy
fapolicyd (File Access Policy Daemon) is an application allowlisting framework for Linux, developed by Red Hat and shipped as a supported component of RHEL 8+. Its security premise is supply-chain integrity at the execution layer: only software that was installed through a trusted package manager (DNF/RPM) or explicitly declared as trusted by an administrator may execute on the system. An attacker who achieves a foothold and drops a new binary — a reverse shell, a lateral movement tool, a cryptominer — will find that binary blocked at execution time, because it is absent from the trust database, regardless of its Unix permissions or SELinux label. fapolicyd addresses a different dimension of access control than SELinux: SELinux models how applications behave (what resources they may access); fapolicyd models whether applications are trusted at all (whether they may execute in the first place). The two are complementary: SELinux confines a trusted application’s behaviour; fapolicyd prevents untrusted applications from running.

IMA (Integrity Measurement Architecture)

Security Linux Kernel Attestation Tpm Integrity
IMA (Integrity Measurement Architecture) is a Linux kernel subsystem, merged in kernel 2.6.30, that hooks into the kernel’s file access paths — execve(), mmap(), open() — and computes a cryptographic hash of each file’s contents before it is accessed, according to a configurable policy. It is the runtime half of the Linux integrity story: where TPM PCR measurements and Secure Boot cover what was loaded during the boot sequence, IMA covers what happens after the OS is running, hashing executables, libraries, kernel modules, firmware, and configuration files as they are opened, creating a continuously updated record of everything the system has actually used.

NBDE / Clevis / Tang (Network-Bound Disk Encryption)

Security Encryption Storage Linux Luks Boot Rhel
NBDE (Network-Bound Disk Encryption) is an approach to automatic LUKS disk unlocking that binds the volume key not to hardware state (a TPM PCR measurement) but to network presence: a LUKS-encrypted volume unlocks automatically at boot if and only if the machine can reach a designated Tang server on a trusted network. Remove the machine from that network — because it was stolen, because a data centre drive was pulled, because someone exfiltrated the hardware — and the volume key becomes unrecoverable without a fallback passphrase. The threat model is therefore complementary to TPM-based unlocking: TPM sealing asks “is this the right software stack?” and locks the key to a specific platform measurement; NBDE asks “is this machine on the trusted network?” and locks the key to network presence. Neither addresses both threat classes alone, which is why the two are routinely combined — and why RHEL formalises NBDE as a subcategory of the broader Policy-Based Decryption (PBD) framework that the Clevis pin system implements.