IPv4でping of death攻撃はどのようにして可能でしたか（そうですか？）
インターネットプロトコルについて読んでいるとき、私は死の攻撃のpingについて読んでいることに気づきました。
つまり、IPv4パケットドロップ（56バイト+ヘッダーより大きいパケットの場合）がすぐにコンピューターシステムに実装されなかったのはなぜですか？ホストが合計84バイトを超えるパケットを受信する理由はありますか？
パケットドロップが実装されていない理由はたくさんあります。 1つの例は、最大9000バイトのペイロードを可能にするジャンボフレームと呼ばれるテクノロジーがあることです。これらは主に、大量のデータが移動するLAN上でサポートされ、ヘッダーの反復的な性質は不要です。
また、ほとんどのパケットは56バイト+ヘッダーよりも大きいことに注意してください。標準のイーサネットフレームサイズは1500バイトです。 ICMPパケットのみを参照している場合、そのような制限を実装することは可能ですが、なぜですか？より大きなICMPパケットが必要な場合の有効な使用例があります。非標準のパケットを適切に処理するネットワークスタックを使用することは、機能を任意に制限するネットワークスタックを使用するよりも一般的に望ましいです。
ホストが合計84バイトを超えるパケットを受信する理由はありますか？
ここにはいくつかの層が関係しており、それが問題の最初の部分です。 ICMPのpingメッセージヘッダー用の84バイト（ペイロードは大きくなる可能性があります...ペイロードフィールドに何でも入れることができます）は、パケットをワイヤープロトコルでシステムが受信し、より大きなパケットに再構成する必要があることを意味します断片化がある場合はIPプロトコル上のパケット。ICMP層に渡され、ICMP層がプロトコルタイプをチェックします。その後、プロトコルタイプの長さをすべてチェックできます。
途中で間違いを犯す可能性のあるメモリを割り当てるコードを記述する場合、多くの場所があります。たとえば、有効なIPv4パケットでは64kを超えるデータを取得できないため、64kのメモリバッファを割り当てることができます。次に、フラグメントを組み立てるときに、フラグメントの合計が割り当てられたメモリサイズよりも小さいことを確認しなかった場合、問題が発生する可能性があります。最大のオフセットパケットを壊さずにフルサイズにすることはできなかったとしても、特定の失敗は、最後の可能なフラグメントの長さヘッダーを再構成されたパケット全体で常に有効であると信頼することでした。
したがって、再構成せずにほとんどのパケットをすぐにドロップすることはできません。最後のパケットサイズ（if offset > x and offset * 8 + len(y) > 64k）に一致チェックを追加することもできますが、これにはパケットの余分なビットをチェックする必要がありますが、これはファイアウォールとホストレベルでのみ適しています。
インターネットが機能するのは、誰もがTCP/IPの標準に従うことに同意しているからです。 56バイト+ヘッダーより大きいpingパケットはTCP/IPで許可されており、実装で処理できないため単純にそれらをドロップすると、TCP/IPが破壊されます。
Ping Of Deathの問題は、TCP/IPの設計ではなく、実装の問題でした。 1つのベンダーが適切にコードを記述しなかったため、有効なIPパケットのルールを変更しません。
大きなpingパケットの有効な使用に関しては、他のネットワーク問題を追跡するのに役立ちます。 簡単な例 は、フラグメント化されなくなるまでパケットサイズを次第に小さくして、ユーザーと別のホストの間のMTUを決定します。
ここにはすでにいくつかの良い答えがあります。
パケットフィルター、ファイアウォール、IPSがこの種の処理に対応できるようにしたかったのです。これらの種類のデバイスは、TCP/IPの通常のルールを無視するように構成されていることが多く、正しいが悪意のあるトラフィックをドロップできます。例としては、大きなICMPパケット、断片化されたTCPパケット、細工されたパケットヘッダー、および正しく形成された他の多くのものが含まれますが、バグの多いTCP/IPまたはアプリプロトコルスタックすべてに問題があります。
このようなルールは、他の回答で説明されている理由によりTCP/IPが一般的に機能しなくなるため、すべてのデバイスに組み込むことはできません。1）診断での特殊なパケットサイズの必要性2）効率のための大きな/ジャンボパケットの必要性（ex ：SANオーバーヘッドの低いスループット）