After a "soup -y" to my SO14 deploy, my local.rules are appearing in downloaded.rules, but commented out

[gradius]

Hello SecurityOnion community,

Setup: SecurityOnion14, most recent update, using Suricata.

So recently I updated my SecurityOnion14 deploy to the newest software releases via a "soup -y" across the board including my Server and all of my sensors.

I was aware of the change where all rules are now included in downloaded.rules, which is why local.rules is getting automatically commented out in suricata.yaml.

After pushing out my update, I realized that a rule-update on my SO Server is adding my /etc/nsm/rules/local.rules to /etc/nsm/rules/downloaded.rules, but in a commented out state. I've checked my settings for disablesid.conf as well as changed the verbosity in pulledpork.pl to -vv, but I still cannot find out why my local.rules are being added in a commented out state.

Any help/tips/direction is appreciated. Please let me know if I can clarify anything.

[Doug Burks]

Hi gradius,

Are you able to provide an example?

Do you have any directives in disablesid.conf?

Are you able to provide the full -vv output of pulledpork?

> --
> 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.
> Visit this group at https://groups.google.com/group/security-onion.
> For more options, visit https://groups.google.com/d/optout.



--
Doug Burks

[gradius]

On Wednesday, January 25, 2017 at 3:10:26 AM UTC-8, Doug Burks wrote:
> Hi gradius,
>
> Are you able to provide an example?
>
> Do you have any directives in disablesid.conf?
>
> Are you able to provide the full -vv output of pulledpork?
>

> On Tue, Jan 24, 2017 at 8:45 PM, gradius wrote:
> > Hello SecurityOnion community,
> >
> > Setup: SecurityOnion14, most recent update, using Suricata.
> >
> > So recently I updated my SecurityOnion14 deploy to the newest software releases via a "soup -y" across the board including my Server and all of my sensors.
> >
> > I was aware of the change where all rules are now included in downloaded.rules, which is why local.rules is getting automatically commented out in suricata.yaml.
> >
> > After pushing out my update, I realized that a rule-update on my SO Server is adding my /etc/nsm/rules/local.rules to /etc/nsm/rules/downloaded.rules, but in a commented out state. I've checked my settings for disablesid.conf as well as changed the verbosity in pulledpork.pl to -vv, but I still cannot find out why my local.rules are being added in a commented out state.
> >
> > Any help/tips/direction is appreciated. Please let me know if I can clarify anything.
> >
> > --
> > 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.
> > Visit this group at https://groups.google.com/group/security-onion.
> > For more options, visit https://groups.google.com/d/optout.
>
>
>
> --
> Doug Burks

To provide some more details:

We have about 100 lines of rules in our local.rules file. In the past we've followed the instructions on the wiki to deploy custom rules with no issue. They live in /etc/nsm/rules/local.rules on the SO server.

We have a fairly small disablesid.conf, with mostly single sid entries, and the ones that correspond to sid ranges (eg: 1:2002027-1:2002028) are well documented and have been in production since we started using SO.

I've attached the verbose run of pulledpork.pl with sensitive data omitted.

Also when reviewing /var/log/nsm/sid_changes.log, all of our local.rules appear under the "Deleted" list. Our local.rules start at the SID (5000000)

[Doug Burks]

Hi gradius,

Looking at your rule-update-run.txt, I wonder if PulledPork is trying
to apply the ips_policy to your local.rules and thus disabling them
since they don't match. Could you try commenting out the ips_policy
line in /etc/nsm/pulledpork/pulledpork.conf and then running "sudo
rule-update" again to see if that makes any difference?

[gradius]

That worked! Our local rules are now being included in downloaded.rules when rule-update is ran.

Could you go into a bit more detail as to why this started happening only recently? Reading into README.RULESETS makes it appear that this has a pretty big impact on what rules are shipped with pulledpork.

Again, thank you for your time and for your quick analysis :)

[Doug Burks]

Previous versions of PulledPork did not include local.rules in
downloaded.rules and thus the ips_policy setting didn't apply to the
rules in local.rules at all. Since this new version of PulledPork
does process local.rules into downloaded.rules, it appears the
ips_policy setting does apply to the rules in local.rules and they are
disabled if they don't match. You might be able to add the ips_policy
setting to your rules in local.rules so that they match and you can
keep your ips_policy setting.

While you're thinking about rules, I'll also ask if there is any
particular reason that you're running Suricata with the Snort ruleset.
This is somewhat of an unusual combination as the Snort ruleset
contains some Shared Object rules which Suricata will not load. Most
folks who choose to run Suricata select the Emerging Threats ruleset.
Most folks who choose to use the Snort ruleset select the Snort
engine. If you decide to keep Suricata and change your ruleset to
Emerging Threats, then the ips_policy option in pulledpork.conf would
need to be disabled anyway and this local.rules issue should go away
altogether.

[gradius]

Thanks for the detailed information, this makes much more sense now :)

As for the ruleset choice, it's preference mostly, but I'll be sure to take this information about the ET ruleset back to my team for review.