Unclear on rulecat enable/disable order.

[banjoey]

I have the following in my disable.conf file:

re:.*
re:^#.*
re:ET.* TOR
re:ET.* SCADA
re:ET.* SCADA_SPECIAL
re:ET.* DELETED
re:ET.* SURICATA STREAM

and some individual rule IDs. Then, in my enable.conf file I have a few entries like this:

re:^[^#].* EXPLOIT .*
re:^[^#].* CINS .*
re:^[^#].* CURRENT_EVENTS .*
and some other individual rule IDs.

I am still getting tons of other rules enabled, such as many of the ET DELETED rules, etc. Can you please explain the order of precedence, etc.? Does disable override enable, modify, etc.? Is there a way for me to tell rulecat to favor disable over enable?

[jasonish]

So it is different than other tools.. Better? Worse? I'm not sure yet. The order is disable, then enable on a per rule basis.

foreach rule:
    if rule matches a disable filter then disable

    if rule matches enable filter then enable

Using your files above, I see some deleted rules being enabled as well. The regular expressions are cases insensitive - perhaps that is wrong.. So "re:^[^#].* EXPLOIT .*" is matching some. Is it reasonable to tighten up the regular expressions a little? For instance, to enable to EXPLOIT rules:

re:msg:"(\w)+ EXPLOIT

to enable all ET, ETPRO and GPL exploit rules?

I'm curious to hear your thoughts on what could make this better.

[banjoey]

You're right. I cleaned up my regex and they are much better.

Previously I was using scirius and I prefer rulecat. It isn't bad behavior, I just didn't know where the problem was because I didn't know what order the files were evaluated. Once upon a time I was a developer but I'm so far removed I forget I can look at the source myself... ID10T error.

Thank You,

Joseph Barkley

On Mar 10, 2016, at 4:32 PM, Jason Ish notifications@github.com wrote:

So it is different than other tools.. Better? Worse? I'm not sure yet. The order is disable, then enable on a per rule basis.

foreach rule:
if rule matches a disable filter then disable

if rule matches enable filter then enable

Using your files above, I see some deleted rules being enabled as well. The regular expressions are cases insensitive - perhaps that is wrong.. So "re:^[^#].* EXPLOIT .*" is matching some. Is it reasonable to tighten up the regular expressions a little? For instance, to enable to EXPLOIT rules:

re:msg:"(\w)+ EXPLOIT
to enable all ET, ETPRO and GPL exploit rules?

I'm curious to hear your thoughts on what could make this better.

—
Reply to this email directly or view it on GitHub.

[jasonish]

No worries. To be fair, its a little different than the other tools and its not documented as so. I'm not sure, but I think I prefer it.. Time will tell, and user comments.

Closing for now. Thanks.

[banjoey]

Hey. Just wanted to run something else by you on this topic. I disable everything and then re-enable based on category. Not sure if there's a better way of doing this or not, but...

If I do a count of rules that have "DELETED" in them (which is basically one determining factor of rule that I never want enabled) I have 58. Now, I'm admittedly not an expert on this particular subject, so maybe you can convince me otherwise, but I'd also say that if a rule has a flowbit dependency on a DELETED rule it is likely to cause false positives and should also be disabled.

I'm not sure how this would be handled from a logic standpoint. Special syntax for an "Always disable no matter what" rule in the disable file, which could then be trumped by a similar "always enable no matter what" syntax in the enable file? I don't really like that idea but am coming up short on an alternative.

I can always go in and find the deleted rules and threshold them, but that would require some regular intervention and I'd like to not have those rules even being processed. If you think the above approach is the way to go let me know. I'll try to find some time to work on it and do a pull request. If you have a different idea I'm also interested. I think my idea will get ugly. really. fast.

[jasonish]

Both of these have come up in discussions with other people, so its about time I address them.

As for deleted.rules, I think a list of files to completely ignore is in order, with a default set to "deleted.rules". This would make it impossible for these rules to be enabled. This is more of a something I haven't yet done yet.

The more interesting problem is forcing something always off or always on despite what other patterns or flowbit resolution would do. I was thinking of something like "1:2019401!" where the exclamation mark means leave this rule enabled/disabled no matter what!

Comments welcome.

[banjoey]

I like the ! Idea. I'd say that if you have a rule or expression with that, the flowbit behavior is to disable any dependent rules. You may have meant that already but just figured I'd throw that in there.

Thanks,
jb

On Apr 1, 2016, at 6:02 PM, Jason Ish notifications@github.com wrote:

Both of these have come up in discussions with other people, so its about time I address them.

As for deleted.rules, I think a list of files to completely ignore is in order, with a default set to "deleted.rules". This would make it impossible for these rules to be enabled. This is more of a something I haven't yet done yet.

The more interesting problem is forcing something always off or always on despite what other patterns or flowbit resolution would do. I was thinking of something like "1:2019401!" where the exclamation mark means leave this rule enabled/disabled no matter what!

Comments welcome.

—
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub