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 12 months ago
Would you have an example rule where you would want such a warning ?
Updated by Brandon Murphy 12 months 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.