ICMP は許可か拒否かでは設計できない – IPv4 / IPv6 制御通信の成立条件

ICMP を一つの通信として扱わない

ファイアウォールの通信要件は、TCP や UDP のポート番号を中心に整理されることが多いため、ポートを持たない ICMP は「許可する」「拒否する」という一つの判断にまとめられがちです。しかし、ICMP には疎通確認だけでなく、到達不能、経路上の MTU、TTL または Hop Limit の超過、IP ヘッダーの異常などを送信元へ通知する役割があります。

IPv6 では、これに Neighbor Discovery、Router Advertisement、Duplicate Address Detection、マルチキャスト参加制御なども加わります。ICMPv6 は IPv6 の付加的な診断機能ではなく、アドレス解決やルーター発見を含む制御機構の一部です。

そのため、ICMP の設計を「ping を許可するか」という問いに縮小することはできません。ICMP および ICMPv6 は、少なくとも次の要素を組み合わせて判断する必要があります。

判断軸	確認内容
機能	エラー通知、診断、リンク制御、マルチキャスト制御のどれか
通信方向	外部から内部、内部から外部、装置自身への通信のどれか
通過位置	ルーターを通過する通信か、同一リンク内で完結する通信か
アドレス	送信元・宛先・スコープがメッセージの用途と一致するか
接続状態	エラー通知が実在する通信と対応しているか
装置の役割	ルーター、ホスト、ファイアウォール、L2 ブリッジのどれか
通信量	正常な制御通信の範囲か、資源を圧迫する量か

同じ ICMP Type でも、受信インターフェースや通信方向が異なれば、許可条件も変わります。

この記事は「ポート番号から考えないファイアウォール設計」シリーズの第 4 回です。ここでは、ICMP / ICMPv6 を ping の許可・拒否に縮小せず、Type、Code、方向、アドレススコープ、元フローとの関係から扱います。

ICMP の機能を分類する

ICMPv4 と ICMPv6 には共通する機能がありますが、Type 番号と一部の役割は異なります。ファイアウォールルールへ落とす前に、まず機能単位で整理した方が設計しやすくなります。

機能	ICMPv4	ICMPv6	主な用途
宛先到達不能	Type 3	Type 1	経路、ホスト、ポートなどへ到達できないことを通知
パケットサイズ超過	Type 3 Code 4	Type 2	Path MTU Discovery
時間超過	Type 11	Type 3	TTL／Hop Limit 超過、再構成タイムアウト
パラメーター異常	Type 12	Type 4	IP ヘッダーなどの処理不能を通知
Echo Request／Reply	Type 8／0	Type 128／129	疎通確認、遅延・損失測定
Redirect	Type 5	Type 137	同一リンク上のホストへより適切な経路を通知
ルーター・近隣探索	別機構を含む	Type 133～136	ルーター発見、アドレス解決、到達性確認
マルチキャスト制御	IGMP	MLD 関連 Type	マルチキャストグループ参加制御

この表は、そのまま許可リストとして使うものではありません。例えば、Destination Unreachable は通信維持や障害通知に必要ですが、既存通信と無関係なメッセージまで内部へ通す必要はありません。Router Advertisement は端末収容リンクでは必要になる一方、インターネット境界から内部へ転送する通信ではありません。

エラー通知は元の通信と照合する

ICMP および ICMPv6 のエラーメッセージには、原因となった元パケットの一部が格納されます。ステートフルファイアウォールは、その内容をコネクション追跡情報と照合し、実際に存在する通信へのエラーかを判断できます。

例えば、内部のクライアントが外部の UDP サービスへ通信した後、その通信に対応する Port Unreachable が返ってきた場合は、既存フローに関連するエラーとして扱えます。一方、内部で発生していない通信を示す Destination Unreachable が外部から届いた場合は、同じ Type であっても正当性が異なります。

RFC 6092 では、IPv6 ゲートウェイについて、フィルタリング状態と一致しない Destination Unreachable および Packet Too Big を転送しない考え方が示されています。

ただし、状態照合ができないことを直ちに偽造と判断することもできません。次のような条件では、正当な ICMP エラーを既存通信へ関連付けられない場合があります。

• ICMP 内に格納された元パケットが短く、必要な L4 情報を確認できない
• NAT 変換前後の情報を正しく対応付けられない
• 非対称ルーティングによって元の通信を観測していない
• セッションがすでにタイムアウトしている
• HA 切り替え後に状態が同期されていない
• IPsec やトンネルによって内側のパケットを確認できない

