ステートフルファイアウォールとNAPT（ポート枯渇・ALG）の制御

1. 概要と本質：なぜ静的フィルタからステートフル監視へ移行したのか

インターネットと社内LANの境界に配置されるファイアウォール（Firewall: FW）は、不正な侵入やサイバー攻撃を遮断する最前線の防壁です。

初期のルータで使われていた「静的パケットフィルタリング（Static Packet Filtering）」は、パケットヘッダのIPアドレスやポート番号、TCPフラグ（ACKフラグの有無）だけを単体で検査していました。 しかし、この方式には致命的な脆弱性がありました。攻撃者が「最初からACKフラグを立てた不正パケット（ACKスプーフィング）」を外部から送り込んできた場合、静的フィルタはそれを「社内PCから開始された正当な通信の戻りパケット」と誤認して通過させてしまいます。

この限界を克服するために開発されたのが、現代のあらゆるファイアウォールやUTMの中核技術である「ステートフルインスペクション（Stateful Inspection / 状態監視型）」です。 ステートフルFWは、パケット単体を見るのではなく、「TCP 3ウェイハンドシェイクの手順に従って正当に開始された通信か」「シーケンス番号や確認応答番号は正常な範囲内か」を内部の「セッションテーブル」でリアルタイムに追跡します。

ネットワークスペシャリスト（NW）午後・科目B試験では、「ステートフルFWのセッション管理と戻りパケットの自動許可」「NAPT（IPマスカレード）における同時接続急増時のポート枯渇」「FTPアクティブ／パッシブモードとALG（アプリケーションレイヤゲートウェイ）の動的ピンホール開口」「非対称ルーティングによるパケット破棄事故」が頻出します。 本稿では、それらの内部挙動と設計・トラブルシューティング手法を徹底解説します。

2. ステートフルインスペクションの内部アーキテクチャ

ステートフルファイアウォールは、メモリ上に「セッションテーブル（State Table）」を保持し、通過する通信の状態（ステート）を厳密に管理します。

図のデータを表示できません。

2.1 セッションテーブルの管理項目

セッションテーブルには、以下の「5つ組（5-tuple）」に加えて状態情報が記録されます。

• 送信元IPアドレス / 宛先IPアドレス

• 送信元ポート番号 / 宛先ポート番号

• プロトコル番号（TCP: 6, UDP: 17, ICMP: 1等）

• TCP接続状態（SYN_SENT, ESTABLISHED, FIN_WAIT, TIME_WAIT等）

• 想定されるシーケンス番号（Seq）および確認応答番号（Ack）の有効範囲

• アイドルタイマー（無通信タイムアウト時間）

[!IMPORTANT] 戻り通信（復路）の自動許可 管理者は「社内LAN → 外部」の通信ルールを許可（Permit）するだけでよく、「外部 → 社内LAN」に向けた戻りパケット用の静的ルールをわざわざ開放する必要はありません。 戻りパケットはセッションテーブルに合致する限り、ステートフル機能によって動的・自動的に通過が許可されます。

2.2 ファイアウォール種別の機能比較マトリクス

3. NAPT（IPマスカレード）と「ポート枯渇問題」

企業がインターネットに接続する際、プライベートIPアドレスを少数のグローバルIPアドレスに変換する NAPT（Network Address Port Translation） が同時に実行されます。

図のデータを表示できません。

3.1 ポート枯渇（Port Exhaustion）のメカニズム

TCPおよびUDPのポート番号は 16ビット（0〜65,535） であり、Well-Knownポート（0〜1,023）を除く約 60,000個 がNAPT用の動的ポートとして利用可能です。 つまり、「1つのグローバルIPアドレスで同時に維持できる外部接続セッション数は最大約60,000本」という物理的上限が存在します。

発生シナリオ（試験頻出）

• Ajax / 短時間ポーリングの乱発: 社内の業務Webシステムやチャットツールが、数秒おきに新規TCPコネクションを生成して破棄する。

• TIME_WAIT状態のセッション保持: TCPは切断（FIN/ACK交換）後も、遅延パケットの混入を防ぐために一定時間（標準2分〜4分）セッション情報を保持する。

