スプーフィングされたパケットはどのように検出されますか？
私の仮定：
ファイアウォールがスプーフィングされたパケットをドロップするように構成されている場合、ファイアウォールはソースIPにping（必ずしもICMPではない）を試み、それが実際のホストに属しているかどうか、または稼働しているかどうかを確認し、そうでない場合はパケットをドロップします。
私の質問：
スプーフィングされたパケットのソースIPが実際のオンラインホストに属している場合はどうなりますか？スプーフィングされたパケットを検出する他の方法はありますか？
実際、それを実行する可能性のあるファイアウォールがあると確信していますが、このように動作するファイアウォールについては、きちんと認識していません。パケットのなりすまし検出メカニズムがありますが、動作は少し異なります。
Bogonフィルター
bogon は偽のIPアドレスとして定義されます。具体的には、委任されたRIRによってIANAによって割り当てられていないすべてのIPアドレスのリストです。このリストを取得する最良の方法は、ファイアウォールがbogonサービスへのサブスクライブをサポートすることです。ファイアウォールでbogonフィルタリングを有効にすると、送信元アドレスが RFC 1918 アドレスとしてリストされている入力パケットも含まれる傾向があります。
同じ規則を使用してブロックするか、ローカルの割り当てを含めるためにbogonリストをローカルで編集することも慣例です。通常、ファイアウォールの入力ポートで内部IPアドレスが表示されることはほとんどないと考えられています。これの例外は、ファイアウォールの外側にあるあなたの任意の機器です。ほとんどの場合、これにはパケットシェーパー、ルーター、またはその他のインフラストラクチャ機器が含まれますが、場合によっては、他の機器が意図的に外部に残されることがあります。必ずbogonリストからそれらを除外してください。
MAC制限
ボーダーファイアウォールのようなデバイスの場合、通常、どの物理デバイスが直接それらと通信できるかが非常にわかります。これもまた、パケットシェーパー、ルーターなどのインフラストラクチャデバイスである必要があります。DMZがある場合は、アーキテクチャによってはそこにそれらのデバイスが表示される場合もあります。この場合、列挙できます。 する必要があるMACアドレスがファイアウォールと直接通信し、そのリストにないものをすべて拒否することができます。なお、これは、してはならないこのネットワークセグメントで終了します。
部署に展開したり、ホスト内のサブセットをセグメント化するためにネットワーク内で透過/ブリッジモードにしたりするファイアウォールの場合、これらのリストを作成するのは非常に困難な場合があります。
TTL分析
2つのホスト間では、ホップ数は通常、パケット間で一定であるか、ほとんど変化しません。したがって、TTLが1つのパケットから別のパケットに劇的に変化する場合、これは簡単になりすましの試みとなる可能性があります。これは、より多くの状態情報を保持する必要があり、ルート変更する可能性がありますが、十分な指標であることがよくあります。
ルートチェック
複数のアクティブなアップリンクがある場合は、パケットが正しいインターフェイスに着信していることも確認できます。これと呼ばれるリバースパス転送の標準があります（ [〜＃〜] rpf [〜＃〜] ）。つまり、インターフェイスでパケットが受信されるたびに、ルーターはルーティングテーブルをチェックし、それがそのソースアドレスに適切なインターフェイスかどうかを判断します。つまり、ルーティングテーブルで144.152.10.0/24宛てのパケットがインターフェイスge-0/0/18を介して送信され、インターフェイスge-0/0/20で144.152.10.5からパケットを受信する場合、おそらくなりすまし、ドロップする必要があります。
スプーフィングされたパケットの定義
まず、IP範囲の所有権の概念があります。 IANA（および子会社、委任ISP）からのIPブロックの登録済み所有者または委任者からのものではないものはすべて偽装です。
ルーティングのすべて
なりすましについて話すときに考慮すべきことがいくつかあります。 1つ目は、パケットの発信元であるネットワークでのスプーフィングのみを防止できることです。インターネットルーティングは動的な性質を持つため、トランジットプロバイダーは他のトランジットプロバイダーからのパケットをフィルタリングできません。すべてのソースフィルタリングはISPレベルから行う必要があるため、私のISPが割り当てたアドレスからのパケットのみを送信することを許可しない限り、その馬が納屋から出ると、それはそのまま残ります。
ネットワーク全体でのなりすましに対する主な対策は、most通信が双方向チャネルに依存していることです。特にTCPの場合、シーケンス番号の調整が困難です。 A 1989年の論文 は、基本的な問題を強調していますが、最近のほとんどのシステムでは、完全にランダムなシーケンス番号が生成されるようになりました。
Bogonフィルタリング は、特定のアドレススペースをフィルタリングするために使用されていました。実際、予約されたアドレスにも適用されます。ただし、IPv4の場合、すべてのアドレス空間が割り当てられます。
フィルタリングして双方向の通信が必要な場合でも、スプーフィングからの解放が保証されているわけではありません。 ルーティングが変更される可能性があります または、中継ルーターにアクセスできる任意のユーザーがパケットを挿入する可能性があります。
非対称ルーティングは、送信パケットに対して受信パケットのパスをチェックすることを防ぎます。これは、 ホットポテトルーティング の一般的なポリシーで特に当てはまります。パケットパスはまた、会話中に定期的にネットワークを変更する可能性があるため、TTL=値も非常に変動しやすく、検出を実行する能力が制限されます。
検出されません
自分が所有するネットワークのなりすましを防ぐには、間違ったインターフェースで着信するアドレスを拒否します。範囲内の送信元アドレスのみを許可することにより、ネットワーク上のユーザーによるなりすましを防ぐことができます。平均的なエンドユーザーのルーティング機能がないため、双方向通信を防ぐことにより、ほとんどの攻撃シナリオを防ぎます。ただし、「大物」の1人がアナウンスパスにいる場合、IPアドレスを使用する機能を奪うことを妨げるものはありません。それらの多くは、そのアナウンスパスにも影響を与える可能性があります。
物事は非常に動的に変化する可能性があり、ルーティングが壊れているためにパスホームのないパケットを受信する可能性があるため、パケットがスプーフィングされているかどうかを簡単に判断することはできません。
スプーフィングされたパケットは、偽の送信元IPアドレスを持つパケットです。着信パケットをスプーフィングされたものとして検出するために、ファイアウォールは「ローカルルール」を適用しようとします。パケットが名目上送信元アドレスと互換性のないリンクからのものである場合、ファイアウォールはパケットを拒否します。たとえば、ファイアウォールがIP範囲が既知の内部ネットワークとワイドインターネットの間にある場合、ファイアウォールはリンクからインターネットへのパケットを拒否しますが、内部ネットワーク範囲の送信元アドレスを要求します。
申し立てられた送信ホストが存在するかどうかを確認するためにICMP要求を送信しようとするファイアウォールは知りません。まず、それが存在する場合にのみ、そのホストが実際にパケットを送信したかどうかはわかりません。さらに、多くのホストが存在しますが、ICMP要求をブロックします。最後に、2つのファイアウォールがこの「送信者が存在することを確認するためのping」ポリシーを適用する場合、それらは恐ろしく無限のピンポン怒りに入る可能性があります。
TCPシーケンス番号 は、なりすまし対策と見なすことができます。接続は、3ウェイハンドシェイクが実行された後にのみ「完了」と見なされます。これは、クライアントがサーバーからの回答を見ることができる場合にのみ機能する可能性があります。これは、送信元IPアドレスが「過度に」スプーフィングできないことを意味します。
ボトムライン：全体像として、偽装されたパケットは受信者の近くではなく送信者の近くでブロックされる可能性があります。 ISPは、顧客からのなりすましの試みをブロックすることになっています。 TCP 3ウェイハンドシェイクは、スプーフィングの基本的な使用法を防ぎます。
レポートの観点から、ライブMRTGグラフまたはnagoisやWiresharkトラフィック分析に類似したものから、宛先ネットワークへの送信トラフィックをチェックすることで、実際のスプーフィングを効果的に知ることができます。 tcpシーケンス番号とウィンドウサイズを予測するコンテキストでは、なりすましは容易ではないため、なりすましアドレスは、実際のパケットよりも多くの最初のパケットを受信します。