File integrity monitoring (FIM) is one of the most fundamental security controls for any self-hosted infrastructure. It answers a critical question: has someone modified files on my server without authorization? Whether it’s a compromised binary, a backdoored configuration file, or an attacker planting a rootkit, file integrity monitoring detects changes to critical system files before they can cause damage.
In this guide, we compare three leading open-source FIM solutions — AIDE, OSSEC, and Open Source Tripwire — examining their features, configuration complexity, deployment options, and real-world effecdockerss. We’ll provide Docker deployment configs, installation commands, and policy examples so you can get running quickly.
Why Self-Hosted File Integrity Monitoring Matters
Cloud providers and managed services offer FIM as part of their security suites, but self-hosting gives you full control over what gets monitored, how alerts are generated, and where the data lives. For organizations handling sensitive data, compliance frameworks like PCI DSS, HIPAA, and SOC 2 explicitly require file integrity monitoring on critical systems.
Self-hosted FIM tools also detect issues that network-based security tools miss. While a network IDS like Suricata catches suspicious traffic patterns, FIM catches what happens after an attacker gains a foothold — modified binaries, new cron jobs, or altered SSH authorized_keys files. Combined with log awazuhis from a SIEM platform, file integrity monitoring forms a layered defense strategy.
What Is File Integrity Monitoring?
File integrity monitoring works by creating a cryptographic baseline of your system’s files — computing hashes (SHA-256, MD5, Tiger) along with metadata like file permissions, ownership, and size. The FIM tool then periodically re-scans and compares current file states against this baseline, flagging any discrepancies.
Core Detection Capabilities
- Cryptographic hash verification — detects content changes via SHA-256, SHA-512, or MD5
- Permission monitoring — catches unauthorized chmod, chown, or ACL changes
- New file detection — identifies files that appeared since the last baseline
- Deleted file alerts — warns when expected files are removed
- Attribute tracking — monitors inode changes, link counts, and timestamps
Tool Overview
AIDE (Advanced Intrusion Detection Environment)
| Attribute | Detail |
|---|---|
| GitHub | aide/aide |
| Stars | 708 |
| Last Update | January 2026 |
| Language | C |
| Latest Release | v0.19.3 |
| License | GPL-2.0 |
AIDE is a lightweight, standalone file integrity checker that creates a database of file attributes and compares them during subsequent scans. It’s the simplest of the three tools to deploy — essentially a command-line utility with a configuration file. AIDE is widely used in enterprise environments and is the default FIM tool on many Linux distributions.
AIDE supports multiple hash algorithms simultaneously (SHA-256, SHA-512, MD5, RMD160, Tiger), file attributes tracking (permissions, ownership, size, inode), and flexible rule groups that let you define different monitoring levels for different directories.
OSSEC (Open Source Host-based Intrusion Detection System)
| Attribute | Detail |
|---|---|
| GitHub | OSSEC/ossec-hids |
| Stars | 5,017 |
| Last Update | April 2026 |
| Language | C |
| License | GPL-2.0 |
OSSEC is a full-featured host-based intrusion detection system that goes well beyond file integrity monitoring. It includes log analysis, rootkit detection, policy monitoring, real-time alerting, and active response capabilities. OSSEC operates in a client-server architecture — a central manager collects data from agents running on monitored hosts.
While AIDE and Tripwire focus purely on file integrity, OSSEC correlates file changes with log events, process monitoring, and network activity to provide a broader security picture. The active response module can automatically block IP addresses, restart services, or run custom scripts when specific events are detected.
Open Source Tripwire
| Attribute | Detail |
|---|---|
| GitHub | tripwire/tripwire-open-source |
| Stars | 926 |
| Last Update | February 2024 |
| Language | C++ |
| Latest Release | 2.4.3.7 |
| License | GPL-2.0 / OpenSSL |
Tripwire is the oldest and most established file integrity monitoring tool. Originally a commercial product, the open-source version provides the core FIM engine with a powerful policy language. Tripwire’s policy files define what to monitor and what properties to check using a template-based system that adapts to different operating systems.
Tripwire’s key strength is its policy flexibility — you can define granular rules for different file types, use macros and variables, and set severity levels for different types of violations. The reporting system provides detailed comparison output showing exactly what changed and how.
Comparison Table
| Feature | AIDE | OSSEC | Tripwire |
|---|---|---|---|
| Primary Focus | File integrity only | Full HIDS (FIM + log analysis + rootkit detection) | File integrity only |
| Architecture | Standalone CLI | Client-server (manager + agents) | Standalone CLI |
| Hash Algorithms | SHA-256, SHA-512, MD5, RMD160, Tiger | SHA-1, MD5 | SHA-256, MD5 |
| Real-Time Monitoring | No (scheduled scans only) | Yes (real-time FIM + log monitoring) | No (scheduled scans only) |
| Active Response | No | Yes (block IPs, run scripts) | No |
| Configuration | Simple text config | Complex (XML config + rules) | Policy template files |
| Learning Curve | Low | High | Medium |
| Database Size | ~10-50 MB (typical server) | Varies (stores events centrally) | ~10-50 MB (typical server) |
| Resource Usage | Low (CPU during scan) | Medium (agent + manager) | Low (CPU during scan) |
| Docker Support | Community images | Official Docker (wazuh/wazuh-manager) | No official Docker image |
| Compliance | PCI DSS, CIS benchmarks | PCI DSS, HIPAA, SOC 2, NIST | PCI DSS, CIS benchmarks |
| Alerting | Email, exit codes | Email, syslog, SIEM integration | Email, exit codes |
| Community Activity | Active (2026 release) | Very active (weekly commits) | Infrequent (last update 2024) |
Installation and Configuration
Installing and Configuring AIDE
AIDE is available in most Linux distribution repositories. Installation is straightforward:
| |
After installation, initialize the configuration file at /etc/aide/aide.conf. A typical configuration defines rule groups and specifies which directories to monitor:
| |
Initialize the baseline database and run your first check:
| |
AIDE’s output shows exactly which files changed and what attributes were modified:
| |
To automate regular scans, add a cron job:
| |
Installing and Configuring OSSEC
OSSEC offers the most comprehensive deployment option with Docker Compose. The Wazuh project provides an actively maintained Docker image that includes the OSSEC engine:
| |
For traditional installation on monitored hosts:
| |
Configure FIM rules in the agent’s ossec.conf:
| |
Add the agent to the manager and start monitoring:
| |
Installing and Configuring Tripwire
Open Source Tripwire follows a similar installation pattern:
| |
Tripwire uses a two-key system: a site key for policy and configuration files, and a local key for the database. Initialize both keys during first setup:
| |
Edit the Tripwire policy file (/etc/tripwire/twpol.txt) to define what to monitor. The policy uses a rule-based syntax with property masks:
| |
Run an integrity check:
| |
Choosing the Right Tool
When to Use AIDE
Choose AIDE if you need a simple, lightweight file integrity checker that runs on individual servers without a central management infrastructure. AIDE is ideal for:
- Small deployments with a handful of servers
- Compliance audits that require periodic FIM scans
- Servers with limited resources where you can’t run an agent
- Integration into existing cron-based monitoring workflows
AIDE’s simplicity is its greatest strength — there’s no server to configure, no agents to manage, and no complex rule engine to learn.
When to Use OSSEC
Choose OSSEC if you need comprehensive host-based intrusion detection with real-time monitoring, log correlation, and automated response. OSSEC excels at:
- Multi-server environments requiring centralized monitoring
- Organizations needing real-time alerts and automated incident response
- Teams already running a SIEM that can integrate OSSEC agent data
- Environments where file changes need to be correlated with log events
The trade-off is complexity — OSSEC requires more infrastructure, a steeper learning curve, and ongoing tuning of rules and alert thresholds.
When to Use Tripwire
Choose Tripwire if you need the most granular policy control over what gets monitored and how violations are reported. Tripwire is suitable for:
- Environments with strict compliance requirements demanding detailed audit trails
- Organizations that need custom property masks and rule severity levels
- Teams familiar with the Tripwire policy language from commercial deployments
- Systems where you need to compare reports across multiple scan periods
The slower development pace of the open-source version is worth noting — consider whether the commercial Tripwire Enterprise edition better suits production environments.
Best Practices for File Integrity Monitoring
Baseline immediately after provisioning — create your FIM baseline on a clean, verified system before connecting to production traffic. Any delay means you may capture an already-compromised state.
Store databases and keys separately — keep FIM databases, configuration files, and encryption keys on read-only media or a separate management server. An attacker who gains root access can modify the baseline if it lives on the same system.
Monitor less, but monitor right — exclude volatile directories (
/proc,/sys,/dev,/tmp) and focus on critical paths (/etc,/bin,/sbin,/boot,/usr). Over-monitoring generates noise; under-monitoring creates blind spots.Automate regular scans — schedule FIM checks at least daily via cron. For real-time monitoring (OSSEC), configure alerting thresholds to avoid alert fatigue from expected package updates.
Integrate with broader security monitoring — pair FIM with malware scanning tools and network IDS to create defense-in-depth. FIM catches post-exploitation changes that other tools may miss.
Test your baseline regularly — intentionally modify a monitored file and verify the FIM tool detects it. A broken FIM system is worse than none at all because it creates false confidence.
Version-control your configurations — store AIDE configs, OSSEC rules, and Tripwire policies in a version control system. Track who changed what and when, creating an audit trail for the monitoring system itself.
FAQ
What is the difference between file integrity monitoring and intrusion detection?
File integrity monitoring (FIM) is a subset of intrusion detection. FIM specifically tracks changes to files on disk by comparing cryptographic hashes and file attributes against a known-good baseline. Intrusion detection systems (IDS) are broader — they may monitor network traffic (network IDS), system logs, process activity, and file changes (host-based IDS). Tools like OSSEC combine FIM with other IDS capabilities into a single platform.
How often should I run file integrity checks?
For most environments, daily scheduled scans are sufficient. Critical infrastructure handling sensitive data should run checks every 4-6 hours or use real-time monitoring. The frequency depends on your threat model: high-value targets may warrant continuous monitoring, while lower-risk systems can use daily or weekly scans. OSSEC supports real-time FIM, while AIDE and Tripwire require scheduled runs via cron.
Can file integrity monitoring detect zero-day exploits?
FIM cannot prevent zero-day exploits from occurring, but it can detect their effects. After a zero-day exploit is used to gain access, attackers typically modify files — planting backdoors, altering configurations, or replacing binaries. FIM detects these post-exploitation changes even when the initial attack vector is unknown. This makes FIM a critical detection control regardless of whether the exploit was known in advance.
Does AIDE work inside Docker containers?
Yes, AIDE can be installed and run inside Docker containers. However, since containers are typically ephemeral, the more common pattern is to run AIDE on the host system and monitor container filesystems that are bind-mounted. Alternatively, you can build AIDE into your container image and run it as an init command or health check before the main application starts.
How do I handle false positives from package updates?
Package updates legitimately change monitored files, which triggers FIM alerts. The standard approach is to update the baseline after planned maintenance windows. For AIDE, run aide --update after package updates. For OSSEC, you can configure rules to ignore known package manager paths during scheduled maintenance. For Tripwire, use tripwire --update to accept changes and regenerate the database.
Which tool is best for PCI DSS compliance?
All three tools can satisfy PCI DSS Requirement 11.5 (file integrity monitoring). However, OSSEC provides the most comprehensive compliance coverage because it also addresses log monitoring (Requirement 10), real-time alerting (Requirement 11.4), and automated response capabilities. For organizations needing only FIM, AIDE is the simplest compliant option with the lowest operational overhead.
Can I monitor Windows systems with these tools?
OSSEC supports Windows agents natively and can monitor Windows file systems, registry keys, and Windows event logs. AIDE and Open Source Tripwire are Unix/Linux only. For Windows environments, OSSEC is the only viable option among these three, though you may also consider Windows-native tools like Windows File Server Resource Manager or third-party commercial solutions.
How do I secure the FIM database from tampering?
Store the FIM database on a separate, access-controlled system. For AIDE and Tripwire, copy the database to a read-only NFS share or a dedicated management server after each scan. For OSSEC, the central manager stores all agent data, so secure the manager with strong access controls, firewall rules, and encryption. Encrypt database files where possible, and monitor the database files themselves for unauthorized access.