Are there any good write ups on the effects on performance/throughput on normalizing the S-ACK option out at a firewall or IPS? I was trouble shooting some slow SMB2 file copy issues and saw that the SYN had the flag at the sender but by the time it gets to the destination the S-ACK options has been NOOP'd by a sourcefire IPS. I'd like to take something back to the security guys and try and convince them how stupid this is. asked 28 Feb '14, 11:28  RTJ10 |
2 Answers:
There is no such write up that I am aware of, but I could write one in my blog at a later time. Facts are
If your security guys do not believe me have them contact me and I'll convince them :-) answered 28 Feb '14, 11:48  Jasper ♦♦ showing 5 of 12 show 7 more comments |
hm.. While trying not the sound like a smartass, I 'sometimes' fail to do so ;-)) So, here we go... Software is full of bugs, and a TCP/IP implementation suffers from the same problem. So, people could come up with all kind of sick ideas to misuse the SACK feature, by sending wrong (forged) SACKs or whatever. If there is a bug in the TCP/IP stack, it could lead to almost anything, from a DoS, to a crash, to whatever you can think of. Actually, that's exactly what happened some (long) time ago.
Even Snort failed to handle SACKs in certain environments.
So, if you look at it this way, SACK did have a known relevance (years ago) when it comes to network security. Nevertheless, the problems of the year 2005 are not a valid/good reason to strip the SACK options today. I also believe it's somehow related to the TCP reassembling/buffering problem within the IDS scanner engine. However, I don't know snort/Sourcefire well enough to know why they might do that.
There is a normalizer preprocessor available for snort (and Sourcefire, I guess).
They say, it's helpful to enable it in inline mode, to minimize the chances of evasion. See also here: http://vrt-blog.snort.org/2010/11/inline-normalization-with-snort-290.html @RTJ10: Maybe the same holds true for your Sourcefire configuration. Regards answered 02 Mar '14, 08:41  Kurt Knochner ♦ edited 02 Mar '14, 08:49 @Kurt Knochner - Thank you very much for the comments and links! @Jasper Thank you as well! I will need to track down a public email for Laura and see if she'd be willing to share the PPS or presentation. (29 Apr '14, 06:42) RTJ10 |
I know I saw something by Laura Chappell about ASA's normalizing the S-ACK option out but I can't find the video on youtube, perhaps because she mentions it in passing and never did a presentation or writeup. :(
She presented that one two years ago on Sharkfest I think. I don't have a youtube link either, but it still doesn't make any sense to remove S-ACK options from packets. I think it is a result of the security devices not recognizing the option at all and dropping it for that reason. The vendors should get their TCP normalization engines up to speed and let those options pass.
No, they are doing it on purpose, here's a quote from my security guy:
"After reviewing your captures can see what you're referring to. Yes, we are normalizing TCP traffic across the Sourcefire sensors -- Unfortunately, turning Normalization off will severely impact inspection policies."
tell them to open a support case. Sourcefire needs to fix their "Normalization", which seems to be on the level of the last century.
Well, I passed on your comments to the security folks, I don't think I am very well loved ATM. :)
I bet they need to remove the S-ACK option to be able to search through the stream properly for matching policies, without buffering too much. After all, it's not a whole message but just segments, so they need to see the segments sequentially in order for match rules to work right. I doubt they want to have a large TCP buffer per connection/stream in their IDS to reassemble, and if they don't buffer, then they can't reassemble the stream properly if S-ACK is used; and even if they did buffer, it might be too late by then because the offending/bad segments already went by and will be accepted by the side they're trying to protect.
Wellll, not being an IPS/IDS guy...wouldn't that make sense on outside IPS/IDSs, but safe to turn off on inside devices so as to not negatively affect network performance in or across datacenters?
I'm not sure I understand what you mean... if it's crossing an IPS/IDS, presumably you want the IDS/IPS to apply its policies - otherwise why have it involved to begin with? If you're just talking about traffic between hosts on the private/internal side only, put their internal traffic on a separate network/vlan that the IDS/IPS ignores or isn't even in the path of. No?
Sorry @Hadriel, but S-ACK has no negative effect on buffering segments - on the contrary, it helps getting the complete payload reconstructed in case of packet loss as fast as possible for content inspection.
@Jasper: imagine you're an IDS/IPS receiving TCP segments that you need to reconstruct into a stream to run match policies against (regex or whatever). You currently have last processed TCP seq #3 and are waiting on #4. You see #5+6+7 come through. Do you (a) buffer those and wait for #4 some time later, or (b) drop them and force the far-end to resend them all again in sequence? If you choose (a), you're buffering for some time X. If you choose (b), you have to force S-ACK off, but you can avoid buffering quite a bit depending on the match policies logic. (but as I said, this is only a guess - I don't work for an IDS/IPS vendor)
Really, "force the far end to resend them all in sequence?" That is not a good strategy (to say it in a nice way), because it will delay the transmission a lot, plus nobody can guarantee that the "in sequence" will work the second time - there may be more packet loss or just out-of-orders, and you'll never complete the full transaction.
No, if an IDS/IPS is doing policy matching against TCP payloads it needs to gather (buffer) all segments until the payload is complete.
If it doesn't work the second (or third or whatever) time, your internet connection between host+server is so bad it doesn't matter much what happens. But anyway I didn't say it was a great strategy - I just said I bet that's why they do it. I could be wrong - maybe there's some other reason (aside from just not having implemented it yet type thing).