Suricata » Suricata-Update

What I've done so far is log the following:

26/2/2018 -- 07:32:03 - <Warning> -- Rule has unknown source address var and will be disabled: DC_SERVERS: [1:10002558] [PT OPEN] DCShadow Replication Attempt - DRSUAPI_REPLICA_ADD from non-DC
26/2/2018 -- 07:32:03 - <Warning> -- Rule has unknown dest address var and will be disabled: DC_SERVERS: [1:10002558] [PT OPEN] DCShadow Replication Attempt - DRSUAPI_REPLICA_ADD from non-DC
26/2/2018 -- 07:32:03 - <Warning> -- Rule has unknown source address var and will be disabled: DC_SERVERS: [1:10002557] [PT OPEN] DCShadow Replication Attempt
26/2/2018 -- 07:32:03 - <Warning> -- Rule has unknown dest address var and will be disabled: DC_SERVERS: [1:10002557] [PT OPEN] DCShadow Replication Attempt
26/2/2018 -- 07:32:03 - <Warning> -- Rule has unknown source address var and will be disabled: DC_SERVERS: [1:10002559] [PT OPEN] DCShadow: Fake DC Creation
26/2/2018 -- 07:32:03 - <Warning> -- Rule has unknown dest address var and will be disabled: DC_SERVERS: [1:10002559] [PT OPEN] DCShadow: Fake DC Creation

And then disable the rule.

I do not have a configuration toggle for this though, it always happens, and I think is a good default. Do you think there is a use case where it shouldn't disable and just log, and let the Suricata -T test fail?

How about if a user includes a yaml with vars?

In terms of telling the user to update their config, I'm thinking of recording a series of messages/notes and displaying those at the very end, after suricata-update is done. So you'd get something like:

26/2/2018 -- 07:36:10 - <Info> -- Testing with suricata -T.
26/2/2018 -- 07:36:21 - <Info> -- Done.

Notes:
* At least one rule is using the DC_SERVERS address-group variable
  which is not defined in your configuration. Please consider adding
  it to your suricata.yaml.

Victor Julien wrote:

How about if a user includes a yaml with vars?

Maybe. But thats a more advanced user case which I don't think will be used very often. Still focusing on the 99%.

Jason Ish wrote:

Victor Julien wrote:

How about if a user includes a yaml with vars?

Maybe. But thats a more advanced user case which I don't think will be used very often. Still focusing on the 99%.

Also, the goal here is to raise the attention that the config isn't 100% correct. And I'm wondering if having it fail out completely at -T is a valid use case? A user provided set of vars would be something that user would provide to fix this up, or modify their suricata.yaml. I don't want to add a new toggle if its a very unlikely use case though.

What I'm thinking about is maybe a "--fail-on-warnings" flag that bails out on any warning. Or perhaps flags like "--disable-var-check", which could be furthered with other "disable" flags like "--disable-flowbit-resolve". Or --no-var-check, --no-flowbit-resolve. Maybe not now, but keep the idea open for later?

From a user perspective I would love to know if some variable is defined in the rules but not in the config.
I can often enough happen the engineers that deploy Suricata are not the ones that write the rules - you get an import or similar.
In that case it would be beneficial to know/be notified - including help out in troubleshooting if needed.

Peter Manev wrote:

From a user perspective I would love to know if some variable is defined in the rules but not in the config.
I can often enough happen the engineers that deploy Suricata are not the ones that write the rules - you get an import or similar.
In that case it would be beneficial to know/be notified - including help out in troubleshooting if needed.

Peter, So the "warning" logging, which is orange on a tty will tell you that. Current, my WIP will also disable those rules so Suricata can continue. What I'm mainly interested in is this might be too lenient for some users? Maybe they want the Suricata test to fail out, so the program exits with a non-success code to fix the vars so they have all the rules enabled. But this would be something to turn on.

I think disabling the rules that we know will fail out due to missing vars is probably a good default case.

Jason Ish wrote:

In terms of telling the user to update their config, I'm thinking of recording a series of messages/notes and displaying those at the very end, after suricata-update is done. So you'd get something like:
[...]

I like this 'notes' idea. I think it's nice and clear to the user.

I like the idea of 'notes' as well combined with the proposed default behavior - we just to make it visible in the docs/logs.
I also like the idea of passing an option to fail unconditionally if something is not correct configuration wise (just like Suri will do).