したがって、設計では「ICMP エラーを許可する」という表現ではなく、どの Type と Code を、どの通信方向で、どの状態照合を行ったうえで許可するかを定義する必要があります。

Path MTU Discovery を壊さない

ICMP フィルタリングによる代表的な障害が Path MTU Discovery の失敗です。

IPv4 では、ルーターが転送先リンクの MTU より大きいパケットを受信し、かつ DF ビットによってフラグメント化できない場合、ICMP Destination Unreachable の Fragmentation Needed を送信元へ返します。

IPv6 では中継ルーターがパケットをフラグメント化しません。転送できないサイズのパケットを受信したルーターは、ICMPv6 Packet Too Big を送信元へ返し、送信元がパケットサイズを調整します。IPv6 Path MTU Discovery における Packet Too Big の処理は RFC 8201 で規定されています。

これらを破棄すると、小さなパケットだけが通過し、大きなパケットが途中で消失します。TCP の 3 ウェイハンドシェイクは成功する一方、データ転送を開始すると通信が停止するため、アプリケーションや TLS の障害に見えることがあります。RFC 8504 でも、ICMPv6 が遮断された場合に、TCP 接続確立後のデータ転送が停止するブラックホール問題が説明されています。

Path MTU Discovery に必要な ICMP を許可する場合も、無条件に通す必要はありません。元のフロー、送信元、宛先、通知された MTU 値、受信方向を検証できる製品では、それらを組み合わせて正当性を確認します。

一方で、検査を厳しくしすぎて正当な Packet Too Big を破棄すれば、セキュリティ機能そのものが通信障害の原因になります。ICMP Type を許可したことだけでなく、実際に異なる MTU を持つ経路で Path MTU Discovery が機能することを試験する必要があります。

Echo Request／Reply は診断ポリシーとして扱う

Echo Request と Echo Reply は、ネットワークの基本的な到達性、遅延、損失、経路変更を確認するために使われます。ただし、アプリケーション通信の成立に常に必須というわけではないため、エラー通知や Neighbor Discovery とは分けて扱えます。

判断すべきなのは、ICMP Echo をネットワーク全体で許可するかではなく、どの区間で誰に診断を認めるかです。

通信区間	設計例
管理ネットワークからインフラ機器	監視・障害解析のため許可
監視システムからサーバー	死活・遅延監視のため許可
インターネットから公開サービス	運用方針に応じて許可または制限
クライアント間	セグメンテーション方針に応じて制御
ファイアウォール自身	コントロールプレーン保護と合わせて制限

Echo を拒否しても、TCP や UDP サービスが公開されていればホストの存在を完全に隠せるわけではありません。一方、無制限に応答すれば、CPU 負荷や反射・増幅への加担、監視ログの増加につながる場合があります。

そのため、Echo は送信元、宛先、受信インターフェースを限定し、必要に応じてレート制限を適用します。単純な一律拒否ではなく、診断可能性と資源保護のバランスとして設計します。

IPv4 で扱いを見直すべきメッセージ

古いファイアウォールルールには、現在では使用すべきではない ICMPv4 Type が残っている場合があります。

代表例が Source Quench です。Source Quench は、輻輳を通知して送信量を抑制させる目的で定義されていましたが、現在は廃止されています。RFC 6633 では、ホストは Source Quench を送信してはならず、TCP を含む各トランスポートは受信した Source Quench を無視することが求められています。

したがって、古いルールセットに Source Quench の許可が残っていても、現在の設計へそのまま引き継ぐ理由はありません。

Redirect についても、無条件に受け入れるべきではありません。Redirect は同一リンク上のルーターがホストへより適切な経路を通知する仕組みですが、不正な Redirect を受け入れると通信経路を変更される可能性があります。利用しない環境ではホスト側で無効化し、利用する場合は正規のルーター、受信インターフェース、通知内容を限定します。

古い Type 一覧をコピーするのではなく、現在のプロトコル仕様、OS の動作、ネットワークでの利用有無を確認して更新する必要があります。

ICMPv6 はリンク制御を含む

IPv6 では、IPv4 の ARP に相当する Neighbor Discovery が ICMPv6 で実装されています。主なメッセージは次のとおりです。

