Firepowerデータパスのトラブルシューティングフェーズ4:アクセス コントロール ポリシー
内容
概要
この記事は、Firepowerシステムのデータパスを体系的にトラブルシューティングし、Firepowerのコンポーネントがトラフィックに影響を与えているかどうかを判断する方法を説明する一連の記事の一部です。Firepowerプラットフォームのアーキテクチャに関する情報や、その他のデータパスのトラブルシューティングに関する記事へのリンクについては、概要記事を参照してください。
この記事では、Firepowerのデータパスのトラブルシューティングの4番目の段階であるアクセスコントロールポリシー(ACP)について説明します。 この情報は、現在サポートされているすべてのFirepowerプラットフォームおよびバージョンに適用されます。
アクセスコントロールポリシー(ACP)フェーズのトラブルシューティング
一般的に、フローが一致するACPルールを決定することは、非常に簡単です。接続イベントを確認して、どのルール/アクションが適用されているかを確認できます。ACPがトラフィックに対して何を行っているかが明確に示されていない場合は、Firepowerコマンドラインインターフェイス(CLI)でデバッグを実行できます。
接続イベントの確認
入力インターフェイスと出力インターフェイスを確認した後、トラフィックとフロー情報が一致する必要があります。Firepowerがフローをブロックしているかどうかを確認する最初のステップは、該当するトラフィックの接続イベントを確認することです。これらは、Firepower Management Centerの[Analysis] > [Connections] > [Events]で表示できます。
[Edit Search（検索の編集）]をクリックし、一意のソース（イニシエータ）IPでフィルタリングすると、Firepowerによって検出されたフローを確認できます。[Action]列には、このホストのトラフィックの[Allow]が表示されます。
Firepowerが意図的にトラフィックをブロックしている場合、アクションには「ブロック」という単語が含まれます。 [接続イベントのテーブルビュー]をクリックすると、さらに多くのデータが表示されます。アクションが「ブロック」の場合、接続イベントの次のフィールドを確認できます。
-原因
– アクセスコントロールルール
迅速な緩和手順
ACPルールが原因と考えられる問題を迅速に緩和するには、次の手順を実行します。
- 該当するトラフィックに対して「Trust」または「Allow」のアクションを使用してルールを作成し、それをACPの一番上、またはすべてのブロックルールの上に配置します。
- 「ブロック」という単語を含むアクションを使用して、ルールを一時的に無効にします
- [Default Action]が[Block All Traffic]に設定されている場合は、一時的に[Network Discovery Only]に切り替えます
ACPのデバッグ
ACP操作に対する詳細なトラブルシューティングは、> system support firewall-engine-debug CLIユーティリティを使用して実行できます。
システムサポートのfirewall-engine-debugユーティリティには、ACPで評価される各パケットのエントリがあります。ルールの評価プロセスが実行され、ルールが一致するか一致しないかが表示されます。
例 1：信頼ルールに一致するトラフィック
次の例では、SSHセッションの確立は、system support firewall-engine-debugを使用して評価されます。
これは、Firepowerデバイスで実行されているACPです。
ACPには3つのルールがあります。
- 1つ目のルールは、SSHで使用される宛先ポートを持つ192.168.0.7からのトラフィックを信頼することです。
- 2番目のルールは、10.0.0.0/8から送信され、ネットワーク基準がXFFヘッダーデータに基づいて一致するすべてのトラフィックを検査します（ネットワークオブジェクトの横のアイコンで示されます）
- 3番目のルールは、192.168.62.3から10.123.175.22へのすべてのトラフィックを信頼します
トラブルシューティングシナリオでは、192.168.62.3から10.123.175.22へのSSH接続を分析しています。
セッションがACルール3の「信頼サーバのバックアップ」と一致することが期待されます。 問題は、このセッションでこのルールに一致するために必要なパケットの数です。ACルールまたは複数のパケットを決定するために最初のパケットに必要な情報はすべて必要ですか。必要な場合は何ですか。
Firepower CLIで、ACPルール評価プロセスを確認するために次のように入力します。
> system support firewall-engine-debug
Please specify an IP protocol: tcp
Please specify a client IP address: 192.168.62.3
Please specify a client port:
Please specify a server IP address: 10.123.175.22
Please specify a server port: 22
Monitoring firewall engine debug messages
次のデバッグ出力では、セッションの最初の4つのパケットが評価されています。
SYN
SYN、ACK
ACK
最初のSSHパケット（クライアントからサーバ）
これは、デバッグロジックをさらに詳しく説明したチャートです。
このフローでは、デバイスがルールに一致するために4パケットかかります。
デバッグ出力の詳細な説明を次に示します。
- IPアドレスが要件に一致しないため、「trust ssh for host」ルールが一致しないため、ACP評価プロセスは「inspect」ルールから開始されます。このルールが一致する必要があるかどうかを判断するために必要なすべての情報が最初のパケット（IPおよびポート）に存在するため、これは迅速に一致します
- HTTPアプリケーショントラフィックにX-Forwarded-For(XFF)情報が見つかっており、アプリケーションはまだ認識されていないため、セッションはルール2（保留中のアプリケーションデータ）の保留状態になります。
- 4番目のパケットでアプリケーションが識別されると、「inspect」ルールは一致しません。これは、アプリケーションがHTTPではなくSSHであるためです
- 次に、IPアドレスに基づいて「信頼サーバのバックアップ」ルールが照合されます。
要約すると、接続はセッションに一致するために4パケットを要します。これは、ルール2にアプリケーションの制約があるため、ファイアウォールがアプリケーションを識別するまで待機する必要があるためです。
ルール2に送信元ネットワークしかなく、XFFでない場合、セッションに一致するために1パケットが必要でした。
レイヤ1 ～ 4のルールは、ポリシー内の他のすべてのルールの上に常に配置する必要があります。これは、通常、これらのルールが決定を行うために1パケットが必要になるためです。ただし、レイヤ1 ～ 4のルールだけで、ACルールに一致するパケットは1パケット以上になる可能性があります。その理由はURL/DNSセキュリティインテリジェンスです。これらのイネーブルのいずれかがある場合、ファイアウォールはACポリシーによって評価されるすべてのセッションのアプリケーションを決定する必要があります。これは、アプリケーションがHTTPかDNSかを決定する必要があるためです。次に、ブラックリストに基づいてセッションを許可するかどうかを決定する必要があります。
firewall-engine-debugコマンドの出力の一部を次に示します。このコマンドに関連するフィールドが赤で強調表示されています。特定されたアプリケーションの名前を取得するために使用するコマンドに注意してください。
例 2：信頼ルールに一致するトラフィックがブロックされる
一部のシナリオでは、ACPの信頼ルールが一致していても、トラフィックをブロックできます。次の例では、同じアクセスコントロールポリシーとホストのトラフィックを評価します。
上記のように、firewall-engine-debugの出力は、トラフィックが「信頼」に一致していることを示しています。一方、接続イベントは、侵入ポリシールールによるブロックのアクションを示します(理由カラムが侵入ブロックを示すために決定されます)。
この問題が発生する理由は、ACPの[詳細設定]タブでアクセス制御ルールが設定される前に使用される侵入ポリシーが原因です。ルールアクションごとにトラフィックが信頼される前に、対象の侵入ポリシーがパターン一致を特定し、トラフィックをドロップします。ただし、IPアドレスが「信頼サーバーのバックアップ」ルールの基準と一致しているため、ACPルールの評価は信頼ルールと一致します。
トラフィックが侵入ポリシー検査を受けないようにするには、信頼ルールを「検査」ルールの上に配置します。これは、どちらの場合でもベストプラクティスです。アプリケーションIDは「inspect」ルールの一致と非一致に必要なため、アクセスコントロールルールの前に使用される侵入ポリシーが決定され、同じルールで評価されるトラフィックに使用されます。「trust server backup」ルールを「inspect」ルールの上に配置すると、最初のパケットが見つかった場合にトラフィックがルールと一致します。これは、最初のパケットで決定できるIPアドレスに基づいてルールが作成されるためです。したがって、アクセス制御ルールの前に使用される侵入ポリシーを使用する必要がないと判断されます。
シナリオ 3：アプリケーショントグによってブロックされるトラフィック
このシナリオでは、cnn.comがブロックされているとユーザが報告します。しかし、CNNをブロックする特定のルールはありません。Connection Eventsとfirewall-engine-debugの出力は、ブロックの理由を示しています。
最初に、接続イベントには、アプリケーションに関する情報と、Firepowerがアプリケーションを分類する方法を示すアプリケーションフィールドの横に情報ボックスがあります。
この情報を念頭に置いて、firewall-engine-debugが実行されます。デバッグ出力では、トラフィックはアプリケーションタグに基づいてブロックされます。
http://cnn.comを明示的にブロックするルールがない場合でも、タグ付き表示広告はACPルールのApplicationsタブ内でブロックされています。
TACに提供するデータ
| Data | 手順 |
| トラフィックを検査するFirepowerデバイスからのファイルのトラブルシューティング | http://www.cisco.com/c/en/us/support/docs/security/sourcefire-defense-center/117663-technote-SourceFire-00.html |
| system support firewall-engine-debugおよびsystem-support-trace出力 | 手順については、この記事を参照してください |
| アクセスコントロールポリシーのエクスポート | [システム(System)] > [ツール(Tools)] > [インポート/エクスポート(Import/Export)]に移動し、[アクセスコントロールポリシー(Access Control Policy)]を選択し、[エクスポート(Export)]ボタンをクリックします |
次の手順：SSLポリシーレイヤのトラブルシューティング
SSLポリシーが使用中で、アクセスコントロールポリシーのトラブルシューティングで問題が明らかでない場合は、次のステップとしてSSLポリシーのトラブルシューティングを行います。
フィードバック