Bug #7392
openVerdict output reports "drop" when rejected
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"
]
}
Updated by Victor Julien about 1 month 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?
Updated by Jamie Lavigne about 1 month 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.