送信元 IP だけでは不正と判断できない – 経路とトポロジーから破棄条件を考える

はじめに

ファイアウォールには、通信すべきではない IP アドレスをまとめた拒否リストが設定されることがあります。

例えば、インターネット側から次の送信元アドレスを持つパケットが到着した場合、一般的には不正な通信が疑われます。

• プライベート IPv4 アドレス
• ループバックアドレス
• リンクローカルアドレス
• 自組織に割り当てられたアドレス
• マルチキャストアドレス
• 特殊用途として予約されたアドレス

しかし、これらを単純に「不正な IP アドレス」としてまとめると、設計を誤ります。10.0.0.0/8 はインターネット上では到達可能な送信元として扱えませんが、内部ネットワークでは正常なアドレスです。IPv6 のリンクローカルアドレスも、ルーターを越えて到着すれば不正ですが、同一リンク上の Neighbor Discovery などでは必要になります。

つまり、IP アドレスだけを見て、その通信が正しいかを判断できません。必要なのは、そのアドレスを持つパケットが、その場所から到着することはあり得るかを、アドレス、受信インターフェース、経路、スコープの関係として確認することです。

この記事は「ポート番号から考えないファイアウォール設計」シリーズの第 2 回です。第 1 回で置いた全体原則を受けて、ここでは送信元 IP アドレスを固定的な拒否リストではなく、受信位置、経路、スコープ、トポロジーとの関係で判断します。

IP アドレスには有効範囲がある

IP アドレスは、単なる数値ではありません。アドレスごとに、使用できる場所や目的が決められています。

IPv4 には、次のようなアドレスがあります。

• グローバルユニキャスト
• プライベートアドレス
• 共有アドレス空間
• ループバック
• リンクローカル
• マルチキャスト
• ドキュメント用アドレス
• ベンチマーク用アドレス
• ブロードキャスト
• その他の特殊用途アドレス

IPv6 にも、次のようなアドレスがあります。

• グローバルユニキャスト
• Unique Local Address
• リンクローカル
• ループバック
• 未指定アドレス
• マルチキャスト
• ドキュメント用アドレス
• プロトコル固有の特殊用途アドレス

これらは、すべて同じ場所で使用できるわけではありません。例えば、IPv4 リンクローカルアドレスは同一リンク内で使用するためのものであり、ルーターはリンクローカルの送信元または宛先を持つパケットを別リンクへ転送してはなりません。

IPv6 の Unique Local Address は、サイト内や限定されたサイト間での利用を想定しており、グローバルインターネット上での到達性は想定されていません。

IPv6 マルチキャストアドレスは、送信元アドレスとして使用できません。

したがって、ファイアウォールは IP アドレスの値だけでなく、そのアドレスが持つ意味と、受信した場所を照合する必要があります。

「不正な IP」ではなく「成立しない組み合わせ」を見る

送信元アドレス検証は、次のような組み合わせで考えます。

観点	送信元アドレスの妥当性を構成する観点
アドレス種別	そのアドレスが送信元として使える種類か
受信インターフェース	その場所から到着することがあり得るか
受信ゾーン	境界、内部、VPN、クラウドなどの役割と合うか
ルーティング	戻り経路や広告経路と矛盾しないか
通信の役割	利用者通信、制御通信、トンネル内通信などとして説明できるか

例えば、次のようになります。

送信元	受信した場所	判断
10.0.0.0/8	社内 LAN	正常になり得る
10.0.0.0/8	インターネット回線	通常は成立しない
IPv6 リンクローカル	同一 L2 リンク	正常になり得る
IPv6 リンクローカル	インターネット境界	成立しない
自組織のグローバルプレフィックス	内部側	正常になり得る
自組織のグローバルプレフィックス	外部側	通常は送信元詐称
VPN 用アドレスプール	VPN トンネル	正常になり得る
VPN 用アドレスプール	通常のインターネット回線	成立しない

ここでの「外部側」「内部側」は、物理インターフェースだけを意味しません。VPN、トンネル、VRF、クラウドネットワーク、オーバーレイでは、一つの物理インターフェース上に複数の論理的な境界が存在します。

したがって、実際の設計では物理ポートだけでなく、

• 論理インターフェース
• セキュリティゾーン
• VRF
• VPN トンネル
• VLAN
• テナント
• ワークロード属性

