FTDプリフィルタポリシーの設定と運用

概要

このドキュメントでは、Firepower Threat Defense(FTD)プレフィルタポリシーの設定と動作について説明します。

前提条件

要件

このドキュメントに特有の要件はありません。

使用するコンポーネント

このドキュメントの情報は、次のソフトウェアとハードウェアのバージョンに基づいています。

• FTDコード6.1.0-195が稼働するASA5506X
• 6.1.0-195が稼働するFireSIGHT Management Center(FMC)
• 15.2イメージを実行する2台の3925 Cisco IOS®ルータ

このドキュメントの情報は、特定のラボ環境にあるデバイスに基づいて作成されました。このドキュメントで使用するすべてのデバイスは、初期（デフォルト）設定の状態から起動しています。本稼働中のネットワークでは、各コマンドによって起こる可能性がある影響を十分確認してください。

背景説明

プレフィルタポリシーは6.1バージョンで導入された機能で、主に次の3つの目的に使用されます。

1. 内部ヘッダーと外部ヘッダーの両方に基づいてトラフィックを照合する
2. フローがSnortエンジンを完全にバイパスできる早期アクセス制御の提供
3. Adaptive Security Appliance(ASA)移行ツールから移行されるAccess Control Entries(ACE；アクセスコントロールエントリ)(ACE)のプレースホルダとして機能します。

設定

プレフィルタポリシーの使用例1

プレフィルタポリシーでは、トンネル規則タイプを使用できます。このタイプを使用すると、FTDは内部および外部の両方のIPヘッダートンネリングトラフィックに基づいてフィルタリングできます。この記事が書かれた時点では、トンネルトラフィックとは次のことを指しています。

• 総称ルーティング カプセル化（GRE）
• IP-in-IP
• IPv6-IP
• Teredo ポート 3544

図に示すように、GREトンネルを検討します。

GREトンネルを使用してR1からR2にpingを実行すると、トラフィックは図に示すようにファイアウォールを通過します。

ファイアウォールがASAデバイスの場合は、図に示すように、外部IPヘッダーがチェックされます。

ASA# show conn
GRE OUTSIDE 192.168.76.39:0 INSIDE  192.168.75.39:0, idle 0:00:17, bytes 520, flags

ファイアウォールがFirePOWERデバイスの場合は、図に示すように内部IPヘッダーをチェックします。

プレフィルタポリシーを使用すると、FTDデバイスは内部ヘッダーと外部ヘッダーの両方に基づいてトラフィックを照合できます。

要点：

プレフィルタポリシーの使用例2

プレフィルタポリシーでは、早期アクセス制御を提供し、フローがSnortエンジンを完全にバイパスできるようにするプレフィルタルールタイプを図に示すように使用できます。

タスク 1.デフォルトのPreFilterポリシーの確認

タスク要件：

デフォルトのプレフィルタポリシーの確認

ソリューション：

ステップ 1：[Policies] > [Access Control] > [Prefilter] に移動します。図に示すように、デフォルトのプレフィルタポリシーがすでに存在します。

ステップ 2：[Edit] を選択して、図に示すようにポリシー設定を表示します。

ステップ 3：図に示すように、プレフィルタポリシーはすでにアクセスコントロールポリシーに適用されています。

CLI(LINA)の検証

プレフィルタルールはACLの上に追加されます。

firepower# show access-list
access-list cached ACL log flows: total 0, denied 0 (deny-flow-max 4096)
            alert-interval 300
access-list CSM_FW_ACL_; 5 elements; name hash: 0x4a69e3f3
access-list CSM_FW_ACL_ line 1 remark rule-id 9998: PREFILTER POLICY: Default Tunnel and Priority Policy
access-list CSM_FW_ACL_ line 2 remark rule-id 9998: RULE: DEFAULT TUNNEL ACTION RULE
access-list CSM_FW_ACL_ line 3 advanced permit ipinip any any rule-id 9998 (hitcnt=0) 0xf5b597d6
access-list CSM_FW_ACL_ line 4 advanced permit 41 any any rule-id 9998 (hitcnt=0) 0x06095aba
access-list CSM_FW_ACL_ line 5 advanced permit gre any any rule-id 9998 (hitcnt=5) 0x52c7a066
access-list CSM_FW_ACL_ line 6 advanced permit udp any any eq 3544 rule-id 9998 (hitcnt=0) 0xcf6309bc

