WIP: Allow file change before syscheck raise an alert

[calve]

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:

• we must be able to tell OSSEC that a particular file could change
• we must be able to allow changes for specific agents
• we must be able to set an upper time-limit until the file is allowed to change
• if the file changes after the time limit, we must get an alert
• if the file changes twice during the time limit, we must get an alert ...
• ... unless it have been allowed to change a second time, in which case we don't want an alert
• the agent should be able to tell the monitor which files could change
• we must get an alert if a changement have not been allowed
• actually, we always want an alert whenever one file changes
• we want different alerts levels depending on whether it have been allowed or not

Based on these requierements, I extended syscheckd to accept a
-u <timestamp>. Called with this switch, syscheckd won't start
in 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), we
watch for those message and produce allowchanges token in an
agent-specific queue. This token contains

1. a flag to know whether the token is still valid
2. a timestamp until which it is not valid anymore
3. the filepath allowed to change.

Now everytime analysisd is about to
generated 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 access
could simply just turn it off.

What do you think about it ?

[ddpbsd]

Since this is an entirely new file, you should probably take ownership.

[calve]

Note; I don't expect this pull request to be merged as-is, I opened it for discussion.

[lostinthetubez]

Being able to account for file system changes caused by updates is something many system admins have asked about in the past. Would you mind sharing how you have been using this proposed feature? I'm not clear on how one would go about automating, say, an 'apt-get upgrade' or a 'yum update', but am very curious.

[calve]

Would you mind sharing how you have been using this proposed feature?

I have to say that I do not use the proposed patch in production, nor have I fully tested it (as in a multiple remote agents setup).

For apt, I expect to be able to get the list of file changes before running the upgrade with a mix of apt-file to get the list of files changes, then hook some glue before running the actual update.

Probably something like apt-file $(apt-get list-upgrades) | ossec-syscheckd -u $(date +5min) && apt-get upgrade