Suricata

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 TLS outbound by SNI requires 13 hand-written rules covering the TCP handshake, all client states, and all server states. The author must know every protocol state name, which state carries which keyword, and the correct direction for each. This pattern repeats for HTTP, DNS, and every other app-layer protocol.

We're exploring a < prefix operator on the hook name that tells the engine to automatically accept all prerequisite states before the specified hook:

accept:tx <tls:client_hello_done $HOME_NET any -> $EXTERNAL_NET any (tls.sni; content:".amazon.com"; endswith; sid:1003;)

This collapses the 13-rule TLS example into a single rule. The author still names the exact hook where the condition is evaluated — the engine handles the transport setup and prior state accepts. Internally this would be a pre-processing step that emits the same state-based rules, so no new architecture is needed.

An alternative expression as a keyword (accept-prior-states;) was also considered for readability. We evaluated several other approaches (full keyword-derived state resolution, keyword-based templates, structured blocks, YAML config) but believe the < operator strikes the right balance between usability and precision.

We also have a few open questions we'd appreciate OISF's perspective on:

• For rules matching keywords at multiple states (e.g., tls.sni at client_hello_done and tls.cert_subject at server_cert_done), should the engine use the latest state, or should such rules be disallowed?

We're looking for feedback on this approach and whether it aligns with the direction OISF envisions for firewall mode. Happy to iterate on the syntax or semantics based on your input.