However, if you actually test it, it will be affected.
It is detected when distance is 2 and within is 4, but is not detected when distance is 0 and within is 4.
Hi, we did run into the same question and found this old thread.
According to the docs, within ‘is relative to the preceding match‘ [1]. There is no word about whether distance is included or not.
Therefore we assume that the last graphic [2] maybe is not fully correct, because the pink within-pointer points between f-g because of within: 4 depending on the end of the previous content. But it should instead point between g-h, because it does include the distance keyword! So in the graphic, even a distance:1; within:3; should be a match.
We did a short test with the rules and the PCAP attached (Suricata v8.0.3, Debian unstable). It contains a UNIX ping having some payload “ABCDEFGHI…”.
Signature 5 uses content:"ABC"; content:"EFG"; distance:1; within:3; which should not fire, according to the docs, because within: 3 only would include “DEF”, but not “EFG“. But this rule does fire in our test! So our assumption seems to be correct.
This leads me to the following question: What is the intended behaviour of the within keyword? Should it start searching beginning at the distance from the previous content match or should it start directly after the previous match?
Assuming the current Suricata code/behaviour is correct, we should probably correct the graphic and move the pink within-pointer between g-h. If you agree, I can try to do some merge request fixing that.
