Stay Ahead With Linux Security HOWTOs

file integritysystem administrationsecurity best practices

Effective File Integrity Monitoring Techniques for Linux Systems

A Linux system can be changed without immediately looking broken. A service still starts. Users still log in. The application still responds. Then an administrator finds that an SSH setting was changed, a firewall rule file has different permissions, or a systemd unit appeared in a directory where nothing new was expected. . That is the point where file integrity monitoring becomes useful. This HOWTO explains how to think about file integrity changes on Linux systems, what to monitor, what changes matter, and how to investigate alerts without treating every file change as a compromise. What File Integrity Monitoring Does File integrity monitoring checks whether selected files and directories still match a known baseline. The baseline is usually created when the system is in an approved state. Later checks compare the current filesystem against that baseline. The comparison is not limited to file contents. A file integrity tool may track: File type Permissions Inode number User and group Size Timestamps Link count and link name ACLs and extended attributes SELinux labels Cryptographic hashes AIDE, for example, builds a database from files listed in its configuration and stores many of these attributes for later comparison. That matters because attackers do not always need to replace a binary. A permission change can be enough. An ownership change can be enough. A new file in a startup path can be enough. A modified configuration file can change how the system authenticates users or exposes services. The purpose is not to record every possible change. The purpose is to notice changes that affect trust. Start With Files That Control System Behavior A common mistake is trying to monitor the whole filesystem at the same level. That creates long reports and weak attention. Start with files that define how the system behaves . Useful first targets include: /etc/ssh/sshd_config /etc/passwd /etc/shadow /etc/group /etc/sudoers /etc/sudoers.d/ PAM configuration systemd unit files cron directories firewall rule files kernel module configuration package manager configuration privileged scripts system binaries shared libraries application configuration files that control authentication or execution These are not the only paths that matter, but they are good examples of security-relevant files. A change to one of them can alter access, privilege, persistence, or network exposure. A web server may also need integrity checks on selected application paths. A bastion host may need stricter checks on SSH, sudo , shell profile, and audit configuration. A database server may need close monitoring on service units, authentication configuration, and backup scripts. The right scope depends on the host. The question to ask is simple: if this file changes without approval, does the system trust the change? Build the Baseline Carefully The baseline is the reference point. If the baseline is wrong, the monitoring will be wrong. Create the baseline from a clean and approved system state. Ideally, this is after installation, hardening, package updates, and application deployment, but before the host is exposed to production traffic. On existing systems, the first baseline can still be useful, but treat it as the current observed state, not proof that the system is clean. With AIDE, the basic model is to initialize the database, then use later checks to compare the system against it. Red Hat’s documentation describes this workflow as installing AIDE, generating an initial database, running integrity checks, and updating the database after verified system changes. It also recommends keeping the database, configuration, and AIDE binary in a secure location such as read-only media for stronger protection. That last part is important. If an attacker can modify the database, the configuration, or the integrity-checking binary, the result is less trustworthy. Local fileintegrity monitoring is still useful, but it is not tamper-proof when all of its components are stored on the same compromised host. Do not automatically approve every change into the baseline. A baseline update should follow a known event: a package update, a configuration management run, an application deployment, or an approved manual change. Automatic baseline replacement can turn a security control into a record of whatever happened last. Choose Attributes Based on the File Not every file needs the same checks. For system binaries: Content hashes matter. Ownership and permissions also matter because a binary that becomes writable by the wrong user is a problem even before it is modified. For configuration files: Content changes are important, but so are permissions, ownership, SELinux labels, and extended attributes. A configuration file may contain the same text but become writable by an account that should not control it. For directories: Added and removed files may be more important than content. A new file under /etc/cron.d/ , /etc/systemd/system/ , or a privileged script path may indicate persistence. A removed file may indicate cleanup or tampering. For logs and spools: Content changes are expected. Monitoring the full contents of every log file usually creates noise. But permissions, ownership, unexpected deletion, or suspicious truncation may still matter. AIDE allows rules to define which attributes are checked for different files and directories. The documentation also warns that configuration takes tuning and that broad ignores can hide files that an attacker may want to place somewhere unmonitored. The goal is not maximum coverage on paper. The goal is useful coverage in operation. Exclude Noisy Paths Without Creating Hiding Places Some paths change constantly. Logs grow. Caches update. Temporary files appear and disappear. Package managers write state. Applications create runtime data. Ignoring those paths completely may make reportsreadable, but it can also create blind spots. Avoid rules that exclude broad areas without thinking through attacker behavior. For example, ignoring all of /var may hide too much. A better approach is to exclude specific volatile file patterns while continuing to watch security-relevant paths under /var , application directories, and service-specific locations. Be careful with pattern matching. A loose exclusion may ignore more than intended. The AIDE documentation gives examples where a rule meant to ignore rotated log files can also ignore a current file or create room for an attacker to place files under a similar name. It recommends precise matching, including anchoring patterns when a single file is intended. Readable reports are important. So are safe exclusions. A report that nobody reads is not useful. A quiet policy that ignores attacker-controlled paths is also not useful. The work is in the middle. Use Audit Data to Find the Actor File integrity monitoring usually tells you what changed. It may not tell you who changed it. Linux auditing helps fill that gap. The audit daemon is the userspace component of the Linux Audit system. It writes audit records to disk. Rules are loaded into the kernel, and records can be reviewed with tools such as ausearch and aureport . For sensitive files, add audit rules that watch writes and attribute changes. For example: auditctl -w /etc/ssh/sshd_config -p wa -k sshd_config_change That kind of rule can help connect a file change to a user, process, and event. It is especially useful when the integrity alert only says that the file no longer matches the baseline. The auditd documentation also notes that rules can be loaded at startup and that adding the audit=1 boot parameter helps ensure early processes are marked as auditable by the kernel. Without that, some early activity may not be properly audited. Use file integrity monitoring for state. Use audit data for attribution. One tells you the file changed. The otherhelps explain how it changed. Use Real-Time Events Where Delay Matters Scheduled checks are useful, but some paths need faster visibility. Linux provides inotify for monitoring filesystem events. It can monitor files or directories and report events such as access, metadata changes, write-close events, file creation, deletion, modification, and rename activity. This can be useful for narrow, high-value monitoring . Examples include: SSH configuration sudoers files firewall rule paths cron directories systemd unit directories privileged application configuration Do not treat inotify as a complete integrity system. It has important caveats. Directory monitoring is not recursive by default. Event queues can overflow. Rename handling has race conditions. Events may be missed if activity happens outside the watched path. The API does not directly identify the user or process that triggered an event. It also does not report all activity on network filesystems or pseudo-filesystems in the way administrators may expect. Real-time monitoring is an early warning. It is not proof of the complete filesystem state. For important systems, use it alongside scheduled integrity checks and audit records. Investigate Alerts by Building a Timeline When a file integrity alert appears, do not start by assuming compromise. Start by placing the change in time. First, identify what exactly changed : Was the content modified? Were permissions changed? Was ownership changed? Was a file added? Was a file removed? Was a file renamed? Did the SELinux context or extended attributes change? Did the baseline change? Then, compare the alert against normal system activity . Check package manager history, configuration management logs, deployment records, sudo logs, audit records, user sessions, systemd journal entries, and nearby files or directory timestamps. A changed SSH configuration during a documented hardening update is differentfrom the same change made by an interactive shell at 03:00. A new file under a systemd directory from a package install is different from a manually written service unit that launches a binary from /tmp . Look for clusters. Attackers often change more than one thing. A new service file, a modified script, and a log gap around the same time are more concerning than any single event alone. MITRE describes adversaries selectively deleting or modifying artifacts such as logs, command histories, and file metadata to reduce indications of activity while keeping enough normal data in place to avoid immediate suspicion. That is why missing data matters . A cleared shell history, a truncated log, a changed timestamp, or an unexpected log rotation near an integrity alert should not be ignored. Watch for Changes That Look Administrative Many suspicious changes do not look dramatic. An attacker may enable password authentication in SSH for a short period. They may add an authorized key. They may place a script under a name that resembles a legitimate maintenance task. They may add a cron job that calls a script from an ordinary-looking path. They may change permissions so a low-privilege user can later modify a file. They may replace a binary and restore timestamps. Those changes can look like administration if viewed one at a time. This is why file integrity monitoring should focus on behavior. A file is not important only because of where it sits. It is important because of what the system does with it. Ask yourself: Does this file run as root? Does it affect login? Does it affect sudo ? Does it affect network exposure? Does it start at boot? Does another trusted process execute it? Can a non-privileged user now write to it? That line of thinking catches issues that simple path-based monitoring can miss. Know When Detection Should Become Enforcement Most file integrity monitoring detects change after it happens. That is enough for many systems. Somesystems need stronger controls. Linux Integrity Measurement Architecture (IMA) can calculate file hashes, maintain measurement logs, support audit logging, and appraise files against known-good values or signatures. With appraisal, access can be denied when verification fails. Extended Verification Module (EVM) can protect security-relevant metadata such as security.ima , SELinux labels, capabilities, UID, GID, mode, and related attributes. Red Hat’s kernel integrity guidance describes IMA measurement, appraisal, and audit as separate features. It also explains that an app can compare a file hash or signature against a trusted reference and deny access when verification fails. This is not the same as running a periodic AIDE check. It is a stricter model. Use it where the operational profile fits: stable systems, high-value workloads, regulated environments, or hosts where unauthorized execution should be blocked rather than merely reported. Test it carefully. Enforcement can break workloads if policies, labels, signatures, or update flows are wrong. Detection is easier to operate. Enforcement gives stronger guarantees but less room for mistakes. Protect the Monitoring System Itself Monitor the integrity of the monitoring configuration. Monitor the database. Monitor the reports. Monitor whether scheduled checks stop running. An attacker who understands the environment may not only change the target file. They may change the monitoring rule, remove a watched path, modify the baseline, stop the scheduled job, or tamper with local logs. This is why off-host evidence matters. Send logs and alerts to a central system. Restrict who can update baselines. Keep old baselines for comparison. Review baseline updates manually. Store critical integrity data somewhere the monitored host cannot freely rewrite. NIST’s integrity control language focuses on using integrity verification tools to detect unauthorized changes to software, firmware, and information, and on taking defined actionswhen unauthorized changes are detected. It also includes enhancements for integrity checks, automated notifications, centralized tools, and integration with incident response. That is the operational point. Detecting change is only part of the control. Someone has to receive the alert, understand it, and act. Operational Takeaways File integrity monitoring is useful when it answers practical questions: What changed? Was the change expected? Who or what made it? Does it affect authentication, privilege, execution, persistence, logging, or network exposure? Can the current system still be trusted? Best Practices Summary: Start with a clean baseline. Watch files that control system behavior. Tune rules so reports are readable, but do not create broad hiding places. Treat metadata changes as seriously as content changes when the file is security-sensitive. Pair integrity checks with audit data. Use real-time events for narrow, high-value paths. Send evidence off-host. Update baselines only after changes are verified. The purpose is not to prove that no file ever changes. Linux systems change constantly. The purpose is to notice when the wrong files change, understand what that means, and respond before a quiet modification becomes a long investigation. FAQs What is file integrity monitoring on Linux? File integrity monitoring compares selected files and directories against a trusted baseline to detect content, permission, ownership, metadata, or attribute changes. Is AIDE enough to detect compromise? AIDE can detect many unauthorized changes, but it should be paired with audit logs, centralized logging, and incident response procedures. Should I monitor the whole filesystem? Usually no. Start with files that affect authentication, privilege, startup behavior, execution, logging, and network exposure. . Learn how to implement file integrity monitoring on Linux systems effectively to detect unauthorized changes and improve security.. Linux FilesystemMonitoring, File Integrity, System Security, AIDE Configuration, Secure Linux Systems. . MaK Ulac

May 18, 2026 • MaK Ulac How to Harden My Filesystem