Overriding securityonion_rules.xml

[grs...@dakelake.com]

Should it be possible to override/modify rules in securityonion_rules.xml by creating entries in local_rules.xml? If not, is it possible in some other way, and if so how?

For example: I would like to temporarily force rule 111112 to ignore eth1.
perhaps with something like the following. The syntax here may be wrong (or non-optimal), but I cannot test because OSSEC server restart first complains. ossec-analysisd: Overwrite rule '111112' not found.

<group name="local,syslog,">
<rule id="111112" level="7" overwrite="yes">
<if_sid>111111</if_sid>
<match>eth2: 0|eth3: 0|eth4: 0</match>
<description>Received 0 packets in designated time interval (defined in ossec.conf). Please check interface, cabling, and tap/span!</description>
</rule>
</group>

[Wes Lambert]

Have you tried something like this?

<rule id="100002" level="0">

    <if_sid>111112</if_sid>

    <match>eth1: 0</match>

    <description>Drop no packets received rule for eth1</description>

  </rule>

If rule 111112 triggers, then if it has triggered for eth1, it will will be ignored (level="0")

However, if you are not using eth1 at all, then maybe you should consider disabling the interface altogether:

https://github.com/Security-Onion-Solutions/security-onion/wiki/RemovingASensor#disable-sensor-interface

Thanks,

Wes

--
Follow Security Onion on Twitter!
https://twitter.com/securityonion
---
You received this message because you are subscribed to the Google Groups "security-onion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to security-onion+unsubscribe@googlegroups.com.
To post to this group, send email to security-onion@googlegroups.com.
Visit this group at https://groups.google.com/group/security-onion.
For more options, visit https://groups.google.com/d/optout.

[GRSmith]

Using that suggestion I now get…

rules_list: Signature ID '111112' not found. Invalid 'if_sid'

 

Notice the similarity here to my original question regarding why I would see this:

ossec-analysisd: Overwrite rule '111112' not found

…when attempting to use my own example rule.

 

As a possible explanation… I was wondering… could it be the order in which rule files get read during ossec startup?  The last two files being read are these.

2017/08/13 18:40:52 ossec-analysisd: INFO: Reading rules file: 'local_rules.xml'

2017/08/13 18:40:52 ossec-analysisd: INFO: Reading rules file: 'securityonion_rules.xml'

If “reading rules file” implies verifying each rule in the file, then I can understand why a 111112 rule in local_rules.xml would not be able to find rule 111112… because it has not yet been loaded.

 

Assuming there is any merit to this theory… how could I work around the issue?  I don’t want to modify securityonion_rules.xml directly, because I assume it could be overwritten by any future SO updates.

To unsubscribe from this group and stop receiving emails from it, send an email to security-onio...@googlegroups.com.
To post to this group, send email to securit...@googlegroups.com.

Visit this group at https://groups.google.com/group/security-onion.
For more options, visit https://groups.google.com/d/optout.

 

--

Follow Security Onion on Twitter!
https://twitter.com/securityonion
---
You received this message because you are subscribed to the Google Groups "security-onion" group.

To unsubscribe from this group and stop receiving emails from it, send an email to security-onio...@googlegroups.com.
To post to this group, send email to securit...@googlegroups.com.

[Wes]

You may want to swap the order of securityonion_rules.xml and local.rules in /var/ossec/etc/ossec.conf and see if that helps.

Thanks,
Wes

[GRSmith]

I guess my theory holds because your suggestion did the trick! Rules referencing 111112 are now accepted without the previous complaints during server restart. I hesitated changing ossec.conf wondering if that too would be overwritten by future updates. Could you offer insight on that?

One lingering question would then be, are we missing some good reason why securityonion_rules.xml was placed after local_rules.xml in ossec.conf? I'm a little uncomfortable undoing something which appears intentional.

[Doug Burks]

Hi GRSmith,

ossec.conf will be overwritten when the next OSSEC package is
released. I've made a note for when we build the package to correct
the order of those items and ensure that local_rules.xml is included
after securityonion_rules.xml:
https://github.com/Security-Onion-Solutions/security-onion/issues/708

Doug Burks