AIDE File Integrity Monitor on AWS User Guide

Overview

This image runs AIDE (Advanced Intrusion Detection Environment), the open source, GPL-2.0 licensed host-based file and directory integrity checker. AIDE builds a cryptographic baseline database of the attributes of the files it watches - permissions, ownership, inode, size, timestamps and content hashes - and on every subsequent run reports exactly what has been added, removed or changed against that baseline. It is a host intrusion detection staple and a direct answer to compliance controls that mandate file-integrity monitoring, such as PCI-DSS requirement 11.5 and the CIS Benchmarks.

This is a headless command-line image. There is no web interface, no service to log into and no credentials: AIDE is a purely local tool that you drive with the aide command over SSH using your own key. AIDE opens no network socket and runs no daemon.

The single most important design decision in this image is that the baseline database is never baked into the AMI. An AIDE baseline is a fingerprint of one specific machine's filesystem; a baseline computed on the build server would describe the wrong machine, so the very first check on your instance would report thousands of spurious differences. Instead, the baseline is generated on your instance at first boot, so it fingerprints your real machine. A systemd timer then runs a daily integrity check and writes the report to /var/log/aide/aide.log, and the check is fail-closed: it refuses to run unless a valid per-instance baseline is present.

Prerequisites

Before you deploy this image you need:

• An Amazon Web Services account where you can launch EC2 instances
• IAM permissions to launch instances, create security groups, and subscribe to AWS Marketplace products
• An EC2 key pair in the target Region for SSH access to the instance
• A VPC and subnet in the target Region, with a security group allowing inbound port 22 from your management network
• The AWS CLI (version 2) installed locally if you plan to deploy from the command line

Connecting to Your Instance

This listing may offer more than one operating system variant. Connect over SSH on port 22 as the default login user for the variant you launched:

Use your EC2 key pair, for example:

ssh -i /path/to/your-key.pem ubuntu@<vm-ip>

Step 1: Launch the Instance from the AWS Marketplace

Sign in to the AWS Management Console, open the EC2 service, and select Launch instance. Under Application and OS Images choose AWS Marketplace AMIs and search for AIDE. Select the cloudimg listing and choose Select, then Continue on the subscription summary.

Pick an instance type of m5.large or another size that suits your workload. Choose your EC2 key pair under Key pair (login). Under Network settings select your VPC and subnet, and either create or select a security group that opens port 22 from your management network. Leave the root volume at the default size or larger.

Select Launch instance. First boot initialisation - during which AIDE builds the per-instance baseline database - takes a minute or two after the instance state becomes Running and the status checks pass.

Step 2: Launch the Instance from the AWS CLI

The following block launches an instance from the cloudimg AIDE Marketplace AMI into an existing subnet and security group. Replace <ami-id> with the AMI ID shown on the Marketplace listing, <key-name> with your EC2 key pair name, <subnet-id> with your subnet ID, and <security-group-id> with a security group that opens port 22 from your management network.

aws ec2 run-instances \
  --image-id <ami-id> \
  --instance-type m5.large \
  --key-name <key-name> \
  --subnet-id <subnet-id> \
  --security-group-ids <security-group-id> \
  --tag-specifications 'ResourceType=instance,Tags=[{Key=Name,Value=aide}]'

Step 3: Confirm AIDE and the Per-Instance Baseline

Connect over SSH as shown above, then confirm the AIDE version and that the per-instance baseline database was built at first boot. The firstboot unit stays active after it completes, and the baseline lives at /var/lib/aide/aide.db.

aide --version
sudo systemctl is-active aide-firstboot.service
sudo test -s /var/lib/aide/aide.db && echo "per-instance baseline present at /var/lib/aide/aide.db"

A per-instance note is written at first boot describing the appliance. It contains no secrets - AIDE has no login or credential of any kind.

sudo cat /root/aide-instance.txt

Step 4: Understand the Monitored Scope

The appliance ships a focused, hardened default configuration at /etc/aide/aide.conf. It watches the paths that matter for tamper detection - executables, libraries, boot, kernel modules and /etc - while excluding volatile, high-churn paths so the report stays signal rather than noise. Review the monitored paths and exclusions:

sudo grep -E '^/|^!/|^FULL|^DIRS' /etc/aide/aide.conf

