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

はじめに

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

前提条件

要件

このドキュメントに関する固有の要件はありません。

使用するコンポーネント

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

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

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

バックグラウンド情報

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

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

設定

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

プレフィルタポリシーでは、トンネル規則タイプを使用できます。このタイプでは、FTDが内部と外部の両方のIPヘッダートンネリングトラフィックに基づいてフィルタリングできます。この記事の執筆時点では、トンネルトラフィックとは次の意味を持ちます。

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

図に示すように、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を適用すると、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)

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

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

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

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

2. 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 dropカウンタをクリアして、同じテストを完了します。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 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.保存して展開します。

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

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

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 Threat Defense(FTD)におけるこの記事の説明も含め、Cisco Firepowerの次世代セキュリティテクノロジーに関する実践的な詳細な知識を習得できます

• すべての設定とトラブルシューティングのテクニカルノートについては、『Cisco Secure Firewall Management Center

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