[Snort-users] Limits of Snort TCP reconstruction

Russ rucombs at cisco.com
Fri Sep 1 08:36:59 EDT 2017


Yep, on the Snort++ roadmap.

On 9/1/17 3:35 AM, tom.barbette at ulg.ac.be wrote:
> Hi Geoff,
>
> Thanks for this very extensive review.
>
> I understand why I was a little lost. I always assumed some DFA state was kept between (smaller) windows. Has this already been considered/studied? It would avoid evasion techniques and allow to flush more often. Of course it wouldn't work with back-tracking.
>
> Tom
>
> ----- Mail original -----
>> De: "Geoff Serrao" <geoff.serrao at gmail.com>
>> À: "Al Lewis (allewi)" <allewi at cisco.com>
>> Cc: "tom barbette" <tom.barbette at ulg.ac.be>, snort-users at lists.snort.org
>> Envoyé: Jeudi 31 Août 2017 20:58:59
>> Objet: Re: [Snort-users] Limits of Snort TCP reconstruction
>> Tom,
>>
>> Snort has the ability to reassemble individual TCP packets into a much
>> larger TCP "psuedo-packet" which is run through the fast pattern matcher
>> and then the rest of the detection engine.
>>
>> There are many different important factors that influence the size of a
>> rebuilt TCP psuedo-packet, stream5 policy and pre-ack post-ack mode to name
>> a couple, but flush types is in my experience a good place to start in
>> understanding how stream determines max rebuilt TCP psuedo-packet sizes:
>>
>> The expected size of a rebuilt psuedo-packet by the stream preprocessor is
>> called a stream "footprint" and is determined by which flush type the TCP
>> session falls under (check
>> out src/preprocessors/Stream6/snort_stream_tcp.c):
>>
>>   250 // flush types
>>   251 #define STREAM_FT_INTERNAL  0  // normal s5 "footprint"
>>   252 #define STREAM_FT_EXTERNAL  1  // set by other preprocessor
>>   253 #define STREAM_FT_PAF_MAX   2  // paf_max + footprint fp
>>
>> STREAM_FT_INTERNAL
>> The internal footprint is the default flush point and can apply to streams
>> that do not fit in the other two categories.
>>
>> STREAM_FT_EXTERNAL
>> External footprints allow a preprocessor which registered for a stream
>> reassembling port to decide based on it's analysis of the TCP session data
>> to set the footprint size. The rpc_decode preprocessor was the only
>> preprocessor I found in 2.9.9.9 that uses this option. I think this
>> footprint was more popular before PAF became a thing.
>>
>> STREAM_FT_PAF_MAX
>> PAF stands for "protocol aware flushing" and as of 2.9.9.9 most protocols
>> that have a matching snort network preprocessor leverage this footprint
>> size (HTTP, SMTP, SIP, POP, IMAP, Modbus, FTP, DNS, DNP3, DCERPC). Simply
>> put, these protocols have special PAF handler functions that stream5 calls
>> periodically in order to get an update on whether that preprocessor is
>> ready to flush this particular stream.
>>
>> When a PAF handler is deciding whether or not signal to stream5 to flush,
>> it will use protocol specific indications that most or all of a protocol
>> PDU is within the reassembly window and flushing would be optimal for
>> detection (eg. for an HTTP client request HTTP PAF will try to signal a PAF
>> flush when the HTTP verb, url, protocol, headers and any client body if it
>> exists have been seen). See this blog post by Russ describing PAF when it
>> was first introduced: http://blog.snort.org/2011/09/what-is-paf.html
>>
>> The config option paf_max in the snort conf sets an upper byte limit that
>> stream5 is willing to reassemble before overriding the PAF handler and
>> flushing the rebuilt stream to the detection engine. This upper limit is
>> important since without one an attacker could take advantage of a forever
>> reassembling, but never flushing, stream5.
>>
>> Just like the rest of the flush points, PAF flush points tend to be
>> "fuzzy", which means the exact number of bytes can vary in order to prevent
>> an attacker from simply straddling the exploit across a flush boundary and
>> evading a rule.
>>
>> Those are the basics in deciding flush footprint size.
>>
>> Snort gurus please jump in if this doesn't seem like an accurate summary or
>> could be improved.
>>
>> Thanks!
>>
>> On Thu, Aug 31, 2017 at 10:59 AM, Al Lewis (allewi) via Snort-users <
>> snort-users at lists.snort.org> wrote:
>>
>>> If the limit is reached and its not found.. I wouldn’t expect to see an
>>> alert.
>>>
>>> The size of the data held can be set and should be explained in the readme.
>>>
>>>
>>>
>>> Albert Lewis
>>> ENGINEER.SOFTWARE ENGINEERING
>>> SOURCEfire, Inc. now part of Cisco
>>> Email: allewi at cisco.com
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> On 8/31/17, 10:55 AM, "tom.barbette at ulg.ac.be" <tom.barbette at ulg.ac.be>
>>> wrote:
>>>
>>>> Hi Albert,
>>>>
>>>> Thanks for your quick answer. However this documentation is very much
>>> limited.
>>>> Let's say the first limit reached is a limit of 5 segments. My attack
>>> starts at segment 5. As the limit is reached, it is not found. Then segment
>>> 6 arrives with the end of the attack. What happens?
>>>> I specifically consider inline mode. I guess the stream will not be held
>>> for the default max window of 65536 << 14 bytes, right?
>>>> Thanks,
>>>> Tom
>>>>
>>>>
>>>> ----- Mail original -----
>>>>> De: "Al Lewis (allewi)" <allewi at cisco.com>
>>>>> À: "tom barbette" <tom.barbette at ulg.ac.be>, snort-users at lists.snort.org
>>>>> Envoyé: Jeudi 31 Août 2017 16:44:20
>>>>> Objet: Re: [Snort-users] Limits of Snort TCP reconstruction
>>>>> Take a look at the README.stream5 included in the download.
>>>>>
>>>>>
>>>>>
>>>>> Albert Lewis
>>>>> ENGINEER.SOFTWARE ENGINEERING
>>>>> SOURCEfire, Inc. now part of Cisco
>>>>> Email: allewi at cisco.com
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On 8/31/17, 10:37 AM, "Snort-users on behalf of tom.barbette at ulg.ac.be"
>>>>> <snort-users-bounces at lists.snort.org on behalf of
>>> tom.barbette at ulg.ac.be>
>>>>> wrote:
>>>>>
>>>>>> Hi list,
>>>>>>
>>>>>> I read a lot of documentation, but it is still not clear to me what are
>>> the
>>>>>> limitations of the Snort TCP reconstruction. It seems that when
>>> creating a rule
>>>>>> which match on TCP payload, it will match the payload across multiple
>>> packets.
>>>>>> But what's the limit in term of number of packets here?
>>>>>>
>>>>>> E.g. If I want to match on "<script>.*</script>" in HTTP payload, would
>>> Snort
>>>>>> fail to match if ".*" is actually big enough?
>>>>>>
>>>>>> If someone can link me to some more documentation, or help me
>>> understand the
>>>>>> limits, that would be great.
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> Tom
>>>>>> _______________________________________________
>>>>>> Snort-users mailing list
>>>>>> Snort-users at lists.snort.org
>>>>>> Go to this URL to change user options or unsubscribe:
>>>>>> https://lists.snort.org/mailman/listinfo/snort-users
>>>>>>
>>>>>> Please visit http://blog.snort.org to stay current on all the latest
>>> Snort news!
>>> _______________________________________________
>>> Snort-users mailing list
>>> Snort-users at lists.snort.org
>>> Go to this URL to change user options or unsubscribe:
>>> https://lists.snort.org/mailman/listinfo/snort-users
>>>
>>> Please visit http://blog.snort.org to stay current on all the latest
>>> Snort news!
> _______________________________________________
> Snort-users mailing list
> Snort-users at lists.snort.org
> Go to this URL to change user options or unsubscribe:
> https://lists.snort.org/mailman/listinfo/snort-users
>
> Please visit http://blog.snort.org to stay current on all the latest Snort news!




More information about the Snort-users mailing list