-
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/sip: add sticky buffers to match headers v4 #11330
Conversation
A stub file has been added to implement the sticky buffers for SIP headers. Ticket OISF#6374
According to RFC 3261, a single header can be repeated one or more times, and its name can also be specified using the 'compact form.' This patch updates the hashmap used for storing headers to accommodate multiple values instead of just one. Additionally, if a header name is defined in the compact form, it is expanded into its long form (i.e., the standard name). This conversion simplifies the logic for matching a given header and ensures 1:1 parity with keywords. Ticket OISF#6374
To match on response SIP headers, those headers must be stored. Ticket OISF#6374
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #11330 +/- ##
==========================================
- Coverage 82.41% 82.41% -0.01%
==========================================
Files 934 942 +8
Lines 247239 247376 +137
==========================================
+ Hits 203773 203875 +102
- Misses 43466 43501 +35
Flags with carried forward coverage won't be shown. Click here to find out more. |
Thanks Giuseppe, quick remark : you can now have this in pure rust |
I saw your commit about rust keywords merged but I have a question: |
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.
Thanks for the work :-)
This PR needs a rebase
- CI : 🟢
- Code : checking now
- Commits segmentation : I would squash some together
- Commit messages : ok for me
- Git ID set : looks fine for me
- CLA : you already contributed
- Doc update : looks fine
- Redmine ticket : ok
- Rustfmt : ok
- Tests : SV ok
- Dependencies added: none
|
||
void RegisterSipHeadersVia(void) | ||
{ | ||
DetectSipHeadersRegisterStub(); |
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 do them in rust now
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.
Am I wrong, or has your PR for multibuffer keywords in rust not been merged yet?
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.
It has been merged today :-)
@@ -97,6 +97,22 @@ fn is_header_value(b: u8) -> bool { | |||
is_alphanumeric(b) || is_token_char(b) || b"\"#$&(),/;:<=>?@[]{}()^|~\\\t\n\r ".contains(&b) | |||
} | |||
|
|||
fn expand_header_name(h: &str) -> &str { | |||
match h { | |||
"i" => "Call-ID", |
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.
Can we detect if some header uses the short or long form ?
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.
Why should we detect that?
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.
To get the most expressivity.
I do no say we should do that, I just asked if we can.
I guess this deserves some mention in the docs., like
This keyword matches on the From field that can be present in SIP headers.
It matches both short and regular form, and these forms cannot be distinguished by this 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.
I'm not sure I understand what you mean. If a header uses the short form, it is 'expanded' ( converted to the long form) to enable matching in both cases with its related sticky buffer.
If this is what you are referring to, it has already been implemented.
If not, I'm unclear on what you mean by 'detecting which form is used by a header.'
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.
I meant 2 things :
If a header uses the short form, it is 'expanded' ( converted to the long form) to enable matching in both cases with its related sticky buffer.
-
This should be in the docs
-
And the doc should also mention that there is only the normalized form, not the raw one (as we can have for http uri for instance where there are 2 keywords)
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.
I meant 2 things :
If a header uses the short form, it is 'expanded' ( converted to the long form) to enable matching in both cases with its related sticky buffer.
1. This should be in the docs 2. And the doc should also mention that there is only the normalized form, not the raw one (as we can have for http uri for instance where there are 2 keywords)
+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.
I only have a nit comment for the copyright year change in sip/detect.rs
, but do agree with Philippe's comment that we should mention in the docs about the headers being normalized :)
@@ -1,4 +1,4 @@ | |||
/* Copyright (C) 2019 Open Information Security Foundation | |||
/* Copyright (C) 2024 Open Information Security Foundation |
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.
nit: when updating copyright years, we add the current year beside the initial one:
/* Copyright (C) 2024 Open Information Security Foundation | |
/* Copyright (C) 2019-2024 Open Information Security Foundation |
Replaced with #11620 |
Make sure these boxes are signed before submitting your Pull Request -- thank you.
https://docs.suricata.io/en/latest/devguide/contributing/contribution-process.html
https://suricata.io/about/contribution-agreement/ (note: this is only required once)
https://redmine.openinfosecfoundation.org/projects/suricata/issues
(if applicable)
Link to ticket: https://redmine.openinfosecfoundation.org/issues/
https://redmine.openinfosecfoundation.org/issues/6374
Describe changes:
SV_BRANCH=OISF/suricata-verify#1926