detect: add keywords for LDAPDN - v5#12634
Conversation
ldap.request.dn matches on LDAPDN from request operations This keyword maps the following eve fields: ldap.request.bind_request.name ldap.request.add_request.entry ldap.request.search_request.base_object ldap.request.modify_request.object ldap.request.del_request.dn ldap.request.mod_dn_request.entry ldap.request.compare_request.entry It is a sticky buffer Supports prefiltering Ticket: OISF#7471
ldap.responses.dn matches on LDAPDN from responses operations This keyword maps the following eve fields: ldap.responses[].search_result_entry.base_object ldap.responses[].bind_response.matched_dn ldap.responses[].search_result_done.matched_dn ldap.responses[].modify_response.matched_dn ldap.responses[].add_response.matched_dn ldap.responses[].del_response.matched_dn ldap.responses[].mod_dn_response.matched_dn ldap.responses[].compare_response.matched_dn ldap.responses[].extended_response.matched_dn It is a sticky buffer Supports prefiltering Ticket: OISF#7471
AkakiAlice
requested review from
a team,
jasonish,
jufajardini and
victorjulien
as code owners
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #12634 +/- ##
==========================================
- Coverage 80.77% 80.74% -0.03%
==========================================
Files 932 932
Lines 259286 259411 +125
==========================================
+ Hits 209437 209472 +35
- Misses 49849 49939 +90
Flags with carried forward coverage won't be shown. Click here to find out more. |
catenacyber
left a comment
catenacyber
left a comment
There was a problem hiding this comment.
Thanks for the work Alice
CI : ✅
Code : good
Commits segmentation : ok
Commit messages : good
Git ID set : looks fine for me
CLA : you already contributed
Doc update : thanks
Redmine ticket : ok
Rustfmt : good from your side, but rustfmt rust/src/ldap/*.rs gives a small change from Jason :-p
Tests : good
Dependencies added: none
| *buffer_len = 0; | ||
|
|
||
| let response = &tx.responses[local_id as usize]; | ||
| // We expect every response in one tx to be the same protocol_op |
There was a problem hiding this comment.
What about IntermediateResponse and SearchResultReference cases ?
There was a problem hiding this comment.
For Intermediate Response, we should find real pcaps with it to see how it happens
There was a problem hiding this comment.
And we also need a pcap with SearchResultReference
There was a problem hiding this comment.
(For me, the PR is good, but I would like to better test/investigate/understand these cases)
|
Merged in #12653, thanks! |
|
Thanks Alice for your first sticky buffer |
3 participants
Ticket: #7471
Contribution style:
https://docs.suricata.io/en/latest/devguide/contributing/contribution-process.html
Our Contribution agreements:
https://suricata.io/about/contribution-agreement/ (note: this is only required once)
Changes (if applicable):
(including schema descriptions)
https://redmine.openinfosecfoundation.org/projects/suricata/issues7471
Link to ticket: https://redmine.openinfosecfoundation.org/issues/7471
Description:
ldap.request.dnandldap.responses.dnChanges:
nit:commits todoc:SV_BRANCH=OISF/suricata-verify#2303
Previous PR: #12620