← Back to posts
comparison guide self-hosted · · 13 min read

AIDE vs OSSEC vs Tripwire: Self-Hosted File Integrity Monitoring Guide 2026

Compare AIDE, OSSEC, and Tripwire for self-hosted file integrity monitoring. Learn installation, configuration, and best practices for detecting unauthorized file changes on your servers.

OS
Editorial Team

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)

AttributeDetail
GitHubaide/aide
Stars708
Last UpdateJanuary 2026
LanguageC
Latest Releasev0.19.3
LicenseGPL-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)

AttributeDetail
GitHubOSSEC/ossec-hids
Stars5,017
Last UpdateApril 2026
LanguageC
LicenseGPL-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

AttributeDetail
GitHubtripwire/tripwire-open-source
Stars926
Last UpdateFebruary 2024
LanguageC++
Latest Release2.4.3.7
LicenseGPL-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

FeatureAIDEOSSECTripwire
Primary FocusFile integrity onlyFull HIDS (FIM + log analysis + rootkit detection)File integrity only
ArchitectureStandalone CLIClient-server (manager + agents)Standalone CLI
Hash AlgorithmsSHA-256, SHA-512, MD5, RMD160, TigerSHA-1, MD5SHA-256, MD5
Real-Time MonitoringNo (scheduled scans only)Yes (real-time FIM + log monitoring)No (scheduled scans only)
Active ResponseNoYes (block IPs, run scripts)No
ConfigurationSimple text configComplex (XML config + rules)Policy template files
Learning CurveLowHighMedium
Database Size~10-50 MB (typical server)Varies (stores events centrally)~10-50 MB (typical server)
Resource UsageLow (CPU during scan)Medium (agent + manager)Low (CPU during scan)
Docker SupportCommunity imagesOfficial Docker (wazuh/wazuh-manager)No official Docker image
CompliancePCI DSS, CIS benchmarksPCI DSS, HIPAA, SOC 2, NISTPCI DSS, CIS benchmarks
AlertingEmail, exit codesEmail, syslog, SIEM integrationEmail, exit codes
Community ActivityActive (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:

1
2
3
4
5
6
7
8
# Debian/Ubuntu
sudo apt install aide

# RHEL/CentOS/Fedora
sudo dnf install aide

# Alpine
sudo apk add aide

After installation, initialize the configuration file at /etc/aide/aide.conf. A typical configuration defines rule groups and specifies which directories to monitor:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
# /etc/aide/aide.conf

# Rule definitions
F = p+i+l+n+u+g+s+m+c+sha256
DIR = p+i+l+n+u+g

# Critical system files - full check
/etc    F
/bin    F
/sbin   F
/usr/bin    F
/usr/sbin   F
/usr/lib    F
/boot   F

# Directories - check permissions only
/home   DIR+sha256
/root   DIR

# Exclude volatile directories
!/var/run
!/proc
!/sys
!/dev
!/tmp
!/var/tmp
!/var/lock

Initialize the baseline database and run your first check:

1
2
3
4
5
6
7
8
# Initialize the baseline database
sudo aide --init

# Copy the new database to the active location
sudo cp /var/lib/aide/aide.db.new.gz /var/lib/aide/aide.db.gz

# Run an integrity check
sudo aide --check

AIDE’s output shows exactly which files changed and what attributes were modified:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
AIDE 0.19.3 found differences between database and filesystem!!
Start timestamp: 2026-04-19 03:00:00

Summary:
  Total number of entries:    52418
  Added entries:              3
  Removed entries:            1
  Changed entries:            7

Changed entries:
  /etc/ssh/sshd_config
    Size     : 3256                              | 3260
    Mtime    : 2026-04-15 10:22:00               | 2026-04-19 02:55:00
    SHA256   : abc123...                         | def456...

To automate regular scans, add a cron job:

1
2
3
# /etc/cron.daily/aide-check
#!/bin/bash
/usr/bin/aide --check | mail -s "AIDE Daily Report - $(hostname)" admin@example.com

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:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
# docker-compose.yml - OSSEC Manager Single Node
services:
  ossec-manager:
    image: wazuh/wazuh-manager:5.0.0
    hostname: ossec-manager
    container_name: ossec-manager
    restart: always
    ports:
      - "1514:1514"      # Agent communication
      - "1515:1515"      # Agent enrollment
      - "55000:55000"    # RESTful API
      - "514:514/udp"    # Syslog reception
    environment:
      - INDEXER_USERNAME=admin
      - INDEXER_PASSWORD=YourStrongPassword123!
    volumes:
      - ossec-api-config:/var/wazuh-manager/api/configuration
      - ossec-etc:/var/wazuh-manager/etc
      - ossec-logs:/var/wazuh-manager/logs
      - ossec-queue:/var/wazuh-manager/queue

volumes:
  ossec-api-config:
  ossec-etc:
  ossec-logs:
  ossec-queue:

For traditional installation on monitored hosts:

1
2
3
4
5
6
7
# Install OSSEC agent on a monitored server
wget https://github.com/ossec/ossec-hids/releases/download/3.7.0/ossec-hids-3.7.0.tar.gz
tar -xzf ossec-hids-3.7.0.tar.gz
cd ossec-hids-3.7.0
sudo ./install.sh

# During installation, select "agent" mode and provide the manager IP

Configure FIM rules in the agent’s ossec.conf:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
<!-- /var/ossec/etc/ossec.conf on the agent -->
<syscheck>
  <!-- Frequency of scans (in seconds) -->
  <frequency>43200</frequency>

  <!-- Directories to monitor in real-time -->
  <directories realtime="yes" check_all="yes" report_changes="yes">/etc</directories>
  <directories realtime="yes" check_all="yes">/bin,/sbin,/usr/bin,/usr/sbin</directories>

  <!-- Files to ignore -->
  <ignore>/etc/mtab</ignore>
  <ignore>/etc/hosts.deny</ignore>
  <ignore>/etc/mail/statistics</ignore>

  <!-- Enable real-time monitoring -->
  <realtime enabled="yes">
    <directories>/etc,/usr/bin,/usr/sbin</directories>
  </realtime>
</syscheck>

Add the agent to the manager and start monitoring:

1
2
3
4
5
6
# On the manager, register the agent
sudo /var/ossec/bin/manage_agents -a <agent_ip> -n web-server-01
# Extract the agent key and provide it to the agent during setup

# Restart the agent
sudo systemctl restart ossec

Installing and Configuring Tripwire

Open Source Tripwire follows a similar installation pattern:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
# Debian/Ubuntu
sudo apt install tripwire

# RHEL/CentOS/Fedora
sudo dnf install tripwire

# Build from source (recommended for latest version)
git clone https://github.com/tripwire/tripwire-open-source.git
cd tripwire-open-source
./autogen.sh
./configure
make
sudo make install

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:

1
2
3
# Generate site and local keys
sudo twadmin --create-polfile -S /etc/tripwire/site.key /etc/tripwire/twpol.txt
sudo tripwire --init --site-keyfile /etc/tripwire/site.key --local-keyfile /etc/tripwire/$(hostname)-local.key

Edit the Tripwire policy file (/etc/tripwire/twpol.txt) to define what to monitor. The policy uses a rule-based syntax with property masks:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
# /etc/tripwire/twpol.txt

# Rule: Monitor critical binaries
(
  rulename = "Critical Binaries",
  severity = 100,
  emailto = admin@example.com
)
{
  /bin         -> $(SEC_BIN) -i ;
  /sbin        -> $(SEC_BIN) -i ;
  /usr/bin     -> $(SEC_BIN) -i ;
  /usr/sbin    -> $(SEC_BIN) -i ;
}

# Rule: Monitor configuration files
(
  rulename = "Configuration Files",
  severity = 75
)
{
  /etc         -> $(SEC_CONFIG) -i ;
}

# Rule: Monitor boot files
(
  rulename = "Boot Files",
  severity = 100
)
{
  /boot        -> $(SEC_CRIT) -i ;
}

Run an integrity check:

1
2
3
4
5
6
7
8
# Run a check and output to terminal
sudo tripwire --check

# Run a check and generate a report file
sudo tripwire --check --report-format html --report-file /tmp/tw-report.html

# Update the database after reviewing changes
sudo tripwire --update --twrfile /var/lib/tripwire/report/$(hostname)-$(date +%Y%m%d).twr

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

  1. 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.

  2. 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.

  3. 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.

  4. 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.

  5. 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.

  6. 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.

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

Advertise here