ICMPスプーフィングは実用的ですか？

ICMPスプーフィングはどの程度実用的ですか？

シナリオ1：NAT環境で、NATはどのようにしてICMPセッション（接続指向ではないため、技術的にはセッションではない）を追跡しますか？ECHO / ECHO応答の場合、Windowsは同じ識別子（0x1）とシーケンス番号を使用し、パケットごとに256インクリメント。2つのホストが同じ外部サーバーにpingを送信する場合、NATは着信ICMPパケットをどのように区別しますか？内部ネットワークが送信元アドレスをフィルタリングしない場合、ECHO応答を偽造することはどれほど難しいですか？使用例：監視に使用されるicmp ping、偽造されたICMP応答（宛先に到達できない、高遅延など）を受信すると、ロードバランサーが正しくない/不要なアクションを実行する場合がある

シナリオ2：通過パス上のパケットを検査する、一部のIPSデバイス（GFWなど）。ICMPエラーメッセージを偽造してステルス接続を強制終了することは、どれほど実用的ですか。TCP RSTを送信する代わりに、宛先ポート到達不能/パケットが大きすぎる（これは興味深いかもしれません:)）偽造ソースIP（反対側の正当なIPまたはパスのさらに下のいくつかのホップ）を送信します。元のIPヘッダーを追跡し続けると、最初の64バイトは高価になる可能性がありますが、現在利用可能なコンピューティング能力があれば、それは可能ですか？

基本的に、NATの内部または外部のいずれかから、偽造されたICMPが損傷/混乱を引き起こす可能性はどのくらいありますか？ICMPフラッドについて話しているのではありません。

ところで、NATはTCP / UDP以外のIPプロトコルを処理できますか？実際には、さまざまなICMPタイプをどのように処理するのか正確にはわかりません。

RFC 5508「ICMPのNAT動作要件」は次のように述べています（セクション3.1）：

NATデバイスによるICMPクエリマッピングは、現在のICMPクエリベースのアプリケーションが機能するために必要です。これには、NATデバイスがNATの背後にあるノードから開始されたICMPクエリパケットを透過的に転送し、これらのクエリパケットへの応答を反対方向に転送する必要があります。[NAT-TRAD]で指定されているように、これにはIPヘッダーの変換が必要です。NAPTデバイスはさらに、転送前にICMPクエリIDおよびICMPヘッダー内の関連するチェックサムを変換します。

したがって、NATデバイスは、要求を外部に転送するときに、IDフィールドに一意の値を実際に入力できます。同じ識別子を使用する内部の2台のマシンは問題ありません。NATデバイスは2つの異なる値を使用し、元のIDと内部IPアドレスの組み合わせを記憶します。

いくつかの（古い）シスコ固有の情報は、http：//www.ciscopress.com/articles/article.asp？p = 25273＆seqNum = 3にあります。このページには、NATでサポートされているプロトコル/アプリケーションのリストも含まれています。

ICMPメッセージがTCP接続によって引き起こされたエラーを通知するために送信される場合、ICMPメッセージには、エラーをトリガーしたTCPセグメントのヘッダーとペイロードの一部が含まれている必要があります。これは、受信ホストがTCP接続を識別できるようにするために必要です。

NATデバイスは、受信するICMPエラーの送信先を特定するために、まったく同じことを実行できます。ICMPペイロードのTCPヘッダーに対応するマッピングがある場合、ICMPメッセージの送信先を認識しています。

ICMPエラーを偽装する攻撃者は、メッセージを作成するために送信元と宛先のIPアドレスとポートを知る必要があります。ICMPメッセージペイロードにはTCPシーケンス番号も含まれるため、TCPエンドポイントは、このシーケンス番号が有効である（つまり、送信され、まだ確認されていない）かどうかも確認できます。これにより、なりすましが非常に困難になりますが、この検証はすべてのシステムに実装されているとは限りません。

おそらくRFC 5927「TCPに対するICMP攻撃」をよく見る必要があります。

最新のステートフルNAT実装では、接続追跡は一般に、それを容易にするための基本的な部分です。NATでどのIPプロトコルを処理できるかについては、特に制限はありません。LinuxNetfilterは、任意のIPプロトコルを喜んでNAT処理できますが、明らかに、そのプロトコルに対する特別な処理がない場合（つまり、追加の弁別子）は、内部のホストは1つだけです。一度に特定の外部ホストと通信できるようになります。

ICMPの場合echo request、識別子とタイムスタンプフィールドは、同じリモートエンドポイントにpingを送信する別のホストのものと一致する可能性はほとんどありません。したがって、NAT /接続追跡実装がこのデータを利用できる場合、2つを区別できます。以下のためにdestination unreachableNATデバイスICMPエラーメッセージの正当性を保証するために（すなわち、最初の8バイト）ペイロードデータを追跡しなければならない-それでも、ホストエンドポイントは、ほとんど間違いなく、そのようなメッセージ自体を検証しなければなりません。

一般的に言って、RFC準拠のネットワークスタックを想定すると、いくつかのフィールドが一意であるという事実により、偽造されたICMPメッセージは問題になりません...攻撃者が直接の人間でない限り、かなり自由に干渉できます-もちろん、これがIPsec、TCP-MD5、TCP-AOなどが存在する理由です。

nb：NATに関しては多くのRFCが存在しますが、ルーティングプロトコルなどのように、合意された標準と見なすべきではありません。