なども含めて受信位置を定義する必要があります。

インターネット側で破棄できる送信元

インターネットへ直接接続する境界では、通常、グローバルインターネット上から到着することが成立しない送信元を破棄できます。

代表的な例は次のとおりです。

プライベート IPv4 アドレス

• 10.0.0.0/8
• 172.16.0.0/12
• 192.168.0.0/16

これらは組織内部では正常に使用できるが、通常のインターネット経路から送信元として到着することは想定されません。

ただし、VPN やオーバーレイの内側では、プライベートアドレスを持つ正当なパケットが外部回線を経由することがあります。

その場合、検証対象を次のように分けます。

• 外側のカプセル化ヘッダ
• 復号・デカプセル化後の内側ヘッダ
• どのトンネルから受信したか
• そのトンネルに許可した内部プレフィックスか

「物理的にインターネット回線から来た」という理由だけで、内側のプライベートアドレスまで不正と判断してはなりません。

自組織のアドレス

インターネット側から、自組織に割り当てられたアドレスを送信元とするパケットが到着した場合、通常は送信元詐称と考えられます。

自組織のアドレスを送信元とする通信は、原則として自組織側から外部へ出るためです。ただし、次のような構成では例外が生じます。

• 複数拠点から同一プレフィックスを広告している
• Anycast を使用している
• マルチホーム構成で別回線から戻る
• VPN や閉域網を経由する
• クラウドとオンプレミスでアドレス空間を共有している
• 経路変更中に一時的な非対称性が発生する

そのため、「自組織のアドレスだから必ず破棄」ではなく、その受信経路から到着する可能性があるかを設計時に確認します。

ループバック、リンクローカル、未指定アドレス

ループバックやリンクローカルなど、使用範囲が限定されているアドレスは、インターネット境界を越えて到着すること自体がアドレスの性質と矛盾します。一方、未指定アドレスには注意が必要です。

IPv4 の0.0.0.0や IPv6 の::は、アドレス設定前の一部の制御通信で送信元として使用されることがあります。

例えば、DHCP や IPv6 Duplicate Address Detection などです。

したがって、アクセスネットワークを含めて一律に破棄すると、アドレス設定そのものを阻害する可能性があります。インターネット境界では破棄できても、端末収容セグメントではプロトコル上の例外を定義する必要があります。

固定的な BADIP 一覧だけでは設計できない

特殊用途アドレスをまとめた固定リストをファイアウォールへ設定する方法は分かりやすいです。しかし、特殊用途アドレスは、すべて同じ性質を持つわけではありません。

IANA の IPv4／IPv6 Special-Purpose Address Registry では、各プレフィックスについて次のような属性が個別に管理されています。

• 送信元として使用できるか
• 宛先として使用できるか
• ルーターが転送できるか
• グローバルに到達可能か
• プロトコルによって予約されているか

例えば、192.0.0.0/24全体を単純に拒否すると、その中に個別に割り当てられたグローバル到達可能な Anycast アドレスまで含めてしまいます。

また、プライベートアドレス、共有アドレス空間、ドキュメント用アドレス、ベンチマーク用アドレスでは、用途も転送可能性も異なります。

したがって、設計では一つのBADIP変数へまとめるのではなく、少なくとも次のように理由を分ける必要があります。

分類	破棄する理由
送信元として使用不能	プロトコル上、送信元にできない
リンク内限定	ルーターを越えて到着してはならない
組織内限定	グローバルインターネットから到着しない
自組織プレフィックス	受信方向が組織の経路設計と矛盾する
未割り当て・未広告	現在の経路情報と対応しない
ローカルポリシー	その環境では使用しない

破棄理由を分けておけば、例外が必要になったときにも、どの前提を変更するのか判断できます。

内部から外部へ出る送信元も検証する

送信元検証というと、インターネットから入ってくるパケットだけを考えがちです。しかし、自組織から外部へ出るパケットについても、送信元アドレスを検証する必要があります。

例えば、クライアント用セグメントから外部へ送信されるパケットの送信元は、そのセグメントに割り当てたプレフィックスであるべきです。次のような送信元は、設計と矛盾します。

