Bug #5076
openkeyword content does not work over reassembled TCP
Description
Using rulealert ip any any -> any any (content:"HTTP/2.loc"; sid:11;)
on attached pcap
with stream.reassembly.toserver-chunk-size=25
does not trigger an alert
It does trigger the alert without the setting.
I fear we might have an evasion if I split the packets over the default value of 2560...
Updated by Philippe Antoine over 3 years ago
This was found during investigation of #4858
Updated by Jeff Lucovsky over 3 years ago
- Copied to Bug #5110: keyword content does not work over reassembled TCP (6.0.x backport) added
Updated by Jeff Lucovsky over 3 years ago
- Copied to Bug #5111: keyword content does not work over reassembled TCP (5.0.x backport) added
Updated by Philippe Antoine almost 3 years ago
From talk with Victor, this is a known limitation, where the chunk size is supposed to be a bit random to protect against evasion attempts.
The solution may be to use hyperscan as a streaming engine (instead of running it on different chunks/blocks)
Updated by Philippe Antoine almost 3 years ago
- Related to Documentation #2470: document content inspection in chunks added
Updated by Victor Julien over 2 years ago
- Target version changed from 7.0.0-beta1 to 8.0.0-beta1
Updated by Philippe Antoine over 2 years ago
- Related to Task #4431: libsuricata: Example showing libsuricata as a replacement for libnids (network grep) added
Updated by Philippe Antoine about 1 year ago
I think this one can be postponed after 8
Updated by Victor Julien 3 months ago
- Target version changed from 8.0.0-beta1 to 8.0.0-rc1
Updated by Philippe Antoine 16 days ago
- Target version changed from 8.0.0-rc1 to 9.0.0-beta1
Updated by Shivani Bhardwaj 15 days ago
The solution may be to use hyperscan as a streaming engine (instead of running it on different chunks/blocks)
nice!
I was recently studying this part and realized that just keeping the match window flexible while giving it to prefilter may also work.
e.g.
content to be matched: "SURICATA"
current inspection window "AAAAAAAAAAAAAAAAABATATASURI" -> MPM will find no possible matches against the pattern for the given rule(s)
next inspection window: "CATAMMMMMMMM"
result: no match
However, if we calculated the length of the biggest pattern (usually already tracked and auto used as fast pattern), we could ask MPM to go backwards/forwards by that length in the window.
So, instead of discarding the current inspection window when no matches were found,
we keep 8 bytes from the end, when the next inspection window comes, we send "TATASURICATAMMMMMMMM" to the MPM and voila! there's a possible match!
There are some things around this that'll have to be thought through though.
Lmk wdyt?