Optimization #5076
open
keyword content does not work over reassembled TCP
Added by Philippe Antoine over 3 years ago.
Updated 4 days ago.
Description
Using rule
alert 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...
Related issues
3 (3 open — 0 closed)
This was found during investigation of #4858
- Copied to Bug #5110: keyword content does not work over reassembled TCP (6.0.x backport) added
- Copied to Bug #5111: keyword content does not work over reassembled TCP (5.0.x backport) added
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)
- Label deleted (
Needs backport)
- Target version changed from 7.0.0-beta1 to 8.0.0-beta1
- Related to Task #4431: libsuricata: Example showing libsuricata as a replacement for libnids (network grep) added
I think this one can be postponed after 8
- Target version changed from 8.0.0-beta1 to 8.0.0-rc1
- Target version changed from 8.0.0-rc1 to 9.0.0-beta1
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?
- Tracker changed from Bug to Optimization
- Affected Versions deleted (
6.0.4)
- Related to Task #7743: http: trigger raw stream inspection added
Just to bring some precisions : there is indeed a link to #7743 but this ticket is not specially about HTTP, just TCP (with an unknown protocol for instance) see #1598
Also available in: Atom
PDF