Suricata

Use case : a rule can use alert http1 when Suricata version is above 6

Questions :
- Can multiple rules have the same sid but different "Suricata versions" ?
- How would 3rd party tooling know which exact rule was used (the one for suri version 6 or version 7) ?

Remarks:
- Besides suricata version, the same kind of thing should be done for features (like availability of geoip, file magic...)

Proposals:
- add a new version keyword

alert http any any -> any any (http.uri; content: "abc"; requires: features:geoip, version:6.0.0-7.0.0 ;)

alert http any any -> any any (http.uru; content: "abc"; metadata: features geoip, version 6.0.0-7.0.0 ;)

alert http any any -> any any (msg:"TEST"; {{ if suricata.version >= 7 }}new stuff;{{ else }}old stuff;{{endif}} sid:1; rev:1;)@ (can be also suricata style @alert http any any -> any any (version:6.0.0; http.uri; content: "abc"; version:7.0.0; http.uri; content: "def"; version:*; http.otheri; content: "abc";) )

#version >7
alert http any any -> any any (http.uri; content: "abc";)

if SURICATA_VERSION > 7
alert http any any -> any any (http.uri; content: "abc";)
endif

Preferred version for now seems

alert http any any -> any any (http.uri; content: "abc"; requires: features:geoid, version:6.0.0-7.0.0 ;)

On the requires format, we cannot re-use ':' within.. So

requires: features geoip,foo version >=7.0.4
requires: version 6.0.0-7.0.0

One idea would be to take a version specification format like used in Rust crates, so we can use a library like https://crates.io/crates/versions.

alert tls any any -> any any (ja3; content:"...."; geoip:src,NL; \
    requires: feature ja3, feature geoip, version >=6.0.0, version <10.0.0; sid:1; rev:1;)

Victor Julien wrote in #note-14:

Request to @Brandon Murphy : can you help test this during development?

Sure.

I will say it is VERY unlikely ET will ever intentionally produce a rules file with duplicate sids.

Given the new keyword will not be present in 7.0.0, it will also go against ET practice to use it starting at a minor release. To ensure compatibility with all 7.x versions, we're unlikely to use it until 8.0.0 .

To document current behavior, when an unknown keyword is found, a non-fatal error is produced. Suricata skips over the invalid rule, but continues to load the other rules

Notice: suricata: This is Suricata version 7.0.1 RELEASE running in USER mode
Info: cpu: CPUs/cores online: 4
Info: suricata: Setting engine mode to IDS mode by default

<snip boring stuff>

Error: detect-parse: unknown rule keyword 'requires'.
Error: detect: error parsing signature "alert http any any -> any any (msg:"TEST"; flow:established,to_server; http.method; content:"POST"; requires: feature ja3; classtype:attempted-admin; sid:1; rev:1;)" from file /tmp/499d08574bf7c6c5_Nov-10-2023_00-50-23/dalton-custom.rules at line 1
Info: detect: 2 rule files processed. 67630 rules successfully loaded, 1 rules failed
Info: threshold-config: Threshold config parsed: 0 rule(s) found
Info: detect: 67633 signatures processed. 1310 are IP-only rules, 10927 are inspecting packet payload, 55360 inspect application layer, 0 are decoder event only
Info: pcap: Starting file run for /tmp/499d08574bf7c6c5_Nov-10-2023_00-50-23/pcaps/proxy-231103-180549_fixed.pcap
Notice: threads: Threads created -> RX: 1 W: 4 FM: 1 FR: 1   Engine started.
Info: pcap: pcap file /tmp/499d08574bf7c6c5_Nov-10-2023_00-50-23/pcaps/proxy-231103-180549_fixed.pcap end of file reached (pcap err code 0)
Notice: suricata: Signal Received.  Stopping engine.
Info: suricata: time elapsed 0.243s
Notice: pcap: read 1 file, 550 packets, 241653 bytes

<snip boring stuff>

Info: counters: Alerts: 13

The errors are still errors. Most (serious) deployments will first test with -T and those errors will fail then. Same for --init-errors-fatal.

Another thought from post-processing yesterdays session. Would it make sense to add support for protocols to check if a protocol is enabled?

requires: protocol dnp3;

I'm looking to only support the following version comparison operators:
- >
- >=
- <
- <=

I don't think ^ and ~ per semver make sense for us. And = probably has not much use, or could lead to confusion.

I agree.