Hello,
Currently I have a configuration using the multi-tenant configuration with two tenants.
When I run suricata-update I receive errors such as the following:
– Rule has unknown dest address var and will be disabled: HOME_NET: # [1:2014216] ET MALWARE Delf/Troxen/Zema controller responding to client*
– Rule has unknown dest address var and will be disabled: EXTERNAL_NET: [1:2029183] ET MALWARE Win32/MailerBot CnC Activity
– Rule has unknown source address var and will be disabled: EXTERNAL_NET: # [1:2005777] ET WEB_SPECIFIC_APPS @lex Guestbook SQL Injection Attempt – index.php lang UPDATE
– Rule has unknown dest address var and will be disabled: HTTP_SERVERS: # [1:2005777] ET WEB_SPECIFIC_APPS @lex Guestbook SQL Injection Attempt – index.php lang UPDATE*
22/10/2020 – 13:41:50 - – Disabled 20 rules.
22/10/2020 – 13:41:50 - – Enabled 18 rules.
22/10/2020 – 13:41:50 - – Modified 0 rules.
22/10/2020 – 13:41:50 - – Dropped 0 rules.
22/10/2020 – 13:41:50 - – Enabled 1 rules for flowbit dependencies.
22/10/2020 – 13:41:50 - – Backing up current rules.
22/10/2020 – 13:42:00 - – Writing rules to /var/lib/suricata/rules/suricata.rules: total: 90286; enabled: 703; added: 51860; removed 55600; modified: 2049
22/10/2020 – 13:42:01 - – Testing with suricata -T.
22/10/2020 – 13:42:02 - – [ERRCODE: SC_ERR_MT_NO_MAPPING(271)] - device p1p1 not found
22/10/2020 – 13:42:02 - – [ERRCODE: SC_ERR_MT_NO_MAPPING(271)] - no multi-detect mappings defined
22/10/2020 – 13:42:02 - – [ERRCODE: SC_ERR_INITIALIZATION(45)] - initializing multi-detect detection engine contexts failed.
22/10/2020 – 13:42:02 - – Suricata test failed, aborting.
22/10/2020 – 13:42:02 - – Restoring previous rules.
[suricata]# ip a | grep p1p1
2: p1p1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
[suricata]# ip a | grep p1p2
5: p1p2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
In /etc/suricata/suricata.yaml
multi-detect:
enabled: yes
default: no
selector: device
loaders: 8
tenants:
- id: 1
yaml: /etc/suricata/suricata-tenant-c.yaml - id: 2
yaml: /etc/suricata/suricata-tenant-d.yaml
mappings:
- device: p1p1
tenant-id: 1 - device: p1p2
tenant-id: 2
In /etc/suricata I have the following:
[suricata]# ls -l /etc/suricata/
classification.config
disable.conf
enable.conf
reference.config
suricata-tenant-c.yaml
suricata-tenant-d.yaml
suricata.yaml
threshold.config
Suricata Info
[suricata]# cat /etc/redhat-release
CentOS Linux release 7.8.2003 (Core)
[suricata]# suricata -V
This is Suricata version 5.0.3 RELEASE
[suricata]# suricata --dump-config
multi-detect = (null)
multi-detect.enabled = yes
multi-detect.default = no
multi-detect.selector = device
multi-detect.loaders = 8
multi-detect.tenants = (null)
multi-detect.tenants.0 = id
multi-detect.tenants.0.id = 1
multi-detect.tenants.0.yaml = /etc/suricata/suricata-tenant-c.yaml
multi-detect.tenants.1 = id
multi-detect.tenants.1.id = 2
multi-detect.tenants.1.yaml = /etc/suricata/suricata-tenant-d.yaml
multi-detect.mappings = (null)
multi-detect.mappings.0 = device
multi-detect.mappings.0.device = p1p1
multi-detect.mappings.0.tenant-id = 1
multi-detect.mappings.1 = device
multi-detect.mappings.1.device = p1p2
multi-detect.mappings.1.tenant-id = 2
Cronjob for Suricata-update
@hourly ( /usr/bin/suricata-update -D /var/lib/suricata --suricata-conf /etc/suricata/suricata.yaml --suricata /usr/bin/suricata ) > /dev/null 2>&1
This leads to a few questions:
-
Would I be correct in my understanding that I don’t need any vars: section in /etc/suricata if the tenant configurations are setup with this information? I’m basing that off the documentation section 10.4.2
“In the main (“master”) YAML, the suricata.yaml, a new section called “multi-detect” should be added.”
“tenants: list of tenants
id: tenant id
yaml: separate yaml file with the tenant specific settings” -
Why is suricata-update not parsing the variables correctly such as HOME_NET, EXTERNAL_NET, etc? Do I have to implement separate suricata-update jobs that point to the tenant configs instead of /etc/suricata.yaml?
Note I have (6) other installations that do not use mulit-tenant setup, run the same suricata-update cron job, and pull from the same rule sources without any of these errors. The main difference is their vars are defined within the /etc/suricata.yaml file.