To watch additional paths, add a line such as /opt/myapp FULL to /etc/aide/aide.conf, then rebuild the baseline (Step 8).

Step 5: The Scheduled Daily Integrity Check

A systemd timer, aidecheck.timer, runs an integrity check once a day (with a randomised delay) and appends the report to /var/log/aide/aide.log. Confirm it is enabled and see when it will next run:

systemctl is-enabled aidecheck.timer
systemctl list-timers aidecheck.timer --no-pager || true

After the first scheduled run, review the report at any time:

sudo test -f /var/log/aide/aide.log && sudo tail -n 20 /var/log/aide/aide.log || echo "no scheduled report yet - the daily timer has not fired since first boot"

A report that lists added, removed or changed files is AIDE working as designed - not a failure. Review it, and if the changes were expected, update the baseline as shown in Step 8.

Step 6: Run an Integrity Check on Demand

Run a check against the per-instance baseline whenever you want. On a freshly booted instance this reports no differences; after any change to a monitored path it reports exactly what changed. The command below never leaves your shell in an error state - it prints a friendly note if differences are found.

sudo aide --check --config=/etc/aide/aide.conf | tail -n 12 || echo "AIDE reported differences (review the report above). A diff is normal after intentional changes - update the baseline as shown in Step 8."

Step 7: Prove Change Detection with a Controlled Test

The following self-contained test proves the detector end to end without touching any real system path. It builds a tiny baseline over a temporary directory, verifies a clean check passes, then adds and modifies a file and shows that AIDE names exactly those files in its report.

WORK="$(mktemp -d)"; MON="$WORK/watched"; mkdir -p "$MON"
printf 'original\n' > "$MON/file-a.txt"
cat > "$WORK/aide.conf" <<CONF
database_in=file:$WORK/db
database_out=file:$WORK/db.new
gzip_dbout=no
DEMO = p+i+n+u+g+s+b+m+c+sha256
$MON DEMO
CONF
aide --init -c "$WORK/aide.conf" >/dev/null 2>&1
mv "$WORK/db.new" "$WORK/db"
echo "-- unchanged baseline (expect clean) --"
if aide --check -c "$WORK/aide.conf" >/dev/null 2>&1; then echo "CLEAN: no differences"; else echo "unexpected diff"; fi
echo "-- add and modify a file, then re-check --"
printf 'planted\n' > "$MON/intruder.txt"
printf 'modified\n' > "$MON/file-a.txt"
aide --check -c "$WORK/aide.conf" 2>&1 | grep -E 'Added entries|Changed entries|intruder\.txt|file-a\.txt' | head -8
rm -rf "$WORK"
echo "DETECTED: AIDE named the added and changed files above"

Step 8: Update the Baseline After Intentional Changes

After you make deliberate, reviewed changes to the system - a package update, a configuration edit, deploying a new application - the next check will report those changes. Once you have confirmed they are expected, refresh the baseline so future checks compare against the new known-good state.

sudo aide --update --config=/etc/aide/aide.conf > /tmp/aide-update.log 2>&1 || true
sudo mv -f /var/lib/aide/aide.db.new /var/lib/aide/aide.db 2>/dev/null || true
sudo chmod 0600 /var/lib/aide/aide.db
echo "baseline refreshed - future checks compare against the current state"

The single-command equivalent shipped with AIDE on this image is sudo aideinit, which builds a fresh baseline into /var/lib/aide/aide.db.new; move it into place with sudo mv /var/lib/aide/aide.db.new /var/lib/aide/aide.db.

Step 9: Hardening the Baseline for Real Assurance

The baseline database is stored read-restricted at /var/lib/aide/aide.db. For strong tamper assurance, an attacker who can rewrite both the filesystem and the baseline could hide their tracks, so for high-value systems copy the baseline off the instance (or onto read-only media) after each intentional update, and compare against that trusted copy. AIDE is installed unmodified from the operating system's official package archive, so it continues to receive standard unattended security updates.

Support

cloudimg provides 24/7 technical support for this product by email and live chat at support@cloudimg.co.uk. Support covers baseline initialisation and updates, tuning the monitored scope, interpreting integrity reports, wiring the schedule and reports into a log or SIEM pipeline, moving the baseline off-box for stronger assurance, and compliance mapping (PCI-DSS 11.5, CIS Benchmarks). Critical issues receive a one-hour average response.