Project

General

Profile

Actions

Feature #2449

closed

handling missing variables

Added by Victor Julien about 6 years ago. Updated over 5 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Target version:
Effort:
Difficulty:
Label:

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.

Actions #1

Updated by Victor Julien about 6 years ago

  • Tracker changed from Bug to Feature
Actions #2

Updated by Jason Ish about 6 years ago

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?

Actions #3

Updated by Victor Julien about 6 years ago

How about if a user includes a yaml with vars?

Actions #4

Updated by Jason Ish about 6 years ago

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.

Actions #5

Updated by Jason Ish about 6 years ago

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%.

Actions #6

Updated by Jason Ish about 6 years ago

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.

Actions #7

Updated by Jason Ish about 6 years ago

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?

Actions #8

Updated by Peter Manev about 6 years ago

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.

Actions #9

Updated by Jason Ish about 6 years ago

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.

Actions #10

Updated by Victor Julien about 6 years ago

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.

Actions #11

Updated by Peter Manev about 6 years ago

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

Actions #12

Updated by Jason Ish about 6 years ago

  • 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.

Actions #13

Updated by Jason Ish over 5 years ago

  • Target version changed from 1.0.0 to 1.0.0rc1
Actions

Also available in: Atom PDF