ファイアウォール設計はポート番号から始めない – 正常な通信の条件から破棄対象を逆算する

はじめに

ファイアウォールの通信要件は、次のような表で整理されることが多いです。

送信元	宛先	プロトコル	ポート	動作
インターネット	公開 Web サーバー	TCP	443	許可
管理端末	サーバー	TCP	22	許可
DNS サーバー	外部 DNS サーバー	UDP/TCP	53	許可

この形式自体に問題があるわけではありません。どのサービスを誰に利用させるかを整理するうえでは必要です。

しかし、これはサービスの利用要件を定義しているだけで、ファイアウォールが判断すべき条件のすべてを表しているわけではありません。

例えば、インターネットから公開 Web サーバーへの TCP/443 を許可していたとしても、次のようなパケットまで通してよいとは限りません。

• インターネット側から、内部ネットワークのアドレスを送信元として到着した
• 新規接続なのに TCP の開始条件を満たしていない
• 既存のセッションと対応しない応答パケットが到着した
• ファイアウォールが上位プロトコルまで正常に検査できない
• 本来とは異なるインターフェースから到着した
• 短時間に大量の新規接続が発生している

宛先ポートが 443 であることは、正常な通信を構成する条件の一つにすぎません。

ファイアウォール設計では、必要なポートを許可するだけでなく、正常な通信が成立する条件を定義し、その条件に反する通信を破棄する必要があります。

シリーズの位置づけ

このシリーズ「ポート番号から考えないファイアウォール設計」では、ファイアウォールをプロトコル別や製品別ではなく、何を根拠に破棄するかという観点で分けます。第 1 回では全体原則を置き、第 2 回以降で個別の判断軸を掘り下げ、最後に設計、検証、変更管理へ接続します。

回	主題	答える問い
1	全体原則	ポート許可以外に何を設計するのか
2	アドレスと経路	その送信元は、その場所から来るはずなのか
3	パケットと接続状態	その通信はプロトコルとして成立しているのか
4	ICMP / ICMPv6	ポートを持たない制御通信をどう扱うか
5	通信量と資源	正常なパケットが、いつ攻撃へ変わるのか
6	制御を配置する場所	どの装置・レイヤーで破棄するのか
7	設計と運用	破棄条件をどう定義・検証・更新するのか

ファイアウォールが許可するのはポートではない

ファイアウォールが許可する通信は、概念的には次のような条件の組み合わせになります。

観点	正常な通信を構成する条件
サービス要件	誰が、どのサービスを、どの方向で利用するのか
接続状態	新規接続、戻り通信、関連通信として説明できるか
パケット構造	プロトコルとして解析でき、形式が成立しているか
アドレス	送信元と宛先が、その場所で使われるべき範囲にあるか
経路	受信インターフェースやルーティングと矛盾しないか
装置の役割	通過通信、管理通信、制御プレーン通信を分けられているか
通信量	正常時の範囲を超えず、装置や回線の資源を圧迫しないか

TCP/443 が許可されていても、ほかの条件を満たさなければ正常な通信とはいえません。

例えば、公開 Web サービスへの通信は、次のように定義できます。

• インターネット側インターフェースから受信する
• 公開用アドレスを宛先とする
• TCP/443 を使用する
• 新規接続は正常な TCP 状態から開始する
• 戻り通信は作成済みのセッションと対応する
• 送信元アドレスが受信経路と矛盾しない
• ファイアウォールがパケットを正常に解析できる
• 装置の処理能力を超える通信量ではない

これらをまとめて初めて、「インターネットから公開 Web サービスへの HTTPS を許可する」という意味になります。

正常な通信はネットワーク設計から決まる

何が正常かは、ファイアウォール単体では決められません。

正常な通信を定義するには、先にネットワークの前提を固定する必要があります。

• どのインターフェースがどのゾーンに属するか
• 各ゾーンにどの IPv4／IPv6 プレフィックスを割り当てるか
• 各サーバーやネットワーク機器がどの役割を持つか
• どちら側から通信を開始するか
• どの経路を通るか
• 非対称ルーティングが存在するか
• どの IP プロトコルを使用するか
• NAT、VPN、トンネルを使用するか
• ICMP／ICMPv6 のどの機能が必要か
• 正常時にどの程度の通信量が発生するか

例えば、10.0.0.0/8 はアドレスだけを見れば不正ではありません。内部ネットワークでは正常に使用できます。

一方、インターネット側インターフェースから 10.0.0.0/8 を送信元とするパケットが到着した場合は、ネットワーク構成と矛盾します。

つまり、単独で「悪い IP アドレス」が存在するというより、そのインターフェースから、そのアドレスを持つパケットが到着することはあり得るかという関係で判断する必要があります。

送信元アドレス検証でも、固定的な禁止リストだけでは不十分です。実際の経路やマルチホーム構成を考慮する必要があり、Strict uRPF が非対称ルーティングを正常通信ごと破棄する可能性もあります。

