Questions on best practices using aide

Latest response

Hi Everyone,
(updated 12/23/2014 to fix a typo)

I have been using aide for a bit, and am searching for best practices using aide *(such as this RH Solution ID 55021)*, and would like to see if anyone has any recommendations for what they found as a best practice.

Some questions:
1) What are people's best practices
2) Omitting directories/mount points so aide does not hit Storage Area Network or Network Area Storage (SAN or NAS). (especially when a number of systems have that SAN/NAS mounted)
3) Disabling prelinking? (see reference below)
4) Periodicaly executing aide because it does not do so by default
5) Does anyone have ideas regarding or beyond the above topics? open to ideas/suggestions...

  • My own thoughts on Question number 2
    I have added a few lines to my /etc/aide.conf file to (I believe) stop aide from reviewing my Storage Area Network (SAN) (i put some comments in the solution id above.)
# egrep -A 3 'my/san' /etc/aide.conf
!/path/to/my/san
!/path/to/my/nas
!/path/to/my/iscsi/if/applicable
  • While not a Storage Area Network, perhaps tell aide so it does not hit directories that frequently change such as:
!/var/log.*
!/var/spool/.*
  • Prelinking question number 3

    • Does anyone shut off prelinking for the sake of aide?

    • According to this source, it recommends disabling prelinking because "The prelinking feature changes binaries in an attempt to decrease their startup time. In order to disable it, change or add the following line inside the file /etc/sysconfig/prelink :"

  • That guide in the link above recommends "PRELINKING=no" in /etc/sysconfig/prelink .

# grep ^PRELINK /etc/sysconfig/prelink # default is yes
PRELINKING=yes  # guide above recommends "no"
PRELINK_OPTS=-mR
PRELINK_FULL_TIME_INTERVAL=14
PRELINK_NONRPM_CHECK_INTERVAL=7

Next, after changing the PRELINKING=yes to PRELINKING=no, it recommends runing the following command to return binaries to a normal, non-prelinked state:

# /usr/sbin/prelink -ua

There is a remediation script at the same link that is about 12 lines long that is intended to disable prelinking altogether.

  • My own thoughts on Question number 4
  • We keep a copy of the original database for aide for each system in a separate location off of the system and another location.
  • We periodically check aide with a cron.
  • We keep a copy of the md5sum of the database, including the one stored above.
  • We Manually Verify Integrity of AIDE

Caveats
- AIDE will not solve everything - this is true of most intrusion detection systems; however, it can certainly help shorten the investigation time during incident response by focusing in on the files that have been changed. It may also be useful if an authorized administrator has implemented changes that did not go as planned.

A few last questions:
- Does anyone have any other ideas/best practices for using aide?
- What are people's thoughts about shutting off prelinking especially in regards to aide?
- What about causing aide to not search autofs mounts? My inclination is to stop aide from searching autofs mounts.

Thanks and appreciate any input...

Responses

  • Just found tad bit of additional info at this bit https://access.redhat.com/site/discussions/443703,
  • and also at that link, it also mentions /usr/share/doc/packages/aide/manual.html (but add [version] to /usr/share/doc/packages/aide-[VERSION]/manual.html . There are also a couple of README files).

  • /usr/share/doc/packages/aide-[VERSION]/manual.html also recommends omitting /var/log in the /etc/aide.conf file...

1) I find an iterative approach to configuring AIDE works best in my experience. Initially I start out with almost everything included and slowly change (loosen) the rules to remove false positives. My suggestion when doing this is to keep other admins out of any automated reporting chatter as they quickly grow tired of false positives and will potentially lose faith in the tool (get the alerts down to a reasonable level before sharing your configuration triumph!)

2) I only run aide against locally mounted filesystems. I don't have any major restrictions or exclusions at the filesystem level except the obvious dynamic filesystems. From memory, exclusions are all generally at the directory/file level.

3) I only run AIDE on servers that I have disabled prelinking. This involves disabling it (using the method you describe) and removing prelinking from binaries that have already been prelinked. I find some of the most critical files to monitor are system binaries so I am happy to take the performance hit to ensure they are being monitored correctly. With prelinking on I find you get far too many false positives for it to be useful. I haven't personally seen any major performance degradation, but I am conscious of the fact that it is disabled and was nervous about doing it initially.

4) I think executing frequently using cron (to email + log) and re-baseline as part of patching or software deployment is a good basic approach. What you suggest regarding protection of the aide database sounds like a nice addition too. I would also suggest that if you are going to add it to cron to use a random sleep at the start of the job because AIDE can tax the filesystem during the check and you don't want all your VM's hitting the disk at the same time!

5) One trick I found when dealing with log files (because the AIDE report would be filled with logs when they rotated) was to use dateext for the log file rotation and then ignore creation of compressed log files with a date extension in the log directory. This way you can still monitor the log directories for modification (except the non compressed, current logs), and you don't get all the 'noise' when the sequence numbers all shuffle down one during rotation.

Thanks much Pixel, appreciate the good details!

Close

Welcome! Check out the Getting Started with Red Hat page for quick tours and guides for common tasks.