Detect count 5044 v3.3 - #14346
Conversation
Also rename parse_uint_count as parse_multi_count This allows to prepare multi-buffers using this code
As for multi-integers, multi-buffers can now have the following arguments - count - nb - precise index - all Ticket: 5044
Ticket: 5044
Codecov Report❌ Patch coverage is Additional details and impacted files@@ Coverage Diff @@
## main #14346 +/- ##
==========================================
- Coverage 84.20% 84.18% -0.02%
==========================================
Files 1012 1013 +1
Lines 261769 261981 +212
==========================================
+ Hits 220415 220552 +137
- Misses 41354 41429 +75
Flags with carried forward coverage won't be shown. Click here to find out more. 🚀 New features to boost your workflow:
|
|
Information: QA ran without warnings. Pipeline = 28484 |
inashivb
left a comment
inashivb
left a comment
There was a problem hiding this comment.
Thank you, Philippe. This is great! :)
Q: Why do we need to create lists per mode? Can we not check the optional args corresponding to any multi buffer?
| if (prec->oob) { | ||
| // match as out of bounds |
There was a problem hiding this comment.
not following this. Why match if oob?
There was a problem hiding this comment.
This is an option. It is especially meant with negated content : we may want to match if 3rd buffer does not have "toto" or if there is no third buffer.
Does that answer your question ?
| if (arg) { | ||
| return DetectMultiSetup(de_ctx, s, arg); | ||
| } | ||
|
|
There was a problem hiding this comment.
and these updates will have to be done for all keywords?
There was a problem hiding this comment.
yes, hence the draft draft to get feedback about general design.
See TODOs in first comment :
- update doc if design is agreed
- add support for all multi-buf keywords
- add more tests
- rustfmt removes one line in mod.
| case DETECT_MULTI_NB: | ||
| if (!eof) { | ||
| DetectU32Data *du32 = (DetectU32Data *)smd->ctx; | ||
| if (du32->mode != DETECT_UINT_GTE && du32->mode != DETECT_UINT_GT) { |
There was a problem hiding this comment.
why can't we have other modes for number of matches?
There was a problem hiding this comment.
If I have a rule that matches if there are less than 10 http headers, I might get there in a case I have only 5 http headers, but I may receive more in the future (because !eof).
There was a problem hiding this comment.
ok. Why do we do a hasty inspection of multi buffers with count if they're not complete? Will this not lead to cases like http.header: all; to be evaluated needlessly only to find it can't match yet?
There was a problem hiding this comment.
Why do we do a hasty inspection of multi buffers with count if they're not complete?
It works if we want to see at least 5 http headers (DETECT_UINT_GTE and DETECT_UINT_GT)
For all case, we wait for eof, so this is good, right ?
I am not sure I understand your questions. |
Sorry for being unclear. We're registering 5 types of sm lists that we append the data to respectively as and when we encounter the keyword. |
Yes, I think we can indeed just register one and then have the options in it... I think this style comes from the fact that we may thus add easily |
|
rebased in #15100 |
3 participants
Link to ticket: https://redmine.openinfosecfoundation.org/issues/
https://redmine.openinfosecfoundation.org/issues/5044
Describe changes:
countoption to multi-buffers, behaving like a keyword but syntax isemail.received: count <3;instead ofemail.received; count: <3;all,all_or_absent,nb`, and precise indexingSV_BRANCH=OISF/suricata-verify#2634
Draft :
#14279 needed rebase, #14345 good branch rebased
TODOs :