悪魔のパズル：Teardrop攻撃が突きつけるIPフラグメントの深淵と防御の鉄則
ネットワークエンジニアの諸君、OSI参照モデルを暗唱できるだけでは、現代の戦場は生き残れない。特に、パケットの断片化（フラグメンテーション）という、一見地味な機能が抱える脆弱性は、歴史を振り返ればOSそのものを沈黙させる「凶器」へと変貌してきた。
本稿では、レガシーかつ極めて悪質な「Teardrop攻撃」のメカニズムを解剖し、我々が守るべきエンタープライズ環境で、この古くて新しい脅威をいかに封じ込めるか、カーネルレベルの視点から紐解いていく。
—
1. IPフラグメントの構造と「パズルの不整合」
IPパケットは、MTU（Maximum Transmission Unit）を超える通信が発生した際、ルーターによって断片化される。ここで登場するのがIPヘッダー内の3つの重要なフィールドだ。
1. Identification: フラグメントの識別子。同じパケットの断片であることを示す。
2. Fragment Offset: データの先頭からの相対位置を示す。8バイト単位でカウントされる。
3. Flags (More Fragments): 続きがあるかを示すフラグ。
Teardrop攻撃の核心は、この Fragment Offset を意図的に不正に操作することにある。
例えば、1つ目のフラグメントが Offset 0 で長さ100バイト、2つ目のフラグメントが Offset 50 で始まるようなパケットを送るとどうなるか。受信側のOS（特に古いスタックや脆弱な実装）は、パケットの再構築時にメモリ上のバッファを上書きしようとしてパニックを起こすか、計算不能なオフセット値によってメモリ破壊を引き起こす。これが、OSを即座にクラッシュさせる「Teardrop」の正体だ。
2. カーネルレベルで考える「再構築のコスト」
現代のLinuxカーネルは、このような攻撃に対して極めて堅牢だ。しかし、ネットワークの境界を守るアーキテクトとして、我々は「なぜ堅牢なのか」を理解しておく必要がある。
Linuxの netfilter や conntrack のサブシステムは、パケットが到着するたびにフラグメントの整合性を検証する。もし、再構築処理（IP Reassembly）が不十分なままスタックに渡されれば、TCP/IP のハンドシェイクはおろか、上位レイヤーの TLS 暗号化通信も成立しない。
対策：カーネルパラメーターの最適化
もし君の管理下にあるサーバーが、高負荷かつ攻撃の標的になりやすい環境であれば、以下の sysctl 設定を見直すべきだ。
# ネットワークの防御設定（/etc/sysctl.conf）
# IPフラグメントの再構築に使用するメモリ量を制限する（単位: バイト）
# 攻撃によるメモリ枯渇を防ぐための防波堤となる
net.ipv4.ipfrag_high_thresh = 262144
net.ipv4.ipfrag_low_thresh = 196608
# フラグメントを保持するタイムアウト時間を短縮し、リソース解放を早める
net.ipv4.ipfrag_time = 303. 現代的な防御の最前線：ファイアウォールとIDS/IPS
現代のエンタープライズネットワークでは、フラグメント攻撃を個々のホストで防ぐのは「最終防衛ライン」に過ぎない。本来は、境界ルーターや次世代ファイアウォール（NGFW）で「正規のパケットだけを通す」フィルタリングを徹底するのが鉄則だ。
特に、TCP のようなセッション指向のプロトコルであれば、TLS ハンドシェイクの Client Hello が断片化されて届くような状況は、特殊なMTU設定を除けば稀である。
iptables/nftablesによる正規化
パケットが内部ネットワークに侵入する前に、疑わしいフラグメントを破棄するポリシーを適用せよ。
# 不正なフラグメントをDROPするnftablesの例
table inet filter {
chain input {
type filter hook input priority 0;
# フラグメントされたパケットを明示的に処理する
# 攻撃の兆候があれば即座にログを吐き捨てさせる
ip frag-off > 0 log prefix "FRAG_ATTACK: " drop
}
}4. パフォーマンスとセキュリティのジレンマ
アーキテクトが陥りやすい罠がある。それは「セキュリティを固めすぎて RTT（Round Trip Time）が悪化する」という本末転倒だ。
フラグメントの検証はCPUリソースを消費する。パケットサイズを MTU 以下に収めるよう、MSS（Maximum Segment Size）クランプを適切に行うことは、セキュリティ向上とパフォーマンス最適化の双方に寄与する。TCP バッファのチューニングと組み合わせることで、パケットの再送を最小限に抑え、結果として攻撃者が付け入る隙を物理的に減らすことができるのだ。
# MSS値を最適化して断片化自体を未然に防ぐ設定（ルーターやゲートウェイで実施）
# 1460バイト + 40バイト（IP+TCPヘッダー）= 1500MTU
iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1460結びに代えて
Teardropのような攻撃は、ネットワークの「基礎」を突く。どれだけ最新の TLS 1.3 で暗号化を強固にしても、その土台となるIP層が揺らげば通信そのものが崩壊する。
我々スペシャリストがすべきことは、教科書をなぞることではない。カーネルがどうメモリを扱い、NICがパケットをどう切り出し、ファイアウォールがどのフィールドを見て判断を下しているのか。その「パケットの旅」を脳内でシミュレートし続けることだ。
ネットワークの世界に「絶対」はない。だが、深い理解に基づいた防衛策は、攻撃者にとっての「絶対的な壁」となり得るはずだ。諸君のネットワークが、今日も平穏かつ高速に稼働することを願う。
コメント