-
Notifications
You must be signed in to change notification settings - Fork 1.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
output/eve: add 'verdict' field to 'alert' and 'drop' events - v9 #9216
Conversation
Related to Bug OISF#5464
Related to Bug OISF#5464
The `field action` portion seemed to be comprised of a more generic section that followed it. Also formatted the section for lines to be within the character limit.
If packet->action is never set to 'pass', we won't know if a packet had a 'pass' verdict. Related to Bug OISF#5464
Codecov Report
Additional details and impacted files@@ Coverage Diff @@
## master #9216 +/- ##
==========================================
+ Coverage 82.36% 82.39% +0.03%
==========================================
Files 968 968
Lines 273761 273803 +42
==========================================
+ Hits 225470 225612 +142
+ Misses 48291 48191 -100
Flags with carried forward coverage won't be shown. Click here to find out more. |
Information: QA ran without warnings. Pipeline 15124 |
@@ -416,6 +416,7 @@ void PacketAlertFinalize(DetectEngineCtx *de_ctx, DetectEngineThreadCtx *det_ctx | |||
|
|||
/* pass "alert" found, we're done */ | |||
if (pa->action & ACTION_PASS) { | |||
p->action |= ACTION_PASS; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
hmm we had done quite a nice cleanup before, removing the flag from the Packet::action
. Since it is only for logging, I wonder if we can keep it out of this field to make clear it's not used otherwise.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
hmm we had done quite a nice cleanup before, removing the flag from the
Packet::action
. Since it is only for logging, I wonder if we can keep it out of this field to make clear it's not used otherwise.
Would it make sense to have a field for the verdict itself? I can try to access the last packet alert in the queue, which should be the one with the pass rule... 🤔
That last "empty" alert to just log verdict feels wrong to me. Maybe this is where we'd use the verdict event type. |
Will update the SV tests that are currently failing with windows, I think I inadvertently removed a requires:
features:
- LIBNET1.1 That must be there when we use |
Trying a different approach for the empty alert: #9220 |
Link to redmine ticket:
https://redmine.openinfosecfoundation.org/issues/5464
Previous PR: #9162
Describe changes from previous PR:
verdict.action: pass
never showed upverdict.reject
verdict.reject
an array instead of a string (json)OISF/suricata-verify#1308
Some output samples: