File integrity monitoring looks at those attributes of a file that may indicate that its content has changed. These attributes include size, modification and creation times, one-way hashes of the contents of the file itself, and ownership and permissions of the file. Any change to one or more of these attributes triggers an alert. With OSSEC, we can customize the checks at a system-wide, per-directory, or even per-file level.

We're going to tune the default configuration to monitor additional directories, to always alert on file changes, and to configure the scanning to occur when our systems aren't under heavy load.

After a few a days of running the default configuration, you may notice that the alarm volume drops off dramatically from the FIM. The default configuration automatically ignores any file that changes beyond the third change, assuming the changes are a part of the normal operation. While this helps with the volume of the alerts, it may not satisfy your compliance requirements. To receive these alerts, we need to disable the auto_ignore feature of syscheck daemon by setting it to no.

When the syscheck daemon detects a new file, it silently creates an entry using this new file's attributes as the baseline. A file's initial state is considered clean and only changes to that state will trigger alerts. If you wish to receive notifications when a file is added to a directory, you may tell OSSEC to notify you by setting alert_new_files to yes.

Now that we have enabled comprehensive alerting on changes to files and directories, we can start to fine-tune the performance of the syscheck daemon. By default, a restart of OSSEC' syscheck daemon starts a scan of all the directories being monitored. This may not be ideal if you need to restart OSSEC for configuration changes in the middle of your peak utilization. To be safe, we disable the startup scan by setting scan_on_start to no.

Now the scans will schedule in accordance with the values defined by our frequency attribute, ignoring daemon restarts. You may have noticed that there has been a possible impact on the performance of this system. Disks just aren't as fast as the rest of our system components. If we're doing scans of directories with a substantially large number and/or size, it's going to impact the performance of the rest of the system. This is true of any FIM solution and not just OSSEC.

To avoid these performance penalties, OSSEC has an option of utilizing the inotify system to check only those files that change. In our directories definition, we set the realtime attribute to yes, and on systems supporting inotify, checks will automatically run when the file or directory is updated.

This means we can relax our scanner further and schedule the full scan to run at a low usage time during the day. We configured syscheck to start scans at 3 A.M., after a minimum of 23 hours (82,800 seconds) since the last scan. For the /etc, /usr/bin and /usr/sbin directories, we enable the realtime notifications if they are supported on the host system. File modifications in these directories will be scanned as they occur at 3 A.M. everyday. For the remaining directories, the realtime option hasn't been enabled, so they will only be scanned once per day at 3 A.M.

Play with these settings to get adequate coverage without imposing a performance penalty on your network or systems.

Working with the OSSEC FIM implementation is nice given how flexible it is. It even has extended capabilities for Windows and hooks for Linux systems using prelinking.

<syscheck>
    <!-- scheduling and directories would go here -->
    <windows_registry>HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services</windows_registry>
    <windows_registry>HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\RunServicesOnce</windows_registry>
    <windows_registry>HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\RunServices</windows_registry>
   <!-- Repeat for all interesting registry keys -->
</syscheck>

<prefilter_cmd>/usr/sbin/prelink -y</prefilter_cmd>