破棄理由は分類して考える

ファイアウォールが通信を破棄する理由は、すべて同じではありません。

少なくとも、次のように分けて考える必要があります。

1. プロトコルとして成立しない

パケット単体の構造や、プロトコルの状態遷移に問題があるものです。

• 不正な IP ヘッダ
• 不自然な TCP フラグ
• 正常に再構成できないフラグメント
• IPv6 ヘッダチェーンの異常
• Type と Code の組み合わせが成立しない ICMP
• ファイアウォールが正常に解析できないパケット

これは、サービスの許可ポートとは独立した破棄条件になります。

ただし、TCP フラグや IPv6 拡張ヘッダを独自ルールで闇雲に列挙すればよいわけではありません。ファイアウォール製品や OS の解析能力を確認し、標準機能で何が検証されるかを把握する必要があります。

IPv6 拡張ヘッダについても、認識できないという理由で一律に破棄するのではなく、利用目的と装置の処理能力に基づく明示的なポリシーが必要になります。

2. 接続状態として成立しない

パケットの形式自体は正常でも、既存の通信状態と対応しないものがあります。

• 新規接続の開始条件を満たしていない
• 既存セッションに対応しない戻り通信
• NAT 状態と一致しない応答
• コネクション追跡でINVALIDと判断されたパケット
• ICMP エラーに含まれる元パケットが既存通信と対応しない

ステートフルファイアウォールは、パケットを一つずつ独立して見るのではなく、それまでの通信との関係を判断します。

したがって、同じ送信元、宛先、ポート番号を持つパケットでも、接続状態によって許可と破棄が分かれます。

3. トポロジー上成立しない

パケットも接続状態も正常に見えても、その場所から到着することがあり得ない通信があります。

• 外部側から到着する内部プレフィックス
• 内部側から送信される割り当て外アドレス
• ファイアウォール自身のアドレスを詐称した通信
• 別リンクから到着するリンクローカルアドレス
• 送信元として使用できないマルチキャストアドレス
• 想定した経路と受信インターフェースが一致しない通信

この分類では、送信元アドレスだけでなく、受信インターフェース、ルーティング、アドレススコープを組み合わせて判断します。

IPv6 でも同様に、リンクローカル fe80::/10、Unique Local Address fc00::/7、グローバルユニキャスト、マルチキャスト ff00::/8 などの性質と、受信した場所との整合性を見る必要があります。

4. 装置やゾーンの役割と一致しない

同じポートでも、通信先の役割が違えば意味が変わります。

• 公開 Web サーバーへの TCP/443
• ファイアウォール管理画面への TCP/443
• VPN 装置への TCP/443
• 内部 API への TCP/443

これらを単に「HTTPS」としてまとめることはできません。

また、ファイアウォール自身への通信と、ファイアウォールを通過する通信も分けて考える必要があります。

• 装置自身への管理通信
• ルーティングプロトコル
• 冗長化プロトコル
• ICMP／ICMPv6
• 通過する利用者通信

特に装置自身の制御プレーンは、通過通信を処理するデータプレーンより処理能力が低い場合があります。正当な制御通信を特定し、それ以外を破棄またはレート制限することが必要になります。

5. 組織のポリシーとして許可しない

技術的には成立しても、利用を認めていない通信があります。

• 管理セグメント以外からの SSH
• クライアントセグメントからサーバー管理ポートへの通信
• 使用を認めていない VPN やトンネル
• 不要なルーティングプロトコル
• 外部へ直接接続することを認めていないサーバー通信

これは「不正なパケット」ではなく、組織やシステムの利用方針に反する通信です。

プロトコル異常とポリシー違反を区別しておけば、ログや障害解析でも破棄理由を説明しやすくなります。

6. 量や頻度によって異常になる

SYN や ICMP Echo Request は、単体では正常なパケットです。

しかし、短時間に大量に送信されれば、回線、セッションテーブル、CPU、ログ領域などを圧迫します。

• 新規 TCP 接続の集中
• ICMP フラッド
• UDP クエリの集中
• 認証試行の反復
• セッションテーブルの枯渇
• 制御プレーンへ送られるパケットの集中

この分類は、パケット単体の正当性とは分ける必要があります。

また、すべての通信を合算した一律の閾値では、正常な複数利用者までまとめて制限してしまいます。送信元、宛先、サービス、接続状態、通常時の通信量を考慮して判断する必要があります。

大規模な攻撃については、境界ファイアウォールに到達してから破棄しても、すでに回線が飽和している可能性があります。どこで破棄するかも含めて設計しなければなりません。

7. 脅威情報によって遮断する

既知の攻撃元アドレスや外部の脅威情報を基にした遮断もあります。

ただし、これはプロトコルやトポロジーから導かれる原理的な破棄条件とは異なります。

