Bug #8454
opendoh2: FN with rulesets combining dns rules and http2 rules
Description
Ruleset containing rules with dns keywords and http keywords
alert dns any any -> any any (dns.query; content: "www.gstatic.com"; sid:20; ) alert doh2 any any -> any any (dns.query; content: "www.gstatic.com"; sid:21; ) alert http2 any any -> any any (http.request_header; content:"authority|3a 20|dns.google"; sid:30; ) alert doh2 any any -> any any (http.request_header; content:"authority|3a 20|dns.google"; sid:31; )
does not trigger on http rules, even if it triggers when the dns rules are absent
OT Updated by OISF Ticketbot 21 days ago
- Subtask #8455 added
OT Updated by OISF Ticketbot 21 days ago
- Label deleted (
Needs backport to 8.0)
PA Updated by Philippe Antoine 21 days ago
- Status changed from Assigned to In Review
JI Updated by Jason Ish 10 days ago
Further details from the commit message:
For example, when there are 2 rules
alert doh2 any any -> any any (dns.query; content: "www.gstatic.com"; sid:21; )
alert doh2 any any -> any any (http.request_header; content:"dns.google"; sid:31; )
Both dns.query and http.request_header engines are registered
with progress 1 in their respective alprotos: dns and http2
So, dns engine has is_last_for_progress = true, as the engines in
signature group heads are sorted by tx_min_progress then alproto
When prefilter runs a doh2 transaction,
- it first checks the dns engine,
- then it used to update tx->detect_progress beyond progress 1,
- and so in the next iteration of the loop, for the http.request_header
engine, we had tx->detect_progress > engine->ctx.tx_min_progress
and we skipped the http.request_header prefilter engine,
thus resulting in false negative.
PA Updated by Philippe Antoine about 4 hours ago
- Status changed from In Review to Resolved