File Integrity Monitoring Wazuh: Cara Kerja dan Who-Data

Someone replaced a configuration file on the server in the early hours, and no one knew until the service encountered issues. This type of problem is addressed by file integrity monitoring (FIM) in Wazuh: a module that records the initial condition of files and then alerts when files are created, modified, or deleted.

How it works: baseline then compare

According to Wazuh documentation, the FIM module stores cryptographic checksums and other attributes of monitored files during the initial scan. Each time a file changes, the module compares the checksum and attributes with that baseline and triggers an alert if there is a discrepancy. Three events are recorded: file created, modified, and deleted.

The configuration is located in the <syscheck> section of the agent's ossec.conf (on Linux: /var/ossec/etc/ossec.conf). Monitoring is written through the <directories> element. If you do not configure it, Wazuh uses a default list: /etc, /usr/bin, /usr/sbin, /bin, and /sbin.

Scheduled or real-time

There are two detection modes, and the difference is important:

Scheduled scanning compares files with the baseline at the time the scan is running. Real-time mode is enabled through the realtime="yes" attribute in <directories>, with a default value of no, available only on Linux and Windows, and it only works on directories, not individual files.

Two notes from the documentation: real-time detection is paused during scheduled scanning and then resumes afterward. Also, directories must exist before the agent is restarted; if not, they are ignored until the next restart.

Which attributes are compared

The check_all option records all attributes at once, and by default, all attributes are set to yes. The check_sum option is equivalent to enabling MD5, SHA-1, and SHA-256 hashes simultaneously. If the two options conflict, the last one written takes precedence.

The content of new files is also stored if you enable report_changes, but by default, it is set to no and the feature is limited to text files. The size limit for differences is set by diff_size_limit, with a default of 50 MB.

Who changed it: who-data

Regular FIM alerts notify what has changed, not who made the change. The attribute whodata="yes" (default no) adds the user and process that made the changes. On Linux, audit mode requires:

The audit daemon is installed and active;
On Audit 3.1.1 and above, the audispd af_unix plugin is installed;
No -a never,task rule in /etc/audit/rules.d/audit.rules. Many systems include this by default, and as long as that rule exists, who-data will not report anything.

After the agent is restarted, auditctl -l | grep wazuh_fim should display the rules added by Wazuh. One trap in reading the results: if the actor uses sudo, the effective user is recorded as root, which differs from the user who started the session. Also, check the login user column, not just the effective user.

Testing in your own environment

The Wazuh testing guide uses a single directory with check_all="yes", report_changes="yes", and realtime="yes". Create a text file, add content, and then delete it, with a pause of about 5 seconds in between. In the File Integrity Monitoring module on the dashboard, filter with rule.id: is one of 550,553,554 to display alerts for files added, modified, and deleted. Such tests should ideally be conducted on a test machine, not on a production server.

If you prefer to see directly how the graphs of file additions, modifications, and deletions appear on the dashboard, there is a clip on the Taalenta video page.

Wazuh FIM: How Alerts for File Creation, Modification, and Deletion Work

How it works: baseline then compare

Scheduled or real-time

Which attributes are compared

Who changed it: who-data

Testing in your own environment

Sources