• 別の内部セグメントのアドレス
• ネットワーク機器の管理アドレス
• ファイアウォール自身のアドレス
• 自組織に割り当てられていないグローバルアドレス
• 利用していないプライベートアドレス
• 別テナントや別 VRF のアドレス
• 使用を認めていない IPv6 プレフィックス

これを外部へ出すと、自組織が送信元詐称通信の発生源になります。

BCP 38 として知られる RFC 2827 は、顧客や接続ネットワークに割り当てた正当な送信元以外を境界で遮断し、詐称アドレスを持つ通信がインターネットへ伝播することを防ぐ考え方を示しています。

つまり、Ingress Filtering は「外から入れない」だけを意味しません。あるネットワーク事業者から見れば、顧客側から受信する通信を検証することも Ingress Filtering です。その結果として、インターネット全体から見れば不正な通信を外へ出さない Egress Filtering になります。重要なのは、境界をどちら側から見ているかです。

送信元に近い場所で検証する

送信元詐称は、境界ファイアウォールだけで防ぐ必要はありません。むしろ、送信元に近い場所ほど、より詳細な情報を持っています。

検証する場所	判断できること
ホスト	自身に割り当てられたアドレスか
アクセススイッチ	接続ポート、MAC アドレス、DHCP 割り当てとの対応
L3 ゲートウェイ	受信セグメントと送信元プレフィックスの対応
内部ルーター	VRF、経路、拠点、テナントとの対応
境界ルーター	顧客・自組織プレフィックスとの対応
境界ファイアウォール	ゾーン、セッション、サービスとの対応
ISP	契約した顧客プレフィックスとの対応

境界に近づくほど、複数の送信元が集約される。そのため、境界だけでは「この組織のプレフィックスから来ている」ことは確認できても、「どの端末が使用すべきアドレスか」までは判断できません。

例えば、uRPF によってクライアントセグメントのプレフィックスだと確認できても、同じセグメント内の別端末のアドレスを詐称している可能性は残ります。uRPF は送信元アドレスの所有者を認証する機能ではなく、その送信元アドレスへの経路が受信した場所と整合するかを確認する機能です。

より細かな端末単位の検証が必要なら、アクセスネットワーク側の情報と組み合わせる必要があります。

uRPF は一つの方式ではない

Unicast Reverse Path Forwarding は、受信したパケットの送信元アドレスをルーティング情報と照合する仕組みです。

ただし、uRPF には複数の考え方があります。

Strict uRPF

送信元アドレスへの最適な戻り経路が、パケットを受信したインターフェースと一致することを確認します。

考え方は明確だが、非対称ルーティングでは正常な通信まで破棄する可能性があります。

Loose uRPF

送信元アドレスへの経路が、ルーティングテーブル上のどこかに存在することを確認します。

非対称ルーティングには対応しやすいが、どのインターフェースから到着すべきかという方向性の検証は弱くなります。

Feasible-Path uRPF

最適経路だけでなく、実際に使用可能な複数の経路を考慮します。

Enhanced Feasible-Path uRPF

マルチホームや複数経路環境で、正常なパケットの誤破棄を減らしつつ、到着方向の検証を維持するために拡張された方式です。

方式	検証内容	主な注意点
Strict	最適な戻り経路と受信 IF が一致	非対称経路に弱い
Loose	送信元への経路が存在	到着方向の検証が弱い
Feasible-Path	使用可能な複数経路を考慮	経路情報の扱いが複雑
Enhanced Feasible-Path	正当な複数経路をより正確に考慮	装置対応と設計確認が必要

どの方式が最も安全かを単独で決めることはできません。経路が対称で固定されている環境では Strict が適する可能性があります。一方、BGP マルチホーム、ECMP、拠点間冗長、クラウド接続などでは、Strict が正常通信を落とす可能性があります。

uRPF の方式はセキュリティ製品の設定値ではなく、ルーティング設計の結果として選択する必要があります。

非対称ルーティングを異常と決めつけない

行きと戻りで異なる経路を使用することは、必ずしも異常ではありません。

• BGP マルチホーム
• ECMP
• SD-WAN
• 複数のインターネット回線
• Active-Active 構成
• クラウドとオンプレミスの複数接続
• CDN や Anycast
• 障害時の経路切り替え

