Hi Marty,
Ossec uses the "as soon as something matches, stop" approach. However, if the rule has any "child", it will attempt to match them too (tree-like structure where ossec will attempt all the rules until an end-node is found). Let's give an example of an sshd log: 1- ossec receives message. 2- sshd is decoded and ip/username is extracted (by decoder). 3- message goes to the rule tree. 3a - The root "nodes" of the tree are the high level rules at rules_config.xml. Since it is a syslog related message, it will go to the syslog leaf. 3.b - Once in the syslog leaf, it will search for the available rules. In this case, rule "5700" will match, since it was decoded as sshd. 3.c - It will then search for all the "child" nodes of the 5700, which are all the ones related to sshd. Hope this helps clarifies a bit. -- Daniel B. Cid dcid ( at ) ossec.net On 9/14/06, Marty E. Hillman <[EMAIL PROTECTED]> wrote:
I have been monitoring the discussion of rules processing somewhat and need a clarification on how the rules are processed. Am I understanding correctly that the rules are all processed and that it is just a matter of order as to how they are processed? Or are they processed much like filters for ipfw are processed where once a rule is true, processing stops? I can see benefits to both approaches, but am unclear on what the current situation is. Just brainstorming here, but would a hybrid approach be more beneficial: one where the administrator can choose whether to process multiple rules under some conditions or end rule checking if a particular result is true? Or am I missing the boat and something like that already exists in the rule processing? Or am I just not making sense anymore? :) This electronic mail (including any attachments) may contain information that is privileged, confidential, and/or otherwise protected from disclosure to anyone other than its intended recipient(s). Any dissemination or use of this electronic email or its contents (including any attachments) by persons other than the intended recipient(s) is strictly prohibited. If you have received this message in error, please notify us immediately by reply email so that we may correct our internal records. Please then delete the original message (including any attachments) in its entirety. Thank you.
