-
Notifications
You must be signed in to change notification settings - Fork 1.5k
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
detect: add ldap.request.option keyword - v1 #12321
base: master
Are you sure you want to change the base?
detect: add ldap.request.option keyword - v1 #12321
Conversation
ldap.request.operation matches on Lightweight Directory Access Protocol request operations It is an unsigned 8-bit integer Doesn't support prefiltering Ticket: OISF#7453
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #12321 +/- ##
==========================================
- Coverage 83.26% 83.24% -0.03%
==========================================
Files 912 913 +1
Lines 257643 257717 +74
==========================================
+ Hits 214521 214528 +7
- Misses 43122 43189 +67
Flags with carried forward coverage won't be shown. Click here to find out more. |
|
||
Syntax:: | ||
|
||
ldap.request.operation: operation; |
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.
Looking good from a brief overview! Would like other opinions on the name of the keyword. This looks good to me but perhaps too long?
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.
For info, this name comes from json schema
|
Please put the full clickable link to redmine ticket https://redmine.openinfosecfoundation.org/issues/7453 ;-) |
|
||
.. table:: **Operation values for ldap.request.operation keyword** | ||
|
||
==== ================================================ |
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.
When you implement ldap.response.operation, the same table should be used for both
ProtocolOp::ModDnRequest(_) => 12, | ||
ProtocolOp::ModDnResponse(_) => 13, | ||
ProtocolOp::CompareRequest(_) => 14, | ||
ProtocolOp::CompareResponse(_) => 15, |
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.
Do you know why is there a hole for 16, 17... ?
Maybe something that was implement in LDAP v1 and is obsolete in LDAP v3 but we should still recognize ?
ProtocolOp::ExtendedRequest(_) => 23, | ||
ProtocolOp::ExtendedResponse(_) => 24, | ||
ProtocolOp::IntermediateResponse(_) => 25, | ||
ProtocolOp::Unknown => 255, |
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.
This is not ideal
There should be some documentation at least
Or even better, we should have ProtocolOp::Unknown(u) => u.opcode,
but this may require big changes...
@@ -300,6 +300,34 @@ pub enum ProtocolOp { | |||
Unknown, | |||
} | |||
|
|||
impl ProtocolOp { |
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.
@jasonish what do you think about this rust code that works ?
G_LDAP_REQUEST_OPERATION_BUFFER_ID = DetectHelperBufferRegister( | ||
b"ldap.request.operation\0".as_ptr() as *const libc::c_char, | ||
ALPROTO_LDAP, | ||
false, |
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.
Please comment meaning of these true/false values
let ctx = cast_pointer!(ctx, DetectUintData<u8>); | ||
let option: u8 = match &tx.request { | ||
Some(request) => request.protocol_op.to_u8(), | ||
None => 0, |
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.
We should return 0, instead of having option=0
Otherwise, we match on ldap.request.operation: 0
for responses
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.
Better call rs_detect_u8_match(option, ctx)
only if let Some(request) = &tx.request{
and return 0 by default at the end of function
} | ||
let ctx = rs_detect_u8_parse(raw) as *mut c_void; | ||
if ctx.is_null() { | ||
return -1; |
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.
You can implement a protocol_op from_str
and call it there if rs_detect_u8_parse
fails
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.
Really good, you have a first code working :-)
Design seems good, a few bugs to fix, and you can expand on it with ldap.response.operation
Ticket: #7453
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/issues
Link to ticket: https://redmine.openinfosecfoundation.org/issues/7453
Description:
ldap.rs
static mut
topub(super) static mut
so I can use ALPROTO_LDAP on file ldap/detect.rsmod.rs
detect
types.rs
detect-engine-register.c
ScDetectLdapRegister()
detect.rs
ldap-keywords.rst
index.rst
ldap-keywords
SV_BRANCH=OISF/suricata-verify#2206