DEV Community

Cover image for AIDE in Motion Automating and Signing System Integrity Checks
Richard Chamberlain
Richard Chamberlain

Posted on

AIDE in Motion Automating and Signing System Integrity Checks

#fileintegrity #gpg #cryptography #automation

If your system could testify, AIDE would be its expert witness.
In this article, we take the next step — not just monitoring integrity, but proving it.

With automation, cryptographic signatures, and daily verification, your Linux system learns to trust but verify itself.

Introduction

I’ll be the first to admit: encryption isn’t my strongest area.

Sure, I’ve worked with public and private keys for SSH authentication and have signed keys before, so I’m not entirely new to the topic. But I hadn’t really explored how cryptography ties into system integrity — until now.

In the first article of this series, we installed and configured AIDE (Advanced Intrusion Detection Environment) — a silent guardian that fingerprints your Linux system and detects when files change unexpectedly. It’s an excellent tool for monitoring file integrity, but it raises an important question:

If AIDE verifies the integrity of your files, who verifies the integrity of AIDE?

That’s where hashing and cryptographic signing come into play. In this article, we’ll use GPG to sign AIDE’s baseline database and check results, ensuring every integrity report can be proven genuine — even after the fact.

🧭 Table of Contents

  1. Introduction
  2. From Watching to Proving
  3. GPG (GNU Privacy Guard)
  4. Protecting and Signing the AIDE Baseline
  5. Protecting AIDE Check Results
  6. Conclusion – Integrity You Can Prove
  7. Related Resources

🧰 From Watching to Proving

Most administrators install AIDE to keep watch over their systems — to detect when files change, permissions shift, or unexpected binaries appear. But detection is only half the battle. To trust what AIDE reports, you must also verify that its baseline and results haven’t been altered. Otherwise, a compromised attacker could quietly modify both the files and the evidence. This article builds on the first AIDE tutorial by showing how to sign and verify AIDE’s outputs using GPG (GNU Privacy Guard), creating a chain of integrity that can be trusted even in hostile environments.

GPG (GNU Privacy Guard)

GPG is a widely used encryption and signing tool that provides both confidentiality and integrity verification. In this workflow, we’ll use it to sign AIDE’s database and output logs, guaranteeing they haven’t been altered after creation.

GPG works with a public/private key pair. Your private key is used to sign or decrypt data, while the public key can be shared with others to verify those signatures.

To create a key pair, use one of the following commands:

gpg --generate-key
# or for more control:
gpg --full-generate-key
Enter fullscreen mode Exit fullscreen mode

You’ll be prompted to provide a name, email address, and passphrase — details used to identify and protect your key. Once generated, GPG stores your keys inside the ~/.gnupg/ directory.

To confirm your key exists, run:

gpg --list-keys
Enter fullscreen mode Exit fullscreen mode

We’ll soon use this key to sign and verify AIDE’s baseline database and reports, creating an additional layer of trust in your monitoring process.

🗝️ Protecting and Signing the AIDE Baseline

When you run:

aide --init
Enter fullscreen mode Exit fullscreen mode

AIDE creates a baseline database, a snapshot of the system defined by the rules in aide.conf. This database represents your system’s memory — and if it’s modified, the entire trust chain collapses.

In the previous setup, AIDE saved the baseline to /var/lib/aide/aide.db.gz. To protect it, we’ll sign it using GPG and store the signature securely so it can be verified before each integrity check.

# Create a secure directory
sudo mkdir -p /root/.aide

# Sign the baseline with your GPG key
sudo gpg --output /root/.aide/aide.db.gz.sig --detach-sign /var/lib/aide/aide.db.gz

# Restrict access and make it immutable
sudo chmod 400 /root/.aide/aide.db.gz.sig
sudo chattr +i /root/.aide/aide.db.gz.sig
Enter fullscreen mode Exit fullscreen mode

The --detach-sign flag creates a signature file without altering the original database. Before any future aide --check runs, you can verify that the database hasn’t changed:

sudo gpg --verify /root/.aide/aide.db.gz.sig /var/lib/aide/aide.db.gz
Enter fullscreen mode Exit fullscreen mode

🔍 Note:
The signature is stored in /root/.aide instead of alongside the baseline in /var/lib/aide/ because /root/ is restricted to the root user. This separation prevents low-privileged processes—or an attacker who compromises them—from accessing or modifying the signature. By isolating it in a root-only directory and marking it immutable, you preserve the trust boundary even if the baseline database itself is tampered with.

🛡️ Protecting AIDE Check Results

Once your baseline is protected, the next step is to safeguard AIDE’s check results. When you run aide --check, it compares the current system to the baseline and produces a report. These reports must also be hashed and signed — otherwise, they could be edited to hide signs of intrusion.

First, generate a timestamped log file:

LOG_DIR="/var/log/aide"
SAFE_DIR="/root/.aide/reports"
DATESTAMP=$(date +"%Y-%m-%d_%H-%M-%S")

LOG_FILE="${LOG_DIR}/aide-check-${DATESTAMP}.log"

sudo mkdir -p "$LOG_DIR" "$SAFE_DIR"
sudo aide --check >"$LOG_FILE" 2>&1
Enter fullscreen mode Exit fullscreen mode

This creates a report such as /var/log/aide/aide-check-2025-10-28_15-42-01.log.

To make this log tamper-evident, hash and sign it.
The log stays in /var/log/aide, but the hash and signature are stored securely in /root/.aide:

HASH_FILE="${SAFE_DIR}/aide-check-${DATESTAMP}.log.sha512"
SIG_FILE="${SAFE_DIR}/aide-check-${DATESTAMP}.log.sig"

sha512sum "$LOG_FILE" >"$HASH_FILE"
gpg --output "$SIG_FILE" --detach-sign "$LOG_FILE"

sudo chmod 400 "$HASH_FILE" "$SIG_FILE"
sudo chattr +i "$HASH_FILE" "$SIG_FILE"
Enter fullscreen mode Exit fullscreen mode

Your system now maintains a verifiable chain of integrity reports:

/var/log/aide/
└── aide-check-2025-10-28_15-42-01.log

/root/.aide/reports/
├── aide-check-2025-10-28_15-42-01.log.sha512
└── aide-check-2025-10-28_15-42-01.log.sig
Enter fullscreen mode Exit fullscreen mode

These signatures and hashes ensure that even if logs in /var/log are tampered with, it will be immediately detectable — because the verification artifacts are protected inside /root/.aide.

For a deeper walkthrough on building your own automation script, see the AIDE Automation Build Guide, and for a quick reference, use the AIDE Daily Integrity Checklist, both available alongside this article.

🧭 Conclusion – Integrity You Can Prove

AIDE doesn’t stop attacks — it detects evidence that one has occurred. That evidence only matters if it can be trusted. By integrating GPG signing and hashing into your AIDE workflow, you ensure that your system’s integrity checks cannot be silently altered or falsified.

This adds an important layer of assurance to your Linux environment — one that slows attackers, strengthens your audit process, and gives you verifiable proof of system integrity.

In the next phase, we’ll take this a step further by linking signatures into a cryptographic ledger, creating a verifiable evidence chain across systems.

📚 Related Resources

Top comments (0)