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
h2. Design Proposal One author-visible rule. The Rule_Loader auto-synthesises the accept chain from the protocol's registered state machine. Two equivalent syntaxes:Yash Datre
Hi Victor, Here are the real-world SMTP firewall scenarios we need, with rulesets using your per-command transaction design. Our original _request_command_data_ hook proposal doesn't hold up — SMTP has a sequence of commands (EHLO → M...Yash Datre
Hi Victor, Here are the ruleset examples. Three scenarios, then thoughts on hook design. h3. Scenario 1: Read-only FTP (block uploads) Access control happens on the control channel via _ftp:request_command_complete_. The data ch...Yash Datre
We'd like to propose a syntax addition to Suricata's firewall mode that reduces the rule authoring burden for common firewall use cases while preserving the precision of the state machine. Currently, writing a firewall rule to allow T...Yash Datre
We'd like to propose a syntax addition to Suricata's firewall mode that reduces the rule authoring burden for common firewall use cases while preserving the precision of the state machine. Currently, writing a firewall rule to allow T...Yash Datre