Feature #2449
closed
handling missing variables
Added by Victor Julien almost 7 years ago.
Updated over 6 years ago.
Description
A recent 'PT open' update added rules that depend on a new variable:
[1411] 17/2/2018 -- 10:20:11 - (util-rule-vars.c:102) <Error> (SCRuleVarsGetConfVar) -- [ERRCODE: SC_ERR_UNDEFINED_VAR(101)] - Variable "DC_SERVERS" is not defined in configuration file
[1411] 17/2/2018 -- 10:20:11 - (detect-engine-loader.c:184) <Error> (DetectLoadSigFile) -- [ERRCODE: SC_ERR_INVALID_SIGNATURE(39)] - error parsing signature "alert tcp !$DC_SERVERS any -> $DC_SERVERS [1024:] (msg: "[PT OPEN] DCShadow Replication Attempt - DRSUAPI_REPLICA_ADD from non-DC"; flow: established, to_server, no_stream; content: "|05 00 00 03|"; depth: 4; content: "|05 00|"; distance: 18; within: 2; flowbits: isset, RPC.Bind.DRSUAPI; reference: url, blog.alsid.eu/dcshadow-explained-4510f52fc19d; classtype: attempted-admin; sid: 10002558; rev: 1; )" from file /var/lib/suricata/rules/suricata.rules at line 8734
[1411] 17/2/2018 -- 10:20:12 - (util-rule-vars.c:102) <Error> (SCRuleVarsGetConfVar) -- [ERRCODE: SC_ERR_UNDEFINED_VAR(101)] - Variable "DC_SERVERS" is not defined in configuration file
[1411] 17/2/2018 -- 10:20:12 - (detect-engine-loader.c:184) <Error> (DetectLoadSigFile) -- [ERRCODE: SC_ERR_INVALID_SIGNATURE(39)] - error parsing signature "alert tcp !$DC_SERVERS any -> $DC_SERVERS [1024:] (msg: "[PT OPEN] DCShadow Replication Attempt"; flow: established, to_server; content: "|05 00 0B|"; depth: 3; content: "|35 42 51 E3 06 4B D1 11 AB 04 00 C0 4F C2 DC D2|"; distance: 0; flowbits: set, RPC.Bind.DRSUAPI; flowbits: noalert; reference: url, blog.alsid.eu/dcshadow-explained-4510f52fc19d; classtype: attempted-admin; sid: 10002557; rev: 2; )" from file /var/lib/suricata/rules/suricata.rules at line 21510
[1411] 17/2/2018 -- 10:20:15 - (util-rule-vars.c:102) <Error> (SCRuleVarsGetConfVar) -- [ERRCODE: SC_ERR_UNDEFINED_VAR(101)] - Variable "DC_SERVERS" is not defined in configuration file
[1411] 17/2/2018 -- 10:20:15 - (detect-engine-loader.c:184) <Error> (DetectLoadSigFile) -- [ERRCODE: SC_ERR_INVALID_SIGNATURE(39)] - error parsing signature "alert tcp !$DC_SERVERS any -> $DC_SERVERS 389 (msg: "[PT OPEN] DCShadow: Fake DC Creation"; flow: established, to_server; content: "|68 84 00|"; content: "CN="; distance: 5; within: 3; content: "CN=Servers,CN="; distance: 0; content: ",CN=Sites,CN=Configuration,DC="; distance: 0; content: "objectClass"; distance: 0; content: "server"; distance: 0; reference: url, blog.alsid.eu/dcshadow-explained-4510f52fc19d; classtype: attempted-admin; sid: 10002559; rev: 2; )" from file /var/lib/suricata/rules/suricata.rules at line 45205
It would be nice if suricata-update could detect this and disable those rules, as well as inform the user that the config needs an update.
- Tracker changed from Bug to Feature
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).
- Status changed from New to Closed
- Target version set to 1.0.0
Fix merged here: https://github.com/OISF/suricata-update/pull/31
Warning messages will be output when an unknown variable is seen and the rule will be disabled. A note will be printed at the end of the run telling the user what happened and what they should do about it.
- Target version changed from 1.0.0 to 1.0.0rc1
Also available in: Atom
PDF