• 結果: わずか数百人の社員のPCから一斉に通信が発生しただけで、利用可能なグローバルポート番号がすべて消費尽くされ、「新規のWeb閲覧が一切できなくなる（名前解決もタイムアウトする）」というポート枯渇障害に陥る。

対策

1. グローバルIPプールの拡大: NAPT用に複数のグローバルIPアドレスを割り当て、利用可能ポート総数を $60,000 \times N$ 個に増強する。

2. TCPタイムアウト値の適正化: FIN切断後のクローズドタイムアウト時間を短縮（例: 30秒）してポートを早期回収する。

3. 通信プロトコルの見直し: 短時間ポーリングを廃止し、長寿命セッション（WebSocketやHTTP/2多重化）へ移行する。

4. ALG（Application Layer Gateway）の動作原理

一般的なファイアウォールはレイヤ3・4（IPヘッダとTCP/UDPヘッダ）までしか見ません。 しかし、世の中には「アプリケーションのデータペイロード（通信データの中身）に、自分のIPアドレスやポート番号を書き込んで相手に通知するプロトコル」が存在します。代表例が FTP（File Transfer Protocol） や SIP（VoIP電話） です。

4.1 FTPアクティブモードとファイアウォールの衝突

図のデータを表示できません。

4.2 ALGによる動的ピンホール開口とアドレス書換

この障害を自動救済する機能が ALG（Application Layer Gateway / FTP-ALG） です。

図のデータを表示できません。

1. FWのALGは、制御コネクション内を行き交う PORT コマンドを検知する。

2. ペイロードに書かれたプライベートIP（10.1.1.50）を、FW自身のグローバルIP（203.0.113.1）に書き換え、待受ポート番号も空きポート（例: 60000）へ書き換える。

3. 外部FTPサーバからそのポート（203.0.113.1:60000）宛てに送られてくる逆接続データパケットを通すため、セッションテーブルに「一時的な通過許可穴（ピンホール）」を動的生成する。

[!TIP] 近代的な解決策：パッシブモード（PASV）の利用 ALGに頼らずとも、クライアント側から PASV コマンドを発行する 「FTPパッシブモード」 を使えば、データコネクションも「社内クライアントから外部サーバへ向けて」発信されるため、一般的なステートフルFWを無設定でスムーズに通過できます。

5. 非対称ルーティング（Asymmetric Routing）の罠

ファイアウォールを2台並列に冗長化したネットワークにおいて、最も恐ろしい設計ミスが「非対称ルーティング」です。

図のデータを表示できません。

• 発生原理:

- 行き（往路）のパケットは FW-A を通過し、FW-A に「SYN_SENT」のセッションが作られる。 - 帰り（復路）の応答パケットが、動的ルーティング（OSPF/BGP）の非対称性により FW-B へ戻ってきてしまった。 - FW-B には先行する SYN パケットの記録が一切ないため、「正規のハンドシェイクを経ていない不正な ACK パケット」と判断してパケットを遮断する。

• 対策:

- FW間でセッションテーブルを常時同期させる（HA同期クラスタリング）。 - または、往路と復路が必ず同一のFWを通過するよう、ルーティング（メトリックやPBR: ポリシーベースルーティング）を厳格に統一する。

6. 午後・科目B形式 実戦演習

【問題シナリオ】

製造業のF社は、外部の取引先企業と大容量のCAD図面データを授受するため、社内DMZセグメントに新規のファイル転送サーバ（FTPサーバ）を構築した。 DMZセグメントの前段にはステートフルインスペクション型ファイアウォール（FW-Core）が設置されている。

図のデータを表示できません。

FW-Coreにおけるセキュリティポリシーは以下の通り設定した。

• ルール1: 送信元「Any（インターネット）」、宛先「FTPサーバの公開IP」、サービス「TCP 21（FTP制御）」＝ 許可（Permit）

• ルール2: 上記以外の外部からの通信 ＝ すべて破棄（Deny All）

