Hello Jesus,
Following is the design recipe for an /advanced/ OSSEC correlation engine.
The engine is to have the following capabilities:
i) Look forward and look back: Wait a certain time for next events,
-or- look back a certain time for previous events.
ii) Conditions based on the content
To gain visibility into what is going on at the agent side, turn on debug
mode on the agent.
In C:\Program Files (x86)\ossec-agent\internal_options.conf change:
# Windows debug (used by the windows agent)
windows.debug=0
to
# Windows debug (used by the windows agent)
windows.debug=2
and restart
to follow up to my own post-- First, the problem was indeed happening
during ossec-rootcheck, but I was unable to determine what was failing.
Secondly, the affected servers all were at one time or another, exporting a
CIFS or NFS share. Disabling the share didn't prevent ossec-rootcheck from
Hi Ed,
A couple things that might help here. When you enable logall, you’ll want to
look inside archives.log, not alerts.log. Assuming this wasn’t a typo, here’s a
few things that might help with your problem:
If you go look at your msauth_rules.xml file, you’ll note that OSSEC receives
Thanks; I will look into that and see what the logs show.
On Tuesday, March 7, 2017 at 4:30:09 AM UTC-6, InfoSec wrote:
>
> To gain visibility into what is going on at the agent side, turn on debug
> mode on the agent.
>
> In C:\Program Files (x86)\ossec-agent\internal_options.conf change:
>
> #
I have no issues with creating decoders and rules, been doing it for years.
But these do not make up for event information that the agent fails to
include in the event that it forwards to the OSSEC server. That is where
the problem lies -- agent-side /not/ server-side.
In the case of WMI, suffici
I've seen the possibility mentioned in this forum a couple of times
regarding adding the ability to check an MD5sum CDB list with rules. Right
now, I'm in a situation where I could use that ability. However, I can't
see anywhere that describes how to use it. Was that ever implemented?
Frankly,
I just lost our instance the runs ossec. I tried to reconfigure using
persistent disk, but ran into all kinds of queue problems. So I create a
fresh install and am getting this error
2017/03/08 07:56:08 ossec-syscheckd(1210): ERROR: Queue
'/data/ossec/queue/ossec/queue' not accessible: 'Queue n
