Detect multiprotocol keywords 7304 v1 #12149
Conversation
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #12149 +/- ##
==========================================
+ Coverage 49.81% 49.84% +0.03%
==========================================
Files 909 909
Lines 257904 258003 +99
==========================================
+ Hits 128467 128610 +143
+ Misses 129437 129393 -44
Flags with carried forward coverage won't be shown. Click here to find out more. |
|
Information: QA ran without warnings. Pipeline 23517 |
such as ja4 Ticket: 7304
instead of hardcoding list Ticket: 7304
catenacyber
force-pushed
the
detect-multiprotocol-keywords-7304-v1
branch
from
db18fe8 to
7f018f5
Compare
| "ja4.hash; content: \"q13d0310h3_55b375c5d22e_cd85d2d88918\";)"); | ||
| // just ja4.hash any proto | ||
| FAIL_IF_NULL(s); | ||
| s = SigInit(de_ctx, "alert quic any any -> any any (sid: 1; " |
There was a problem hiding this comment.
this adds another sid:1, is that not rejected as a duplicate? Or do we only check later? Might be good to use unique id's for all sigs, but esp for the good ones
There was a problem hiding this comment.
We only do SigInit to check parsing result ;-)
We should free the valid ones I guess...
|
I'm missing a lot of explanation on the new logic. |
Motivation is to have a cleaner support for multi-protocol keywords such as JA3 both on QUIC and TLS. From the keyword point of view, I propose to add From the data structure, I propose to add a fixed-length array in SignatureInitData, as the use case is a sparse number of protocols, not taking half of the 32 protocols we support... |
|
Information: QA ran without warnings. Pipeline 23609 |
|
Next in #12229 |
Link to ticket: https://redmine.openinfosecfoundation.org/issues/
https://redmine.openinfosecfoundation.org/issues/7304
Describe changes:
Is there something to do with DCERPC/SMB stuff ?
I think file keywords have their own logic and it is ok.