このような環境では、あるインターフェースから受信したパケットの戻り経路が別インターフェースになることがあります。これを単純に送信元詐称と判断すると、冗長性のために用意した経路をファイアウォールが遮断します。

一方で、「非対称経路があるから送信元検証を行わない」とするのも適切ではありません。必要なのは、

1. 正常に利用される経路を列挙する
2. 障害時の経路も含める
3. どのプレフィックスがどのインターフェースから到着し得るかを定義する
4. その範囲を超える通信だけを破棄する

という設計です。

非対称ルーティングによって検証を諦めるのではなく、正常な非対称性を定数として定義する必要があります。

IPv6 ではアドレススコープを明示する

IPv6 では、一つのインターフェースが複数の性質を持つアドレスを同時に使用することがあります。

• リンクローカルアドレス
• Unique Local Address
• グローバルユニキャストアドレス
• 一時アドレス
• マルチキャストアドレス

そのため、IPv4 ルールを IPv6 へ置き換えるだけでは不十分です。

ループバックアドレス

::1/128はローカルノード内でのみ使用します。

ネットワークインターフェースから到着することは、アドレスの性質と矛盾します。

未指定アドレス

::/128は通常の通信相手を示すアドレスではありません。

ただし、アドレス設定前の Duplicate Address Detection などでは、送信元として使用される場合がある。

したがって、インターネット境界では破棄できても、同一リンク内ではプロトコル上の例外が必要になります。

リンクローカルアドレス

リンクローカルアドレスは fe80::/10 で表され、同一リンク内で使用します。

fe80::/10 を送信元または宛先に持つパケットが別リンクから到着したり、ルーターを越えて転送されようとしたりする場合は、スコープと矛盾します。

一方、Neighbor Discovery やルーター間プロトコルなどでは正当な利用があるため、すべてのインターフェースで拒否することはできません。

Unique Local Address

Unique Local Address は fc00::/7 で表されます。グローバルインターネットでの到達性は想定しませんが、組織内部や限定されたサイト間ではルーティングできます。

そのため、インターネット境界では通常破棄できても、拠点間 VPN や閉域網では正常な送信元になり得ます。

マルチキャストアドレス

IPv6 マルチキャストアドレスは ff00::/8 で表され、送信元アドレスとして使用できません。

また、宛先として使用する場合も、ff00::/8 のアドレスに含まれるスコープを越えて転送してはなりません。

IPv6 では、アドレスがユニキャストかマルチキャストかだけでなく、どこまで到達可能なスコープなのかを確認する必要があります。

宛先アドレスもトポロジーと照合する

送信元検証だけでは、トポロジーの整合性を完全には確認できません。

宛先についても、次のような条件を確認する必要があります。

• そのゾーンに存在するプレフィックスか
• 外部公開を認めたアドレスか
• ファイアウォール自身の管理アドレスではないか
• ブロードキャストやマルチキャストのスコープが正しいか
• NAT や VIP で定義した宛先か
• VPN や VRF の内側にだけ存在する宛先ではないか
• ルーティング上、そのインターフェースへ転送すべき宛先か

例えば、外部から TCP/443 を許可していても、すべての内部アドレスに対する TCP/443 を許可するわけではありません。

許可するのは、外部公開用として定義した VIP やサーバーだけです。

したがって通信の妥当性は、

観点	トポロジー整合性を判断する観点
受信位置	どのインターフェース、ゾーン、トンネルから届いたか
送信元	その場所から使われるべきアドレスか
宛先	そのゾーンや公開範囲に存在する宛先か
経路	転送先や戻り経路と矛盾しないか
スコープ	リンクローカル、ULA、マルチキャストなどの到達範囲に合うか
通信の役割	サービス、管理、制御、VPN 内通信などとして説明できるか

として判断する必要があります。

NAT は送信元検証の代わりにならない

送信元 NAT を行えば、外部から見える送信元はファイアウォールや NAT 装置のアドレスに変換されます。

しかし、NAT 前の内部パケットが正当な送信元を持っているとは限りません。

内部端末が別セグメントや他組織のアドレスを詐称していても、NAT 装置が無条件に変換すれば、外部からは正規のアドレスに見えてしまいます。

そのため、処理の考え方は次のようになります。

1. 受信した内部パケットの送信元を検証する
2. そのセグメントから送信してよいアドレスか確認する
3. 正常なパケットだけを NAT 対象にする
4. 変換後の通信を外部へ送信する

