Feature #5973
openwarn when HTTP rules will only work for a specific version of HTTP
Description
As a rule writer, I'd like to be warned should if a rule only supports certain versions of HTTP due to use of keywords which only support certain HTTP versions.
This feature was mentioned within https://github.com/OISF/suricata/pull/8670
Should we warn on a rule alert http that is only for HTTP1 or HTTP2 based on its keywords ?
I see no reason to not warn on this condition and as such am formally requesting it.
Side Note:
I could see some other use cases such as warning when nocase isn't applied to http.header_names, http.header, etc. Though perhaps those use cases are not good fits for the engine to identify.
Updated by Victor Julien over 1 year ago
- Target version changed from TBD to 8.0.0-beta1
The warning should make sure not to ever warn on legacy keywords if HTTP/2 doesn't support them.
Also not sure if a warning is the proper way, as as a valid rule shouldn't really warn ideally. Wonder if it is more something for engine analysis.
Updated by Philippe Antoine about 1 year ago
Would you have an example rule where you would want such a warning ?
Updated by Brandon Murphy about 1 year ago
Victor Julien wrote in #note-1:
Wonder if it is more something for engine analysis.
I think that's a great idea.
Philippe Antoine wrote in #note-2:
Would you have an example rule where you would want such a warning ?
sure! these two come to mind quickly.
alert http any any -> any any (msg:"http.start only supports HTTP/1"; flow:established,to_server; http.start; content:"GET /foo"; startswith; content:"|0d 0a|Host|3a 20|"; within:15; sid:1;) alert http any any -> any any (msg:"http.msg only populated with content on HTTP/1"; flow:established,to_server; http.msg; content:"Found"; sid:2;)
There might be others, but i'm not 100% sure they'd be good for the engine. I suppose as engine-analysis they would be ok.
Things like the use of pseudo headers on contents, which would indicate the rule would only work with HTTP/2. In that example, the RFC's defined list of :pseudo headers (https://www.rfc-editor.org/rfc/rfc9113.html#section-8.3.1) would be used to identify the usage.
capital letters in contents when to_lowercase transformation is applied to a buffer
capital letters in contents of http.header_names (would indicate it might be HTTP/1 only)
when header_lowercase is applied to a buffer, and content matches contain something that matches the same logic as header_lowercase [^\x3a]+\x3a[^\r\n]+[\r\n]+ bring that content to the rule writers attention.
Idk, I'm just brainstorming here, some if these we can probably do within ET's own rule analysis.