Snort mailing list archives
Re: Limits of Snort TCP reconstruction
From: Geoff Serrao via Snort-users <snort-users () lists snort org>
Date: Thu, 31 Aug 2017 14:58:59 -0400
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 muchlimited.Let's say the first limit reached is a limit of 5 segments. My attackstarts 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 heldfor 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 reconstructionTake 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 oftom.barbette () ulg ac be>wrote:Hi list, I read a lot of documentation, but it is still not clear to me what arethelimitations of the Snort TCP reconstruction. It seems that whencreating a rulewhich match on TCP payload, it will match the payload across multiplepackets.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, wouldSnortfail to match if ".*" is actually big enough? If someone can link me to some more documentation, or help meunderstand thelimits, 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 latestSnort 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!
Current thread:
- Limits of Snort TCP reconstruction tom . barbette (Aug 31)
- <Possible follow-ups>
- Re: Limits of Snort TCP reconstruction Al Lewis (allewi) via Snort-users (Aug 31)
- Re: Limits of Snort TCP reconstruction tom . barbette (Aug 31)
- Re: Limits of Snort TCP reconstruction Al Lewis (allewi) via Snort-users (Aug 31)
- Re: Limits of Snort TCP reconstruction Geoff Serrao via Snort-users (Aug 31)
- Re: Limits of Snort TCP reconstruction tom . barbette (Sep 01)
- Re: Limits of Snort TCP reconstruction Russ via Snort-users (Sep 01)
- Re: Limits of Snort TCP reconstruction tom . barbette (Aug 31)