[Snort-users] Limits of Snort TCP reconstruction

Geoff Serrao geoff.serrao at gmail.com
Thu Aug 31 14:58:59 EDT 2017


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

The internal footprint is the default flush point and can apply to streams
that do not fit in the other two categories.

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 that uses this option. I think this
footprint was more popular before PAF became a thing.

PAF stands for "protocol aware flushing" and as of 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.


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
> 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
> >> 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!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.snort.org/pipermail/snort-users/attachments/20170831/3efc8ac5/attachment.html>

More information about the Snort-users mailing list