タスク 2.タグ付きトンネルトラフィックのブロック

タスク要件：

GREトンネル内でトンネリングされるICMPトラフィックをブロックします。

ソリューション：

ステップ 1：これらのACPを適用すると、図に示すように、Internet Control Message Protocol（ICMP；インターネット制御メッセージプロトコル）トラフィックが、GREトンネルを通過するかどうかにかかわらず、ブロックされていることがわかります。

R1# ping 192.168.76.39
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.76.39, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)

R1# ping 10.0.0.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.0.2, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)

この場合、プレフィルタポリシーを使用してタスク要件を満たすことができます。ロジックは次のとおりです。

1. GRE内にカプセル化されているすべてのパケットにタグを付けます。
2. タグ付きパケットに一致し、ICMPをブロックするアクセスコントロールポリシーを作成します。 

アーキテクチャの観点から、パケットはLInux NAatively(LINA)プレフィルタルールに対してチェックされ、次にSnortプレフィルタルールとACPがチェックされ、最後にSnortがLINAにドロップを指示します。最初のパケットはFTDデバイスを通過します。

ステップ 1：トンネリングされたトラフィックのタグを定義します。

[Policies] > [Access Control] > [Prefilter] に移動し、新しいプレフィルタポリシーを作成します。図に示すように、デフォルトのプレフィルタポリシーは編集できないことに注意してください。

プレフィルタポリシーでは、次の2種類のルールを定義できます。

1. トンネル規則
2. プレフィルタ規則

この2つは、プレフィルタポリシーで設定できる完全に異なる機能と考えることができます。

この作業では、図に示すようにトンネル規則を定義する必要があります。

アクションに関して：

ステップ 2：タグ付きトラフィックのアクセスコントロールポリシーを定義します。

最初は非常に直感的ではありませんが、Access Control Policy Rule（ACL；アクセスコントロールポリシー規則）によって送信元ゾーンとしてトンネルタグを使用できます。[Policies] > [Access Control] に移動し、図に示すように、タグ付きトラフィックのICMPをブロックするルールを作成します。

注：新しいプレフィルタポリシーがアクセスコントロールポリシーに適用されます。

検証：

LINAおよびCLISHでキャプチャを有効にします。

firepower# show capture
capture CAPI type raw-data trace interface inside [Capturing - 152 bytes]
capture CAPO type raw-data trace interface outside [Capturing - 152 bytes]

> capture-traffic
Please choose domain to capture traffic from:
  0 - br1
  1 - Router

Selection? 1

Please specify tcpdump options desired.
(or enter '?' for a list of supported options)
Options: -n

R1から、リモートGREトンネルエンドポイントへのpingを試みます。pingが失敗します。

R1# ping 10.0.0.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.0.2, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)

CLISHキャプチャは、最初のエコー要求がFTDを通過し、応答がブロックされたことを示します。

Options: -n
18:21:07.759939 IP 192.168.75.39 > 192.168.76.39: GREv0, length 104: IP 10.0.0.1 > 10.0.0.2: ICMP echo request, id 65, seq 0, length 80
18:21:07.759939 IP 192.168.76.39 > 192.168.75.39: GREv0, length 104: IP 10.0.0.2 > 10.0.0.1: ICMP echo reply, id 65, seq 0, length 80
18:21:09.759939 IP 192.168.75.39 > 192.168.76.39: GREv0, length 104: IP 10.0.0.1 > 10.0.0.2: ICMP echo request, id 65, seq 1, length 80
18:21:11.759939 IP 192.168.75.39 > 192.168.76.39: GREv0, length 104: IP 10.0.0.1 > 10.0.0.2: ICMP echo request, id 65, seq 2, length 80
18:21:13.759939 IP 192.168.75.39 > 192.168.76.39: GREv0, length 104: IP 10.0.0.1 > 10.0.0.2: ICMP echo request, id 65, seq 3, length 80
18:21:15.759939 IP 192.168.75.39 > 192.168.76.39: GREv0, length 104: IP 10.0.0.1 > 10.0.0.2: ICMP echo request, id 65, seq 4, length 80

