tests: showcase endswith, distance + within usage - v1 #2060
Conversation
Suricata docs state that `endswith` cannot be mixed with `offset`, `within` or `distance` for the same pattern, but apparently, at least from Suricata 7 on, this seems possible. Tests created based on material and scenarios provided by Brandon Murphy in the Redmine ticket. Related to Task #5030
| @@ -0,0 +1 @@ | |||
| alert tcp any any -> any any (msg:"Test"; content:"yYYYYYYYYYYYYYYYY"; distance:9; within:29; endswith; sid:1;) | |||
There was a problem hiding this comment.
I guess the tests are good, but yYYYYYYYYYYYYYYYY is not an easy pattern to read (like how many y ? )
Also, we could use a sticky buffer (such as a user agent) where we know the definite size (as opposed to a TCP stream)
We could then also add different signatures, like one with bsize to confirm the buffer size
And we could have one pcap with different flows having different user agents (lengths) to show the different cases
There was a problem hiding this comment.
Well, I guess my comments are nits and these tests are already better than the current state :-)
There was a problem hiding this comment.
I'm a bit confused by my own attempts at improving these tests. In the ticket discussion, it is said that in practice, distance and within can be used to limit how much of the payload is present, while still ensuring that the content is at the end of the payload. However, in the rule above, distance + within = 39, while the payload len is only 34, and we still get a match for that rule. So... While I still think it is important to properly document this, I'm not sure if there aren't things that I'm failing to grasp, or maybe even some small bug around this.
There was a problem hiding this comment.
hmm I'm reading your tests and Brandon's explanations as correct. Trying to explain below why.
it is said that in practice, distance and within can be used to limit how much of the payload is present
It can be. However, it is not the only use case. In order to have that limit properly, rule writer should use the correct values in these keywords.
distance + within = 39, while the payload len is only 34, and we still get a match for that rule.
distance + within == 38 here which is bigger than the payload length but the rule can be read as:
Part 1: "Starting at the 10th byte of the payload, find if the pattern exists anywhere within the next 29 bytes"
Part 2: "Ensure that if the pattern was found in the given limits, it falls at the end of the payload"
So, the engine tries to look for the pattern in the next 29 bytes starting at the 10th byte, it finds the pattern successfully midway (or runs out of bytes to look at as in this case), it stops looking further. Then, endswith ensures that the pattern was in fact the last part of the payload.
lmk wdyt?
There was a problem hiding this comment.
(true, 38, not 39, math is definitely not my forte xD )
I was interpreting these as you explained above, but then the payload size bit doesn't really count, right?
I mean, these keywords can be, used in combination, like what you've described, but the payload size won't really be "controlled" by them. Or am I missing some bit, still?
There was a problem hiding this comment.
I think I'm not following what do you expect as a part of the "control the payload len". Payload len comes from the traffic, we don't control it anyway, we can control w these rule keywords how much we want to look into the payload and from where. If you want full payload, sure, make sure the values for these keywords align w the full payload len..
There was a problem hiding this comment.
I think I was just misinterpreting what was present in the ticket discussion. Thanks for trying to enlighten me :P
Now, wrt the request for other test cases, my understanding from at least one of the examples on the ticket are precisely about situations where bsize can't be used... https://redmine.openinfosecfoundation.org/issues/5030#Example-2
|
Merged in #2097, thanks! |
Suricata docs state that
endswithcannot be mixed withoffset,withinordistancefor the same pattern, but apparently, at least from Suricata 7 on, this seems possible.Tests created based on material and scenarios provided by Brandon Murphy in the Redmine ticket.
Related to
Task #5030
As part of the effort to sift through good Outreachy tickets, I'm also trying to add a bit more context to explanation to some potential candidates. This one also seemed to make sense that we would have this showcased if we want to fix the docs, especially considering all the work done by Brandon.
Ticket
If your pull request is related to a Suricata ticket, please provide
the full URL to the ticket here so this pull request can monitor
changes to the ticket status:
Redmine ticket:
https://redmine.openinfosecfoundation.org/issues/5030