Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.debian.bugs.rc > #319784 > unrolled thread
| Started by | Sascha Steinbiss <satta@debian.org> |
|---|---|
| First post | 2022-05-11 07:10 +0200 |
| Last post | 2022-05-11 07:10 +0200 |
| Articles | 1 — 1 participant |
Back to article view | Back to linux.debian.bugs.rc
This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by
below is the oldest one visible, not the original post.
Bug#1010771: suricata: recieve erros after adding rule list Sascha Steinbiss <satta@debian.org> - 2022-05-11 07:10 +0200
| From | Sascha Steinbiss <satta@debian.org> |
|---|---|
| Date | 2022-05-11 07:10 +0200 |
| Subject | Bug#1010771: suricata: recieve erros after adding rule list |
| Message-ID | <ElMLL-eH9t-7@gated-at.bofh.it> |
[Multipart message — attachments visible in raw view] — view raw
severity 1010771 normal thanks Hi Tim, I just noticed you also included your suricata.yaml configuration file in your bug report. I think I found the cause of your problem. Let's take a look at a problematic rule: > 9/5/2022 -- 14:20:21 - <Error> -- [ERRCODE: SC_ERR_INVALID_SIGNATURE(39)] - > error parsing signature "alert udp ![$SMTP_SERVERS,$DNS_SERVERS] any -> > $DNS_SERVERS 53 (msg:"ET DNS DNS Lookup for localhost.DOMAIN.TLD"; > content:"|01|"; offset:2; depth:1; content:"|00 01 00 00 00 00 00|"; > distance:1; within:7; content:"|09|localhost"; fast_pattern; nocase; > classtype:bad-unknown; sid:2011802; rev:6; metadata:created_at 2010_10_13, > updated_at 2019_09_03;)" from file /var/lib/suricata/rules/suricata.rules at > line 3806 So this rule alerts if the content patterns are found in traffic from source addresses that are _not_ in the ranges configured for SMTP and DNS servers (![$SMTP_SERVERS,$DNS_SERVERS]). These variables are referenced in the rule but -- since the rule author does not know what the IP addresses of these servers are in your network -- need to be configured elsewhere, namely in your suricata.conf. Here's the relevant snippet from yours: [...]> %YAML 1.1 > --- > vars: > # more specific is better for alert accuracy and performance > address-groups: > HOME_NET: "[192.168.0.0/16,10.0.0.0/8,172.16.0.0/12]" > HOME_NET: "[192.168.0.0/16]" > HOME_NET: "[10.0.0.0/8]" > HOME_NET: "[172.16.0.0/12]" > HOME_NET: "any" > EXTERNAL_NET: "!$HOME_NET" > EXTERNAL_NET: "any" > HTTP_SERVERS: "$HOME_NET" > SMTP_SERVERS: "$HOME_NET" > SQL_SERVERS: "$HOME_NET" > DNS_SERVERS: "$HOME_NET" > TELNET_SERVERS: "$HOME_NET" > AIM_SERVERS: "$EXTERNAL_NET" > DC_SERVERS: "$HOME_NET" > DNP3_SERVER: "$HOME_NET" > DNP3_CLIENT: "$HOME_NET" > MODBUS_CLIENT: "$HOME_NET" > MODBUS_SERVER: "$HOME_NET" > ENIP_CLIENT: "$HOME_NET" > ENIP_SERVER: "$HOME_NET" So you are setting both SMTP_SERVERS and DNS_SERVERS to the same value as your HOME_NET, which here effectively is "any", i.e. any possible IP address. Note that each of these assignments of HOME_NET overwrites the previous setting, so the last one here counts. Now, evaluating that configuration, the rule above is now requiring the source address to be _not_ any possible IP address, which is obviously a problem which leads to an error being reported: > 9/5/2022 -- 14:20:21 - <Error> -- [ERRCODE: > SC_ERR_INVALID_SIGNATURE(39)] - Complete IP space negated. Rule > address range is NIL. Probably have a !any or an address range that > supplies a NULL address range The solution is easy. Please set only one value for HOME_NET which correctly reflects your internal IP addresses and make sure that DNS_SERVERS and the others are also set accordingly. Did you just comment in all the examples [1] in the stock suricata.yaml file? These are just examples -- keeping the first one with the RFC1918 addresses is usually sufficient. Otherwise, setting these values is a typical step in Suricata initial configuration and baselining. Note that the same applies to EXTERNAL_NET. Please let me know if you have any more questions. Lowering the severity here since from what I can see this is not an issue with Suricata per se but rather related to configuration. Best regards Sascha [1] https://github.com/OISF/suricata/blob/master/suricata.yaml.in#L19
Back to top | Article view | linux.debian.bugs.rc
csiph-web