After the installation, the Wazuh manager and the Wazuh agent have defined a default syscheck configuration, which should be reviewed and adjusted to the particular environment. This section presents configuration examples, helping to learn how to use it in different use cases:
Syscheck component is configured both in the Wazuh manager's and in the Wazuh agent's ossec.conf file. This capability can be also configured remotely using centralized configuration and the agent.conf file. The list of all syscheck configuration options is available in the syscheck section.
To configure syscheck, a list of files and directories must be identified. The
check_all attribute of the directories option allows checks of the file size, permissions, owner, last modification date, inode and all the hash sums (MD5, SHA1 and SHA256).
By default, syscheck scans selected directories, whose list depends on the default configuration for the host's operating system.
If a directory is specified both in a centralized configuration and on the Wazuh agent's
ossec.conf, the centralized configuration will take preference and override the local configuration.
<syscheck> <directories check_all="yes">/etc,/usr/bin,/usr/sbin</directories> <directories check_all="yes">/root/users.txt,/bsd,/root/db.html</directories> </syscheck>
It is possible to hot-swap the monitored directories. This can be done for Linux, in both the Wazuh agent and the Wazuh manager, by setting the monitoring of symbolic links to directories. To set the refresh interval, use syscheck.symlink_scan_interval option found in the internal configuration of the monitored Wazuh agent.
Once, the directory path is removed from the syscheck configuration and the Wazuh agent is being restarted, the data from the previously monitored path is no longer stored in the FIM database.
By default, syscheck scans when the Wazuh starts, however, this behavior can be changed with the scan_on_start option.
For the schedluled scans, syscheck has an option to configure the frequency of the system scans. In this example, syscheck is configured to run every 10 hours:
<syscheck> <frequency>36000</frequency> <directories>/etc,/usr/bin,/usr/sbin</directories> <directories>/bin,/sbin</directories> </syscheck>
There is an alternative way to schedule the scans using the scan_time and the scan_day options. In this example, the scan will run every Saturday at the 10pm. Configuring syscheck that way might help, for example, to set up the scans outside the environment production hours:
<syscheck> <scan_time>10pm</scan_time> <scan_day>saturday</scan_day> <directories>/etc,/usr/bin,/usr/sbin</directories> <directories>/bin,/sbin</directories> </syscheck>
Real-time monitoring is configured with the
realtime attribute of the directories option. This attribute only works with the directories rather than with the individual files. Real-time change detection is paused during periodic syscheck scans and reactivates as soon as these scans are complete:
<syscheck> <directories check_all="yes" realtime="yes">c:/tmp</directories> </syscheck>
New in version 3.4.0.
Who-data monitoring is configured with the
whodata attribute of the directories option. This attribute replaces the
realtime attribute, 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:
<syscheck> <directories check_all="yes" whodata="yes">/etc</directories> </syscheck>
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.
It is possible to lose
who-data events when a flood of events appears. The following options help the audit socket and dispatcher to deal with big amounts of events:
/etc/audit/auditd.conf -> disp_qos = ["lossy", "lossless"] /etc/audisp/audisp.conf -> q_dephs = [<Numerical value>]
disp_qos sets blocking/lossless or non-blocking/lossy communication between the audit daemon and the dispatcher. There is a 128k buffer between the audit daemon and dispatcher. This is sufficient for most uses. If lossy is chosen, incoming events going to the dispatcher are discarded when the queue is full. In this case, events are still written to disk if
log_format is not
nolog. Otherwise, the auditd daemon will wait for the queue to have an empty spot before logging to disk. The risk is that while the daemon is waiting for network IO, an event is not being recorded to disk. The recommended value is lossless.
q_dephs is a numeric value, by default set to 80, that tells how big is the internal queue of the audit event dispatcher. A bigger queue handles flood of events better but could hold events that are not processed when the daemon is terminated. This value has to be increased if there are messages in the syslog indicating that the events are being dropped.
On the Wazuh side, the
rt_delay variable from the internal FIM configuration can help to prevent the loss of events:
/var/ossec/etc/internal_options.conf -> syscheck.rt_delay = [Numerical value]
It sets a delay between real-time alerts in milliseconds. The value has to be decreased to process who-data events faster.
To report new files added to the system, syscheck can be configured with the alert_new_files option. By default, this feature is enabled on the monitored Wazuh agent, but the option is not present in the syscheck section of the configuration:
<syscheck> <alert_new_files>yes</alert_new_files> </syscheck>
An example alert on a new file creation looks as follows:
** Alert 1585943821.46978: - ossec,syscheck,pci_dss_11.5,gpg13_4.11,gdpr_II_5.1.f,hipaa_164.312.c.1,hipaa_164.312.c.2,nist_800_53_SI.7, 2020 Apr 03 19:57:01 (agent) any->syscheck Rule: 554 (level 5) -> 'File added to the system.' File '/etc/new_file' added Mode: scheduledAttributes: - Size: 2 - Permissions: rw-r--r-- - Date: Fri Apr 3 19:56:50 2020 - Inode: 23194 - User: root (0) - Group: root (0) - MD5: 9a8ad92c50cae39aa2c5604fd0ab6d8c - SHA1: a9fcd54b25e7e863d72cd47c08af46e61b74b561 - SHA256: 092fcfbbcfca3b5be7ae1b5e58538e92c35ab273ae13664fed0d67484c8e78a6
To report the exact content that has been changed in a text file, syscheck can be configured with the
report_changes attribute of the directories option.
Report_changes should be used with caution as Wazuh copies every single monitored file to a private location.
In this example, by enabling the
report_changes, the alerts will show the changed content for all the text files in a listed directory and its subdirectories:
<syscheck> <directories check_all="yes" realtime="yes" report_changes="yes">/test</directories> </syscheck>
** Alert 1585758628.156629: - ossec,syscheck,pci_dss_11.5,gpg13_4.11,gdpr_II_5.1.f,hipaa_164.312.c.1,hipaa_164.312.c.2,nist_800_53_SI.7, 2020 Apr 01 16:30:28 (agent) any->syscheck Rule: 550 (level 7) -> 'Integrity checksum changed.' File '/test/file' modified Mode: real-time Changed attributes: size,mtime,inode,md5,sha1,sha256 Size changed from '14' to '13' Old modification time was: '1585758615', now it is '1585758628' Old inode was: '23186', now it is '23188' Old md5sum was: 'f296597bd5a808e5d1ad8cc2ab09c9f3' New md5sum is : 'ab68c0f2af74dc4a1c482a83c0c5a3ec' Old sha1sum was: 'ba0fe43dcd9586c8c2703d8278a960a3aa4b4754' New sha1sum is : '3a686748bf79db0adbad15f22ef566212a13b6c8' Old sha256sum was: '53fe48bd127d4bf0e559f26b005ee40ee40d1bba4e971dd0437da6aa47759310' New sha256sum is : '40e29c160ea4e9911cafb9bcdbb2bcec21904a0c13a2871936c79145ff8085c7'Attributes: - Size: 13 - Permissions: rw-r--r-- - Date: Wed Apr 1 16:30:28 2020 - Inode: 23188 - User: root (0) - Group: root (0) - MD5: ab68c0f2af74dc4a1c482a83c0c5a3ec - SHA1: 3a686748bf79db0adbad15f22ef566212a13b6c8 - SHA256: 40e29c160ea4e9911cafb9bcdbb2bcec21904a0c13a2871936c79145ff8085c7What changed: 1c1 < Original text --- > Altered text
If some sentive files exist in the monitored with
report_changes path, nodiff option can be used. This option disables computing the diff for the listed files, avoiding data leaking by sending the files content changes through alerts:
<syscheck> <directories check_all="yes" realtime="yes" report_changes="yes">/test</directories> <nodiff>/test/private</nodiff> </syscheck>
In this example, by adding nodiff option, syscheck will not compute the diff for a listed text file:
** Alert 1585757658.154829: - ossec,syscheck,pci_dss_11.5,gpg13_4.11,gdpr_II_5.1.f,hipaa_164.312.c.1,hipaa_164.312.c.2,nist_800_53_SI.7, 2020 Apr 01 16:14:18 (agent) any->syscheck Rule: 550 (level 7) -> 'Integrity checksum changed.' File '/test/private' modified Mode: real-time Changed attributes: size,mtime,inode,md5,sha1,sha256 Size changed from '14' to '20' Old modification time was: '1585757413', now it is '1585757658' Old inode was: '23187', now it is '23185' Old md5sum was: 'ef4ad1a40d0a95ad2e1b72eccdca6d44' New md5sum is : '158ccd88359654ac4ffd0e3cecb79a49' Old sha1sum was: '5f34d30f7bdefe9e825bff388de047dacdc09853' New sha1sum is : '18dfef68273c00fc733e28ce9aa1830f5e8fabd8' Old sha256sum was: '211ae95d4e54cff5724a98f0bae0b505adfdafe1ed8b15e40570a5fe58d20c61' New sha256sum is : '60c2a08e66f02bacea882f7b437f9c983431d75a686b703661c34e288d36de9d'Attributes: - Size: 20 - Permissions: rw-r--r-- - Date: Wed Apr 1 16:14:18 2020 - Inode: 23185 - User: root (0) - Group: root (0) - MD5: 158ccd88359654ac4ffd0e3cecb79a49 - SHA1: 18dfef68273c00fc733e28ce9aa1830f5e8fabd8 - SHA256: 60c2a08e66f02bacea882f7b437f9c983431d75a686b703661c34e288d36de9dWhat changed: <Diff truncated because nodiff option>
In order to avoid false positives, syscheck can be configured to ignore certain files and directories that do not need to be monitored by using the ignore option:
<syscheck> <ignore>/etc/random-seed</ignore> <ignore>/root/dir</ignore> <ignore type="sregex">.log$|.tmp</ignore> </syscheck>
Similar functionality, but for the Windows registries can be achieved by using the registry_ignore option:
<syscheck> <registry_ignore>HKEY_LOCAL_MACHINE\Security\Policy\Secrets</registry_ignore> <registry_ignore type="sregex">\Enum$</registry_ignore> </syscheck>
An alternative method to ignore specific files scanned by syscheck is by using rules and setting the rule level to 0. By doing that the alert will be silenced:
<rule id="100345" level="0"> <if_group>syscheck</if_group> <match>/var/www/htdocs</match> <description>Ignore changes to /var/www/htdocs</description> </rule>
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"> <if_group>syscheck</if_group> <match>/var/www/htdocs</match> <description>Changes to /var/www/htdocs - Critical file!</description> </rule>
New in version 3.6.0.
It is possible to configure the maximum recursion level allowed for a specific directory by using the
recursion_level attribute of the directories option.
recursion_level value must be an integer between 0 and 320.
An example configuration may look as follows:
<syscheck> <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> </syscheck>
Using the following directory structure and
folder_test ├── 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
The alerts will be genarated for all files up to
folder_test/level_1/level_2/level_3/ but not for any files in the directory deeper than
To disable the recursion and generate the alerts only for the files in the monitored folder, the
recursion_level value has to be set to 0.
recursion_level is not specified, it is set to the default value defined by
syscheck.default_max_depth in the internal options configuration file.
New in version 3.12.0.
To adjust syscheck CPU usage on the monitored system the process_priority option can be used. It sets the nice value for syscheck process. The default
process_priority is set to 10.
process_priority value higher than the default, will give syscheck lower priority, less CPU resources and make it run slower. In the example below the nice value for syscheck process is set to maximum:
<syscheck> <process_priority>19</process_priority> </syscheck>
process_priority value lower than the default, will give syscheck higher priority, more CPU resources and make it run faster. In the example below the nice value for syscheck process is set to minimum:
<syscheck> <process_priority>-20</process_priority> </syscheck>
New in version 3.12.0.
When the Wazuh agent starts it performs a first scan and generates its database. By default, the database is created in disk:
<syscheck> <database>disk</database> </syscheck>
Syscheck can be configured to store the database in memory instead by changing value of the database option:
<syscheck> <database>memory</database> </syscheck>
The main advantage of using in memory database is the performance as reading and writing operations are faster than performing them on disk. The corresponding disadvantage is that the memory must be sufficient to store the data.
New in version 3.12.0.
Synchronization can be configured to change the synchronization interval, the number of events per second, the queue size and the response timeout:
<syscheck> <synchronization> <enabled>yes</enabled> <interval>5m</interval> <max_interval>1h</max_interval> <response_timeout>30</response_timeout> <queue_size>16384</queue_size> <max_eps>10</max_eps> </synchronization> </syscheck>
If the Wazuh agent is upgraded to the v3.12 and keeps its old configuration, the synchronization section will not be present in the
ossec.conf file but the Wazuh agent will still use the default synchronization settings as shown above.