Project

General

Profile

Actions

Feature #3202

closed

classtypes: validate classtypes in use

Added by Victor Julien about 5 years ago. Updated about 3 years ago.

Status:
Rejected
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 1 (0 open1 closed)

Blocked by Suricata-Update - Feature #3203: manage classification.configClosedShivani BhardwajActions
Actions #1

Updated by Victor Julien about 5 years ago

  • Tracker changed from Support to Feature
Actions #2

Updated by Victor Julien about 5 years ago

Actions #3

Updated by Jason Ish about 5 years 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.

Actions #4

Updated by Victor Julien about 5 years 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.

Actions #5

Updated by Victor Julien about 5 years 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.

Actions #6

Updated by Jason Ish about 5 years 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.

Actions #7

Updated by Jason Ish about 5 years 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.

Actions #8

Updated by Shivani Bhardwaj about 5 years ago

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

Updated by Shivani Bhardwaj about 5 years 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)?

Actions #10

Updated by Shivani Bhardwaj about 5 years 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?

Actions #11

Updated by Jason Ish about 5 years 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.

Actions #12

Updated by Jason Ish about 5 years 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.

Actions #13

Updated by Shivani Bhardwaj about 5 years ago

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

Updated by Jason Ish almost 5 years ago

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

Updated by Jason Ish almost 5 years ago

Actions #16

Updated by Jason Ish about 3 years ago

  • Status changed from Assigned to Rejected

Closing. I'm not sure if this is an issue that needs fixing anymore. We still need to make more use of the Suricata-Update managed classification file which is almost an alternative to this issue.

Actions

Also available in: Atom PDF