AIDE on Ubuntu 24.04 LTS on Azure

This image ships AIDE (Advanced Intrusion Detection Environment) on Ubuntu 24.04 LTS, ready to detect tampering from the first boot of every deployed virtual machine. AIDE is installed unmodified from Ubuntu's own archive, so it stays patchable through the normal apt path for the life of the release.

AIDE is an open source host based file and directory integrity checker. It builds a cryptographic baseline database of the files it is told to watch, recording their permissions, ownership, size, timestamps and content hashes, and on every later run it compares the live filesystem against that baseline and reports exactly what has been added, removed or changed.

What this appliance does and does not do

Read this section before you deploy. It is the difference between an appliance that does what you think it does and one that quietly does not.

What AIDE is good at. AIDE answers one question with authority: has anything on this machine been tampered with. It detects a backdoored system binary, an altered configuration file, an unexpected new file dropped into a system directory, or a change to the boot files. It is a foundational control for security hardening and a direct answer to compliance regimes that mandate file integrity monitoring, including PCI DSS requirement 11.5 and the CIS Benchmarks.

What AIDE is not. AIDE is a local, on demand integrity checker. This image does not include, and AIDE itself is not:

• a real time monitor: it checks when it runs, on a schedule, not continuously as files change,
• an antivirus or malware scanner: it detects change, not maliciousness, so it does not know a signature from a backdoor, only that a watched file is now different,
• a central console, a SIEM or an agent that reports to a server,
• a web interface of any kind.

AIDE tells you that something changed. Deciding whether a given change is expected (a package update you ran) or hostile (a file you never touched) is your judgement, and this guide shows you the workflow for exactly that.

What makes this image different

The baseline is built per machine, on first boot, not baked in. An integrity baseline is a fingerprint of one specific machine. A baseline captured at image build time would describe the build machine, so every deployed instance would report thousands of false changes on its very first check and would leak the build machine's state. Instead, no baseline ships. Every virtual machine deployed from this image builds a fresh baseline of its own real filesystem on first boot, so the very first check you run is meaningful.

The image fails closed. The scheduled check will not run against a missing or incomplete baseline. Two independent safeguards enforce that on every run, not merely the first, so an instance that has not finished first boot cannot present an integrity check that silently checks nothing.

A scheduled check is already wired. A systemd timer runs a daily integrity check and logs its findings, so you get continuous coverage without configuring anything. Reporting changes is the tool working as designed, not a fault, and the workflow for reviewing and accepting expected changes is in section 8.

There is no login and no password. AIDE has no user database, no network service and no credential of any kind. There is nothing here to rotate and nothing to leak. Administration is over SSH with your own key.

1. Deploy the virtual machine

Deploy the image from the Azure Marketplace. The defaults in this guide assume:

• Size: Standard_B2s (2 vCPU, 4 GB) is sufficient and is what this image is validated on. AIDE is a lightweight command line tool; size up only if you extend the monitored scope to very large data directories.
• Inbound ports: SSH (22) only. AIDE opens no network port of its own, so nothing else needs to be open.
• Authentication: your own SSH public key.

2. Connect to the virtual machine

ssh azureuser@<vm-ip>

On first boot the machine builds its per machine baseline database before the scheduled check is armed. That takes under a minute on a new machine. If you connect immediately and the baseline is not ready yet, that is first boot still working, and section 10 shows how to watch it.

3. Confirm AIDE is installed and the baseline is built

aide --version | head -1
sudo test -s /var/lib/aide/aide.db && echo "per-VM baseline present" || echo "baseline NOT yet built"
systemctl is-active aide-firstboot.service
sudo test -f /var/lib/cloudimg/aide-firstboot.done && echo "firstboot sentinel present"

You should see the AIDE version, a baseline database that is present, and a first boot service that is active. The baseline at /var/lib/aide/aide.db was built on this machine at first boot.

4. See what is being monitored

The appliance ships a focused, hardened configuration that watches the paths that matter for tamper detection: executables, shared libraries, the boot files and the system configuration under /etc. High churn and self referential paths are deliberately excluded so the check does not drown in noise.

grep -vE '^\s*#|^\s*$' /etc/aide/aide.conf | sed -n '1,40p'

The FULL rule records permissions, inode, link count, owner, group, size, block count, modification and change times, and a SHA-256 content hash for every watched file. That is what lets AIDE tell a genuine content change from a harmless timestamp touch.

5. Run an integrity check now

You can run a check by hand at any time. Immediately after first boot the system matches its baseline, so a check is clean.

