Knowing when a file changed

AIDE

AIDE takes a cryptographic fingerprint of the files you care about and tells you what changed since last time.

apt install aide

aideinit — build the baseline, on a machine you believe is clean

aide --check — compare against it

Run the check nightly from a timer and mail or alert on the result. See cron jobs and timers.

The baseline must live somewhere else

An attacker with root can regenerate the database and your checks go quiet. Copy the database and the configuration to another machine after every legitimate update, and run the comparison against that copy.

Better still, pull it: have a monitoring host fetch the current state over SSH and compare it there. Nothing on the suspect machine then decides what the answer is.

What to watch, and what to leave alone

Watch closely

/bin, /sbin, /usr/bin, /usr/sbin, /lib, /boot — these should change only when you update packages.

Watch for permission changes

/etc, especially sudoers, ssh, cron directories and authorized_keys everywhere.

Do not watch content

/var/log, /tmp, /proc, your application's data directories. Watching things that change constantly produces noise, and noise produces ignored alerts.

Update the baseline deliberately

After a legitimate package update, AIDE will report hundreds of changes. Review them rather than rubber-stamping, then re-baseline:

aide --update && mv /var/lib/aide/aide.db.new /var/lib/aide/aide.db

A team that re-baselines without looking has an expensive way of producing no information.

auditd for the live view

AIDE tells you what changed. auditd tells you who, when and with which process:

auditctl -w /etc/passwd -p wa -k identity
auditctl -w /root/.ssh -p wa -k rootkey

ausearch -k rootkey to read it back. Put the rules in /etc/audit/rules.d/ so they survive a reboot, and ship the logs off the machine — local logs are the first thing an intruder edits.

The cheap version

If AIDE is more than you want, two checks catch a surprising amount:

debsums -c — files that differ from their package

find / -xdev -perm -4000 -type f 2>/dev/null — setuid binaries; a new one that you did not install is a strong signal

Combine either with the intrusion basics in securing a new server and know what to do when it fires: a compromised server.

---

Still stuck? Mail support@novogara.com — an engineer answers, at any hour. Back to the knowledge base