SUMMARY:
What is the security impact of disabling TCP Sequence Number Checking?
PROBLEM OR GOAL:
set flow no-tcp-seq-checking
Security risks with set flow tcp-no-seq-check
tcp out of seq counters are high
TCP Sequence number checking
SOLUTION:
Introduction
TCP Sequence (SYN) number checking is a valuable feature in stateful inspecting firewalls like NetScreen.
Every TCP packet contains both a Sequence Number (SYN) and an Acknowledgement Number (ACK), which helps TCP maintain error free end-to-end communications. It can also be used, to a limited extent, to validate a packet.
ScreenOS monitors SYN and ACK numbers within a certain window to ensure that the packet is indeed part of the session. If a packet is received with numbers that fall out of the expected range, the packet is dropped. This is normally a desired behavior, as the packet is invalid. But sometimes some vendors will use non-RFC methods to verify a packet's validity (Raptor Anti-spoofing (KB5815)) or for some other reason a server will send badly numbered packets, expecting a return. For this reason, ScreenOS offers the ability to disable this feature. The command set flow no-tcp-seq-check will disable sequence number checking. It is a global setting, affecting all interfaces.
Impact
Hackers can attempt to 'Hijack' a TCP session by being a "Man-in-the-Middle' and suppressing traffic from one side of the connection and injecting their own data into the stream. This is a very difficult attack technique, but it is possible to do. Generally, a hacker will not be able to match the sequence numbers close enough to be inside the valid window that NetScreen monitors, and the attack is stopped. If this feature is disabled, however, the hacker does not need to match sequence numbers, and any packet with the proper source IP, source port, destination IP, and destination port will go through.
Summary
Man-in-the-Middle TCP session Hijacking is a difficult, but possible attack. Using sequence number checking significantly reduces the likelihood of success of such an attack. Disabling this feature makes a user more vulnerable to this attack, but due to the esoteric nature of the attack, the overall increase in risk is slight. If in doubt, leave the feature enabled, and discover other ways of resolving the problem with invalid sequence numbers.
NOTE:
Due to changes in the behavior of the Stateful Inspection Engine in 3.0, this command may not be necessary for those servers protected by firewalls that mangle the three-way handshake. Try the command and see if it solves the problem for you, then re-enable sequence number checking and look for ways to solve the real problem on the server itself.