Project

General

Profile

Actions

Bug #6976

open

flow/action: not updated w pkt + flow:stateless rules

Added by Juliana Fajardini Reichow 7 months ago. Updated 4 months ago.

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

Description

Not sure if a bug or if expected, but as seen in SV test ips-state-1 (updated here: https://github.com/OISF/suricata-verify/pull/1781),
when we have a TLS flow with a drop rule, Suricata will drop all packets as expected but doesn't set flow.action to drop.

Looking at the stats, I notice that Suricata sees 2 HTTP transactions, but no TLS one. Could somehow be that the flow.action is only set when there is an
associated transaction?
----------------
Current test: https://github.com/OISF/suricata-verify/tree/master/tests/ips-state-1
----------------
Test scenario:

rules:
pass tcp $HOME_NET any -> $EXTERNAL_NET 80 (sid:1;)
drop ip any any -> any any (msg:"DROP ALL"; flow:stateless; sid:2;)

traffic:
pcap contains 3 flows, 2 HTTP, and one TLS.
Flows are passed and dropped as expected, but the TLS one that is dropped doesn't show flow.action: drop in the EVE log.
The passed HTTP flows do show flow.action: pass.


After more discussion, we reached the conclusion that for a rule like this, we would require that each packet have a flow, and thus it makes sense for
flow.action to be updated.

A second, sort of related task is to update the documentation for flow:stateless and make it less paradoxical-looking. (https://docs.suricata.io/en/latest/rules/flow-keywords.html)

Actions #2

Updated by Victor Julien 4 months ago

Doesn't the flow:stateless make it a pkt rule type? So it's eval'd per packet and doesn't apply the drop to the flow?

Actions #3

Updated by Juliana Fajardini Reichow 4 months ago

Victor Julien wrote in #note-2:

Doesn't the flow:stateless make it a pkt rule type? So it's eval'd per packet and doesn't apply the drop to the flow?

This is something that I'm still trying to learn/grasp better. If that's the case, I wonder if we can document this better. -- also in the existing SV where this was pointed out...

Actions #4

Updated by Juliana Fajardini Reichow 4 months ago

  • Subject changed from flow/action: not always updated? to flow/action: not updated w pkt + flow:stateless rules
  • Description updated (diff)
Actions #5

Updated by Juliana Fajardini Reichow 4 months ago

to be decided whether we want to backport it or not (maybe once the work is done, and how intrusive it is?)

Actions #6

Updated by Juliana Fajardini Reichow 4 months ago

Solution will involve updating SignatureIsIPOnly to take into consideration the case described here (cf https://github.com/OISF/suricata/blob/master/src/detect-engine-build.c#L209).

Actions

Also available in: Atom PDF