AIDE vs Tripwire vs eBPF: file integrity monitoring that tells you who

File integrity monitoring is one of the oldest ideas in host security, and one of the most quietly mandated: PCI DSS requires it outright, SOC 2 auditors expect it, and every post-incident review that finds a modified binary asks why nobody knew. The standard answers for twenty years have been AIDE and Tripwire. Both still work the way they did twenty years ago - which is exactly the problem.

How the classics work

AIDE (Advanced Intrusion Detection Environment) builds a database of file hashes, permissions, and attributes, then rescans the filesystem from a nightly cron job and reports differences. Tripwire (the open-source variant) works on the same principle. Both are free, mature, and genuinely better than nothing.

AIDE vs Tripwire: the difference

AIDE is the simpler of the pair: a hash database, a config file listing which attributes to track per path, and a cron job that diffs the filesystem against it. Nothing about the database is signed, so anyone with root can rewrite the baseline as easily as the files it describes - which is why the AIDE manual pushes you toward read-only or off-host storage for it.

Tripwire’s open-source variant adds a cryptographic signing model on top of that same scan approach. The policy file and the baseline database are signed with site and local keys, so tampering with either is detectable rather than silent, at the cost of key management and a passphrase prompt in the middle of every legitimate baseline update. AIDE trades integrity of the baseline for operational simplicity. Tripwire trades simplicity for a baseline you can prove wasn’t edited.

Everything else - the scan interval, the attribution, the baseline maintenance - is common to both, and it’s where the structural problems live.

The three structural gaps

The model has three built-in gaps. They are structural, not bugs:

1. You learn on Tuesday what changed on Sunday. Detection latency equals your scan interval. A nightly scan means an attacker’s modified sshd_config, added cron job, or trojaned binary sits undetected for up to 24 hours. The typical intrusion does its damage in the first hour. FIM that reports at scan time is an audit tool wearing a detection tool’s name badge.

2. It tells you what changed, never who or how. A scan diff says /etc/crontab differs from baseline. It cannot say which process wrote it, which user, which session, or which SSH login spawned it. Every real finding starts a manual forensic dig - the very work you hoped the tool would do.

3. The baseline is a chore that rots. Every legitimate deploy, package upgrade, or config change makes the database stale. Update it too rarely and reports drown in known-good noise. Update it too eagerly and you risk baselining the attacker’s changes. On a fleet, multiply the ritual. The database itself lives on the host an attacker with root can touch, which is why the manuals recommend keeping it on read-only or off-host storage. How many installs actually do?

What eBPF changes

eBPF lets a monitoring agent observe file operations at the kernel as they happen. That flips all three properties:

• Latency drops from hours to seconds. The write to a watched path is the event. AlertKick’s agent streams it off-host immediately - there’s no scan to wait for and no on-host database to tamper with.
• Full attribution comes free. The kernel knows the writing process, its binary path, user, parent chain, and session. The event arrives as “/etc/cron.d/apache-backup created by wget run by www-data, child of your web server process” - the forensic story, pre-assembled, and correlated with the SSH login or process activity around it.
• No baseline ritual. Watching writes needs no hash database. Deploys and package upgrades are recognised for what they are, and AI triage reads each change in context - so apt upgrade touching 400 files doesn’t page anyone, and one odd write to authorized_keys does.

Scan-based tools verify the entire filesystem against a cryptographic baseline. They catch modifications from outside the running system (a tampered disk image, changes made while the host was booted from other media) that runtime monitoring can’t see. They also run air-gapped with no platform behind them. If your threat model is offline tampering, AIDE alongside runtime FIM is a legitimate belt-and-braces answer - the tools compose rather than compete.

Which fits your servers?

• One personal box, no budget, comfortable with cron and mutt: AIDE works. Put the database somewhere the host can’t rewrite it, and actually read the reports.
• Compliance checkbox with an auditor who only asks “do you have FIM?”: either classic tool passes. Note that PCI DSS requires weekly comparisons at minimum and alerting on unauthorized changes. Auditors increasingly ask how fast you’d actually know.
• Production servers where a modified file should interrupt someone’s afternoon: you want event-driven FIM with attribution. That’s the eBPF security model - file integrity monitoring included with every AlertKick host alongside login, process, and network detections. Changes feed straight into compliance evidence so the audit answer writes itself.

The test worth applying to any FIM setup: if someone modified /etc/ssh/sshd_config right now, when would you find out, and would the alert tell you who did it? If the answers are “tomorrow, maybe” and “no” - that’s the gap. Start free, install the agent, touch a watched file, and watch the answer become “seconds, and yes”.