Type	メッセージ	主な役割
133	Router Solicitation	ホストがルーター情報を要求
134	Router Advertisement	ルーターがプレフィックスや各種パラメーターを通知
135	Neighbor Solicitation	アドレス解決、到達性確認、DAD
136	Neighbor Advertisement	アドレスや到達性を通知
137	Redirect	同一リンク上のより適切な経路を通知

これらは通常、同一リンク内で成立する通信です。ルーターを越えて転送される一般的な ICMPv6 通過通信として扱うものではありません。

Neighbor Discovery では Hop Limit に 255 が使用されます。ルーターを一つでも通過すると Hop Limit が減るため、受信側は 255 でない Neighbor Discovery メッセージを正当な同一リンク上の通信として受け入れません。この仕組みにより、別リンクから送信された Neighbor Discovery メッセージを排除できます。

したがって、ICMPv6 のファイアウォール設計では、Type だけでなく次を確認します。

観点	ICMPv6 制御通信の成立条件
ICMPv6 Type / Code	メッセージの機能が用途と一致するか
受信インターフェース	同一リンク、境界、管理面のどこで受けたか
送信元・宛先アドレス	リンクローカル、マルチキャスト、グローバルなどの範囲が合うか
アドレススコープ	そのメッセージが越えてよい範囲か
Hop Limit	Neighbor Discovery などで 255 が維持されているか
装置の役割	ホスト、ルーター、ファイアウォールとして処理すべき通信か

例えば、正規のルーターが接続された端末収容リンクから届く Router Advertisement と、インターネット側や一般端末用ポートから届く Router Advertisement は同じ Type 134 でも意味が異なります。

NDP の保護は境界ファイアウォールだけでは完結しない

Neighbor Discovery や Router Advertisement は同一 L2 リンク内で処理されるため、インターネット境界のファイアウォールを通過しない場合があります。

不正な端末が同一セグメント内で偽の Router Advertisement や Neighbor Advertisement を送信した場合、境界ファイアウォールだけでは防げません。対策には、アクセススイッチ上の RA Guard、ポートの役割制限、First Hop Security、端末収容設計などが必要です。

一方、RA Guard も単に ICMPv6 Type 134 を見て拒否するだけでは不十分です。IPv6 拡張ヘッダーやフラグメントによって、L2 機器が Type まで正しく解析できない場合があるためです。RFC 7113 では、拡張ヘッダーを含む Router Advertisement を正しく検査するための実装上の考慮事項が示されています。

この点でも、ICMPv6 制御は一台のファイアウォールへ集約するのではなく、通信が成立するリンクに近い場所で検証する必要があります。

通過通信と装置自身への通信を分ける

ICMP のルールは、ファイアウォールを通過する通信と、ファイアウォール自身が送受信する通信に分ける必要があります。

区分	例	主な判断
通過するエラー通知	Destination Unreachable、Packet Too Big	元フロー、方向、内包パケットとの対応
通過する Echo	外部から内部サーバーへの ping	診断ポリシー、送信元、レート
装置自身への Echo	ファイアウォール管理 IP への ping	管理・監視要件、コントロールプレーン保護
装置が生成するエラー	Time Exceeded、Packet Too Big	ルーターとして必要な通知
同一リンク制御	RS、RA、NS、NA、Redirect	インターフェース、Hop Limit、アドレススコープ

RFC 4890 も、ICMPv6 フィルタリングを、ファイアウォールを通過する通信とファイアウォールのインターフェース自身に向けられた通信へ分けて整理しています。また、通信の確立・維持を阻害するため破棄してはならないメッセージと、ローカルポリシーで判断できるメッセージを区別しています。

INPUT、OUTPUT、FORWARD という実装上のチェーン名を使うかどうかにかかわらず、設計上はこの区別が必要です。

必要な ICMP にも資源制限は必要になる

通信上必要な ICMP であっても、無制限に処理する必要はありません。

ICMP および ICMPv6 は、次のような攻撃や資源消費に利用される可能性があります。

• Echo Request の大量送信
• 偽造したエラー通知
• ICMP ペイロードを利用したトンネル
• Router Solicitation や Neighbor Solicitation の大量送信
• 不正な Router Advertisement
• Neighbor Cache の消費
• 拡張ヘッダーを伴うパケットの低速処理
• ICMP ログの大量生成

