A more specific match?
murf
being used to probe the
sshd server. That generates, every 5 minutes, a message in /var/log/
secure:
Jan 6 21:20:01 sysname sshd[3567]: Bad protocol version
identification 'quit' from UNKNOWN
Which triggers the 5701 rule in the rules.
5701's match is: "Bad Protocol version idendification"
and it retaliates by trying to block the "UNKNOWN" ip in iptables....
not cool.
What I'd like to do is intro a new rule that is more specific to this
situation,
<match>Bad protocol version identification 'quit' from UNKNOWN</match>
and only alarm if it's more frequent than 1 in 5 minutes.
The existing 5701 should then kick in if there was no more specific
match.
How exactly (or even roughly) would this sort of thing be achieved?
murf
dan (ddp)
> Here I am again. I have a machine where the "big brother" stuff is
People still use big brother?
What do you have so far?
Untested:
<rule id="STUFF" level="0">
<if_sid>5701</if_sid>
<match>Bad protocol version identification 'quit' from UNKNOWN$</match>
<description>Ignore from bb</description>
</rule>
<rule id="STUFF1" level="7" frequency="0" timeframe="300">
<if_sid>STUFF</if_sid>
<description>More than 1 STUFF in 5 minutes</description>
</rule>
Decker Christopher
murf
On Jan 7, 8:42 am, "dan (ddp)" <ddp...@gmail.com> wrote:
> > Here I am again. I have a machine where the "big brother" stuff is
>
> People still use big brother?
>
Don't look at me-- I just secure the stuff!
>
> > How exactly (or even roughly) would this sort of thing be achieved?
>
> > murf
>
> What do you have so far?
>
> Untested:
> <rule id="STUFF" level="0">
> <if_sid>5701</if_sid>
> <match>Bad protocol version identification 'quit' from UNKNOWN$</match>
> <description>Ignore from bb</description>
> </rule>
>
> <rule id="STUFF1" level="7" frequency="0" timeframe="300">
> <if_sid>STUFF</if_sid>
> <description>More than 1 STUFF in 5 minutes</description>
> </rule>
very helpful
in this regard.
I see that if_sid, if_group, if_level, if_matched_sid gives me some
"conditionals"
on the activation of a rule, and that these can form a hierarchy.
Do the rules ALL get tested and matched? Rule evaluation does not stop
with the
first match?
The "if_xxxx"'s are the only way to stop conditionally stop a rule
evaluation?
If the above is true, then maybe, just maybe, I could put something
together that
might work, but it would be nice if the above list (if_sid, etc) had
inverses, like
if_not_sid, if_not_group, etc.
Can a rule belong to more than one group? Can I define a group in a
group? There's
no syntax definition for group in the www.ossec.net/doc/syntax stuff
on the ossec site.
I see that a group option exists under <rule>. But beyond "Add
additional groupings to the alert",
there is nothing more said about it.
As to your example, the docs do state that if you use level 0, then
the rule is tossed immediately,
and will not trigger a if_matched_sid, so, assuming the if_matched_sid
(as Chris noted), and
a level > 0, with perhaps an <options>no_log</options> added, then...
I'll form my best guess at an attack after some of the above questions
are answered....
murf
BP9906
(Untested)
<rule id="STUFF1" level="1">
<if_sid>5701</if_sid>
<hostname>servername</hostname>
match>
<options>no_log</options>
</rule>
<rule id="STUFF2" level="7" frequency="0" timeframe="300">
<if_matched_sid>STUFF1</if_matched_sid>
<hostname>servername</hostname>
match>
</rule>
**some notes here: A) frequency is 0, but ossec logic is that it
happened 2+frequency. B) Using level 0 fails on frequency alerts, so
using alert 1 + no_log option will generate the outcome you expect but
not log the first event.
dan (ddp)
Yes, kinda. If something matches, and there's no <if_sid> or anything
to check then it's done. If there is a possible <if_sid> that needs to
be checked, it will be checked.
> The "if_xxxx"'s are the only way to stop conditionally stop a rule
> evaluation?
>
> If the above is true, then maybe, just maybe, I could put something
> together that
> might work, but it would be nice if the above list (if_sid, etc) had
> inverses, like
> if_not_sid, if_not_group, etc.
>
We accept patches. ;)
> Can a rule belong to more than one group? Can I define a group in a
> group? There's
Yes, rules can belong to more than 1 group. <group>group1, group2</group>
I don't know what you mean by "define a group in a group."
> no syntax definition for group in the www.ossec.net/doc/syntax stuff
> on the ossec site.
>
Fixed in my repo. If the main site is still syncing it will probably
have the addition tomorrow.
Otherwise you can view it here:
http://devio.us/~ddp/ossec/docs/syntax/head_rules.html#element-group
(exciting!)
> I see that a group option exists under <rule>. But beyond "Add
> additional groupings to the alert",
> there is nothing more said about it.
>
It's really simple and there are a bunch of examples.
> As to your example, the docs do state that if you use level 0, then
> the rule is tossed immediately,
> and will not trigger a if_matched_sid, so, assuming the if_matched_sid
> (as Chris noted), and
> a level > 0, with perhaps an <options>no_log</options> added, then...
>
Then do that. I generally test the rules I write, and few of them are
perfect on the first go.
WARNING: You may have to think about your rules.
murf
I've been playing around with ossec-logtest, and think I have
discovered these facts:
1. If two (or more?) rules match the same log line
then the one with the lowest level wins. They
will not both be activated. The rule id doesn't matter.
1a. If the levels are the same, then the first rule occurring in
the file
wins.
2. If you'd like to give precedence to rule that should trigger a
response,
and it is competing with a rule that has a lower level, then set
the
level to match that of the competing rule. Move your rule above
(closer to the
beginning of the file) the competing rule. Add another rule with
<if_sid> pointing
to your rule. Set its level to the level you want. Include the
description. Drop the
pattern match.
Am I right? Is there more to this?
murf