ある種の TCP 成りすまし アタックでは、シーケンスナンバー予測 (Sequence Number Prediction) が使われることがある。この種のアタックでは、アタックに際して他のホストの IPアドレスに偽装した上で、目的のホストが使用するシーケンスナンバー を予測しようとする。
シーケンスナンバー予測による典型的な TCP 成りすまし攻撃の例を見てみよう。登場人物: "アタッカー" [A] が、"被害者" [V] に対しての攻撃を、"他ホスト" [O] であるかのように見せかけて行う。
[A] が SYN を [V] へ送る。送信元IPは [O] のものを使っている。
[V] が [O] に SYN/ACK を回答する。
この時点で [O] が未知の SYN/ACK に対して RST を送り返せば、アタックは失敗に終わる。しかし、[O] は落ちている (フラッドさせられたか、電源を落としてあるか、そうしたパケットを破棄するようなファイヤーウォールの内側にある) と仮定しよう。
アタックが [O] によって台無しにされなかった場合、[A] は、シーケンスナンバー さえ正しく予測できれば、[O] に成りすましたまま [V] と通信できる状態となる。
我々が 3 の段階で未知の SYN/ACK に対して RST を送るようにしていなければ、[V] が攻撃されるのを容認したことになり、我々は共犯者となってしまう。よって、[V] に対しては適切に RST を送るようにしておくのが常識的な配慮である。ルールセット内で "NEW だが SYN でない " ルールを用いていれば、SYN/ACK パケットは破棄される。以上のことから、下記のルールを bad_tcp_packets チェーンの "NEW だが SYN でない " ルールの直前に組み込んでいるのだ:
iptables -A bad_tcp_packets -p tcp --tcp-flags SYN,ACK SYN,ACK \ -m state --state NEW -j REJECT --reject-with tcp-reset
当シナリオの [O] になってしまう可能性はかなり減らすことができ、しかもこのルールが障害になることは滅多にない。ただし、複数のファイヤーウォールで冗長化していて、それらファイヤーウォール間でパケットやストリームの引き継ぎが頻繁に行われる場合だと話は別だ。そのような場合、正規のコネクションであったとしてもブロックされてしまうケースが出てくるだろう。また、このルールはこちらのファイヤーウォールに対するポートスキャンを或る程度許してしまうが、それ以上の何かをされる心配はない。