Open jjrbg opened 8 years ago
That could be a bug. Haven't had time to test it, but this seems to be the code that applies the regex: https://github.com/ossec/ossec-hids/blob/master/src/syscheckd/win-registry.c#L336
I am not particularly strong with debugging C, I don't stand much chance in finding if there's a bug in the source code.
How best can I test this? I have put both the server and a Windows agent in debug mode, I can see agent sends checksum of an "Enum" registry key to the server, so I assume the regex check is done server-side, not client-side...
2016/06/01 10:54:10 ossec-agent: DEBUG: Sending message to server: '0:0:0:0:ee0d74ca83a287578975633ac3e9391d:dae95bde1acd0d77d4f9d549f6f47f9eb4505a12 HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\WUDFRd\Enum'
But, ossec.log on the server doesn't give me much (any) debug info about what syscheckd deamon is doing.
Also, forcing a syscheck on an agent seems not always to work... even after restarting server and agent and running "agent_control -r -u 001", I can't seem to see from the log it crawling through all the registry key... do I just need to be patient?
Hi, We have a number of v2.8.3 Windows agents with centralised shared agent.conf, out-of-the-box configuration monitoring Windows files, folders, and registry locations. Included in this, is the ignore rule:
<registry_ignore type="sregex">\Enum$</registry_ignore>
Yet, we still receive alerts matching rule 594...
Could this be a bug?
We overwrite default rule 594 from ossec_rules.xml (level 5) in local_rules.xml to elevate to level 11. I'm not sure if this overwrite could be contributing to the issue?
Server is also running v2.8.3 on CentOS.
Any help gratefully received!
James