[Snort-users] Limits of Snort TCP reconstruction

tom.barbette at ulg.ac.be tom.barbette at ulg.ac.be
Fri Sep 1 03:35:20 EDT 2017


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!



More information about the Snort-users mailing list