Should Firewalls Track TCP Sequence Numbers?
It all started with a tweet by Stephane Clavel:
@ioshints @BradHedlund I'm puzzled NSX dFW does not track connections seq #. Still true? To me this is std fw feature.— stephaneclavel (@stephaneclavel) January 31, 2016
Trying to fit my response into the huge Twitter reply field I wrote “Tracking Seq# on FW should be mostly irrelevant with modern TCP stacks” and when Gal Sagie asked for more elaboration, I decided it’s time to write a blog post.
Some background first
I’m assuming you read my Spectrum of Firewall Statefulness blog post. In case you haven’t, please do it now. Don’t worry, I’ll wait.
Firewalls that include application level gateways (example: FTP command session inspection), web application firewalls (including stuff marketed as next-generation whatever) or any other devices that performs deep packet inspection have to include full-blown TCP stack including retransmissions, packet reordering and IP fragment reassembly. A device that doesn’t do all of the above will eventually be spoofed (aka Fernando Gont will eventually get you with the right sequence of extension headers).
In case you didn’t get the above reference, you REALLY SHOULD attend the IPv6 security summit @ Troopers 2016 and enjoy the talks by Fernando, Eric Vyncke and Enno Rey.
What about the devices called stateful firewalls that don’t do more than track incoming and outgoing TCP/UDP sessions? Should they do transport layer session inspection (including TCP sequence number tracking) or is that functionality becoming useless (as I claimed)?
Start with the threat model
Before discussing the number of angels dancing on this particular pin, let’s try to figure out what we’re trying to prevent (the threat):
- Intruder sits in the forwarding path (aka man-in-the-middle attack) ⇒ game over.
- Intruder can inspect the client-server traffic (passive probe) ⇒ game over.
- Intruder can hijack the client prefix ⇒ game over.
- Intruder blindly sends TCP packets hoping to disrupt the established TCP sessions. Interesting.
The first three scenarios cannot be detected or prevented with the TCP sequence number checks, because the intruder either sees the original sequence numbers or has the ability to impersonate the client.
TCP sequence number tracking can prevent the last scenario, and my argument was that the modern TCP stacks should be hardened enough to make that type of carpet bombing useless.
Asking an Expert
Anyway, I don’t know nearly enough about recent state of host TCP/IP stacks, so I asked around and Enno Rey (one of the masterminds behind Troopers and insinuator.net) quickly sent me his thoughts on the topic:
To the best of my knowledge pretty much all "traditional stateful firewalls" (all the Check Points, ASAs, Fortigates and the like) still check TCP sequence numbers. Most of them probably have some optimizations/accelerators/whatever to reduce the performance penalty you mention.
For the vast vast majority of traffic such devices process this is completely unnecessary.
There are some corner cases where (blind) injection of traffic into existing TCP sessions might be feasible and, more importantly, "interesting" from an attacker's perspective (e.g. remotely resetting BGP sessions) but those are usually not mitigated by this type of firewalls but other controls (as you as one of the authors of RFC 7454 know ;-).
I'm not aware of any pentest (even very network-/protocol-centric ones) we performed in the last 10 years where TCP spoofing/blind injection was used.
In my humble opinion checking TCP sequence numbers on stateful devices is based on an outdated threat model and unneeded in 2016 [I mean, attackers think in terms of cost/benefit ratio, too].
Methinks we can declare this particular horse dead and stop flogging it.
Actually, there is a study at University of Michigan (Ann Arbor) - http://web.eecs.umich.edu/~zhiyunq/pub/oakland12_TCP_sequence_number_inference.pdf - that explains how one can actually detect the current sequence range if firewall drops out of sequence packets.
On a side note, quite a few antiDDoS vendors use out-of-sequence TCP packet to check if the host is spoofed or not. And that works quite good comparing to traditional SYN cookie challenge.
In this population as measured in September 2015, we found: (1) 38.4% of systems tested were vulnerable to at least one blind in-window attack; (2) the in-window data attack is the most significant vulnerability, as 29.6% of systems accepted data with inadequate validation of the acknowledgment number; (3) systems that advertised a maximum segment size (MSS) of 1380 were almost never vulnerable to in-window reset and SYN packets (suggesting that middleboxes with this feature correctly filtered those suspicious packets) but incorrectly passed invalid in-window data packets, (4) in response to an in-window SYN, 1.1% of hosts established a parallel TCP connection using the same 4-tuple, which is unexpected behavior as a 4-tuple can only support a single TCP connection at any one time.