Project

General

Profile

Actions

Bug #5076

open

keyword content does not work over reassembled TCP

Added by Philippe Antoine over 3 years ago. Updated 15 days ago.

Status:
New
Priority:
Normal
Assignee:
Target version:
Affected Versions:
Effort:
Difficulty:
Label:

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...


Subtasks 2 (0 open2 closed)

Bug #5110: keyword content does not work over reassembled TCP (6.0.x backport)RejectedVictor JulienActions
Bug #5111: keyword content does not work over reassembled TCP (5.0.x backport)RejectedActions

Related issues 2 (2 open0 closed)

Related to Suricata - Documentation #2470: document content inspection in chunksFeedbackEric UrbanActions
Related to Suricata - Task #4431: libsuricata: Example showing libsuricata as a replacement for libnids (network grep)In ReviewPhilippe AntoineActions
Actions #2

Updated by Philippe Antoine over 3 years ago

This was found during investigation of #4858

Actions #5

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
Actions #6

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
Actions #7

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)

Actions #8

Updated by Victor Julien almost 3 years ago

  • Label deleted (Needs backport)
Actions #9

Updated by Philippe Antoine almost 3 years ago

Actions #10

Updated by Victor Julien over 2 years ago

  • Target version changed from 7.0.0-beta1 to 8.0.0-beta1
Actions #11

Updated by Philippe Antoine over 2 years ago

  • Related to Task #4431: libsuricata: Example showing libsuricata as a replacement for libnids (network grep) added
Actions #12

Updated by Philippe Antoine about 1 year ago

I think this one can be postponed after 8

Actions #15

Updated by Victor Julien 3 months ago

  • Target version changed from 8.0.0-beta1 to 8.0.0-rc1
Actions #16

Updated by Philippe Antoine 16 days ago

  • Target version changed from 8.0.0-rc1 to 9.0.0-beta1
Actions #17

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?

Actions

Also available in: Atom PDF