Project

General

Profile

Actions

Feature #8480

open
VJ VJ

firewall: allow specifying multiple actions

Feature #8480: firewall: allow specifying multiple actions

Added by Victor Julien about 2 months ago. Updated 4 days ago.

Status:
Resolved
Priority:
Normal
Assignee:
Target version:
Effort:
Difficulty:
Label:

Description

Currently a rule that should accept and log, should do something like

accept:packet ... (alert; ...)

It would be clearer if the actions are grouped together in the "action" field.

E.g. something like

accept,log:packet

Some other options:
{accept,log}:packet
accept:flow,log:packet
(accept|alert):packet

Not sure which syntax makes most sense. One thing to consider is if an action like accept is applied to the flow, should alert (or log) also be applied to the flow? Or just trigger once?


Subtasks 1 (1 open0 closed)

Feature #8572: firewall: allow specifying multiple actions (8.0.x backport)In ReviewVictor JulienActions

Related issues 3 (3 open0 closed)

Related to Suricata - Feature #8479: eve/firewall: dedicated log record typeFeedbackOISF DevActions
Related to Suricata - Feature #7701: firewall: configurable default policiesResolvedVictor JulienActions
Related to Suricata - Bug #8444: firewall: accept:flow at app-layer hook bypasses app:td (IDS/IPS) evaluationResolvedVictor JulienActions

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

  • Related to Feature #8479: eve/firewall: dedicated log record type added
  • Related to Feature #7701: firewall: configurable default policies added

VJ Updated by Victor Julien about 2 months ago Actions #2

This could turn the ideas of accept:pass_flow into a bit cleaner solution, I think. accept,pass:flow would apply accept and pass to the flow. This would keep actions and scope more cleanly defined.

JI Updated by Jason Ish about 2 months ago Actions #3

  • Related to Bug #8444: firewall: accept:flow at app-layer hook bypasses app:td (IDS/IPS) evaluation added

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

  • Status changed from New to In Progress
  • Assignee set to Victor Julien
  • Target version changed from TBD to 9.0.0-beta1

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

  • Status changed from In Progress to In Review

https://github.com/OISF/suricata/pull/15300 implements the list approach:

accept:flow,pass:flow,alert
accept:flow,alert

Still to do: more testing and the same for the packet filter table.

VJ Updated by Victor Julien 23 days ago Actions #6

  • Status changed from In Review to Resolved

VJ Updated by Victor Julien 21 days ago Actions #7

  • Label Needs backport to 8.0 added

OT Updated by OISF Ticketbot 21 days ago Actions #8

  • Subtask #8572 added

OT Updated by OISF Ticketbot 21 days ago Actions #9

  • Label deleted (Needs backport to 8.0)

JL Updated by Jamie Lavigne 4 days ago Actions #10

Are there restrictions on what combinations of actions are allowed? I'm trying to reason about what e.g. accept:hook,pass:flow would mean. The rest of this flow would bypass TD, but still be subject to firewall accepting the next hooks?

What about something like an accept:hook,pass:packet rule followed by an accept:flow on that connection? Would TD see that connection starting somewhere in the middle, since the earlier packets bypassed it?

Actions

Also available in: PDF Atom