It was worth a shot. :) And <location> can also be used with the agent name, just not there. I was hoping that it could: http://www.ossec.net/doc/manual/output/granular-email-output.html
On Thu, Oct 7, 2010 at 5:52 PM, blacklight <vphu...@yahoo.com> wrote: > The <location> paramter is a flop: > > (1) I tried the following: > > Existing rule 6203 (in asterisk_rules.xml): > > <rule id="6203" level="7"> > <if_sid>6200</if_sid> > <match>^ERROR</match> > <description>Asterisk error message.</description> > </rule> > > Attempt to make sure rule 6203 doesn't fire by inserting rule 206203 > in asterisk_rules.xml > > <rule id="206203" level="0"> > <if_sid>6203</if_sid> > <location>acd01.cricketdebt.com</location> > </rule> > > Error message is self-explanatory: > > [r...@wiggum rules]# ossec-logtest -f -D /tmp/ossectest-121509/ -c / > tmp/ossectest-121509/etc/ossec.conf > > 2010/10/07 17:34:54 ossec-analysisd: Invalid option 'location' for > rule '206203'. > 2010/10/07 17:34:54 ossec-testrule(1220): ERROR: Error loading the > rules: 'asterisk_rules.xml'. > > The ossec syntax doesn't like the <location> parameter > > Part of the reason is that the <location> parameter is given a > specific meaning i.e. the file system path of a log file that ossec is > reading.: > > http://www.ossec.net/main/manual/manual-log-analysis/ > > > I can see why you like the <location> parameter: > > 2010 Oct 06 21:21:49 Rule Id: 6203 level: 7 > Location: (acd01.xxxxxxx.com) 10.80.83.6->/var/log/messages > Asterisk error message. > Oct 6 18:21:48 acd01 asterisk[14796]: ERROR[14799]: devicestate.c:730 > in devstate_change_collector_cb: Invalid device state change event > received > > The agent name is most probably referred to in the OSEC source code by > some other parameter name than "location" > > > On Oct 1, 1:46 pm, "dan (ddp)" <ddp...@gmail.com> wrote: >> If you try the location method before I get a chance, let us know if >> it works or not. >> >> On Fri, Oct 1, 2010 at 1:26 PM, blacklight <vphu...@yahoo.com> wrote: >> > Yo, you are a pal :) >> >> > On Oct 1, 1:18 pm, "dan (ddp)" <ddp...@gmail.com> wrote: >> >> Thinking about it a bit more, I don't think it's a bad idea. Just not >> >> sure how it would be implimented. >> >> >> I have one idea on how to do it with currently available source, but >> >> I'm not sure it's possible. I've asked though, so hopefully I'll have >> >> an answer soon-ish. If it isn't possible to do it in the way I'm >> >> thinking, there may be a bribe of beer or something involved to make >> >> it possible. :P >> >> >> I'm also wondering (and not able to try it out at the moment) if the >> >> "location" option is available in rules. Usually location is the agent >> >> name or filename the alert came from. If that is indeed an available >> >> option it could help solve the problem of the multiple app01's. >> >> >> On Fri, Oct 1, 2010 at 12:40 PM, blacklight <vphu...@yahoo.com> wrote: >> >> > The scalability problem comes in two ways: >> >> >> > (1) While all our OSSEC agent hosts have unique FQDN's, the relative >> >> > host name i.e. the name that appears in the agent host syslog for >> >> > example, may not be unique. For example, app01.applesauce.com and >> >> > app01.bananapeel.com have the same relative host name in their >> >> > respective syslogs: app01 We might want app01.applesauce not to block >> >> > the source IP host but we might want app01.bananapeel to do just that. >> >> > So, if the correct syntax for <hostname> is <hostname>app01</ >> >> > hostname>, we would be in trouble. I am not sure that using an IP >> >> > address or an FQDN for <hostname> will work because I believe that the >> >> > OSSEC server reads off the <hostname> directly from the log entry. >> >> >> > (2) Let's say that on a customer subnet, we have five hosts that we >> >> > want to whitelist. We would have to derive a rule for each one of >> >> > them. Right now, we are managing 150+ hosts - I could end up writing >> >> > up quite a few rules :) >> >> >> > There are quite a few situations where we want whitelisting where the >> >> > source or attack IP is a host whose behavior creates log messages on >> >> > the target host that fall under a rule that triggers an active >> >> > response, but where we know the source or attack IP is harmless. We >> >> > definitely would want active response to be triggered to protect the >> >> > target host if the source or attack IP were any other host. >> >> >> > I have done some research in the meantime: >> >> > [ossec-list] Re: Can agents have their own white list which adds to >> >> > the server white list? >> >> >http://www.mail-archive.com/ossec-list@googlegroups.com/msg02761.html >> >> >> > The ossec-list discussion thread (year date 2007) just above seems to >> >> > indicate that the rule method is more fine grained than the outright >> >> > whitelist method, but Peter Abraham's objection to the rule method is >> >> > the same as mine: we are monitoring lots of agents and we could be >> >> > adding to the clutter with as many rules. >> >> >> > Again, if agents could be whitelisted at the agent rather than at the >> >> > server, the manual configuration work would be simpler. Is there a way >> >> > to whitelist at the agent level? If not, is there another option aside >> >> > from the rule method? The whitelist method at the server is too much >> >> > of a blunt instrument for us. >> >> >> > On Oct 1, 11:55 am, Michael Starks <ossec-l...@michaelstarks.com> >> >> > wrote: >> >> >> On Fri, 1 Oct 2010 07:36:55 -0700 (PDT), blacklight <vphu...@yahoo.com> >> >> >> wrote: >> >> >> >> > I just spoke with my boss - the method I ran by you is cumbersome and >> >> >> > lacks scalability. Is there a way to get whitelisting implemented at >> >> >> > the agent level? >> >> >> >> I'm a bit confused. The rule method is easy to implement on the manager >> >> >> and is effective against the one host, which I understand is your goal. >> >> >> Whitelisting the IP for all active responses is also easy to implement >> >> >> on >> >> >> the manager and easy to do. Where's the scalability problem? >> >> >> >> -- >> >> >> [I] Immutable Security >> >> >> Information Security, Privacy and Personal >> >> >> Libertyhttp://www.immutablesecurity.com
