少し前に、私と私の友人はTCPハンドシェイクが偽装されたIPアドレスで渡される可能性があるかどうかと主張しました。
特定のIPアドレスのみを許可するWebサーバーがあるとします。だれでもそのWebサーバーをIPスプーフィングで接続できますか?
短い答え:いいえ。
より長い答え:はい、ターゲットデバイスに近いルーターデバイスを制御している場合(実際のソースIPアドレスとターゲット間のパス、および偽造IPアドレスとターゲット間のパス上にある必要があります)、またはターゲットネットワーク/ホストは ソースルートパケット を受け入れます。
短い答え:はい、しかし以前ほどではなく、文字通りあなたの質問にどれだけ答えるかに依存します。
長い答え:
私はあなたがnotをしたことに気づきました "偽装されたIPアドレスでTCP会話を続行することは可能ですか?"-その質問は@symcbeanによって適切に回答されました。具体的には、「pass TCPハンドシェイクなりすましIPアドレスを使用することは可能ですか」と尋ねました。そのため、「SYN-> SYN/ACK-> ACKを偽装して、接続が正常に釘付けにされたとサーバーが信じるようにする」という質問と、おそらく、「あなたはできますか?」スプーフィングされたクライアントアドレスとTCP会話を続けます。
それでは、あなたが尋ねた文字通りの質問を見てみましょう。その場合、答えは「はい、サーバーによってSYN/ACKに含まれる最初のTCPシーケンス番号が予測可能であれば」です。そのため、ISN(Initial Sequence Number)の予測可能性は脆弱性スキャナーによってテストされたものであり、今日では10年または15年前よりもはるかに広く正しく正しく実装されています。この脆弱性に関する2001年のシスコの勧告を引用すると、「 TCPにおけるこの脆弱性の一般的なケースは、情報システムのセキュリティコミュニティでよく知られています。 "最も有名なのは、- ミトニックは下村への攻撃でこの機能を悪用した 。
ソースルーティングまたはネットワークパス内のルーターへのアクセスが利用できない場合、これは持続可能なセットアップではありません。クライアントはISNを推測できる可能性がありますが、 以降のシーケンス番号は送信されるパケットのサイズによって増加します 、これは攻撃者には表示されず、確実に予測できません。したがって、3ウェイハンドシェイクの後に少なくとも1つのパケットを受信できるはずですが、会話はできません。そして、時には1つのパケットで十分です。
ISN予測は TCPシーケンス予測攻撃 の特定のサブセットです。良い数字を引用することはできませんが、私の経験では、この脆弱性は本来あるべき長さよりもずっと長く続いていることが示唆されています。それが原因で、スキャンに失敗したデバイス間で実行されます。 TCPスタックだけを修正するのは困難です。特に、修正に堅牢な乱数生成が含まれる場合は、限られた安価なハードウェア(ネットワークデバイスに投入されるようなもの)でやや難しい常時)。
許可されたIPアドレスのいずれかの背後にあるネットワークへのアクセス、または許可されたIPアドレスのいずれかの背後にあるマシンへのアクセスがなければ、notを渡すことができます- TCP 3-wayハンドシェイク なりすましIPアドレス。
TCPパケットを任意のIPアドレスで送信するのは簡単です。Linuxでは、生のソケットを開いて必要なものを送信できます。問題はSYN/ACK(またはその他の応答)を受信しています) 、元のIPにルーティングされます。
クライアント間のルーターには、リクエストを拒否するファイアウォールルールがある場合がありますが、多くの場合、クライアントは別のホストからのパケットをルーティングしているだけであると想定します。