AIDE and Tripwire are both excellent tools for monitoring file integrity on Linux systems, but they approach the problem from slightly different angles, and understanding those differences is key to choosing the right one for your needs.
Tripwire is the older, commercial option (though an open-source version exists), known for its robust security features and detailed reporting. AIDE (Advanced Intrusion Detection Environment) is its open-source counterpart, widely adopted for its flexibility and ease of integration. Both work by creating a database of cryptographic hashes (like MD5 or SHA-256) and metadata for selected files and directories. When you run a check, they compare the current state of these files against the stored database. Any discrepancies – a changed file, a deleted file, or a newly created file – are flagged as potential security incidents.
Let’s see AIDE in action. First, you install it:
sudo apt update
sudo apt install aide aide-common
Then, you initialize the database. This process scans your system and creates the baseline. It’s crucial to do this on a known-good system and store the database securely, ideally on read-only media.
sudo aide --init
This will create a database file, typically in /var/lib/aide/aide.db.new.gz. You’ll then rename it to make it active:
sudo mv /var/lib/aide/aide.db.new.gz /var/lib/aide/aide.db.gz
Now, imagine an attacker modifies /etc/passwd. If you run an AIDE check:
sudo aide --check
You’ll get output like this:
AIDE 0.17.3 found differences between database and filesystem!!
Start timestamp: 2023-10-27 10:00:00
End timestamp: 2023-10-27 10:05:00
Summary:
Total number of files: 100000
Added files: 0
Removed files: 0
Changed files: 1
---------------------------------------------------
Filename: /etc/passwd
State: Changed
Attribute Old value New value
---------------------------------------------------------
sha256 a1b2c3d4... e5f6g7h8...
mtime 2023-10-26 08:00:00 2023-10-27 10:02:00
size 1024 1050
This tells you precisely what changed, when, and how. To update the database after a legitimate change (e.g., a system update), you’d run:
sudo aide --update
This generates a new .new.gz database reflecting the current state. Again, you’d rename it to make it active.
The core problem AIDE and Tripwire solve is detecting unauthorized modifications to critical system files. In a secure environment, these files should change very rarely, and any change warrants investigation. Think of it as a tamper-evident seal for your filesystem.
Tripwire’s configuration, typically found in /etc/tripwire/tw.cfg and /etc/tripwire/twpol.txt, allows for very granular control over what is monitored. You can specify file permissions, ownership, timestamps, and various hash algorithms. AIDE’s configuration is in /etc/aide/aide.conf, which uses a simpler syntax but offers similar power.
The real magic of these tools lies in their ability to operate out-of-band. If your system is compromised, an attacker might try to disable or tamper with your monitoring tools themselves. By storing the AIDE database on a separate, read-only medium (like a USB drive or a network-mounted filesystem that’s mounted read-only for checks), you ensure that even if the main system is compromised, the integrity baseline remains untouched. You can then boot from a trusted rescue environment, mount the compromised filesystem read-only, and run AIDE against the read-only filesystem using the secure database.
A common pitfall is forgetting to update the AIDE database after legitimate system changes. If you install new software or apply patches, the database will report these as changes. You need a process to review these changes and update the database accordingly. AIDE’s --update functionality is key here, but it must be used deliberately and securely.
The most surprising thing about file integrity monitoring is how often it catches accidental misconfigurations or failed software updates rather than malicious attacks. A service that writes its configuration to /etc and then fails to clean up a temporary file can trigger an alert just as easily as a rootkit.
The next step after setting up file integrity monitoring is to integrate these alerts into a centralized logging system or a Security Information and Event Management (SIEM) solution. This allows for automated correlation of events and faster response.