LINAキャプチャは、これを確認します。

> show capture CAPI | include ip-proto-47
 102: 18:21:07.767523  192.168.75.39 > 192.168.76.39:  ip-proto-47, length 104
 107: 18:21:09.763739  192.168.75.39 > 192.168.76.39:  ip-proto-47, length 104
 111: 18:21:11.763769  192.168.75.39 > 192.168.76.39:  ip-proto-47, length 104
 115: 18:21:13.763784  192.168.75.39 > 192.168.76.39:  ip-proto-47, length 104
 120: 18:21:15.763830  192.168.75.39 > 192.168.76.39:  ip-proto-47, length 104
>
> show capture CAPO | include ip-proto-47
  93: 18:21:07.768133  192.168.75.39 > 192.168.76.39:  ip-proto-47, length 104
  94: 18:21:07.768438  192.168.76.39 > 192.168.75.39:  ip-proto-47, length 104

CLISH firewall-engine-debugを有効にし、LINA ASPドロップカウンタをクリアして、同じテストを実行します。CLISHデバッグは、エコー要求に対してプレフィルタルールに一致したこと、およびエコー応答に対してACPルールに一致したことを示しています。

10.0.0.1-8 > 10.0.0.2-0 1 AS 1 I 0 New session
10.0.0.1-8 > 10.0.0.2-0 1 AS 1 I 0 uses prefilter rule 268434441 with tunnel zone 1
10.0.0.1-8 > 10.0.0.2-0 1 AS 1 I 0 Starting with minimum 0, id 0 and SrcZone first with zones 1 -> -1, geo 0 -> 0, vlan 0, sgt tag: 65535, svc 0, payload 0, client 0, misc 0, user 9999997, icmpType 8, icmpCode 0
10.0.0.1-8 > 10.0.0.2-0 1 AS 1 I 0 pending rule order 3, 'Block ICMP', AppId
10.0.0.1-8 > 10.0.0.2-0 1 AS 1 I 0 uses prefilter rule 268434441 with tunnel zone 1
10.0.0.1-8 > 10.0.0.2-0 1 AS 1 I 0 Starting with minimum 0, id 0 and SrcZone first with zones 1 -> -1, geo 0 -> 0, vlan 0, sgt tag: 65535, svc 3501, payload 0, client 2000003501, misc 0, user 9999997, icmpType 0, icmpCode 0
10.0.0.1-8 > 10.0.0.2-0 1 AS 1 I 0 match rule order 3, 'Block ICMP', action Block
10.0.0.1-8 > 10.0.0.2-0 1 AS 1 I 0 deny action

ASPドロップは、Snortがパケットをドロップしたことを示します。

> show asp drop

Frame drop:
  No route to host (no-route)                                     366
  Reverse-path verify failed (rpf-violated)                         2
  Flow is denied by configured rule (acl-drop)                      2
  Snort requested to drop the frame (snort-drop)                    5

[Connection Events]に、一致したプレフィルタポリシーとルールが次の図のように表示されます。

タスク 3.FastpathプレフィルタルールによるSnortエンジンのバイパス

ネットワーク図

タスク要件：

1. 現在のアクセスコントロールポリシールールを削除し、すべてのトラフィックをブロックするアクセスコントロールポリシールールを追加します。
2. 192.168.75.0/24ネットワークを送信元とするトラフィックに対してSnortエンジンをバイパスするプレフィルタポリシールールを設定します。

ソリューション：

ステップ 1：すべてのトラフィックをブロックするアクセスコントロールポリシーを次の図に示します。

ステップ 2：図に示すように、ソースネットワーク192.168.75.0/24に対するアクションとしてFastpathを使用するプレフィルタルールを追加します。

ステップ 3：結果は図のようになります。

ステップ 4：[Save] と[Deploy] をクリックします。

両方のFTDインターフェイスでトレースによるキャプチャを有効にします。

firepower# capture CAPI int inside trace match icmp any any
firepower# capture CAPO int outsid trace match icmp any any

FTDを介してR1(192.168.75.39)からR2(192.168.76.39)へのpingを試みます。pingが失敗します。

R1# ping 192.168.76.39
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.76.39, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)

Insideインターフェイスのキャプチャは次のように表示されます。

firepower# show capture CAPI

