TL;DR: Use
chattr +i /usr/bin/aideto make AIDE binary immutable. Even root cannot modify it without removing the flag first, making rootkit replacement detectable.
Prevent rootkits from replacing AIDE binaries using Linux immutable file attributes.
The Problem: A sophisticated rootkit can replace /usr/bin/aide to hide its presence.
The Solution: Use chattr +i to make AIDE binary immutable - even root cannot modify it without first removing the immutable flag.
# Make file immutable
sudo chattr +i /usr/bin/aide
# Verify
lsattr /usr/bin/aide
# Output: ----i--------e----- /usr/bin/aideWhat immutable means:
- ❌ Cannot be modified (even by root)
- ❌ Cannot be deleted
- ❌ Cannot be renamed
- ❌ Cannot create hard links to it
Security benefit: Rootkit must first remove immutable flag (requires CAP_LINUX_IMMUTABLE capability), which is more likely to be detected.
Protect these critical AIDE files:
# AIDE binary
sudo chattr +i /usr/bin/aide
# AIDE configuration
sudo chattr +i /etc/aide/aide.conf
# Optional: Drop-in configs
sudo chattr +i /etc/aide/aide.conf.d/*.confThe update-aide-db.sh script handles immutable flags automatically:
# Before AIDE update: remove immutable flag
remove_immutable() {
if lsattr "$file" | grep -q '\-i\-'; then
chattr -i "$file"
fi
}
# After AIDE update: restore immutable flag
restore_immutable() {
chattr +i "$file"
}
# Trap ensures restoration even on error
trap 'restore_immutable "$AIDE_BINARY"' EXITWorkflow:
- Script removes immutable flag
- AIDE runs (can write to database)
- Script restores immutable flag (even on error via trap)
When upgrading AIDE package, APT needs to replace the binary.
# Before apt upgrade
sudo chattr -i /usr/bin/aide
# Upgrade
sudo apt upgrade aide
# After upgrade
sudo chattr +i /usr/bin/aideCreate /etc/apt/apt.conf.d/99-aide-unlock:
# Unlock AIDE binary before package operations
DPkg::Pre-Install-Pkgs {
"if [ -x /usr/bin/aide ]; then chattr -i /usr/bin/aide 2>/dev/null || true; fi";
};
# Re-lock after package operations
DPkg::Post-Invoke {
"if [ -x /usr/bin/aide ]; then chattr +i /usr/bin/aide 2>/dev/null || true; fi";
};Test:
# Dry-run upgrade
sudo apt install --simulate aide
# Verify unlock works
lsattr /usr/bin/aide# List all immutable files in /usr/bin
lsattr /usr/bin | grep '\-i\-'
# Check specific file
lsattr /usr/bin/aide
# Should show: ----i--------e----- /usr/bin/aide# Try to modify (should fail)
sudo echo "malicious" >> /usr/bin/aide
# Error: Operation not permitted
# Try to delete (should fail)
sudo rm /usr/bin/aide
# Error: Operation not permitted
# Try to rename (should fail)
sudo mv /usr/bin/aide /usr/bin/aide.bak
# Error: Operation not permitted✅ Defense in Depth: Extra layer beyond file permissions ✅ Rootkit Prevention: Harder for rootkit to replace AIDE ✅ Audit Trail: Removing immutable flag is auditable (if auditd configured) ✅ No Performance Impact: Attribute check is fast
❌ Package Upgrades: Need APT hook or manual unlock ❌ Recovery Complexity: Harder to fix broken AIDE installation ❌ Not Silver Bullet: Skilled attacker can still remove flag
Log when immutable flags are changed:
# /etc/audit/rules.d/99-aide.rules
-a always,exit -F arch=b64 -S ioctl -F a1=0x40086602 -F exe=/usr/bin/chattr -k aide_immutable_changeExplanation:
ioctlsyscall with0x40086602(FS_IOC_SETFLAGS) = chattr operation-k aide_immutable_change= Audit key for filtering
Query audit logs:
sudo ausearch -k aide_immutable_changeIf AIDE is broken and you need to replace binary:
# Remove immutable flag
sudo chattr -i /usr/bin/aide
# Reinstall package
sudo apt install --reinstall aide
# Restore immutable flag
sudo chattr +i /usr/bin/aideMaintain list of immutable files:
# /etc/aide/immutable-files.txt
/usr/bin/aide
/etc/aide/aide.conf
/etc/aide/aide.conf.d/10-docker-excludes.confAfter any AIDE-related operation:
# Check immutable flags are restored
lsattr /usr/bin/aide /etc/aide/aide.confUse auditd to alert on immutable flag changes (see above).
- ✅ AIDE monitoring (detects file changes)
- ✅ Immutable flags (prevents modification)
- ✅ AppArmor/SELinux (restricts process capabilities)
- ✅ Secure Boot (prevents boot-level tampering)
What immutable DOES protect against:
- Accidental deletion
- Simple file replacement attacks
- Unsophisticated rootkits
What immutable DOES NOT protect against:
- Kernel-level rootkits (can bypass immutable check)
- Attacks that first remove immutable flag
- Boot-level tampering (before OS loads)
Recommendation: Use immutable flags as defense in depth, not sole protection.
- SETUP.md - Initial AIDE configuration
- BEST_PRACTICES.md - Production security recommendations
- chattr man page