分類	破棄根拠
プロトコル異常	通信形式として成立しない
状態異常	既存の接続状態と対応しない
トポロジー矛盾	アドレス、経路、インターフェースが一致しない
ポリシー違反	組織として利用を許可していない
振る舞い異常	通信量や頻度が許容範囲を超える
脅威情報	外部情報や過去の観測から危険と判断する

これらを区別せずに一つの拒否リストへ入れると、後から「なぜ遮断しているのか」を説明できなくなります。

ICMP はポート一覧から漏れる

ポート番号を中心に通信要件を整理すると、ICMP や ICMPv6 が抜けやすくなります。

しかし、ICMP には次のような機能があります。

• 宛先到達不能の通知
• Path MTU Discovery
• Hop Limit または TTL 超過の通知
• パラメータ異常の通知
• 疎通確認

さらに IPv6 では、Neighbor Discovery や Router Advertisement なども ICMPv6 で実現されます。

そのため、ICMP を一律に許可するか、一律に破棄するかという設計にはできません。

ICMPv6 のフィルタリングでは、Type と Code だけでなく、通過通信か装置自身への通信か、送信元と宛先のアドレススコープ、受信インターフェースなども判断材料になります。

これも、ファイアウォール設計をポート番号だけで表現できない理由の一つです。

デフォルト拒否は設計の代わりにならない

最後に許可されなかった通信をすべて破棄する、いわゆるデフォルト拒否は重要です。

しかし、デフォルト拒否を設定しただけでは、ファイアウォールを設計したことにはなりません。

最終的な DROP ルールだけでは、次の違いを説明できないためです。

• パケット構造が不正だった
• 送信元アドレスが受信経路と矛盾していた
• 接続状態が存在しなかった
• サービスが許可されていなかった
• 通信量が制限を超えた
• 脅威情報に一致した

すべて同じ DROP であっても、破棄理由は異なります。

破棄理由を分類しておけば、理由別のカウンタ、ログ、アラート、試験項目を設計できます。障害発生時にも、正常通信を誤って破棄したのか、想定した制御が働いたのかを判断しやすくなります。

デフォルト拒否は、設計で分類できなかった残りの通信を処理するための最終動作であり、正常通信と異常通信の定義そのものではありません。

現代のファイアウォール設計では、破棄する場所も考える

すべての破棄条件を一台の境界ファイアウォールへ集める必要はありません。

• 端末の送信元詐称はアクセスネットワークで防ぐ
• 経路との整合性はルータで確認する
• ゾーン間通信はファイアウォールで制御する
• 装置自身への通信はコントロールプレーン保護で制限する
• ホスト固有の通信はホストファイアウォールで制御する
• 大規模 DDoS は回線が飽和する前の上流で処理する
• 利用者やサービスの認証・認可はアプリケーション側でも行う

正常な通信の条件を定義したら、次に、その条件をどこで検証するのが最も正確で効率的かを決めます。

したがって、現代的な設計は次のように表現できます。

現代的な設計は、正常な通信の成立条件を定義し、条件に反する通信を最も適切な場所で検証・破棄するものとして捉えると整理しやすくなります。

ファイアウォールルールは設計から生成される

ファイアウォール設計は、必要そうなポート番号を並べる作業ではありません。

最初に固定するのは、ポートではなくネットワークの構造です。

1. ゾーンとインターフェースを定義する
2. IPv4／IPv6 プレフィックスを定義する
3. 装置、サーバー、利用者の役割を定義する
4. 正常な通信方向と経路を定義する
5. 使用するプロトコルと制御通信を定義する
6. 正常な接続状態と通信量を定義する
7. そこから成立しない通信を抽出する
8. 検証・破棄する場所を決める
9. 最後にファイアウォールルールへ変換する

つまり、ファイアウォールルールは設計の出発点ではありません。

ファイアウォールルールは、ネットワークの構造と正常な通信を定義した結果として生成される成果物です。

まとめ

ポート番号による許可・拒否は、ファイアウォール設計の一部でしかありません。

ファイアウォールが判断すべきなのは、そのパケットが許可ポートへ向かっているかだけではありません。

• プロトコルとして成立しているか
• 接続状態と対応しているか
• 送信元と宛先が正しいか
• 受信経路とアドレスが矛盾していないか
• 装置やゾーンの役割と一致しているか
• 必要な制御通信か
• 処理可能な通信量か
• どの根拠によって破棄するのか

これらを組み合わせて、正常な通信を定義します。

必要なポートを許可してから残りを落とすのではなく、まず正常な通信の成立条件を定めます。その条件に反する通信を抽出し、適切な場所で破棄します。

それが、ポート番号から始めないファイアウォール設計です。

参考資料

• RFC 3704 – Ingress Filtering for Multihomed Networks
• RFC 9288 – Recommendations on the Filtering of IPv6 Packets Containing IPv6 Extension Headers
• RFC 6192 – Protecting the Router Control Plane
• RFC 4890 – Recommendations for Filtering ICMPv6 Messages in Firewalls