Project

General

Profile

Feature #3202

classtypes: validate classtypes in use

Added by Victor Julien over 1 year ago. Updated over 1 year ago.

Status:
Assigned
Priority:
Normal
Target version:
Effort:
Difficulty:
Label:

Description

If a ruleset has many rules that use undefined classtypes the test phase of Suricata will output and error for each of the rules.

I think Suricata-Update should validate that the classtype in the rule is defined in the classification.config.


Related issues

Blocked by Feature #3203: manage classification.configClosedShivani BhardwajActions
#1

Updated by Victor Julien over 1 year ago

  • Tracker changed from Support to Feature
#2

Updated by Victor Julien over 1 year ago

#3

Updated by Jason Ish over 1 year ago

What should happen if the validation does not pass? If this should abort, and restore the old ruleset, we get that with the pass of Suricata -T to validate the rule load.

#4

Updated by Victor Julien over 1 year ago

Validation to me means: it should check that classtypes are defined. Generate a single warning per undefined classtype. Disable rules that contain undefined classtypes. At the end log a count of how many are disabled for this reason.

#5

Updated by Victor Julien over 1 year ago

Although maybe this is too much of a 'silent failure'. Many rules will fail to load while SU only generates warnings. Guess erroring out may be better after all.

#6

Updated by Jason Ish over 1 year ago

So auto-disable rules that don't have a known classification?

So implementation wise:
- Read in system classification.config (/usr/share/suricata/classification.config or /etc/suricata/classification.config).
- Read in any classification.config from any downloaded rulesets.
- Merge...
- For any rule with unknown classification, log warning, disable rule.

#7

Updated by Jason Ish over 1 year ago

Victor Julien wrote:

Although maybe this is too much of a 'silent failure'. Many rules will fail to load while SU only generates warnings. Guess erroring out may be better after all.

Yes, I think I agree.

Suricata-Update does not know anything about classification.config in its current form, so its non-trivial to fix. Pure validation is done by Suricata during the test phase, so already get validation for free. If we want to do something about an invalid/unknown classification, then yes, Suricata-Update should do some pre-validation and fixup.

#8

Updated by Shivani Bhardwaj over 1 year ago

  • Status changed from New to Assigned
  • Priority changed from Normal to Urgent
  • Target version set to 1.1.0
#9

Updated by Shivani Bhardwaj over 1 year ago

How should we differentiate between the Snort's classification.config and the ruleset's in the merged classification.config (only for readability and clarity purposes)?

#10

Updated by Shivani Bhardwaj over 1 year ago

Also, just to be clear, are we looking at two levels of validation for classification.config? First in suricata-update then the usual in suricata?

#11

Updated by Jason Ish over 1 year ago

Shivani Bhardwaj wrote:

How should we differentiate between the Snort's classification.config and the ruleset's in the merged classification.config (only for readability and clarity purposes)?

I wouldn't worry about. One output file. I'd start with the engine included classification.config, then append new ones found while loading rules to the end of it. Would be nice to include a

# From ruleset ...

But we currently throw that information pretty early on, so it could really change the effort on this one.

#12

Updated by Jason Ish over 1 year ago

Shivani Bhardwaj wrote:

Also, just to be clear, are we looking at two levels of validation for classification.config? First in suricata-update then the usual in suricata?

I'm not too keen on validation in Suricata-Update? What do we do if its invalid?

Outputting an up to date classification.config gives everything a higher chance of being valid tho. So I'd be in favour of just having Suricata do the validation.

#13

Updated by Shivani Bhardwaj over 1 year ago

  • Priority changed from Urgent to Normal
  • Target version changed from 1.1.0 to Soon
#14

Updated by Jason Ish over 1 year ago

  • Related to deleted (Feature #3203: manage classification.config)
#15

Updated by Jason Ish over 1 year ago

Also available in: Atom PDF