In firewall mode a rule can hook an application-layer state, e.g. @accept:hook <proto>:request_started@ or @drop:flow <proto>:request_started@. For IMAP these rules load without any error or warning, but they are completely inert: they n...Yash Datre
In firewall mode, the "auto-accept prior states" notation (@accept:... proto:<hook@) is documented to accept the target hook *and* all hooks before it. This does not hold when a lower-SID @drop@ rule at the same target hook has a prefilt...Yash Datre
Thanks Jason, this looks good and covers our firewall use cases well — the session-level transaction with the @request_started@ → @request_data@ → @request_complete@ progression plus xbits maps cleanly onto our sender/recipient validatio...Yash Datre
Found an edge case: @accept:flow dns:<request_complete@ / @dns:<response_complete@ (the auto-accept-prior-hooks @<@ syntax applied to DNS) corrupts the @packet:filter@ table, causing ALL packets to be dropped by the default packet policy...Yash Datre
While validating the "monitor mode" (running a firewall ruleset with default policies flipped from @drop@ to @accept:hook,alert@, so a default-drop ruleset can be trialed in production without disrupting traffic), we found there is no wa...Yash Datre
Thanks for sharing PR "#15402":https://github.com/OISF/suricata/pull/15402 — we've reviewed it and the referenced suricata-verify tests. Looks like the lazy-evaluation alternative from this issue: the @<@ operator keeps the rule as a sin...Yash Datre