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)" <[email protected]> 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 <[email protected]> wrote:
> > Yo, you are a pal :)
>
> > On Oct 1, 1:18 pm, "dan (ddp)" <[email protected]> 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 <[email protected]> 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/[email protected]/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 <[email protected]>
> >> > wrote:
> >> >> On Fri, 1 Oct 2010 07:36:55 -0700 (PDT), blacklight <[email protected]>
> >> >> 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
