Linux Security: File Integrity Monitoring with AIDE and Systemd Timers

Last month, I spent three days chasing a ghost in our staging environment. A configuration file kept reverting to an old state, and I was convinced it was a buggy deployment script. It turned out to be an engineer manually editing files for "quick testing" and forgetting to roll them back. That was the moment I stopped relying on hope and started enforcing host-level visibility.

If you’re running production Linux servers, you need to know exactly when a file changes—whether it’s a malicious actor or a well-meaning teammate. Implementing Linux security measures doesn't always require an enterprise-grade SIEM. For most of my solo projects and smaller team environments, I rely on AIDE (Advanced Intrusion Detection Environment) coupled with Systemd Timers: The Better Way to Handle Linux Automation.

Why AIDE for File Integrity Monitoring?

AIDE works by creating a database of your system’s known good state. It stores cryptographic hashes of files—like /etc/passwd, /usr/bin/, or your application config directories—and compares them against the current state during a check.

We first tried using basic cron jobs to run these checks, but cron lacks the observability I needed. If the job failed or hung, I wouldn't know until the next morning. Switching to systemd timers allowed me to track the exit status, log the output to journald, and easily integrate alerts into our existing pipeline.

Getting Started with AIDE

First, install AIDE. On a Debian-based system, it’s a simple apt install aide. Before you run anything, you need to initialize the database:

Bash
aideinit
mv /var/lib/aide/aide.db.new /var/lib/aide/aide.db

This creates your baseline. Be careful here; if you run this on a compromised system, you’re just baking in the breach. Always initialize on a fresh, hardened machine. You can learn more about the initial setup in my guide on Linux server hardening: Automate audits with Lynis and fail2ban.

Automating with Systemd Timers

To automate your file integrity monitoring, create a systemd service and a corresponding timer. This is much cleaner than a crontab entry.

Create /etc/systemd/system/aide-check.service:

INI
[Unit]
Description=AIDE integrity check

[Service]
Type=oneshot
ExecStart=/usr/bin/aide --check

Now, create the timer at /etc/systemd/system/aide-check.timer:

INI
[Unit]
Description=Run AIDE check daily

[Timer]
OnCalendar=daily
Persistent=true

[Install]
WantedBy=timers.target

Enable the timer with systemctl enable --now aide-check.timer. Now, your system will automatically run an integrity check every 24 hours. If it finds a discrepancy, the service will return a non-zero exit code, which you can easily monitor via journalctl -u aide-check.

Hardening Your Host Environment

File integrity monitoring is only as good as your reaction time. If you don't look at the logs, the tool is useless. I usually pipe the output of the AIDE check to a centralized logging server or a simple Slack webhook if the exit status is non-zero.

Beyond integrity checks, remember that your host's attack surface is usually wider than you think. You should also be looking into Rootless Docker: Secure Your Containers Without Root Privileges to ensure that even if a container is breached, the host file system remains isolated.

Lessons Learned

I've learned the hard way that AIDE can be noisy. If you include logs or temporary files in your /etc/aide/aide.conf, you’ll get false positives every single hour. Keep your configuration rules tight. Focus on directories that should never change, like /boot, /sbin, and core configuration files in /etc.

When you're configuring your rules, remember the hierarchy. A simple !/var/log/.* rule at the top of your config will exclude your log files from being monitored.

One thing I'm still refining is how to handle updates. Every time I run an apt upgrade, AIDE reports a hundred changes. I currently have a small bash script that runs aideinit after a successful deployment, but it feels a bit brittle. If you're managing a large fleet, you might want to automate this process through your configuration management tool (Ansible or Salt) to ensure the baseline stays current without manual intervention.

At the end of the day, host hardening is about reducing the number of variables. AIDE gives you the data to prove what changed, when it changed, and what it looked like before. It isn't a silver bullet, but it's an essential layer for anyone serious about server ownership.

Frequently Asked Questions

1. Does AIDE slow down the system? It only consumes resources when the check is actually running. Since it's a batch process, I usually schedule it for low-traffic hours. The disk I/O impact is noticeable but manageable for most servers.

2. What happens if an attacker modifies the AIDE database? If they have root access, they can compromise the database. That's why I keep a copy of the database on a remote, read-only mount or a separate integrity-verified storage location.

3. Can I use AIDE with containers? You can, but it's overkill inside a container. It's much better to use a read-only root file system for your containers and handle state in volumes. Use AIDE on the host OS itself to monitor the files that the containers interact with.