Build the Next-Generation Data Center
6 week online course starting in spring 2017

Should Firewalls Track TCP Sequence Numbers?

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 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.


  1. Kirill Kasavchenko02 February, 2016 10:57

    Ivan, that perfectly matches my observations. By the way, Juniper also mentions that Session Hijacking is an "esoteric" attack vector at the moment -

    Actually, there is a study at University of Michigan (Ann Arbor) - - 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.

  2. For those wondering how on earth the michigan study works: it relies on information leakage from IPIDs. Alledgedly it's common in middlebox OS's. If your middlebox OS has been raising red flags in `nmap -O` and lagging behind multiple open source network OS for a whole decade now, you should do the community a favour and tell us who *not* to buy :).

  3. Thanks for introduce the Fernando, Eric Vyncke and Enno Rey' work, I didn't know. Great post.

  4. Re: the point that modern TCP stacks "should be" hardened against this, there's recent measurements on this against production web servers:

    Key quote:

    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.

  5. Are there any stateful firewalls that dont track tcp seq number? Or give you the ability to turn the feature off?

    1. NSX Distributed Firewall (which started the whole thread). Not sure what iptables do.

    2. NSX Distributed Firewall does track tcp sequence numbers. (FYI, im with the NSX Technical Product Management team.)

  6. iptables checks sequence numbers. It can be turned off with ip_ct_tcp_be_liberal. Unfortunately there's very few reasons to turn it off, because I think it still incurs the tracking overhead, you're just disabling the enforcement.


You don't have to log in to post a comment, but please do provide your real name/URL. Anonymous comments might get deleted.