It all started with a tweet by Stephane Clavel:
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.