Okay, I think I found an answer to my question: http://groups.google.com/group/ossec-list/browse_thread/thread/d52d47cd43cbc1a3
http://www.ossec.net/wiki/Know_How:Ignore_Rules#Ignoring_a_specific_IP Is there a way to ignore an IP range in addition to specific IPs though? For example, an entry from my whitelist could be: <white_list>192.168.1.0/24</white_list> If I created a new rule and wanted to white list this range, could I do this: <srcip>192.168.1.0/24</srcip> Or will that syntax not be recognized? On May 3, 11:01 am, Jeremy Lee <[email protected]> wrote: > :) > > There's just 3 rules. The problem is is say I've whitelisted 192.168.1.10 > from getting blocked by AR - if I fail my login 100 times from 192.168.1.10 > now then I'll still have tripped up a bunch of email alerts. This is more > likely to be a problem with a partner/client who just forgot a password. > They should be an exception to the case. But what it comes down to is this - > there are multiple people who receive these alerts. So if an IP was > whitelisted and they still receive an alert, it's just unnecessary noise. We > want the alerts to come through, just not for IPs that were whitelisted. > Sure they could just ignore the whitelisted IPs, but they aren't going to > remember all the IPs that were whitelisted either. > > I'm just trying to figure out an easier way to email out ONLY when an active > response was triggered. The big challenge is how to handle this when the AR > is accomplished on a set of agents (i.e. using defined-agent for the same > alerts across multiple agents). > > > > > > > > On Tue, May 3, 2011 at 10:51 AM, dan (ddp) <[email protected]> wrote: > > I'm still sipping on coffee, so it is entirely possible I've missed > > something important. :) > > > Are there a lot of rules that fire from these white listed systems on > > a regular basis? You could always create ignore rules to keep them > > from firing. I'm not sure if an <if_sid>501|502|503</if_sid> (sids > > chosen at random for demonstration purposes only!) will work, but you > > could try it. > > For the srcip check, you can use the cdb feature to make it easier to > > maintain. > > > On Tue, May 3, 2011 at 11:43 AM, jplee3 <[email protected]> wrote: > > > Hey all, > > > > Certain aspects of this question may have been touched upon previously > > > but I don't think I've come across a specific answer. > > > > First, I'll explain my scenario: > > > > - I'm currently using location "defined-agent" and agent_id to trigger > > > the same active response on a set of machines in my environment. > > > - I've whitelisted several IPs so that they don't get blocked by the > > > AR if they happen to trigger the rules that set AR off. > > > - I am currently using the classic OSSEC email alerts to give me a > > > heads-up when AR was triggered. > > > > Now, the main issue with this approach is if I've whitelisted an IP, > > > the OSSEC email alert will still go out if that IP triggered the > > > relevant rule (i.e. multiple failed logons). > > > > To resolve this, I *could* (and actually have been testing this a bit) > > > modify the AR script to send the email out. My main issue with this is > > > consistency - to be consistent, I would want to setup the AR script to > > > include emailing out on every machine where I have AR setup to > > > trigger. This would produce lots of duplicate emails. > > > > I could always just modify the AR script on a single server and rely > > > on that, but if that were the case I'd rather have the email come from > > > the OSSEC master server rather than the local agent running the > > > script. > > > > Ugh, that may have been too convoluted. But if anyone gets what I'm > > > trying to do, please let me know if you have any ideas on Active > > > Response alerting. This would be a cool feature to include in a future > > > release of OSSEC btw :)
