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®ルータ

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

背景説明

Prefilter Policyは、6.1バージョンで導入された機能で、主に次の3つの目的を果たします。

1. 内部ヘッダーと外部ヘッダーの両方に基づいてトラフィックを照合
2. フローがSnortエンジンを完全にバイパスできるようにする早期アクセス制御の提供
3. 適応型セキュリティアプライアンス(ASA)移行ツールから移行されるアクセスコントロールエントリ(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：デフォルトのプレフィルタポリシーの確認

タスク要件：

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

ソリューション：

ステップ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を適用すると、図に示すように、GREトンネルを通過するかどうかに関係なく、Internet Control Message Protocol(ICMP)トラフィックがブロックされていることがわかります。

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をブロックするアクセスコントロールポリシーを作成します。 

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

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

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

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

• トンネルルール
• プレフィルタルール

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

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

アクションに関して：

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

最初はあまり直感的ではありませんが、トンネルタグはアクセスコントロールポリシールールによってソースゾーンとして使用できます。図に示すように、[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デバッグでは、Echo-RequestでプレフィルタルールとEcho-Replyで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 using 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 using 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 Prefilterルールを使用したSnortエンジンのバイパス

ネットワーク図

タスク要件：

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

ソリューション：

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

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

ステップ3：結果は図のように表示されます。

ステップ4：保存と配置を行います。

両方の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)

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

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

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

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

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, using existing 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コンフィギュレーションガイドのすべてのバージョンは、次の場所にあります。

https://www.cisco.com/c/en/us/td/docs/security/firepower/roadmap/firepower-roadmap.html#id_47280

• Cisco Global Technical Assistance Center(TAC)では、このビジュアルガイドを使用して、Cisco Firepower次世代セキュリティテクノロジーに関する詳細な実務知識を得ることを強く推奨しています。このガイドには、次の内容が含まれます。

http://www.ciscopress.com/title/9781587144806

• すべての設定およびトラブルシューティングのテクニカルノート：

https://www.cisco.com/c/en/us/support/security/defense-center/tsd-products-support-series-home.html

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