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

One annoying issue popped up: our yaml parser doesn't like underscores in the keys. So to make it work a snipped would look like this

firewall:
  policies:
    dns:
      request-started:
        - "accept:hook" 
      request-complete:
        - "drop:flow" 
      response-started:
        - "accept:hook" 
      response-complete:
        - "drop:flow" 

Another thing I didn't realize before: when we invoke the default policy we have no signature, so we can't raise an alert either. I was thinking about adding alert the example above:

firewall:
  policies:
    dns:
      request-started:
        - "accept:hook" 
      request-complete:
        - "drop:flow" 
        - "alert" 
      response-started:
        - "accept:hook" 
      response-complete:
        - "drop:flow" 

We would want the alerts from default hooks to be emitted in the eve alert logs if possible

Was thinking about mixing default policies into the rule file as I noticed I was missing that while testing this work. I just wanted to drop an idea of what this could look like, perhaps future work:

default accept:hook packet:filter (sid:9000001; msg:"firewall default packet filter";)
default accept:flow tls:client_in_progress (sid:9000200; msg:"firewall default TLS client in progress";)

Additionally it gives the defaults a signature.

Aneesh Patel wrote in #note-15:

We would want the alerts from default hooks to be emitted in the eve alert logs if possible

This is not implemented yet. Tracking in #8566.

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 way to set a default policy broadly. firewall.policies only accepts exact, fully-qualified keys:

firewall:
  policies:
    packet-filter: ["accept:hook", "alert"]
    tls:
      client-hello-done: ["accept:hook", "alert"]
      # ...every state, for every protocol, must be listed individually

There is no firewall.policies.tls (per-protocol) default, no all/*/default wildcard, and no global default. Any state not listed keeps the built-in default (drop:flow for app states, drop:packet for packet-filter).

Two consequences:

1. To monitor all traffic you must enumerate every state of every protocol in use — verbose and easy to leave gaps.
2. Setting only packet-filter: accept:hook,alert is not sufficient: the TCP transport is accepted, but app-layer flows are still dropped by the per-state app defaults (drop:flow), so HTTP/TLS/etc. traffic is blocked.

Proposal: support a default/wildcard policy, e.g. a global firewall.policies.default and/or per-protocol firewall.policies.<proto>.default, so operators can express "accept and alert everything by default" in one place. This would make safe, non-disruptive rollout of default-drop firewall rulesets practical.

Lets move the conversation about the monitor mode to #8389.