ただし、すべての Type へ同じレート制限を適用すると、必要な制御通信まで失われます。例えば、Echo Request と Packet Too Big では、通信への影響も必要な処理量も異なります。

レート制限は少なくとも次の単位で検討します。

• Type および Code
• 送信元
• 宛先
• インターフェース
• 既存セッションとの関連
• 装置自身への通信か通過通信か
• 通常時の発生量
• CPU 処理へ移るかどうか

Packet Too Big や Destination Unreachable など、通信維持に影響するメッセージを過度に制限すると、攻撃を防ぐ前に正常通信を不安定にします。通常値、装置性能、異常時の影響を基に閾値を設定する必要があります。

ICMP 設計表を作成する

ICMP ルールを Type 番号の一覧から作るのではなく、機能、方向、状態、受信位置を含む設計表から生成します。

機能	IP バージョン	方向	受信位置	状態照合	基本動作
Destination Unreachable	IPv4／IPv6	外部から内部	境界	元フローと照合	条件付き許可
Fragmentation Needed	IPv4	外部から内部	境界	元フローと照合	条件付き許可
Packet Too Big	IPv6	外部から内部	境界	元フローと照合	条件付き許可
Time Exceeded	IPv4／IPv6	双方向	境界	元フローと照合	条件付き許可
Echo	IPv4／IPv6	管理から対象	管理境界	必要に応じて状態管理	診断ポリシーにより許可
Router Advertisement	IPv6	ルーターから端末	同一リンク	状態照合より送信元・HL を検証	正規ルーターのみ許可
Neighbor Discovery	IPv6	同一リンク	端末収容・ルーター間	アドレス、HL、インターフェースを検証	必要な範囲で許可
Source Quench	IPv4	任意	任意	不要	破棄または無視

実際の設計では、これに送信元・宛先プレフィックス、Type、Code、レート制限、ログ方針を加えます。

試験では通信障害の再現まで行う

ICMP の試験を ping の成功・失敗だけで終えると、エラー通知とリンク制御を確認できません。

試験	確認内容
Echo Request／Reply	診断ポリシーとレート制限
IPv4 Fragmentation Needed	DF 付きの大きなパケットで PMTUD が機能する
IPv6 Packet Too Big	MTU 差がある経路で送信サイズが調整される
Time Exceeded	traceroute などの経路診断が成立する
Port Unreachable	UDP エラーが元フローと関連付けられる
状態のない ICMP エラー	無関係なエラーが内部へ通過しない
Router Advertisement	正規ルーターからだけ受信する
Hop Limit が 255 でない NDP	同一リンク通信として受け入れない
不正な RA／NA	アクセスネットワーク側で遮断する
ICMP 大量送信	正常な制御通信を維持したまま資源を保護する

Path MTU Discovery については、単に ICMP ルールのカウンターが増えることではなく、実際のアプリケーション通信が適切なパケットサイズへ収束することまで確認します。

まとめ

ICMP は一つのサービスではありません。到達不能、Path MTU Discovery、経路診断、ヘッダー異常通知、疎通確認、近隣探索、ルーター発見、マルチキャスト制御など、異なる機能を一つのプロトコル群として扱っています。

そのため、「ICMP を許可する」「ICMP を拒否する」という単位では設計できません。必要なのは、Type と Code だけでなく、通信方向、受信インターフェース、アドレススコープ、Hop Limit、元フローとの関連、装置の役割、通信量を組み合わせることです。

IPv4 では、古いルールに残る Source Quench などを現在の仕様に合わせて見直す必要があります。IPv6 では、Packet Too Big や Neighbor Discovery を単純に遮断すると、通信やアドレス設定そのものが成立しなくなります。

ICMP を通すかどうかではなく、その ICMP メッセージが、その場所で、その方向に、その内容で発生することが正しいかを判断します。これが、ポート番号を持たない制御通信のファイアウォール設計です。

参考資料

• RFC 6092 – Recommended Simple Security Capabilities in Customer Premises Equipment for IPv6
• RFC 8201 – Path MTU Discovery for IP version 6
• RFC 8504 – IPv6 Node Requirements
• RFC 6633 – Deprecation of ICMP Source Quench Messages
• RFC 4861 – Neighbor Discovery for IP version 6
• RFC 7113 – Implementation Advice for IPv6 Router Advertisement Guard
• RFC 4890 – Recommendations for Filtering ICMPv6 Messages in Firewalls