![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
[[雑記]] #setlinebreak(on) 昨日に引き続きNetScreenとTCPの話。 netscreenにはシーケンスチェックの機能がある。 いやTCPには全て存在するので、 正確には「TCPシーケンス番号予測攻撃に対して自動防御機能がある」である。 それが「TCP Out of Sequence」だそうです。 よー分からんので少し解説。 以下、wikipediaより抜粋 以下、wikipedia「TCPシーケンス番号予測攻撃」より抜粋 受信者は送信者の送信データ長＋シーケンス番号=ACK番号で返す。 仮に送信者のデータ長1000でシーケンス番号990000だった場合、 データ：1000 + シーケンス番号：990000 = 991000となり 受信者の返信Ack番号は「991000」を返す。 受信者のAck番号を受けた送信者は次のシーケンス番号を「991000」で送信する この時のデータ長が再度1000だった場合は1000+991000=99200となり 受信者は返信Ack番号99200を返す。 ――っとこれがTCPのシーケンス番号とACK番号の流れになる。 これって予測出来るんじゃね？ とゆーのが「シーケンス番号を予測」 別の端末が偽TCP Ackを返答出来る(かも)とゆーことらしい。 当然TCPの通信に割り込める ≒ 通信に介入出来る -> 乗っ取れるかもしれね とゆー話になる。 NetScreenはその防止機能として送信者シーケンス番号と返信者Ack番号を監視し、 一致しないTCPパケットは防御(破棄)されてしまう。 T破棄されたTCPは、シーケンス番号のパケットを求めて再送信要求が 何度も行われる事になり 結果、当然のように速度が低下する。 不安定なWAN回線を利用している場合、通信速度に著しい増減がある場合、 あるいは行きと帰りのルートが異なる場合に発生することがあるらしいので その場合は注意が必要となる。 -NetScreenの設定方法 set flow no-tcp-seq-check unset flow no-tcp-seq-check