sudo aide --check --config=/etc/aide/aide.conf > /tmp/aide-check.out 2>&1; echo "aide --check exit code: $?"
sed -n '1,12p' /tmp/aide-check.out

AIDE's exit code encodes what it found: 0 means no changes, and a non-zero code is a bitmask of the change classes it detected (added, removed, changed). A non-zero exit is not an error, it is a finding. Only review the report to decide whether the change was expected.

6. Prove it actually detects a change

Do not take "the check ran" as proof that detection works. Prove it. This plants a harmless marker file in a monitored directory, runs a check, confirms AIDE reports the new file, and then removes the marker so your baseline is clean again.

sudo touch /usr/local/sbin/aide-demo-intruder
sudo aide --check --config=/etc/aide/aide.conf > /tmp/aide-demo.out 2>&1; echo "exit code: $? (non-zero = change detected)"
grep -A1 -i 'added\|aide-demo-intruder' /tmp/aide-demo.out | head -8
sudo rm -f /usr/local/sbin/aide-demo-intruder
echo "marker removed; baseline is clean again"

You should see the check exit non-zero and the report name /usr/local/sbin/aide-demo-intruder as an added entry. That is the whole product in four lines: a file appeared in a watched directory and AIDE caught it.

7. The scheduled check

A systemd timer runs the same integrity check daily and appends its report to /var/log/aide/aide.log, so you have continuous coverage with nothing to configure.

systemctl is-active aidecheck.timer
systemctl list-timers aidecheck.timer --no-pager | sed -n '1,3p'
echo "reports are appended to /var/log/aide/aide.log"

To run the scheduled check immediately rather than waiting for the timer, and then read the tail of its log:

sudo systemctl start aidecheck.service
sudo tail -n 15 /var/log/aide/aide.log

8. Review reports and update the baseline

Here is the workflow that turns AIDE from a noisy tool into a useful one. When a check reports changes, you decide whether each change was expected. If you ran a package update or edited a configuration file yourself, the changes are expected and you accept them by rebuilding the baseline so future checks are quiet again. If you did not make the change, you have a genuine integrity event to investigate.

After you have reviewed a report and confirmed the changes are legitimate, rebuild the baseline:

# Rebuild the per-VM baseline to accept reviewed, expected changes.
# (aideinit builds a new database and moves it into place.)
sudo aideinit --yes --force
sudo cp /var/lib/aide/aide.db.new /var/lib/aide/aide.db 2>/dev/null || true

The golden rule: only update the baseline after you have reviewed the changes and confirmed they are yours. Updating it blindly defeats the entire purpose, because it accepts whatever an attacker did along with whatever you did.

9. Monitor additional paths

The shipped configuration covers the system paths that matter most. To also watch an application directory, add a rule to a drop-in and rebuild the baseline. This example watches /opt/myapp:

# Append a monitor rule for your own directory, then rebuild the baseline.
echo '/opt/myapp FULL' | sudo tee -a /etc/aide/aide.conf
sudo aideinit --yes --force
sudo cp /var/lib/aide/aide.db.new /var/lib/aide/aide.db

Keep the scope purposeful: watch code and configuration, not high churn data directories, log directories or caches, which would fill every report with expected noise and hide the change that matters.

10. First boot and troubleshooting

The per machine baseline is built by aide-firstboot.service on first boot. To watch or re-run it:

systemctl is-enabled aide-firstboot.service
systemctl status aide-firstboot.service --no-pager | sed -n '1,8p' || true

The unit is a one shot: once it has built the baseline it stays inactive (dead), which is the healthy resting state — is-enabled returning enabled is what confirms it is wired in.

If the baseline was not built (for example the machine lost power mid first boot), re-run it:

# Re-run the first-boot baseline build if it did not complete.
sudo systemctl restart aide-firstboot.service

The scheduled check refuses to run until a valid baseline exists, so a machine that has not finished first boot will never present an integrity check that silently checks nothing.

11. Licensing

AIDE is licensed under the GNU General Public License, version 2. It is installed unmodified from Ubuntu's public apt archive, so it remains patchable through the normal unattended-upgrades path for the life of the release. The complete corresponding source for the exact binaries installed is available from that same archive with apt-get source aide, and a written offer for the source is shipped on the image at /usr/share/doc/cloudimg/AIDE-GPL-2-WRITTEN-OFFER.txt.

Unlike a signature based scanner, AIDE ships no third party detection content: the only data it uses is the baseline it builds from your own machine, so there is no external database to license or redistribute.

Support

Every cloudimg deployment is backed by 24/7 support. If you have any questions about this image, contact us at support@cloudimg.co.uk.