Hi Michael,
I will reply you inline ..
On 1/8/07, Michael Starks <[EMAIL PROTECTED]> wrote:
Just to put a slightly finer point on this, here's an example:
I created a rule in local_rules.xml to ignore some crud. It looks
something like this:
<rule id="100004" level="0">
<if_sid>20100</if_sid>
<srcip>218.26.191.171</srcip>
<srcip>219.140.175.157</srcip>
<srcip>12.166.243.30</srcip>
<srcip>202.228.204.116</srcip>
<description>Ignore SQL Slammer from APNIC address</description>
</rule>
Unfortunately your rule will not work on 0.9-3, since we only support one ip
address (or network) per rule on the srcip/dstip option. I fixed that
on v1 (beta
available) if you want to try.
I have multiple source IPs listed as separate tags, which is OK, but
when I tried something like <srcip>218.26.191.171,
219.140.175.157</srcip> it wasn't valid.
I also wonder what the operator logic is in the rule. The above rule
implies that the rule will match if the sid matches, and if any of the
source IPs match. But what if I wanted a rule to match only if ALL of
the IPs match?
For all the rule options, it is always OR within the same field, so the
srcip will match if ip1 OR ip2 OR ip3 OR.. is found. It doesn't make sense
to have an AND in there (I can't see how the srcip can match more than
one ip at a time)...
One more thought: Is the local_rules.xml read top to bottom, and if a
previous rule matches will further rules be ignored (like firewall logic)?
The rules are read from the highest level to the lowest level, following the
order in the file. If you have:
rule 1 - level 5
rule 2 - level 10
rule 3 - level 20
rule 4 - level 1
rule 5 - level 1,
rule 6 - level 0
The order that they will be evaluated will be (yes, we treat 0 as the
highest :)):
rule 6 - level 0
rule 3 - level 20
rule 2 - level 10
rule 1 - level 5
rule 4 - level 1
rule 5 - level 1
Whenever ossec matches a rule, it will check if it has any child
(if_sid or if_group) and
check them, but it will not look further on the other rules. For
example (if rule == if_sid):
rule 1 - level 5
rule 2 - level 10
rule 3 - level 20
rule 4 - level 10 (if rule 1)
rule 5 - level 0 (if rule 4)
rule 6 - level 2
Rule evaluation would be (for an event that would match on rule 1):
check rule 3 - level 20
check rule 2 - level 10
check rule 1 - level 5
- check rule 4 (if matches, then check rule 5) - stop here.
*Think on the rules as a tree.. For example, on the sshd rules, we
have one initial
signature that looks for "sshd" in the process name. If it doesn't
match, all the other sshd rules are not even evaluated (we do the same
for most of the other rules). It allows great
speed on our internal checkings...
Hope it helps clarify a bit.
--
Daniel B. Cid
dcid ( at ) ossec.net
