1. Basic usage
  2. Configuring scheduled scans
  3. Configuring real-time monitoring
  4. Configure to report changes
  5. Configure to ignore files
  6. Configure maximum recursion level allowed
  7. Ignoring files via rules
  8. Changing severity

Basic usage

Syscheck is configured in the ossec.conf file. Generally this configuration is set using the following sections:

For detailed configuration options, go to Syscheck.

To configure syscheck, a list of files and directories must be identified. The check_all option checks file size, permissions, owner, last modification date, inode and all the hash sums (MD5, SHA1 and SHA256).


If a directory is specified both in a centralized configuration and on the agent’s ossec.conf, the centralized configuration will take precedence and override the local configuration.

  <directories check_all="yes">/etc,/usr/bin,/usr/sbin</directories>
  <directories check_all="yes">/root/users.txt,/bsd,/root/db.html</directories>

Configuring scheduled scans

Syscheck has an option to configure the frequency of the system scans. In this example, syscheck is configured to run every 10 hours.


Configuring real-time monitoring

Real-time monitoring is configured with the realtime option. This option only works with directories rather than with individual files. Real-time change detection is paused during periodic syscheck scans and reactivates as soon as these scans are complete.

  <directories check_all="yes" realtime="yes">c:/tmp</directories>

Configuring who-data monitoring

New in version 3.4.0.

Who-data monitoring is configured with the whodata option. This option replaces the realtime option, which means that whodata implies real-time monitoring but adding the who-data information. This functionality uses Linux Audit subsystem and the Microsoft Windows SACL, so additional configurations might be necessary. Check the Auditing who-data entry to get further information.

  <directories check_all="yes" whodata="yes">/etc</directories>


There is a known bug that affects to the versions 2.8.5 and 2.8.4 of audit that shows a directory as null when it has been moved adding a / at the end of the directory. This bug will cause that no alerts related with this directory will be shown until a new event related to this directory is triggered when whodata is enabled.

Configure to report changes

Using the report_changes option, we can see what specifically changed in text files. Be careful about which folders you set up to report_changes to, because in order to do this, Wazuh copies every single file you want to monitor to a private location.

  <directories check_all="yes" realtime="yes" report_changes="yes">/test</directories>

Configure to ignore files

Files and directories can be omitted using the ignore option (or registry_ignore for Windows registry entries). In order to avoid false positives, syscheck can be configured to ignore certain files that don’t need to be monitored.

  <ignore type="sregex">.log$|.tmp</ignore>

Configure maximum recursion level allowed

New in version 3.6.0.

It is possible to configure the maximum recursion level allowed for a specific directory by setting the recursion_level option. This option must be an integer between 0 and 320. An example of use:

  <directories check_all="yes">/etc,/usr/bin,/usr/sbin</directories>
  <directories check_all="yes">/root/users.txt,/bsd,/root/db.html</directories>
  <directories check_all="yes" recursion_level="3">folder_test</directories>

Using the following directory structure and recursion_level="3":

├── file_0.txt
└── level_1
    ├── file_1.txt
    └── level_2
        ├── file_2.txt
        └── level_3
            ├── file_3.txt
            └── level_4
                ├── file_4.txt
                └── level_5
                    └── file_5.txt

We will receive alerts for all files up to folder_test/level_1/level_2/level_3/ but we won’t receive alerts from any directory deeper than level_3.

If we don’t want any recursion (just get alerts from the files in the monitored folder), we must set recursion_level to 0.


If recursion_level is not specified, it will be set to the default value defined by syscheck.default_max_depth in the internal options configuration file.

Ignoring files via rules

It is also possible to ignore files using rules, as in this example:

<rule id="100345" level="0">
  <description>Ignore changes to /var/www/htdocs</description>

Changing severity

With a custom rule, the level of a syscheck alert can be altered when changes to a specific file or file pattern are detected.

<rule id="100345" level="12">
  <description>Changes to /var/www/htdocs - Critical file!</description>