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 ossec-list+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to