Project

General

Profile

Actions

Bug #8389

open
YD

firewall: Add monitor/observe mode to preview firewall policy without enforcing drops

Bug #8389: firewall: Add monitor/observe mode to preview firewall policy without enforcing drops

Added by Yash Datre about 1 month ago. Updated 15 days ago.

Status:
New
Priority:
Low
Assignee:
-
Target version:
Affected Versions:
Effort:
Difficulty:
Label:

Description

Firewall mode currently has no way to evaluate a rule set without enforcing it. Rules either accept or drop, and the default policy drops unmatched traffic. There is no equivalent of IDS alert-only mode for the firewall engine.

This is a blocker for safe policy deployment. Operators need to preview the effect of a new or modified firewall policy on production traffic before switching to enforcement. The typical workflow is: deploy rules → enable monitor mode → observe logs for hours/days → confirm no legitimate traffic would be blocked → switch to enforce mode.

Ask : A configuration option (in suricata.yaml or via a runtime flag) that puts the firewall engine into a non-enforcing "monitor" state. When enabled:

  1. Firewall rules evaluate identically — same matching, same rule ordering, same table evaluation (pre_flow, pre_stream, main).
  2. Drop/reject verdicts are suppressed — packets that would be dropped or rejected by a firewall rule are instead allowed to pass through. The default drop action for unmatched packets is also suppressed.
  3. Alerts are generated — for every packet where a drop/reject verdict is suppressed, an alert (EVE JSON log entry) is generated indicating the rule that matched and the action that would have been taken. This gives operators full visibility into what enforcement mode would do.
  4. Accept rules behave normally — packets matching accept rules pass through as usual.
Why this can't be done externally :
  • Changing all drop:* rules to alert doesn't work because firewall mode syntax doesn't support alert as an action — only accept and drop (with scope).
  • Running in IDS mode instead doesn't work because IDS mode doesn't evaluate the firewall rule tables (pre_flow, pre_stream, main) or the default drop policy. The rule evaluation path is fundamentally different.
  • Setting the default policy to ACCEPT (Section 4.5 of our requirements) only changes the unmatched-traffic behavior — it doesn't suppress explicit drop:* rule verdicts. Monitor mode needs to suppress all enforcement, including explicit drop rules.

Ideally the runtime toggle approach, so operators can switch between monitor and enforce on a live instance without restarting Suricata or reloading rules.

JL Updated by Jamie Lavigne about 1 month ago Actions #1

I think this one is optional/low priority because with https://redmine.openinfosecfoundation.org/issues/7701 we would have the support we need to do this?

VJ Updated by Victor Julien about 1 month ago Actions #2

  • Subject changed from Firewall mode: Add monitor/observe mode to preview firewall policy without enforcing drops to firewall: Add monitor/observe mode to preview firewall policy without enforcing drops
  • Priority changed from Normal to Low

I think a complexity would be how to handle explicit drop rules. These are terminating actions, so to simulate the enforcement of drop rules we'd have to make them terminating as well. Maybe it would be enough to turn drop:packet into accept:packet, etc.

YD Updated by Yash Datre about 1 month ago Actions #3

In monitor mode, the pipeline must follow the same path — skip the same tables, make the same decisions — and only flip the final action. Since a firewall drop rule skips IPS/IDS rules, in monitor mode the matching drop rule should be accepted directly and skip IPS/IDS mode.

JL Updated by Jamie Lavigne 25 days ago Actions #4

I think that's open to be defined - firewall mode is logically like two independent devices, a firewall with an IDS chained downstream. With that mental model, any packets not dropped by the firewall stage (including monitor mode) would be seen by the downstream IDS device.

AP Updated by Aneesh Patel 15 days ago Actions #5

To clarify the expected monitor mode behavior, so that we all are on the same page. We want exact behavioral parity with ENFORCE — only the final verdict changes from drop to pass.

When monitor mode is enabled:

1. Firewall pipeline runs identically to enforce mode — same table evaluation order, same rule matching, same skip logic.
2. On first drop match (whether from an explicit drop rule or the default policy), the match is logged as "would have dropped" with the rule
details in EVE JSON.
3. All remaining tables are skipped after that drop — including IDS tables — exactly as enforce mode would.
4. The packet is passed instead of dropped.

If no drop rule (or default drop) matches the packet from firewall mode rules and there are multiple drops in IDS that matches the packet, only log the first drop rule from IDS and skip the rest.

Actions

Also available in: PDF Atom