Suricata

Would it be ok to redefine the policy section of the configuration file to a format like this?
The current format as is in: https://github.com/OISF/suricata/blob/43bc2db41e4f7356f6cadb3247750d66e27ea8fe/suricata.yaml.in#L2396
Feels ambiguous, especially since it doesn't allow defining policies to packet-related tables only (hence adding a "packet" node).
The same would be for defining global app policy option (hence adding "app" configuration node)

firewall:
  policies:
    default-policy: ["accept:hook"]     # global fallback (all hooks)
    packet:
      default-policy: ["drop:packet"]   # fallback for packet hooks
      filter:     ["drop:packet"]
      pre-flow:   ["accept:hook"]
      pre-stream: ["accept:hook"]
    app:
      default-policy: ["drop:flow"]     # fallback for all app hooks
      dns:
        default-policy: ["drop:flow"]   # fallback for dns hooks
        request-started: ["accept:hook"]
        request-complete: ["drop:flow", "alert"]
        response-started: ["accept:tx"]

I think it makes sense. @Yash Datre any opinions?

Not particularly related to this ticket, but I would like to propose the change of the app layer policy from "http" to "http1" to be in line with FW rules.

Yes, this should solve the use-case.

Any update on this ticket? This is a pretty critical one for us

Hello, yes, it is on top of my list. I have it implemented, and after my testing/review, I expect I'll create a PR on Monday/Tuesday.

Prequel merged.
https://github.com/OISF/suricata/pull/16021

As thinking through the usability I thought of one extra improvement.

Currently, protocols with substates follow this hierarchy:
``app.<proto>.<sub state>.<hook / generic_state>`` >``app.<proto>.<sub state>.default-policy`` > ``app.<proto>.default-policy`` > ``app.default-policy`` > ``policies.default-policy`` > built-in (``drop:flow``)

But in case, e.g. for http2, the user wants to set both stream and global substates to the same values, then the config needs to be defined for every substate.
Allowing to set hook name on the protocol level could have save this explicitness on the substate level.

The final chain could look like:
``app.<proto>.<sub state>.<hook / generic_state>`` > ``app.<proto>.<hook / generic_state>`` >``app.<proto>.<sub state>.default-policy`` > ``app.<proto>.default-policy`` > ``app.default-policy`` > ``policies.default-policy`` > built-in (``drop:flow``)

And in the config:

From this:

    firewall:
      policies: 
          http2:
            stream:
              request-started: ["accept:hook"]
              request-completed: ["accept:hook"]
              response-started: ["accept:hook"]
              response-completed: ["accept:hook"]
            global:
              request-started: ["accept:hook"]
              request-completed: ["accept:hook"]
              response-started: ["accept:hook"]
              response-completed: ["accept:hook"]

to this:

    firewall:
      policies: 
          http2:
              request-started: ["accept:hook"]
              request-completed: ["accept:hook"]
              response-started: ["accept:hook"]
              response-completed: ["accept:hook"]

Leaving this for a discussion for now, it not part of the current PR.