境界防御の盲点：IPオプションが招く「パケットの迷宮」とセキュリティリスク
ネットワークの現場に長くいると、「教科書通りの通信」がいかに幸せなことかを痛感させられる。OSI参照モデルの第3層、IPヘッダーの先頭20バイト。通常、Web APIのパケットはここが固定長で構成されるが、IPヘッダーには「オプション」という、いわばパンドラの箱が用意されている。
今日のテーマは、このIPオプションフィールドだ。現代のゼロトラストアーキテクチャにおいても、実はこの「忘れ去られた仕様」が、ネットワークの境界防御をすり抜ける糸口や、インフラの処理性能を蝕む病巣になり得る。後輩諸君には、パケットが単なるデータの運搬屋ではなく、時に攻撃者の「操縦席」にもなり得ることを理解してほしい。
なぜIPオプションが「パケットの迷宮」なのか
通常、IPv4のヘッダーは20バイト。しかし、IHL（Internet Header Length）フィールドを調整することで、最大60バイトまで拡張できる。この空いたスペースに書き込まれるのが「IPオプション」だ。
特に危険視されているのが、Source Routing（ソースルーティング）だ。これはパケットの送信元が、そのパケットが経由すべきルーターの経路を強制的に指定する機能である。現代のネットワーク設計では「経路はルーターが決める」のが原則だが、これが有効になっていると、攻撃者は社内の非公開セグメントを飛び越え、セキュリティゲートウェイをバイパスするような挙動をさせることが可能になる。
なぜこれが脅威なのか
1. 境界防御の無効化: 防火壁やIDS/IPSが「信頼できるセグメントからの通信」と誤認するようにパケットを偽装できる。
2. 処理負荷の増大: ルーターは通常のルーティングテーブル検索ではなく、オプションの解析と経路変更の計算を強いられる。これが積み重なると、CPUリソースを食いつぶし、特定のトラフィックを狙い撃ちした「低帯域DoS攻撃」の踏み台にされてしまう。
現場で遭遇するリスクと検証方法
APIサーバーを運用していると、たまに「なぜか特定パケットだけドロップする」「CPU負荷が異常に高い」という謎の現象にぶつかることがある。その原因の一つが、実はこのIPオプションにあるかもしれない。
実践：scapyを用いた不正パケットのシミュレーション
Pythonのscapyライブラリを使えば、意図的にIPオプションを付与したパケットを生成できる。以下のコードは、検証環境でのテスト用だ。本番環境で試すのは厳禁だぞ。
from scapy.all import IP, TCP, send
# 意図的にLoose Source Routingオプションを付与したパケットを作成
# 攻撃者は特定のゲートウェイを経由させるよう指示を埋め込む
packet = IP(dst="192.168.1.100", options=[IPOption_LSRR(routers=["10.0.0.1", "10.0.0.2"])]) / TCP(dport=80)
# パケットを送信（※決して外部ネットワークには飛ばさないこと）
send(packet)防御の鉄則：ルーターとOSでのフィルタリング
では、現場でどう立ち回るべきか。結論から言えば、「不要なIPオプションは即座にドロップする」のが現代の鉄則だ。
Linuxカーネルでの対策（sysctl）
LinuxサーバーをWeb APIのエンドポイントとして公開しているなら、カーネルレベルでソースルーティングを無効化しておくべきだ。/etc/sysctl.confに以下の設定を追記し、再読み込み（sysctl -p）を行うだけで、この種の攻撃はシャットアウトできる。
# 全インターフェースでソースルーティングを受け付けない設定
net.ipv4.conf.all.accept_source_route = 0
net.ipv4.conf.default.accept_source_route = 0
# 必要に応じてIP転送自体も無効化
net.ipv4.ip_forward = 0ネットワーク機器（Cisco等）での対応例
ルーターやL3スイッチの境界部分では、IPオプション付きのパケットを破棄するACL（アクセス制御リスト）を適用するのが定石だ。
! IPオプションが含まれるパケットを拒否する設定例
access-list 100 deny ip any any option 7 ! Record Route
access-list 100 deny ip any any option 131 ! Loose Source Routing
access-list 100 deny ip any any option 137 ! Strict Source Routing
access-list 100 permit ip any any ! 他は許可最後に：ネットワークを「信じない」という姿勢
Web APIの設計において、リクエストヘッダーのバリデーションは徹底する諸君も多いだろう。しかし、その下のレイヤーであるIPヘッダーまで意識できているだろうか？
「通信は正常に届いているはずなのに、なぜか挙動がおかしい」。そんな時、パケットキャプチャを開いてIPヘッダーのIHLフィールドが5（20バイト）以外になっていないかを確認してほしい。
ゼロトラストとは、単にユーザー認証を強化することではない。「通信経路の末端まで、パケットに悪意が隠されていないか疑い続けること」。それが、トラブルを未然に防ぐ凄腕エンジニアの嗜みだ。
次の現場でも、この「IPオプションの影」を忘れずにいてほしい。技術の進歩とともに攻撃の手法も巧妙化しているが、ネットワークの物理的・論理的な基礎知識があれば、必ず綻びを見つけ出せるはずだ。健闘を祈る。
コメント