If an attacker manages to bypass your edge firewalls, dodge your systemd sandboxes, and exploit a local service, what happens next? In a standard environment, sophisticated attackers immediately look to do two things: establish persistence (by modifying binaries or adding cron jobs) and cover their tracks (by erasing standard log files).<\/p>\n\n\n\n
To defend against this, your hardening strategy needs post-compromise visibility and system integrity verification. This is achieved by combining two powerful tools: Auditd<\/strong> (The Linux Auditing System) for real-time kernel-level event tracking, and AIDE<\/strong> (Advanced Intrusion Detection Environment) for host-based file integrity monitoring.<\/p>\n\n\n\n Here is how to deploy them to create an unalterable forensic trail.<\/p>\n\n\n\n Unlike standard application logs that can be easily manipulated or turned off by a privileged user, Auditd relies on rules defined in Here are essential production rules to add to your configuration:<\/p>\n\n\n\n When an anomaly occurs, you use To see a summary of all commands executed by user IDs over a specific timeframe, use While If an attacker drops a rootkit, alters After installing AIDE, you must generate the initial trusted snapshot of your clean operating system.<\/p>\n\n\n\n This creates a baseline database file (typically To compare the current state of the server against your trusted baseline, execute a check:<\/p>\n\n\n\n If a malicious actor added a backdoored file or altered an existing binary, AIDE will print an aggressive summary showing exact cryptographic hash mismatches, size differences, and modified timestamps.<\/p>\n\n\n\n Manually running integrity checks is inefficient. Automate AIDE via a daily cron job that emails you the output or pipes it to your centralized logging dashboard:<\/p>\n\n\n\n Crucial Operational Note:<\/strong> Whenever you intentionally update packages or modify configuration files via Deploying Auditd and AIDE on the local machine is only half the battle. If an attacker manages to achieve full root privileges, they can eventually delete the local AIDE database or clear the To truly secure your forensic logging:<\/p>\n\n\n\n By implementing this dual-layered forensic setup, you ensure that even if an intrusion occurs, the attacker cannot hide, and you possess the absolute clarity required to remediate the system completely.<\/p>\n\n\n\n \n Tracking real-time kernel execution with auditd and verifying file system hashes with AIDE provides an unalterable forensic trail. However, keeping those audit trails secure requires a truly isolated underlying platform. If a server experiences hardware resource contention or lacks bare-metal security boundaries, your monitoring systems can be compromised right alongside your applications.\n <\/p>\n 1. Auditd: Tracking Kernel-Level Events in Real Time<\/h2>\n\n\n\n
auditd<\/code> hooks directly into the Linux kernel. It monitors system calls (syscalls<\/code>) at the lowest level, tracking exactly who executed a command, what file they touched, and when.<\/p>\n\n\n\nWriting Bulletproof Audit Rules<\/h3>\n\n\n\n
\/etc\/audit\/rules.d\/audit.rules<\/code>. To track an attacker’s movements effectively, we want to watch critical system configuration files and user space activity.<\/p>\n\n\n\n# First, clear any existing rules\n-D\n\n# Increase the buffer size to handle high-volume event logging\n-b 8192\n\n# Watch for changes to user accounts and authentication\n-w \/etc\/passwd -p wa -k user_changes\n-w \/etc\/shadow -p wa -k user_changes\n-w \/etc\/sudoers -p wa -k sudo_changes\n\n# Watch for modifications to network and SSH configurations\n-w \/etc\/ssh\/sshd_config -p wa -k sshd_changes\n-w \/etc\/network\/interfaces -p wa -k network_changes\n\n# Track execution of specific administrative tools\n-a always,exit -F arch=b64 -S execve -F euid=0 -k root_commands<\/code><\/pre>\n\n\n\n\n
-w<\/code><\/strong>: Specifies the file or directory path to watch.<\/li>\n<\/ul>\n\n\n\n\n
-p wa<\/code><\/strong>: Triggers an alert on w<\/strong>rites and attribute a<\/strong>lterations (like chmod<\/code> or chown<\/code>).<\/li>\n<\/ul>\n\n\n\n\n
-k<\/code><\/strong>: Assigns a unique search key (e.g., user_changes<\/code>) so you can quickly filter your logs later.<\/li>\n<\/ul>\n\n\n\nSearching the Forensic Trail<\/h3>\n\n\n\n
ausearch<\/code> to parse the audit logs. For example, to see every event tied to your SSH configuration rule, run:<\/p>\n\n\n\nsudo ausearch -k sshd_changes<\/code><\/pre>\n\n\n\naureport<\/code>:<\/p>\n\n\n\nsudo aureport -x --summary<\/code><\/pre>\n\n\n\n2. AIDE: Catching Unauthorized File Modifications<\/h2>\n\n\n\n
auditd<\/code> tells you who<\/em> is doing something in real-time, AIDE<\/code> tells you what changed<\/em> on the filesystem after the fact. AIDE takes a snapshot of your system’s binaries, libraries, and configurations, hashes them, and stores the hashes in a secure database.<\/p>\n\n\n\n\/bin\/bash<\/code>, or adds a malicious backdoor line to a system library, AIDE will flag it on the next run.<\/p>\n\n\n\nStep 1: Initialize the Baseline Database<\/h3>\n\n\n\n
sudo aideinit<\/code><\/pre>\n\n\n\naide.db.new.gz<\/code>). To make it active, move it to the production path:<\/p>\n\n\n\nsudo mv \/var\/lib\/aide\/aide.db.new.gz \/var\/lib\/aide\/aide.db.gz<\/code><\/pre>\n\n\n\nStep 2: Running regular Integrity Checks<\/h3>\n\n\n\n
sudo aide --check<\/code><\/pre>\n\n\n\nStep 3: Automating the System Audit<\/h3>\n\n\n\n
0 3 * * * \/usr\/bin\/aide --check | mail -s \"Daily AIDE Integrity Report for $(hostname)\" admin@yourdomain.com<\/code><\/pre>\n\n\n\n\n
apt<\/code>, yum<\/code>, or Ansible, your AIDE checks will fail because the files legitimately changed. You must update your baseline database immediately after any maintenance window:<\/p>\n<\/blockquote>\n\n\n\nsudo aide --update\nsudo mv \/var\/lib\/aide\/aide.db.new.gz \/var\/lib\/aide\/aide.db.gz<\/code><\/pre>\n\n\n\n3. The Ultimate Rule: Securing the Logs<\/h2>\n\n\n\n
\/var\/log\/audit\/audit.log<\/code> file.<\/p>\n\n\n\n\n
rsyslog<\/code> or vector<\/code> to immediately forward all system and audit logs to a dedicated, offsite log management server.<\/li>\n\n\n\naide.db.gz<\/code> file off-server, or put it on a read-only filesystem mount. If you suspect a breach, copy the verified off-site database back to the server to run your integrity check.<\/li>\n<\/ol>\n\n\n\n\n \ud83d\udee1\ufe0f Secure Forensic Logging Environments\n <\/h4>\n