複数のファイアウォールをまたいでアクセスパスを追跡する方法

接続が失敗した場合、あるいは予期せず成功した場合、最初に浮かぶ疑問は単純です。なぜか。 しかし、現代の環境においてこの疑問に答えることは単純ではありません。2つのシステム間の1つの接続は、次の要素を通過する可能性があります。

• 複数のファイアウォール
• 異なるルールセットと優先順位
• ネットワークゾーンとルーティングパス

1台ずつデバイスを確認しても、完全な答えは得られません。本稿では、複数のファイアウォールにまたがるアクセスパスをトレースし、トラフィックが許可または遮断される理由を正確に特定する方法を説明します。

根本的な課題: アクセスは環境全体で決定される

ファイアウォールのネイティブ管理ツールは、通常、単一のデバイスを対象範囲としています。これらのツールが示すのは次の情報です。

• ルール
• ログ
• 構成の状態

複数の適用ポイントにまたがってトラフィックがどのように評価されるかは示されません。接続が成功するのは、パス上のすべての段階で許可された場合のみです。

アクセスパスとは

アクセスパスとは、トラフィックが送信元から宛先へ移動できるかどうかを決定する一連の評価です。以下が含まれます。

• 送信元システムと宛先システム
• ポートとプロトコル
• 経路上のすべてのファイアウォール、制御ポイント、レイヤー3デバイス
• 各段階でトラフィックを許可または拒否するルール

アクセスパスをトレースするとは、これらの各要素と、それらがどのように相互作用するかを特定することを意味します。

入力と出力

入力

• 送信元システム
• 宛先システム
• ポートとプロトコル
• 環境全体のファイアウォール構成
• ネットワークトポロジーとルーティングパス
• オブジェクトグループとアドレスマッピング

出力

• 接続が許可されるか遮断されるか
• 関与する適用ポイントの順序
• トラフィックを許可または拒否するルール
• 接続を可能にする可能性のある代替パス

ステップ1: 接続を定義する

具体的な問いから始めます。 App_Server はポート 1433 で DB_Server と通信できるか。接続が明確に定義されていなければ、トレースは曖昧なものになります。

ステップ2: 想定されるパスを特定する

トラフィックがネットワーク内をどのように流れるべきかを判断します。これには次が含まれます。

• 送信元ゾーンまたはネットワーク
• 中間セグメント
• 宛先ゾーンまたはネットワーク

多くの環境では、可能なパスが複数存在します。ルールを評価する前に、トポロジーを把握する必要があります。

ステップ3: 各適用ポイントを評価する

各ファイアウォールまたは制御ポイントでは、次を行います。 1. 関連するルールを特定する 2. ルールの順序と優先順位を評価する 3. トラフィックが許可されるか拒否されるかを判断する

例

ファイアウォール A: App → DB (1433) を許可 ファイアウォール B: App → DB (1433) を拒否 すべての適用ポイントがトラフィックを許可する必要があるため、この接続は遮断されます。

ステップ4: オブジェクトグループを展開する

ルールは個々のシステムではなく、オブジェクトグループを参照していることが少なくありません。こうしたグループには複数のアドレスが含まれる場合があります。

例

App → DB_Group (1433) を許可 DB_Group は次のように解決される場合があります。 DB_Server Backup_DB Reporting_DB トレースには、展開されたすべてのメンバーを評価することが必要です。

ステップ5: ルールの相互作用を評価する

ルールは独立して機能するわけではありません。主な要因は次のとおりです。

• ルールの順序
• 重複する条件
• 特定のルールを上書きする広範なルール

例

ルール 1: Allow App → Any (Any Port) ルール 2: Deny App → DB (1433) 拒否ルールは存在しますが、評価されることはありません。

ステップ 6: 代替経路を考慮する

一方の経路がトラフィックをブロックしていても、別の経路がそれを許可している場合があります。

例

経路 1: ファイアウォール A は App → DB を拒否 経路 2: ファイアウォール B は App → DB を許可 ルーティングが経路 2 を許容する場合、接続は成立します。トレースにはすべての可能な経路を含める必要があります。

ステップ 7: 最終的な結果を判定する

以下を評価した後：

• すべての適用ポイント
• ルール間の相互作用
• オブジェクトの展開
• 想定される経路

次のことを判定できます：

• 接続が許可されるか遮断されるか
• どのルールが要因となっているか
• どこで制御を調整すべきか

例: 接続が許可される理由

質問 App_Server はポート 1433 で DB_Server に到達できますか。 構成の調査結果 ファイアウォール A: Allow App → DB_Group (1433) ファイアウォール B: 明示的な拒否なし ルール順序: 広範な許可が優先される 実効的な結果 App → DB (1433) App → Backup_DB (1433) オブジェクトグループの展開とルールの優先順位により、この接続は許可されます。

手作業のトレースが破綻する理由

手作業のトレースは、次の場合に困難になります：

• 複数のデバイスが関与する場合
• ルールセットが大規模かつ複雑な場合
• オブジェクトグループが大きく展開される場合

その結果、次の事態を招きます：

• 分析の不完全性
• 誤った前提
• トラブルシューティングの遅延

ポリシーモデルを用いたアクセス経路の評価

ポリシーモデルは、アクセスを評価するための体系的な手段を提供します。 以下を組み合わせます：

• ファイアウォール構成
• ネットワークトポロジー
• オブジェクトの解決
• ルール評価のロジック

これにより、チームは次のことが可能になります：

• 環境全体の接続性を評価する
• 適用されるすべてのルールを特定する
• アクセスが許可またはブロックされる理由を把握する

FireMon の役割

FireMon は、次の方法でアクセス経路の評価を可能にします：

• ファイアウォール全体で正規化されたポリシーモデルを構築する
• トポロジーとルーティングを取り込む
• システム間の接続性を評価する
• アクセスを制御しているルールを特定する

これにより、「この接続はなぜ許可またはブロックされているのか」という問いに一貫した方法で答えられます。

要点

• アクセスは複数の適用ポイントにまたがって決定される
• 接続はすべての段階で許可されている必要がある
• ルール順序とオブジェクトの展開が結果を左右する
• 代替経路が想定外の接続を成立させることがある
• アクセスの評価にはポリシーとトポロジーの両方が必要になる

まとめ

アクセスのトラブルシューティングにおける目的は、ルールを見つけることではありません。制御ポイントとネットワークトポロジーの両方を活用して接続をエンドツーエンドで可視化し、トラフィックが許可される、あるいは許可されない理由を明確に説明できるようにすることが目的です。