Re: [ossec-list] Re: ossec-remoted high CPU
Shared configs cannot control the windows eventchannel from what I last knew. So I would check them and you will likely see nothing changed. If you turn on logall again you should see the specific event IDs disappear if not then you know it didn't take effect. As for 2.9.0 not sure as I really don't relverage shared configs. On Wed, Dec 20, 2017 at 4:48 AM, Sylvain Crouet <scro...@neocasesoftware.com > wrote: > Hello, > > > > I updated the shared agent.conf file to discard some Windows events. But I > notice that Windows 2.9.0 agents do not receive this shared configuration > file, while 2.8.3 and 2.9.2 do. Below is the ouput of deployment checking > script: > > Current version: c0db7baf32df4a94479756bd6a8c2e63 > > 001 v2.8.3/c0db7baf32df4a94479756bd6a8c2e63 OK > > 002 v2.8.3/c0db7baf32df4a94479756bd6a8c2e63 OK > > 003 v2.8.3/c0db7baf32df4a94479756bd6a8c2e63 OK > > 004 v2.8.3/c0db7baf32df4a94479756bd6a8c2e63 OK > > 005 v2.8.3/c0db7baf32df4a94479756bd6a8c2e63 OK > > 007 v2.8.3/c0db7baf32df4a94479756bd6a8c2e63 OK > > 008 v2.8.3/c0db7baf32df4a94479756bd6a8c2e63 OK > > 009 v2.8.3/c0db7baf32df4a94479756bd6a8c2e63 OK > > 010 v2.8.3/c0db7baf32df4a94479756bd6a8c2e63 OK > > 011 v2.8.3/c0db7baf32df4a94479756bd6a8c2e63 OK > > 012 v2.8.3/c0db7baf32df4a94479756bd6a8c2e63 OK > > 013 v2.8.3/c0db7baf32df4a94479756bd6a8c2e63 OK > > 014 v2.8.3/c0db7baf32df4a94479756bd6a8c2e63 OK > > 015 v2.8.3/c0db7baf32df4a94479756bd6a8c2e63 OK > > 016 v2.8.3/c0db7baf32df4a94479756bd6a8c2e63 OK > > 017 v2.8.3/c0db7baf32df4a94479756bd6a8c2e63 OK > > 018 v2.9.0/3757083ea8656e6141cafb893b55488b NOK > > 019 v2.9.0/3757083ea8656e6141cafb893b55488b NOK > > 022 v2.8.3/c0db7baf32df4a94479756bd6a8c2e63 OK > > 023 v2.8.3/c0db7baf32df4a94479756bd6a8c2e63 OK > > 024 v2.9.0 NOK > > 025 v2.9.0 NOK > > > > The OSSEC server version is 2.9.2. > > Any idea? > > > > Cordialement / Regards > > > > *Sylvain Crouet* > > Security Officer - *Security is everybody’s responsibility* > > Mobile +33 (0) 7 75 24 10 28 > > > > *From:* ossec-list@googlegroups.com [mailto:ossec-list@googlegroups.com] *On > Behalf Of *Sylvain Crouet > *Sent:* mardi 19 décembre 2017 17:24 > *To:* ossec-list@googlegroups.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 (0) 7 75 24 10 28 > > > > *From:* ossec-list@googlegroups.com [mailto:ossec-list@googlegroups.com > <ossec-list@googlegroups.com>] *On Behalf Of *Brett Simpson > *Sent:* mardi 19 décembre 2017 14:42 > *To:* ossec-list@googlegroups.com > *Subject:* Re: [ossec-list] Re: ossec-remoted high CPU > > > > Do true inside your global ossec.conf directive on the > ossec server. This will log everything to > /var/ossec/logs/archives/archives.log. > I would do that for 5 minutes then disable it and look though that archive > to see what is showing up. > > > > On Tue, Dec 19, 2017 at 8:35 AM, Sylvain Crouet < > scro...@neocasesoftware.com> wrote: > > Hello, > > > > How can I identify the agent on which I should do that? I already stopped > the most verbose agents, and there is no change on CPU. > > > > Cordialement / Regards > > > > *Sylvain Crouet* > > Security Officer - *Security is everybody’s 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 <ossec-list@googlegroups.com> > *Subject:* [ossec-list] Re: ossec-remoted high CPU > > > > 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 > drop them without sending. > > > > > > Application > > eventchannel > > Event/System[EventID != 256] and Event/System[EventID != > 258] > > > > > > > > Security > > eventchannel > > Event/System[EventID != 4656] and Event/System[EventID != 4658] > and Event/System[EventID != 4670] and Event/System[EventID != 4672] and > Event/System[EventID != 4688] and Event/System[EventID != 4689] and > Event/System[EventID != 4690] and Event/System[EventID != 5152] and &g
Re: [ossec-list] Re: ossec-remoted high CPU
Do true inside your global ossec.conf directive on the ossec server. This will log everything to /var/ossec/logs/archives/archives.log. I would do that for 5 minutes then disable it and look though that archive to see what is showing up. On Tue, Dec 19, 2017 at 8:35 AM, Sylvain Crouet <scro...@neocasesoftware.com > wrote: > Hello, > > > > How can I identify the agent on which I should do that? I already stopped > the most verbose agents, and there is no change on CPU. > > > > Cordialement / Regards > > > > *Sylvain Crouet* > > Security Officer - *Security is everybody’s 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 <ossec-list@googlegroups.com> > *Subject:* [ossec-list] Re: ossec-remoted high CPU > > > > 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 > drop them without sending. > > > > > > Application > > eventchannel > > Event/System[EventID != 256] and Event/System[EventID != > 258] > > > > > > > > Security > > eventchannel > > Event/System[EventID != 4656] and Event/System[EventID != 4658] > and Event/System[EventID != 4670] and Event/System[EventID != 4672] and > Event/System[EventID != 4688] and Event/System[EventID != 4689] and > Event/System[EventID != 4690] and Event/System[EventID != 5152] and > Event/System[EventID != 5156] and Event/System[EventID != 5158] and > Event/System[EventID != 5447] > > > > > > > > System > > eventchannel > > Event/System[EventID!=7000] > > > > > > > On Tuesday, December 12, 2017 at 10:04:55 AM UTC-5, Sylvain Crouet wrote: > > Hello, > > > > One of my OSSEC server is always busy (100% CPU) for some days, with > ossec-remoted between 90% and 100% CPU. This server manages about 65 agents > only. What can explain this high CPU utilization and how can I solve it? I > already restarted OSSEC services and the whole server. > > > > Cordialement / Kind regards > > > > *Sylvain Crouet* > > Security Officer - *Security is everybody’s responsibility* > > Mobile +33 (0) 7 75 24 10 28 > > > > [image: Image removed by sender. > Logo-Neocase-RGB-TM-TAGLINE-mail-signature] > > > > *Neocase™ Software is a leading provider of integrated HR and Finance > service delivery solutions.* > > www.neocasesoftware.com > > > > [image: Image removed by sender. workday_azure_partners_300dpi_1cm5] > > > > -- > > --- > You received this message because you are subscribed to the Google Groups > "ossec-list" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to ossec-list+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > > -- > > --- > You received this message because you are subscribed to a topic in the > Google Groups "ossec-list" group. > To unsubscribe from this topic, visit https://groups.google.com/d/ > topic/ossec-list/ZzcTfmQTaXE/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > ossec-list+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- --- You received this message because you are subscribed to the Google Groups "ossec-list" group. To unsubscribe from this group and stop receiving emails from it, send an email to ossec-list+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[ossec-list] Re: ossec-remoted high CPU
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 drop them without sending. Application eventchannel Event/System[EventID != 256] and Event/System[EventID != 258] Security eventchannel Event/System[EventID != 4656] and Event/System[EventID != 4658] and Event/System[EventID != 4670] and Event/System[EventID != 4672] and Event/System[EventID != 4688] and Event/System[EventID != 4689] and Event/System[EventID != 4690] and Event/System[EventID != 5152] and Event/System[EventID != 5156] and Event/System[EventID != 5158] and Event/System[EventID != 5447] System eventchannel Event/System[EventID!=7000] On Tuesday, December 12, 2017 at 10:04:55 AM UTC-5, Sylvain Crouet wrote: > > Hello, > > > > One of my OSSEC server is always busy (100% CPU) for some days, with > ossec-remoted between 90% and 100% CPU. This server manages about 65 agents > only. What can explain this high CPU utilization and how can I solve it? I > already restarted OSSEC services and the whole server. > > > > Cordialement / Kind regards > > > > *Sylvain Crouet* > > Security Officer - *Security is everybody’s responsibility* > > Mobile +33 (0) 7 75 24 10 28 > > > > [image: Logo-Neocase-RGB-TM-TAGLINE-mail-signature] > > > > *Neocase™ Software is a leading provider of integrated HR and Finance > service delivery solutions.* > > www.neocasesoftware.com > > > > [image: workday_azure_partners_300dpi_1cm5] > > > -- --- You received this message because you are subscribed to the Google Groups "ossec-list" group. To unsubscribe from this group and stop receiving emails from it, send an email to ossec-list+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[ossec-list] Override eventlog with eventchannel via Centralized agent config
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 it to eventlog and alter the centralized agent config to include that for Windows OS it doesn't work. I do see it get replicated to the agent under the shared folder but it looks like eventlog is taking priority. Touching each agent is not feasible as I just don't have that kind of control, at least I would have to somehow repackage an ossec install and wrap a new config into it, then have my IT people reinstall it on hundreds of Windows systems. Although I'm testing filtering event ID 7000 on a workstation I have many Windows servers with the windows packet filtering bombarding the event logs. This ends up saturating my network links from the agent to the manager which I want to eliminate. In ossec.conf System eventlog In Shared folder as agent.conf System eventchannel Event/System[EventID!=7000] -- --- You received this message because you are subscribed to the Google Groups "ossec-list" group. To unsubscribe from this group and stop receiving emails from it, send an email to ossec-list+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
