Request for Clarification on Frequent File Changes

[Chandra pal singh Chauhan]

Hello team,

I hope you are doing well.

Recently, I configured File Integrity Monitoring (FIM) on the /data directory in our Linux environment. Following this, I have observed that approximately 90% of the generated events are related to file additions, deletions, and modifications.

Upon closer inspection, these events appear to be associated with files having various extensions, and they seem to belong to Elasticsearch indices (possibly related to Wazuh operations). For your reference, I have attached screenshots along with the exact path where these events are being generated.

Path: /data/elasticsearch/indices

Could you please help clarify whether this behavior is expected due to Elasticsearch’s internal processes (such as index management, segment merging, etc.), or if this requires further investigation?

Additionally, I would appreciate your guidance on whether we should exclude this path from FIM monitoring to reduce noise, or if there are recommended best practices for handling such cases.

Looking forward to your insights.

Thanks and Regards,

Chandra

[Olamilekan Abdullateef Ajani]

Hello Chandra,

What you’re seeing is normal based on what you have configured.

That path (/data/elasticsearch/indices) is very busy by design, as it means Elasticsearch is constantly creating, deleting, and modifying files as it writes data, merges segments, and cleans up old ones. So FIM will naturally pick up a lot of changes there as it falls within its purview, that is why most of your alerts are coming from that location.

From a security point of view, monitoring that path usually doesn’t add much value, rather administrator overhead while performing analysis/correlation. It’s not like config files or binaries, where changes are meaningful. Here, changes are happening all the time as part of normal operations, so it just creates noise and makes more critical issues harder to spot.

That said, there are cases where you might still want to keep an eye on it:

if you suspect someone is tampering directly with stored data
or in very strict environments where everything needs to be tracked

But for day-to-day security monitoring, it is better to exclude it and focus FIM on more critical file paths like /etc, system binaries, or app configuration files.

So to wrap this up, what you’re seeing is expected, and yes, excluding that path is usually the right move unless you have a specific reason to monitor it.

Ref:
https://documentation.wazuh.com/current/user-manual/capabilities/file-integrity/how-it-works.html

[Chandra pal singh Chauhan]

Hello Olamilekan,

thank you for your clearance and suggestion.

Regards,

Chandra