5 packets captured

   1: 23:35:07.281738   192.168.75.39 > 192.168.76.39: icmp: echo request
   2: 23:35:09.278641   192.168.75.39 > 192.168.76.39: icmp: echo request
   3: 23:35:11.279251   192.168.75.39 > 192.168.76.39: icmp: echo request
   4: 23:35:13.278778   192.168.75.39 > 192.168.76.39: icmp: echo request
   5: 23:35:15.279282   192.168.75.39 > 192.168.76.39: icmp: echo request
5 packets shown

最初のパケットのトレース（エコー要求）は、次のように表示されます（重要なポイントは強調表示されています）。

Outsideインターフェイスのキャプチャは次のように表示されます。

firepower# show capture CAPO

10 packets captured

   1: 23:35:07.282044   192.168.75.39 > 192.168.76.39: icmp: echo request
   2: 23:35:07.282227   192.168.76.39 > 192.168.75.39: icmp: echo reply
   3: 23:35:09.278717   192.168.75.39 > 192.168.76.39: icmp: echo request
   4: 23:35:09.278962   192.168.76.39 > 192.168.75.39: icmp: echo reply
   5: 23:35:11.279343   192.168.75.39 > 192.168.76.39: icmp: echo request
   6: 23:35:11.279541   192.168.76.39 > 192.168.75.39: icmp: echo reply
   7: 23:35:13.278870   192.168.75.39 > 192.168.76.39: icmp: echo request
   8: 23:35:13.279023   192.168.76.39 > 192.168.75.39: icmp: echo reply
   9: 23:35:15.279373   192.168.75.39 > 192.168.76.39: icmp: echo request
  10: 23:35:15.279541   192.168.76.39 > 192.168.75.39: icmp: echo reply
10 packets shown

戻りパケットのトレースは、現在のフロー(52)と一致するが、ACLによってブロックされていることを示しています。

firepower# show capture CAPO packet-number 2 trace

10 packets captured

   2: 23:35:07.282227       192.168.76.39 > 192.168.75.39: icmp: echo reply
Phase: 1
Type: CAPTURE
Subtype:
Result: ALLOW
Config:
Additional Information:
MAC Access list

Phase: 2
Type: ACCESS-LIST
Subtype:
Result: ALLOW
Config:
Implicit Rule
Additional Information:
MAC Access list

Phase: 3
Type: FLOW-LOOKUP
Subtype:
Result: ALLOW
Config:
Additional Information:
Found flow with id 52, uses current flow

Phase: 4
Type: ACCESS-LIST
Subtype: log
Result: DROP
Config:
access-group CSM_FW_ACL_ global
access-list CSM_FW_ACL_ advanced deny ip any any rule-id 268434432 event-log flow-start
access-list CSM_FW_ACL_ remark rule-id 268434432: ACCESS POLICY: ACP_5506-1 - Default/1
access-list CSM_FW_ACL_ remark rule-id 268434432: L4 RULE: DEFAULT ACTION RULE
Additional Information:

Result:
input-interface: outside
input-status: up
input-line-status: up
Action: drop
Drop-reason: (acl-drop) Flow is denied by configured rule

ステップ 5：リターントラフィック用にもう1つプレフィルタルールを追加します。結果は図のようになります。

次に、表示された戻りパケットをトレースします（重要なポイントが強調表示されています）。

確認

ここでは、設定が正常に機能しているかどうかを確認します。

検証については、それぞれのタスクセクションで説明されています。

トラブルシュート

現在のところ、この設定に関する特定のトラブルシューティング情報はありません。

関連情報

• Cisco Firepower Management Center(FMC)コンフィギュレーションガイドのすべてのバージョンは、次の場所にあります。

Cisco Secure Firewall Threat Defenseに関するドキュメントのナビゲーション

• Cisco Global Technical Assistance Center(TAC)は、このビジュアルガイドを使用して、Cisco Firepowerの次世代セキュリティテクノロジーに関する実践的な知識を深めることを強く推奨します。このガイドには、次の記事で説明されている知識が含まれます。

Cisco Firepower Threat Defense（FTD）

• すべての設定とトラブルシューティングに関するテクニカルノート：

Cisco Secure Firewall Management Center

• テクニカル サポートとドキュメント – Cisco Systems