ステートフルファイアウォールとは何か

ステートフルの「ステート」は、通信の状態を意味します。 ファイアウォールは、最初に届いたパケットだけを見て終わるのではなく、 通信が開始されたか、確立中か、終了したかといった状態を追跡します。

最初のパケットが許可ポリシーに一致すると、ファイアウォールはセッション情報を記録します。 その後のパケットは、毎回まったく新しい通信として扱うのではなく、 既存セッションに一致するかを確認して処理します。

ACL・ステートレスフィルタとの違い

ACLやステートレスなパケットフィルタは、基本的にパケットごとに条件を照合します。 一方、ステートフルファイアウォールは、通信の方向と状態をセッションとして関連付けます。

ACLだけで戻り通信を制御する例

社内PCからWebサーバーへのHTTPSを許可する場合、行きの通信は宛先ポート443です。 しかし戻り通信では、送信元ポートが443、宛先ポートがPC側の一時ポートになります。

ステートレスな制御だけで厳密に許可する場合、戻り通信のポート範囲やTCPフラグを考慮する必要があります。 ステートフルファイアウォールでは、行きの通信から作成したセッションを使って戻り通信を識別できます。

セッションテーブルと5タプル

ファイアウォールが通信を追跡するための中心となる情報が、 セッションテーブルです。 セッションは、一般に次の5つの情報を組み合わせて識別します。

実際のファイアウォールは、5タプルだけでなく、受信・送信インターフェース、 適用ポリシー、NAT変換情報、TCP状態、タイマー、送受信バイト数なども保持することがあります。

セッションテーブルから分かること

• 通信がファイアウォールまで到達し、セッションとして認識されたか
• どのポリシーに一致したか
• どの送信元・宛先・ポートで通信しているか
• TCP接続が確立しているか、開始途中か、終了処理中か
• NAT前後のアドレスやポートがどう変換されたか
• 送受信パケット数やバイト数が増えているか
• セッションがどの程度の時間保持されるか

通信開始から戻り通信までの流れ

社内PCからWebサーバーへTCP/443で接続する例を使い、 ステートフルファイアウォールの処理を順番に確認します。

1. PCがTCP SYNを送信する PCは送信元ポート52000、宛先ポート443として接続開始パケットを送ります。
2. ファイアウォールが既存セッションを検索する 初回通信のため、一致するセッションはまだありません。新規通信として処理します。
3. ルーティングとポリシーを確認する どのインターフェースへ転送するかを確認し、送信元ゾーン、宛先ゾーン、アドレス、サービスなどが許可ポリシーに一致するかを判定します。
4. 必要に応じてNATを決定する インターネット向け通信では、送信元NATなどの変換情報をセッションへ関連付けます。
5. セッションを作成してパケットを転送する 5タプル、方向、ポリシー、NAT、タイマーなどを記録し、SYNをWebサーバーへ転送します。
6. WebサーバーからSYN/ACKが戻る 送信元と宛先は逆になりますが、ファイアウォールは逆方向の情報も含めて既存セッションと照合します。
7. 戻り通信を既存セッションとして許可する セッションと整合する応答であれば、新規接続用の別ポリシーを探すのではなく、既存通信の戻りとして転送します。
8. TCP接続状態を更新する 3ウェイハンドシェイクが完了すると、セッション状態を確立済みとして管理します。

外部から無関係なパケットが届いた場合

たとえば、外部の別ホストが社内PCの52000番ポートへ突然パケットを送っても、 送信元IPアドレスや送信元ポートなどが既存セッションと一致しません。 そのため、正当な戻り通信とは判定されず、新規通信としてポリシー判定を受けます。

TCP・UDP・ICMPをどう管理するか

ステートフルファイアウォールは、プロトコルごとの特性に合わせて状態を管理します。 TCPのように明確な接続状態がある通信と、UDPのように接続確立手順がない通信では、管理方法が異なります。

TCPは「接続状態」を追跡できる

UDPはタイマーの影響を受けやすい

UDPにはTCPのような接続開始・終了の手順がありません。 そのため、ファイアウォールは「この送信元からこの宛先へUDP通信が許可された」という情報を一定時間保持します。 通信間隔がタイムアウトより長いアプリケーションでは、途中でセッションが消え、次のパケットが新規通信として扱われることがあります。

NATとセッション管理の関係

NATとステートフル検査は別の機能ですが、実際のファイアウォールでは密接に連携します。 NATを行う通信では、変換前と変換後のアドレス・ポートをセッションに関連付けて管理します。

