Yes. At last decided to discard Application and System logs and only collect Security logs.
I hope this can help in much better way On Thursday, 6 November 2014 17:35:07 UTC+5:30, [email protected] wrote: > > That is an interesting idea, however all the logs are processed server > side, not agent side, thus by the time you detect an uptick in events, you > have already sent the traffic. > > In theory you could create a custom rule for # of X event types over a > period of time, and if the rule fires, you have a custom script looking for > that alert which subsequently logs into the server in question and turns > off the agent. > > That all seems overkill, perhaps don't collect Application logs? That > alone will reduce your volume significantly > > On Wednesday, November 5, 2014 10:25:14 AM UTC-5, priyonko chakraborty > wrote: >> >> Hi, >> >> I know it is not problem of OSSEC. Point is we want to capture the >> windows event logs including system, security and application. As OSSEC >> agents collects all those logs, sometime due to configuration error or any >> application error, windows triggered lots of noise on event logs and OSSEC >> captured everything and trying to send it to server. >> >> So I wanted to know, is there any rule I can implement if the events will >> be high, it simply disconnect the agent with server. So there will be no >> impact on system performance as well network bandwidth. >> >> In short it's possible to put some bandwidth limitations, uniq events >> logging, etc??? >> >> Regards, >> Priyonko >> >> On Wednesday, 5 November 2014 20:40:25 UTC+5:30, Michael Starks wrote: >>> >>> On 2014-11-05 5:49, priyonko chakraborty wrote: >>> >>> > Can you suggest your views, if we can implement any rule to discard >>> > the connection from OSSEC agent to Servers if it crosses some >>> > threshold. Like if the we will get Event count after '20000': >>> > 13179011->8264848 (62%), there should be some rule which stops the >>> > connection between OSSEC agent with servers and help us to stop >>> > bandwidth killing. >>> >>> Identify the cause of the chatty logs and address that. You may have >>> object auditing enabled, which can generate a large number of events. >>> This is not really an OSSEC problem. OSSEC sends every log to the >>> manager for analysis just like any other log analysis tool and it needs >>> to do that in order to do its job. It even compresses the logs, so I >>> really think you need to examine the source of the problem and address >>> it there. >>> >> -- --- 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
