WIP: Allow file change before syscheck raise an alert #790
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Hi,
When my hosts gets an upgrade, either distribution packages or
in-house applications, I get flooded with
Integrity file changed
alerts for files and software I upgraded.
Actually, I do not want those alerts, whose lower the signal/noise
ratio. Morever, I tend to just not read these kind of alerts since I
feel most of them are false-positive.
At the moment, OSSEC miss a feature to allow a file to change prior to
the actual update.
I thought of the following requierements:
Based on these requierements, I extended
syscheckd
to accept a-u <timestamp>
. Called with this switch,syscheckd
won't startin daemon, but will read paths from stdin. Those path will be sent to
the monitor, together with the timestamp.
On the monitor (whatever host is running
analysisd
actually), wewatch for those message and produce
allowchanges
token in anagent-specific queue. This token contains
Now everytime
analysisd
is about togenerated an alert for an integrity change, it try to consume one
token for the file. If a token have been found, we set the decoder to
syscheck-allowchange
, and users can write their rules according to their needs.Otherwise, the old behaviour still apply.
As a security consideration, we could argue that this mechanism allow
an attacker to silentely changes binary on the agents if she allows
the changes before being evil. In fact, the monitor already trust
syscheckd
for the file integrity, so an attacker with root accesscould simply just turn it off.
What do you think about it ?