Webサーバーからは、宛先198.51.100.10:61000へ応答が返ります。 ファイアウォールはセッションに記録したNAT情報を参照し、 宛先を192.168.10.10:52000へ戻して社内PCへ転送します。

NAT障害を切り分けるときに見る情報

• セッションが作成されているか
• 想定したNATルール・ポリシーに一致しているか
• 変換後のIPアドレスとポートが正しいか
• 戻りパケットが変換後アドレスへ到達しているか
• 戻りパケットが同じファイアウォールを通っているか
• 変換アドレスやポートの資源が不足していないか

セッションタイムアウトと終了

セッションテーブルの情報は永久に保持されません。 終了した通信や、一定時間パケットが流れない通信を削除しなければ、 セッション数が増え続けてファイアウォールの資源を消費するためです。

セッションが削除される主な条件

タイムアウトが短すぎる場合

• 長時間アイドルになる業務アプリケーションが切断される
• SSHやリモートデスクトップが無操作中に切れる
• UDPベースの通信で応答が戻る前にセッションが消える
• 再接続処理が増え、利用者が不安定さを感じる

タイムアウトが長すぎる場合

• 不要なセッションが長く残り、同時セッション数を消費する
• NAT用のポートや変換資源が解放されにくくなる
• 大量通信時にセッションテーブルが圧迫される
• 障害復旧後も古い状態が残り、想定外の挙動を続けることがある

ポリシー設計で確認する項目

ステートフルファイアウォールのポリシーは、単に送信元IPアドレスと宛先ポートだけを設定するものではありません。 どの通信を、どの方向で、どこまで許可するかを整理します。

最小権限で設計する

「通信できるようにする」だけなら、広いアドレス範囲と全サービスを許可すれば簡単です。 しかし、障害時の影響範囲とセキュリティリスクが大きくなります。

ポリシーの順序に注意する

多くのファイアウォールは、上から順番にポリシーを照合し、最初に一致したルールを適用します。 広い許可ルールが上にあると、下に作成した詳細な拒否・検査ルールへ到達しないことがあります。

通信できないときの切り分け

ファイアウォールを通過する通信が失敗した場合、 「ポリシーが間違っている」とすぐに決めつけず、通信経路を順番に確認します。

1. 通信要件を明確にする 送信元IP、宛先IP、プロトコル、宛先ポート、通信開始方向、発生時刻を確認します。
2. 端末からファイアウォールまでを確認する 端末のIP設定、デフォルトゲートウェイ、VLAN、ARP、ルーティングを確認します。
3. 受信インターフェースでパケットを確認する パケットキャプチャーや受信カウンターで、対象通信がファイアウォールへ到達しているかを確認します。
4. ルーティングを確認する 宛先への送信インターフェースとネクストホップが想定どおりかを確認します。ポリシー判定に経路情報が影響する製品もあります。
5. 一致したポリシーを確認する 送信元・宛先ゾーン、アドレス、サービス、スケジュール、ユーザー認証、ポリシー順序を確認します。
6. セッションテーブルを確認する セッションが存在するか、状態がどうなっているか、送受信カウンターが増えるかを確認します。
7. NAT変換を確認する 変換前後のIPアドレス・ポートが正しいか、想定外のNATルールに一致していないかを確認します。
8. 送信インターフェースから出ているかを確認する ファイアウォールが許可していても、ARP未解決、リンク障害、次ホップ障害などで転送できない場合があります。
9. 戻りパケットを確認する 応答が戻っているか、別経路へ流れていないか、既存セッションに一致しているかを確認します。
10. ログ・破棄理由・脅威検査を確認する ポリシー許可後にIPS、アンチウイルス、URLフィルター、SSL検査などで停止していないかを確認します。

セッションの状態から原因を考える

非対称ルーティングが問題になる理由

ステートフル検査では、往復パケットを同じセッションとして確認する必要があります。 行きと戻りで異なるファイアウォールを通る構成では、状態同期がない限り、戻り側装置に対応セッションが存在しません。

調査結果の報告例

ステートフルでも防げないこと

ステートフルファイアウォールは重要な防御機能ですが、 セッションを管理しているだけで、すべての脅威や誤通信を防げるわけではありません。

ステートフルファイアウォールに関するよくある勘違い

自分の言葉で説明する課題

最後に、次の質問へ30秒から1分程度で答えてください。