Intrusion detection environment
.gitignore | ||
aide-0.14-man.patch | ||
aide-0.15.1-fipsfix.patch | ||
aide.conf | ||
aide.logrotate | ||
aide.spec | ||
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.