本記事は学習用です。作成には ChatGPT と GitHub Copilot を使用しています。
1. 導入：定義・脅威像
IPスプーフィング（IP spoofing） は、ネットワーク層の IPパケット に含まれる「送信元IPアドレス」を偽装して送信する手法を指す。正規の送信元に見せかけることで、送信者の身元を隠蔽したり、アクセス制御やレート制限を回避したり、他の攻撃（例：反射・増幅型DDoS）を成立させる基盤になる。Cloudflareの解説は、IPスプーフィングがDDoSで多用されること、パケットヘッダの送信元情報を改ざんして成立することを端的に示している。(cloudflare.com)
- 仕組み：なぜ偽装が可能なのか（プロトコルと経路制御の観点）
- 代表的な攻撃シナリオと具体例
- 失敗しない対策の設計指針（BCP38/BCP84、uRPF、ACL、SAV）
- すぐに使える検知・防御の設定例（Linux、Cisco IOS 等）
- 運用時の落とし穴と検証手順
2. 背景：IPスプーフィングが成立する理由と歴史的経緯
2.1 なぜ偽装が可能か
IPはコネクションレスで、送信元アドレスが 正当な到達経路を持つか をパケット単体で検証しない。したがって、攻撃者がローカルの送信元アドレスを任意値へ書き換えて送信しても、途中のルータがそれを自動的に排除するとは限らない。この欠陥を補う運用上の規律が BCP38（RFC 2827） と BCP84（RFC 3704） による Ingress/Egress Filtering である。日本語訳の要点は「偽装された送信元アドレスを用いるパケットをネットワークの 入口 で落とす」ことで、DoS/DDoSの成立を難しくする点にある。(nic.ad.jp)
2.2 送信元近傍で止めることの重要性
SAV（Source Address Validation） は送信元に近い機器で行うほど効果が高い。経路上流で廃棄すればするほど帯域や装置への負荷を軽減でき、送信元の文脈（AS、ポート、VLAN）を使った厳格な判定も可能になる、という設計原則が運用事例で強調されている。(インターネットイニシアティブ-IIJ)
3. 攻撃シナリオ：何に使われ、どう成立するか
3.1 反射・増幅型DDoS（典型）
攻撃者は、送信元を 被害者IP に偽装して 反射器（DNS/NTP/Memcached 等） にリクエストを送る。反射器は応答を被害者に返し、
増幅率 \( A=\frac{\lvert\text{Response}\rvert}{\lvert\text{Request}\rvert} \)
が高いほど被害は大きくなる。BCP38/84が広く行き渡れば、この 偽装リクエスト 自体が入口で落ちるため、攻撃は成立しにくくなる。(blog.nic.ad.jp)
3.2 侵入・横展開の足場（ARP併用）
同一L2セグメントでは ARPスプーフィング と組み合わせ、MITMで改ざん・セッションハイジャックへ進む。JPCERT/CCは、ARPスプーフィング起点でWeb改ざん・マルウェア感染に至る国内外事例を公表している。(jpcert.or.jp)
3.3 IP認証の回避
旧来システムでは IPアドレスによる素朴な許可制 を置くケースがある。攻撃者は許可IPを名乗るだけでバイパスできるため、IPスプーフィングはその根本的弱点を突く。カスペルスキーの解説は、多要素認証など 層的防御 への移行を推奨している。(kaspersky.co.jp)
4. 防御アーキテクチャ：BCP38/84・uRPF・ACLの実装方針
4.1 設計原則（Ingress/Egress Filtering）
Ingress：上流やピアから入ってくるパケットの送信元が、自ASのアドレスで ありえない なら破棄。
Egress：自ネットワークから出ていくパケットの送信元が、自組織に 割り当て外 なら破棄。JPCERT/CCも、送信元偽装パケットのフィルタリングを 境界機器で標準設定として強く推奨 している。(jpcert.or.jp)
4.2 uRPF（Unicast Reverse Path Forwarding）
uRPF はルータの FIB（Forwarding Information Base） を参照し、受信インタフェースが「送信元IPへ戻る最良経路」と整合しているかで判定する。
- Strictモード：受信インタフェースが その送信元の最良戻り経路 と一致しないパケットを破棄。
- Looseモード：送信元への戻り経路が いずれか1つでも存在しない場合 に破棄（存在すれば許可）。
国内ISP（OCN）も早期から採用を発表しており、IETF推奨の代表的実装として普及している。(NTT)
4.3 マルチホーム環境とBCP84（RFC 3704）
マルチホームでは「最良経路＝受信インタフェース」とは限らない。BCP84（RFC 3704） はuRPFのモードや ACL併用 による誤検知低減、ポリシーベース な経路選択を考慮したフィルタ設計を示す。(tex2e.github.io)
4.4 SAVの配置と責務分担
- ISP/トランジット境界：uRPF（loose/VRF-aware）＋ bogon/私設アドレスACL
- 企業境界（CPE/EGW）：Egress ACL（社内未使用プレフィクス遮断）
- データセンタToR/AGG：VRF/テナント単位のEgress制御（クラウド/ホスティング）
いずれも 送信元近傍での適用が最も効果的 という原則に沿う。(インターネットイニシアティブ-IIJ)
5. 設定例：すぐに使える検知・防御スニペット
※ 以下は概念実装。装置・OSによりコマンド体系や副作用が異なるため、本番適用前に検証環境で確認すること。
5.1 Linux（Egress 偽装排除：iptables/nftables）
# 例：組織に 203.0.113.0/24 が割り当て。外向けはこの範囲のみ許可。
# iptables（legacy）
iptables -N SPOOF_OUT
iptables -A OUTPUT -j SPOOF_OUT
iptables -A SPOOF_OUT -o eth0 ! -s 203.0.113.0/24 -j DROP
# nftables（modern）
nft add table inet anti_spoof
nft add chain inet anti_spoof egress { type filter hook output priority 0; }
nft add rule inet anti_spoof egress ip saddr != 203.0.113.0/24 oif "eth0" drop5.2 Cisco IOS（uRPF）
! Strict uRPF（単一ホームに適合）
interface GigabitEthernet0/0
ip verify unicast source reachable-via rx
ip verify unicast source reachable-via rx allow-default
ip verify unicast source reachable-via rx allow-self-ping
! Loose uRPF（マルチホームや非対称経路で）
interface GigabitEthernet0/1
ip verify unicast source reachable-via anyStrictは非対称経路で誤検知しやすい。Looseは網羅性が下がるため、bogon/プライベート のEgress ACLを併用して強化する（例：10.0.0.0/8 などを外向け送信で拒否）。
5.3 Juniper Junos（参考）
set interfaces ge-0/0/0 unit 0 family inet rpf-check
set routing-options forwarding-table unicast-reverse-path feasible-paths（feasible-paths を指定するとECMP/非対称経路での誤検知低減に有効。詳細は対象バージョンの公式ドキュメントを参照。）
5.4 監視・検知（tcpdump + eBPF）
兆候：外向けインタフェースから、自組織割り当て以外の送信元で出ていくパケット。
# 送信元が自ASのプレフィクス以外なら表示（例：203.0.113.0/24 が正規）
tcpdump -ni eth0 'not src net 203.0.113.0/24 and (ip or ip6) and not multicast'eBPF/XDPでの 早期ドロップ は高PPSの環境で有効。ユーザ空間へのコピーを避け、内側から外側 へ出る偽装パケットを内側で潰す。
5.5 フィルタ設計チェックリスト
- ルーティングの非対称性（ECMP、ポリシーベース）
- アドレス管理台帳（DHCP/static/Anycast）の正確性
- NAT（SNAT/DNAT）後の観測点とルールの適用順
- トンネル（GRE/IPsec/VXLAN）終端での送信元検証
6. アーキテクチャ設計の具体例（構成図・テスト計画）
6.1 典型的な境界構成（Mermaid）
- (1) 企業側：外向け Egress ACL で自組織割り当て外の送信元を拒否
- (2) 境界ルータ：uRPF（単一ホームはstrict、マルチホームはloose＋ACL）
- (3) ISP側：SAV を入口で実施（契約/Peering条件で確認）(インターネットイニシアティブ-IIJ)
6.2 検証計画（最小実験）
- 台帳確定：割り当てプレフィクス、各VLAN/VRFの許容送信元レンジを表に落とす
- ラボ：非対称経路を再現（2本上流、ECMP）→ uRPF strict/loose の廃棄ログを比較
- 段階適用：観測のみ → drop/alert 比率調整 → 本番適用
- シミュレーション：
hping3 -a <spoofed-src>等で合成トラフィック生成、境界でのドロップ確認 - 運用フック：SIEMに
ip verify、ACLヒットカウンタ、XDPドロップを連携
7. よくある誤りと対処
- 誤り：uRPF strict をマルチホームに一律適用
→ 対処：loose に切り替え、ポリシーベース（IF・VRF・BGP community）とACLを併用。BCP84の勧告に沿う。(tex2e.github.io) - 誤り：Egress 側を未設定（Ingressだけで満足）
→ 対処：Egress ACL で私設アドレス（RFC1918）、ループバック、未使用帯域を遮断。JPCERT/CCも境界での偽装フィルタを推奨。(jpcert.or.jp) - 誤り：SAV をISP任せ
→ 対処：送信元に近い位置（ToR/EGW）で落とす方が効果的。(インターネットイニシアティブ-IIJ) - 誤り：ARPスプーフィング対策をL3側だけで考える
→ 対処：L2での DHCP Snooping/DAI（Dynamic ARP Inspection）、ポートセキュリティと併用。 - 誤り：可観測性不足（落とした実数が見えない）
→ 対処：ip verify統計、ACLカウンタ、XDPドロップを メトリクス 化してSLO化。
8. まとめ：実運用に落とすための最小セット
- ポリシー：BCP38/84準拠のIngress/Egressフィルタをネットワーク標準にする（設計書に明文化）
- 実装：境界は uRPF＋ACL、内側は Egress ACL/XDP で「送信元近傍で潰す」
- 検証：非対称経路とNAT/トンネルの影響を 検証手順に組み込む
- 可視化：ドロップ件数・ヒットACL・uRPF統計をダッシュボード化し 継続監視
- 教育：IPベース認証の廃止、認証は 多要素 を採用
9. 参考図表
表：プレフィクスと許容送信元レンジの棚卸し
| テナント/VRF | VLAN/IF | 正規送信元レンジ | 例外（Anycast/NAT/Loopback） | 備考 |
|---|---|---|---|---|
| corp-vrf | vlan10 | 203.0.113.0/25 | 203.0.113.200/32 (Anycast) | NAT出口は 203.0.113.1 |
| corp-vrf | vlan20 | 203.0.113.128/25 | なし | サービス系 |
コード断片：反射器への偽装リクエスト観測（テスト）
# 注意：許可を得た隔離環境でのみ実施すること
hping3 --udp -a 198.51.100.10 -p 53 -c 5 <dns-reflector>A. 参考サイト
- JPNIC: RFC2827 日本語ページ（BCP38） — ネットワークのイングレスフィルタリングの趣旨と位置づけ。(nic.ad.jp)
- IIJ 技術解説: 送信元検証（SAV） — 「送信元に近いほど効果的」という設計原則と実装例。(インターネットイニシアティブ-IIJ)
- NTT（OCN）: uRPF の導入 — 国内事例とstrict/looseの運用。(NTT)
- Cloudflare 学習センター: IPスプーフィングとは — 概念とDDoSにおける位置づけ。(cloudflare.com)
- JPCERT/CC: 送信元IPアドレスを詐称したパケットのフィルタリング — 境界での標準設定として推奨。(jpcert.or.jp)
- JANOG/NTP WG 資料：BCP38/84だけでは不十分な局面もある — 実運用での示唆。(janog.gr.jp)
B. 関連書籍
※ RFC日本語訳への参照は学習補助を目的とする。厳密な仕様は原文（IETF Datatracker）を確認のこと。(tex2e.github.io)
コメント