com
> *Subject:* RE: [ossec-list] Re: ossec-remoted high CPU
>
>
>
> Done, very informative indeed. Thank you Brett.
>
>
>
> Cordialement / Regards
>
>
>
> *Sylvain Crouet*
>
> Security Officer - *Security is everybody’s responsibility*
>
> Mobile +33
responsibility*
>
> Mobile +33 (0) 7 75 24 10 28
>
>
>
> *From:* ossec-list@googlegroups.com [mailto:ossec-list@googlegroups.com] *On
> Behalf Of *Brett Simpson
> *Sent:* jeudi 14 décembre 2017 18:38
> *To:* ossec-list
> *Subject:* [ossec-list] Re: ossec-remoted high C
I would suggest you turn on debug on one of the agents and see what the
agent is trying to send versus what the server actually keeps. I had issues
with a few event IDs generating thousands of events per second that weren't
even used by the ossec server so I used a line like this on the agent to
We saw this as well. We had a group of domain controllers running OSSEC
2.8.0 start consuming all memory after a recent set of Window patches. We
ended up updating them to 2.9.0 and chalked it up as a bug that has been
fixed as 2.8.1 and above haven't shown the issue.
On Thursday, February 23,
I wasn't sure how to do this or if it's possible but I have a large number
of ossec agents where I want to filter out specific Windows Event ID agent
side. If I modify the ossec.conf on the agent and replace the log_format of
my System from eventlog to eventchannel it works however if I leave i