Project

General

Profile

Actions

Bug #7392

open

Verdict output reports "drop" when rejected

Added by Jamie Lavigne 10 months ago. Updated 17 days ago.

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

Description

When a rule with reject action matches and resets a connection, the verdict action reported is not "reject" but instead "drop". This makes it more difficult to do log analysis of the actions taken to distinguish between reject actions and actual drops, although it is possible using the supplementary "reject" fields. Is this intentional, or could Suricata report "reject" as the action in this case?

"verdict": {
    "action": "drop",
    "reject-target": "to_client",
    "reject": [
        "tcp-reset" 
    ]
}

Related issues 1 (1 open0 closed)

Related to Suricata - Bug #7544: Verdict output reports "alert" when traffic is allowed implicitly/passivelyNewJuliana Fajardini ReichowActions
Actions #1

Updated by Victor Julien 10 months ago

At least in IPS mode, a reject is a drop + reject. Since the reject is a best effort thing, the drop is what we think of as the most important action. Any thoughts on how to express it differently to help your use case?

Actions #2

Updated by Jamie Lavigne 10 months ago

This one was reported to me by an internal user but I think the motivations are both philosophical and practical.

On the philosophical side I think many of our users don't necessarily think about the internal mechanics of a reject being composed of a drop plus a best-effort reset - they think more in terms of actions that are configured in rules, where their problem here is answering something like "how many times were the configured pass/drop/alert/reject actions applied". The practical side of the request is around answering that question using common log analysis tools, where counting the number of actions using the event.verdict.action field is easy but interpreting the context around it to differentiate a drop from a drop+reset (a "reject") is much harder.

Introducing something like a rule-action field that would report consistently with the rule action might be a solution that would make the most sense for these users, or alternatively allowing action to be a list (of ["drop", "reset"]) might work although it would be a bit more cumbersome for both understanding and analysis.

Actions #3

Updated by Philippe Antoine about 1 month ago

  • Assignee changed from OISF Dev to Juliana Fajardini Reichow

Juliana, you are working on this verdict stuff, right ?

Actions #4

Updated by Juliana Fajardini Reichow 17 days ago

  • Target version changed from TBD to 9.0.0-beta1
  • Label Needs backport added
Actions #5

Updated by Juliana Fajardini Reichow 17 days ago

Philippe Antoine wrote in #note-3:

Juliana, you are working on this verdict stuff, right ?

Yep, initially, at least :)

Actions #6

Updated by Juliana Fajardini Reichow 17 days ago

  • Related to Bug #7544: Verdict output reports "alert" when traffic is allowed implicitly/passively added
Actions

Also available in: Atom PDF