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 worth examining.

How the classics work

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

The model has three built-in gaps, and they’re structural rather than 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 - and 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, as which user, spawned by which session, from which SSH login. So 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 in. On a fleet, multiply the ritual - and 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.

The honest trade-offs in the other direction: scan-based tools verify the entire filesystem against a cryptographic baseline, which catches 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 is fine. 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 technically passes - but note PCI DSS asks for weekly comparisons at minimum and alerting on unauthorized changes, and 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, with changes feeding 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”.