web-dev-qa-db-ja.com

パケットチェックサム

私は最近、すべてのパケットにチェックサムバイトが含まれており、チェックサムが一致しない場合、コンピューターがパケットを再度要求することを学びました。次の攻撃はどのようにしてこのような保護手段を打ち破りますか?

ARPスプーフィング-攻撃者がパケットの内容を実際に変更せず、送信中に傍受して元の意図された受信者に中継するだけなので、これは可能だと思います。私は正しいですか?

挿入攻撃(ARPスプーフィング経由)-挿入攻撃とは、テキストと画像の置換と置換を指します。この例では、攻撃者は上記と同じ種類の攻撃を実行していますが、パケットのコンテンツを変更している(テキストまたはイメージを変更している)必要があることはわかっています。では、なぜ受信者はパケットを拒否しないのでしょうか。

パケットの変更後にチェックサムを再計算または再生成できますか?

6
chubby_monky

パケットのチェックサムは暗号化の手段ではなく、セキュリティ機能を意図したものではありません。誰でも(攻撃者を含めて)何でも含むパケットのチェックサムを計算でき、計算に含まれる秘密/鍵はありません。

チェックサムは、パケットの送信中にエラーを検出することを目的としています。ビットの反転、通信の誤りなどです。基本的に、セキュリティではなく信頼性のために存在します。

19
David

パケットが変更された後でチェックサムを再計算できるだけではありません。これは、IPの通常の動作中に発生します。

変更されていないペイロードを転送できるようになる前に、ルーターがパケットの3つの異なるチェックサムを更新しなければならないことは珍しくありません。

私が言及している3つのチェックサムは、ネットワークスタックのイーサネット、IP、およびトランスポート層にあります。

ルーターによる転送後、実際にはまったく新しいイーサネットフレームが別のイーサネットセグメントで送信されるため、イーサネットチェックサムを再計算する必要があります。通常、着信パケットのチェックサムはハードウェアによって検証および除去され、発信パケットのチェックサムはハードウェアによって追加されます。 IPは異なる物理層で動作するように設計されているため、2つのチェックサムは設計上互いに完全に独立しています。そのため、着信パケットはイーサネットで発信され、別の発信パケットまたはその逆になります。

ルータは実際にTTLを減らすためにIPヘッダーを変更する必要があるため、IPヘッダーチェックサムを再計算する必要があります。

トランスポートチェックサム(通常はUDPまたはTCP)を更新する必要はありません。 IPは、ルーターがトランスポートプロトコルを知る必要すらないように設計されています。ただし、インターネットは古いバージョンのプロトコル4を実行しているため、NATデバイスが多数導入され、トランスポートチェックサムの対象となるフィールドの一部が変更されています。これが発生した場合、ルーターはトランスポートチェックサムも更新します。これは、ルーターがチェックサムを再計算するためにペイロード全体を見さえしないように最適化されています。古いチェックサムだけでなく、変更されたフィールドでは、新しいチェックサムを計算できます。これは通常、ペイロードを変更せずに実行されます。

上記の多くはIPv6で変更されています。イーサネットチェックサムに関する部分は同じです。しかし、IPヘッダーチェックサムは、処理を簡略化して高速化するために削除されました。いずれにしても、IPの上下の両方のレイヤーがデータのチェックサムをとる場合は冗長でした。さらに、IPv4の制限により、実行中のトランスポートチェックサムの変更は回避策でした。そのような修正はもはや必要ありません。

これはセキュリティとは関係ありません。パケットの悪意のある変更に対するセキュリティが必要な場合は、チェックサムに依存せず、代わりにメッセージ認証コードに依存します。この標準化されたプロトコルはIPsecと呼ばれ、IPsec用語では、MACは整合性チェック値と呼ばれます。厳密に言えば、ICVはMACの代わりに署名である可能性があるためです。

7
kasperd