I think I read somewhere that a <srcip>192.168.1.0/24</srcip> should work, but I haven't tested it. You could definitely do a cdb rule though. http://www.ossec.net/doc/manual/rules-decoders/rule-lists.html
<rule id="blah" level="0"> <if_sid>blah2</if_sid> <list field="srcip" lookup="address_match_key">list/file</list> <description>Ignore these things.</description> </rule> On Thu, May 5, 2011 at 12:20 PM, jplee3 <[email protected]> wrote: > 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 :)
