Suricata » Suricata-Update

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.

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.

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.

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.

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.

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)?

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?

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.

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.