Suricata

It kind of combines 1 and 2, but allowing a default action of accept:hook combined with visibility into what the default action matches would be very valuable for testing new rulesets in a non-destructive way before enabling enforcement.

Inserting a firewall into an existing environment is a potentially dangerous operation if it ends up blocking traffic unintentionally. The two ideas above would allow a user to first configure the firewall in a way that evaluates rules and tells you what it would block but does not take any blocking action, so the user can validate the ruleset before switching the default action to blocking.

How about a simple YAML structure like this?

firewall:
  policies:
    packet:
      filter: "drop:packet" 
      pre_flow: "accept:hook" 
      pre_stream: "accept:hook" 
    app:
      http1:
        request_started: "accept:hook" 
        request_line: "accept:hook" 
        request_headers: "drop:flow" 
      tls:
        client_in_progress: "accept:hook" 
        client_hello_done: "drop:flow" 

We also need configurable alerts on the default action for monitoring.

For default actions we are thinking to have the following settings:

1. Verdict scope:
   - hook (existing)
   - packet (existing)
   - flow (existing)
   - tx (existing)

In addition to the above, * we would like the equivalent of flow and packet scope that will still send packets to the IPS engine* (flow and packet bypass right now and tx is not a true flow-scoped verdict)

1. Action:
   - drop (existing)
   - accept (existing)
   - reject
   - accept with alert (this one would accept, but log an alert log as well showing that the default action was hit at that hook)

Victor Julien wrote in #note-5:

How about a simple YAML structure like this?
[...]

I think this would be great to support configuring default actions per hook. I suppose doing that could also help (partially) solve the problem of introducing new hook points later, because Suricata effectively punts that problem to its users. It would be useful to have something like an explicit mode that forces you to fully specify them all in the yaml (no implicit defaults). That would take the surprises out of upgrading because you would be forced to notice the addition of new hook points and to provide a default action for them.

I think that makes sense and would definitely fit our use-case - I was envisioning something similar as well