detect/filestore: fix options handling and impact #12312
+83
−18
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
In the commit, use so our tracking can work (and the leaderboard counts them) |
|
Information: QA ran without warnings. Pipeline 24034 |
|
SV_REPO=OISF/suricata-verify#2202 Should be using |
The filestore keyword had an influence on the signature matching when it should not. For example, if Suricata is analysing a traffic with a GET http request to uri /example and have the 2 following signatures loaded: alert http any any -> any any (msg:"ex"; http.uri; content:"/example"; sid:1; rev:1;) alert http any any -> any any (msg:"ex"; http.uri; content:"/example"; filestore; sid:2; rev:1;) then the first signature will match and the second one will not. Also the options of filestore were not honored correctly. A signature like: alert http any any -> any any (msg:"ex"; http.uri; content:"/example"; filestore:to_client,tx; sid:2; rev:1;) was not storing the file in the answer to the request. This patch updates the logic in filestore keyword handling to fix the problems. The patch first makes sure that a signature with filestore will hit even if there is no file in the current application layer context. Then the patch makes sure that postmatch handles the different options correctly. As filestore keyword is not anymore preventing a match, we need to update some unit tests that were using this "feature". Ticket: 7356 Ticket: 7357
regit
force-pushed
the
7357-filestore-keyword-v3.0
branch
from
162dafb to
e1a4441
Compare
Done, thanks for the check. |
|
Information: QA ran without warnings. Pipeline 24041 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Update of #12176
The filestore keyword had an influence on the signature matching when it should not. For example, if Suricata is analysing a traffic with a GET http request to uri /example and have the 2 following signatures loaded:
alert http any any -> any any (msg:"ex"; http.uri; content:"/example"; sid:1; rev:1;) alert http any any -> any any (msg:"ex"; http.uri; content:"/example"; filestore; sid:2; rev:1;)
then the first signature will match and the second one will not.
Also the options of filestore were not honored correctly. A signature like:
alert http any any -> any any (msg:"ex"; http.uri; content:"/example"; filestore:to_client,tx; sid:2; rev:1;)
was not storing the file in the answer to the request.
This patch updates the logic in filestore keyword handling to fix the problems.
The patch first makes sure that a signature with filestore will hit even if there is no file in the current application layer context. Then the patch makes sure that postmatch handles the different options correctly.
As filestore keyword is not anymore preventing a match, we need to update some unit tests that were using this "feature".
Tickets: 7356 7357
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/7357
Describe changes:
SV_BRANCH=OISF/suricata-verify#2202