NAT はアドレスを変換する機能であって、送信元の正当性を証明する機能ではありません。

設計では送信元プレフィックス表を作る

送信元検証を設計するには、禁止アドレス一覧よりも、受信位置ごとの正当な送信元一覧を作る方がよいです。

例えば、次のように整理します。

受信ゾーン	正常な送信元	例外	検証方法
インターネット	外部で到達可能なプレフィックス	ISP・IX・トンネル固有通信	境界 ACL、uRPF
クライアント LAN	その LAN の割り当てプレフィックス	DHCP 開始時通信	First Hop 検証、L3 ACL
サーバー LAN	サーバー用プレフィックス	HA、移行時の一時アドレス	L3 ACL、FW ゾーン
管理 LAN	管理用プレフィックス	踏み台、監視システム	ACL、認証
VPN	VPN アドレスプール、対向拠点プレフィックス	トンネル方式固有通信	VPN ポリシー、経路検証
クラウド接続	VPC/VNet の割り当てプレフィックス	NAT、マネージドサービス	ルート、Security Group
ルーター間リンク	リンク用プレフィックス	ルーティング、冗長化通信	インフラ ACL、CoPP

この表を作ることで、正常な送信元をネットワーク構成から定義できます。

拒否ルールは、その表に含まれない組み合わせから生成します。

よくある設計上の誤り

特殊用途アドレスを一つのリストへまとめる

用途、スコープ、転送可能性が異なるため、同じ理由では破棄できません。

プライベートアドレスをすべてのインターフェースで破棄する

内部ネットワークや VPN で必要な正当な通信まで破棄します。

外部からの送信元だけを検証する

内部から送信元詐称通信を出すことを防げません。

Strict uRPF を無条件に適用する

非対称ルーティングやマルチホーム環境で正常通信を破棄する可能性があります。

uRPF を送信元認証だと考える

同一プレフィックス内の別端末による詐称までは判別できません。

IPv4 だけを検証する

IPv6 が有効なら、IPv6 経由で同じ送信元詐称やスコープ違反が発生します。

現用系の経路だけを正常と定義する

障害時にバックアップ経路へ切り替わると、正常通信を不正として破棄します。

NAT 後のアドレスだけを見る

変換前の内部送信元が正当か確認できません。

まとめ

IP アドレスだけを見て、通信が正しいかを判断できません。同じアドレスでも、使用される場所によって意味が変わります。

• 内部では正常だが、インターネット側では成立しない
• 同一リンクでは正常だが、ルーターを越えると成立しない
• 通常経路では不正ですが、VPN トンネル内では正常になる
• 現用経路とは異なるが、障害時のバックアップ経路では正常になる

したがって、送信元アドレス検証は固定的な拒否リストではなく、

観点	トポロジー整合性を判断する観点
受信位置	どのインターフェース、ゾーン、トンネルから届いたか
送信元	その場所から使われるべきアドレスか
宛先	そのゾーンや公開範囲に存在する宛先か
経路	転送先や戻り経路と矛盾しないか
スコープ	リンクローカル、ULA、マルチキャストなどの到達範囲に合うか
通信の役割	サービス、管理、制御、VPN 内通信などとして説明できるか

の関係として設計する必要があります。

まず、各受信位置から到着し得る正常なプレフィックスを定義します。

次に、VPN、マルチホーム、非対称ルーティング、アドレス設定前の制御通信などの例外を整理します。

そのうえで、正常な組み合わせに含まれない通信を、送信元に最も近い適切な場所で破棄します。

不正な IP アドレスを探すのではありません。ネットワークの構造と矛盾するアドレスの使われ方を見つけることが、経路とトポロジーから考えるファイアウォール設計です。

参考資料

• RFC 3927 – Dynamic Configuration of IPv4 Link-Local Addresses
• RFC 4193 – Unique Local IPv6 Unicast Addresses
• RFC 4291 – IP Version 6 Addressing Architecture
• IANA IPv4 Special-Purpose Address Registry
• IANA IPv6 Special-Purpose Address Registry
• RFC 2827 – Network Ingress Filtering
• RFC 8704 – Enhanced Feasible-Path Unicast Reverse Path Forwarding