運用開始後、取引先から「FTPサーバへログインは成功するが、ファイル一覧（ls コマンド）の取得やファイルのダウンロードを実行すると、数十秒待たされた後に『データコネクションを確立できません』というエラーで失敗する」というクレームが報告された。 取引先のFTPクライアントは「アクティブモード」で接続していた。

【設問1】

取引先PCからログインは成功するにもかかわらず、ファイル一覧の取得やダウンロードが失敗した理由について、FTPアクティブモードにおけるデータコネクションの確立手順、およびFW-Coreの動作に着目して35字以内で述べよ。

解答への思考プロセス

• 通信シーケンスの整理:

- 制御コネクション（TCP 21）は「取引先PC → FTPサーバ」へ発信されるため、ルール1により正常に通過し、認証（ログイン）は通る。 - ファイル一覧取得や転送を行う際、アクティブモードではFTPサーバ側が送信元ポート20番を使い、「FTPサーバ → 取引先PCの待受ポート」へ向けて新規のTCPデータコネクションを発信（逆接続）する。 - FW-Coreから見ると、これは「DMZのサーバから外部への新規TCP通信」、または取引先側のFWから見ると「外部から内部への新規TCP通信」となる。 - F社のFW-Coreのルール2により、21番ポート以外の未知の通信はすべて破棄されるため、データコネクションのSYNパケットがブロックされる。

• 設問要求の確認:

- 「データコネクションの確立手順」＝サーバからクライアントへ逆接続 - 「FW-Coreの動作」＝ルール2によりパケットを遮断 - 35字以内でまとめる。

• 文章作成:

- サーバからのデータ接続要求がFWの遮断ルールにより破棄されたため。（35字）

模範解答

サーバからのデータ接続要求がFWの破棄ルールにより遮断されたため。（35字）

減点・失点分析

• ×「取引先PCのファイアウォールが壊れていたため。」（自社システムの設問であり他社PCの故障を理由にするのは0点）

• △「データ通信用のポート20番が開いていなかったから。」（なぜポート20番の通信が通らないのか「サーバからクライアントへの逆接続である点」に触れていないため部分点どまり）

【設問2】

F社のシステム管理者が、FW-Coreのセキュリティポリシー（ルール2のDeny設定）を安易に全面開放することなく、取引先側で最も簡単かつ安全にこの通信を成立させるためのクライアント側の運用変更策を25字以内で述べよ。

解答への思考プロセス

• 解決策の選定:

- 取引先側の設定変更で対応する。 - FTPにおいて、サーバからの逆接続を回避し、クライアントからサーバへデータコネクションを発信させる方式は 「パッシブモード（PASVモード）」。 - クライアントソフトの接続設定をアクティブモードからパッシブモードへ切り替えるだけで解決する。

• 字数制限（25字以内）への整形:

- 「接続モードをパッシブモードに変更する。」（21字）

模範解答

接続モードをパッシブモードに変更する。（21字）

減点・失点分析

• ×「SFTPやFTPSに切り替える。」（プロトコル全体の入れ替えであり「クライアント側の最も簡単な運用変更策」に正対していない）

• △「ブラウザからアクセスする。」（ブラウザも内部的にパッシブモードを使うが、技術用語として不正確）

7. まとめと次ステップ

ステートフルファイアウォールとNAPTは、企業境界防御の絶対的基盤です。

• ステートフルインスペクションはセッションテーブルにより戻り通信を自動許可する。

• NAPTポート枯渇は同時接続数・TIME_WAIT蓄積により生じるため、IPプール化やタイムアウト短縮で防ぐ。

• ALGはペイロードのアドレス書換と動的ピンホール開口を行う（FTPはパッシブモードが現代の基本）。

• 非対称ルーティングはセッション不一致によるパケットドロップを招くため、往路・復路の経路統一が鉄則。

次稿 NWP-11（IEEE 802.1X認証基盤とEAP-TLS・ダイナミックVLANの実装） では、社内ネットワークへの不正接続を物理ポート・無線APレベルで完全遮断する802.1X認証プロトコル、証明書による厳格なEAP-TLS、および動的VLAN制御の実務を解説します。