<div dir="ltr"><div>Tom, </div><div><br></div>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. <div><br></div><div>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: </div><div><br></div><div>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):</div><div><br></div><div><div>  250 // flush types</div><div>  251 #define STREAM_FT_INTERNAL  0  // normal s5 "footprint"</div><div>  252 #define STREAM_FT_EXTERNAL  1  // set by other preprocessor</div><div>  253 #define STREAM_FT_PAF_MAX   2  // paf_max + footprint fp</div></div><div><br></div><div>STREAM_FT_INTERNAL<br></div><div>The internal footprint is the default flush point and can apply to streams that do not fit in the other two categories. </div><div><br></div><div>STREAM_FT_EXTERNAL<br></div><div>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.</div><div><br></div><div>STREAM_FT_PAF_MAX<br></div><div>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. </div><div><br></div><div>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: <a href="http://blog.snort.org/2011/09/what-is-paf.html">http://blog.snort.org/2011/09/what-is-paf.html</a></div><div><br></div><div>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. </div><div><br></div><div>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.  </div><div><br></div><div>Those are the basics in deciding flush footprint size.</div><div><br></div><div>Snort gurus please jump in if this doesn't seem like an accurate summary or could be improved. </div><div><br>Thanks!</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Aug 31, 2017 at 10:59 AM, Al Lewis (allewi) via Snort-users <span dir="ltr"><<a href="mailto:snort-users@lists.snort.org" target="_blank">snort-users@lists.snort.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">If the limit is reached and its not found.. I wouldn’t expect to see an alert.<br>
<br>
The size of the data held can be set and should be explained in the readme.<br>
<span class="im HOEnZb"><br>
<br>
<br>
Albert Lewis<br>
ENGINEER.SOFTWARE ENGINEERING<br>
SOURCEfire, Inc. now part of Cisco<br>
Email: <a href="mailto:allewi@cisco.com">allewi@cisco.com</a><br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
</span><div class="HOEnZb"><div class="h5">On 8/31/17, 10:55 AM, "<a href="mailto:tom.barbette@ulg.ac.be">tom.barbette@ulg.ac.be</a>" <<a href="mailto:tom.barbette@ulg.ac.be">tom.barbette@ulg.ac.be</a>> wrote:<br>
<br>
>Hi Albert,<br>
><br>
>Thanks for your quick answer. However this documentation is very much limited.<br>
><br>
>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?<br>
><br>
>I specifically consider inline mode. I guess the stream will not be held for the default max window of 65536 << 14 bytes, right?<br>
><br>
>Thanks,<br>
>Tom<br>
><br>
><br>
>----- Mail original -----<br>
>> De: "Al Lewis (allewi)" <<a href="mailto:allewi@cisco.com">allewi@cisco.com</a>><br>
>> À: "tom barbette" <<a href="mailto:tom.barbette@ulg.ac.be">tom.barbette@ulg.ac.be</a>>, <a href="mailto:snort-users@lists.snort.org">snort-users@lists.snort.org</a><br>
>> Envoyé: Jeudi 31 Août 2017 16:44:20<br>
>> Objet: Re: [Snort-users] Limits of Snort TCP reconstruction<br>
><br>
>> Take a look at the README.stream5 included in the download.<br>
>><br>
>><br>
>><br>
>> Albert Lewis<br>
>> ENGINEER.SOFTWARE ENGINEERING<br>
>> SOURCEfire, Inc. now part of Cisco<br>
>> Email: <a href="mailto:allewi@cisco.com">allewi@cisco.com</a><br>
>><br>
>><br>
>><br>
>><br>
>><br>
>><br>
>><br>
>><br>
>> On 8/31/17, 10:37 AM, "Snort-users on behalf of <a href="mailto:tom.barbette@ulg.ac.be">tom.barbette@ulg.ac.be</a>"<br>
>> <<a href="mailto:snort-users-bounces@lists.snort.org">snort-users-bounces@lists.<wbr>snort.org</a> on behalf of <a href="mailto:tom.barbette@ulg.ac.be">tom.barbette@ulg.ac.be</a>><br>
>> wrote:<br>
>><br>
>>>Hi list,<br>
>>><br>
>>>I read a lot of documentation, but it is still not clear to me what are the<br>
>>>limitations of the Snort TCP reconstruction. It seems that when creating a rule<br>
>>>which match on TCP payload, it will match the payload across multiple packets.<br>
>>>But what's the limit in term of number of packets here?<br>
>>><br>
>>>E.g. If I want to match on "<script>.*</script>" in HTTP payload, would Snort<br>
>>>fail to match if ".*" is actually big enough?<br>
>>><br>
>>>If someone can link me to some more documentation, or help me understand the<br>
>>>limits, that would be great.<br>
>>><br>
>>>Thanks,<br>
>>><br>
>>>Tom<br>
>>>___________________________<wbr>____________________<br>
>>>Snort-users mailing list<br>
>>><a href="mailto:Snort-users@lists.snort.org">Snort-users@lists.snort.org</a><br>
>>>Go to this URL to change user options or unsubscribe:<br>
>>><a href="https://lists.snort.org/mailman/listinfo/snort-users" rel="noreferrer" target="_blank">https://lists.snort.org/<wbr>mailman/listinfo/snort-users</a><br>
>>><br>
>> >Please visit <a href="http://blog.snort.org" rel="noreferrer" target="_blank">http://blog.snort.org</a> to stay current on all the latest Snort news!<br>
______________________________<wbr>_________________<br>
Snort-users mailing list<br>
<a href="mailto:Snort-users@lists.snort.org">Snort-users@lists.snort.org</a><br>
Go to this URL to change user options or unsubscribe:<br>
<a href="https://lists.snort.org/mailman/listinfo/snort-users" rel="noreferrer" target="_blank">https://lists.snort.org/<wbr>mailman/listinfo/snort-users</a><br>
<br>
Please visit <a href="http://blog.snort.org" rel="noreferrer" target="_blank">http://blog.snort.org</a> to stay current on all the latest Snort news!<br>
</div></div></blockquote></div><br></div>