Hi guys, I'm running into a weird issue using OSSEC.

Over the last week, we've been warding off quite a few DDOS attacks which 
are characterized by long periods of low traffic followed by several 
thousand unique IPs hitting a login page using several pre-recorded login 
attempts.  I've been using Varnish to tag the offending IPs and OSSEC to 
filter, log, and firewall them by having Varnish respond with an unused 
HTTP status code, then a custom rule in OSSEC to respond to the relevant 
log entries.

What I've found, interestingly, is that OSSEC tends to amplify the attack 
even when there are relatively few unique IPs (ie, several hundred) as it 
seems to open up as many extra firewall-drop processes as unique attacker 
IPs, all trying to obtain a lock - which doesn't seem necessary to me. 
 Sure enough, just commenting the lock; and unlock; dramatically improves 
performance, iptables adds the rules, and the correct results are visible 
in the active response log.

So...  Several questions:
1 - Is the locking behavior necessary for any reason?  It is only required 
on Linux, which suggests it could be a weird iptables thing - but this 
would be taken care of by the while loops surrounding the iptables 
execution attempts.
2 - If the locking behavior is needed, why not use flock when it's 
available?  The overhead of 10k processes playing king of the hill is 
causing much more overhead than anything else happening, and the kernel is 
much better at these kinds of things.
2 - Is throttling these kinds of processes implemented anywhere in the 
OSSEC core?  Am I simply running into a configuration issue?
3 - Does OSSEC have the capability of limiting the number of 
active-response scripts being executed simultaneously?

Thanks for your help and insight
Israel

-- 

--- 
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/groups/opt_out.

Reply via email to