Wazuh FIM reached its file limit: reduce noise before raising it

Problem

Wazuh FIM reaches the configured monitored-file limit, leaving uncertainty about whether critical paths still have complete coverage.

Why it happens

The agent may monitor too many noisy paths such as cache directories, temporary files, build folders, package directories, or container overlay filesystems. Those paths consume the watch budget before the important directories are covered well.

Recommended approach

Classify monitored paths by security value, change rate, and operational cost. Exclude low-value churn first, confirm critical coverage, and increase file_limit only when the remaining scope is justified and host capacity has been measured.

Paths to review

Example noisy paths to review:

<ignore>/var/lib/docker/overlay2</ignore>
<ignore>/tmp</ignore>
<ignore>/var/cache</ignore>
<ignore>/var/lib/containerd</ignore>

Use this when

• Busy Linux servers
• Container hosts
• Lab environments
• Workloads with many temporary files

Avoid this when

• Critical compliance paths that must be monitored
• Systems where the correct fix is a genuinely larger monitored file limit

Common mistakes

• Increasing file_limit before reviewing the monitored path scope
• Monitoring cache and overlay paths by default
• Treating larger coverage as automatically better coverage

What happens when the limit is reached

Wazuh's file_limit controls how many entries FIM stores and monitors. Once the database reaches the configured limit, additional files are ignored. That means an apparently healthy agent can have incomplete coverage, so treat the alert as a monitoring gap rather than only a capacity warning.

Check the agent logs and current configuration:

sudo grep -iE 'file.limit|syscheck|fim' /var/ossec/logs/ossec.log | tail -100
sudo /var/ossec/bin/agent_control -i <agent-id>

On the endpoint, estimate which configured trees contribute the most files:

sudo find /etc /usr/bin /usr/sbin -xdev -type f | wc -l
sudo du --inodes -x -d 2 /var | sort -n | tail

Run broad find commands carefully on busy hosts; scope them to configured directories and avoid crossing network filesystems.

Configure the file limit explicitly

<syscheck>
  <file_limit>
    <enabled>yes</enabled>
    <entries>200000</entries>
  </file_limit>
</syscheck>

The supported upper bound is large, but that is not a recommendation to use it. A higher value increases agent database size, initialization work, scan time, and resource consumption.

Reduce low-value scope first

Good exclusions are workload-specific. Typical candidates include package caches, build output, ephemeral container layers, and temporary directories. Do not copy exclusions blindly: /tmp or container storage can be security-relevant in some threat models.

Prefer narrow rules:

<ignore>/var/cache/apt/archives</ignore>
<ignore>/var/lib/docker/overlay2</ignore>
<ignore type="sregex">.log$|.swp$</ignore>

Keep high-value paths such as authentication configuration, privileged binaries, service units, audit configuration, and application deployment manifests unless the control owner approves an alternative.

Verify after tuning

• Restart the agent during an approved window
• Confirm the limit warning stops
• Create a harmless test file inside a critical monitored directory
• Verify the FIM event reaches the manager
• Compare agent CPU, memory, database size, and scan duration before and after
• Record exclusions and their security rationale for future reviews

References

• Wazuh syscheck and file_limit reference
• Wazuh FIM configuration