Intrusion detection environment
5e25f406f2
Users upgrading from RHEL 9 (aide 0.16) to RHEL 10 (aide 0.19.2) face breaking config changes: removed options, renamed options, dropped hashsums, and deprecated syntax. Without migration the first aide run after upgrade fails with a fatal parse error (exit code 17). Adds aide-migrate-config, a script that automatically migrates aide.conf and all @@include'd files on install or upgrade. It also ships as a standalone tool for users who need to run it manually. verbose= is removed without adding replacement log_level= and report_level= settings; both options default to 'warning' and 'changed_attributes' in AIDE 0.19, so injecting them only clutters user configs. Introduce append_setting() to guarantee that any value appended to a config file starts on a fresh line. Without this, a file lacking a trailing newline at the point of append would have the new field concatenated onto the preceding line, silently corrupting the config. The H group check in needs_migration caused migrate_config_file to run even when no actual config content needed changing. The result was a spurious backup and mtime change on the config file during every 0.19.2-5 -> 0.19.2-6 upgrade with an unmodified aide.conf. Move the H group check to check_and_warn, which runs unconditionally after the migration loop. Resolves: RHEL-178837 Signed-off-by: Cropi <alakatos@redhat.com> |
||
|---|---|---|
| .fmf | ||
| .gitignore | ||
| aide-0.19.2-syslog-format.patch | ||
| aide-migrate-config | ||
| aide-tmpfiles.conf | ||
| aide.conf | ||
| aide.logrotate | ||
| aide.spec | ||
| ci_tests.fmf | ||
| gating.yaml | ||
| gpgkey-aide.gpg | ||
| README.quickstart | ||
| sources | ||
1) Customize /etc/aide.conf to your liking. In particular, add important directories and files which you would like to be covered by integrity checks. Avoid files which are expected to change frequently or which don't affect the safety of your system. 2) Run "/usr/sbin/aide --init" to build the initial database. With the default setup, that creates /var/lib/aide/aide.db.new.gz 3) Store /etc/aide.conf, /usr/sbin/aide and /var/lib/aide/aide.db.new.gz in a secure location, e.g. on separate read-only media (such as CD-ROM). Alternatively, keep MD5 fingerprints or GPG signatures of those files in a secure location, so you have means to verify that nobody modified those files. 4) Copy /var/lib/aide/aide.db.new.gz to /var/lib/aide/aide.db.gz which is the location of the input database. 5) Run "/usr/sbin/aide --check" to check your system for inconsistencies compared with the AIDE database. Prior to running a check manually, ensure that the AIDE binary and database have not been modified without your knowledge. Caution! With the default setup, an AIDE check is not run periodically as a cron job. It cannot be guaranteed that the AIDE binaries, config file and database are intact. It is not recommended that you run automated AIDE checks without verifying AIDE yourself frequently. In addition to that, AIDE does not implement any password or encryption protection for its own files. It is up to you how to put a file integrity checker to good effect and how to set up automated checks if you think it adds a level of safety (e.g. detecting failed/incomplete compromises or unauthorized modification of special files). On a compromised system, the intruder could disable the automated check. Or he could replace the AIDE binary, config file and database easily when they are not located on read-only media.