Project

General

Profile

Actions

Bug #6976

open

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

Added by Juliana Fajardini Reichow about 1 year ago. Updated 2 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 11 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 11 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 10 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 10 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 10 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 #9

Updated by Victor Julien 2 months ago

  • Target version changed from 8.0.0-beta1 to 8.0.0-rc1
Actions

Also available in: Atom PDF