Re: Limits of Snort TCP reconstruction

[tom.barbette () ulg ac be]

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 () gmail com>
> À: "Al Lewis (allewi)" <allewi () cisco com>
> Cc: "tom barbette" <tom.barbette () ulg ac be>, snort-users () 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 () 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 () cisco com
> >
> >
> >
> >
> >
> >
> >
> > On 8/31/17, 10:55 AM, "tom.barbette () ulg ac be" <tom.barbette () 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 () cisco com>
> > > > À: "tom barbette" <tom.barbette () ulg ac be>, snort-users () 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 () cisco com
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > On 8/31/17, 10:37 AM, "Snort-users on behalf of tom.barbette () ulg ac be"
> > > > <snort-users-bounces () lists snort org on behalf of
> > tom.barbette () 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 () 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 () 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 () 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!