Certain TCP spoofing attacks uses a technique called Sequence Number Prediction.
In this type of attack, the attacker spoofs some other hosts IP address, while
attacking someone, and tries to predict the Sequence number used by that host.
Let's look on typical TCP spoofing by sequence number prediction.
Players: "attacker" [A], trying to send packets to a "victim" [V],
pretending to be some "other host" [O].
[A] sends SYN to [V] with source IP of [O].
[V] replies to [O] by SYN/ACK.
now [O] should reply to an unknown SYN/ACK by RST and the attack is
unsuccesful, but let's assume [O] is down (flooded, turned off or behind
firewall that has dropped the packets).
if [O] didn't mess it up, [A] now can talk to [V] pretending to be
[O] as long as it predicts correct sequence numbers.
As long as we do not send the RST packet to the unknown SYN/ACK in step 3, we
will allow [V] to be attacked, and ourselves to be incriminated. Common
courtesy, would hence be to send the RST to [V] in a proper way. If we use the
NEW not SYN rules specified in the ruleset, SYN/ACK packets will be dropped.
Hence, we have the following rules in the
bad_tcp_packets chain, just above the NEW not SYN
rules:
iptables -A bad_tcp_packets -p tcp --tcp-flags SYN,ACK SYN,ACK \
-m state --state NEW -j REJECT --reject-with tcp-reset
The chance of being [O] in this scenario should be relatively small, but these
rules should be safe in almost all cases. Except when you run several redundant
firewalls which will often take over packets or streams from each other. In such
case, some connections may be blocked, even though they are legit. This rule
may actually also allow a few portscans to see our firewall as well, but they
should not be able to tell much more than that.
