FTD Prefilter ポリシーの設定およびオペレーション

概要

この資料は Firepower Threat Defense （FTD）前フィルタ ポリシーの設定およびオペレーションを記述したものです。

前提条件

要件

このドキュメントに関しては個別の要件はありません。

使用するコンポーネント

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

• FTD コード 6.1.0-195 を実行する ASA5506X
• FireSIGHT Management Center （FMC）その実行 6.1.0-195
• Cisco 2 人の 3925 人の IOS® ルータ 15.2 イメージを実行する

本書の情報は、特定のラボ環境にあるデバイスに基づいて作成されたものです。 このドキュメントで使用するすべてのデバイスは、初期（デフォルト）設定の状態から起動しています。 対象のネットワークが実稼働中である場合には、どのような作業についても、その潜在的な影響について確実に理解しておく必要があります。

背景説明

Prefilter ポリシーは 6.1 バージョンで導入される機能で、3 つの主な目的にかないます:

1. 内部および外ヘッダに基づいてトラフィックを一致する
2. フローが Snort エンジンを完全にバイパスするようにする早いアクセスコントロールを提供します
3. （ASA）移行 ツールから適応型セキュリティ アプライアンス（ASA）ソフトウェア移行されるアクセス制御エントリ（ACE）のためのプレースホルダーとしてはたらかせて下さい。

設定

前フィルタ ポリシー 使用例 1

前フィルタ ポリシーは FTD が内部両方および/または外部 IP ヘッダー トンネルトラフィックに基づいてフィルタリングするようにするトンネル規則の種類を使用できます。 この技術情報が書かれていた時、トンネルトラフィックは参照します:

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

イメージに示すように GREトンネルをここに考慮して下さい。

R1 から GREトンネルの使用の 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 エンジンを完全にバイパスするように許すできる Prefilter 規則の種類を使用できます。

タスク 1.はデフォルト前フィルタ ポリシーを確認します

タスク 要件:

デフォルト Prefilter ポリシーを確認して下さい

ソリューション：

ステップ 1.ポリシー > アクセスコントロール > Prefilter へのナビゲート。 既にイメージに示すように存在 するデフォルト Prefilter ポリシー。

ステップ 2.イメージに示すようにポリシー設定を見るために『Edit』 を選択 して下さい。

ステップ 3 前フィルタ ポリシーはイメージに示すようにアクセスコントロール ポリシーに既に接続されています。

CLI （リーナ）確認

前フィルタ ルールは 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.ブロック トンネルトラフィック

タスク 要件:

ブロック ICMP トラフィック GREトンネルの中でトンネル伝送される。

ソリューション：

ステップ 1： これらの ACP を適用する場合、GREトンネルを通過するかどうかイメージに示すように、関係、インターネット制御メッセージ プロトコル（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 をブロックするアクセスコントロール ポリシーを作成します。 

アーキテクチャ観点から、パケットはリーナ前フィルタ ルールに対してチェックされましたり、そしてルール前フィルタ鼻を鳴らし、ACP はおよび最終的に Snort リーナに廃棄するように指示します。 最初のパケットは FTD デバイスを通してそれを作ります。

ステップ 1.トンネルトラフィックのためのタグを定義して下さい。

ポリシー > アクセスコントロール > Prefilter にナビゲート し、Prefilter 新しいポリシーを作成して下さい。 デフォルト Prefilter ポリシーがイメージに示すように編集することができないことを覚えていて下さい。

Prefilter ポリシーの中で、ルールの 2 つの型を定義できます:

• トンネル ルール
• Prefilter ルール

Prefilter ポリシーで設定することができる全く違う機能としてこれら二つについて考えることができます。

このタスクに関しては、イメージに示すようにトンネル ルールを定義することは必要です。

操作に関して:

ステップ 2.タグ付きトラフィックのためのアクセスコントロール ポリシーを定義して下さい。

それが最初は非常に直観的ではないかもしれないがトンネル タグはソース ゾーンとしてアクセスコントロール ポリシー ルールによって使用することができます。 ポリシー > アクセスコントロールにナビゲート し、イメージに示すようにタグ付きトラフィックのための ICMP をブロックするルールを作成して下さい。

注: Prefilter 新しいポリシーはアクセスコントロール ポリシーに接続されます。

確認：

リーナと 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 キャプチャは最初の echo-request が 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

リーナ キャプチャはこれを確認します:

> 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 ファイアウォール エンジン デバッグを、リーナ クリア ASP ドロップ カウンタ 有効に し、同じテストをして下さい。 CLISH デバッグは Echo-Request のためにエコーリプライのための prefilter ルールと 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

接続イベントでは、Prefilter ポリシーを表示し、イメージに示すように一致したことを支配できます。

ファストパス Prefilter ルールのタスク 3.バイパス Snort エンジン

ネットワーク図

タスク 要件:

1. 既存のアクセスコントロール ポリシー ルールを取除き、すべてのトラフィックをブロックするアクセスコントロール ポリシー ルールを追加して下さい。
2. 192.168.75.0/24 ネットワークから送信されるトラフィックのための Snort エンジンをバイパスする Prefilter ポリシー ルールを設定して下さい。

ソリューション：

ステップ 1.アクセスコントロール ポリシーはイメージに示すようにすべてのトラフィックをブロックするあります。

ステップ 2.イメージに示すようにソースネットワーク 192.168.75.0/24 のための操作としてファストパスの Prefilter ルールを追加して下さい。

ステップ 3 結果はイメージに示すようにあります。

ステップ 4.保存および導入。

両方の FTD インターフェイスのトレースのキャプチャを有効に して下さい:

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

R1 から ping することを試みて下さい（192.168.75.39） R2 に（192.168.76.39） FTD によって。 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

最初パケット（echo-request）のトレースは示します（強調表示される重要な点）:

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, 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 つのより多くの prefilter ルールを追加して下さい。 結果はイメージに示すようにあります。

この場合見るリターンパケットをトレースして下さい（強調表示される重要な点）:

確認

このセクションでは、設定が正常に機能していることを確認します。

確認はそれぞれタスク セクションで説明されました。

トラブルシューティング

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

関連情報

• Cisco Firepower Management Center コンフィギュレーション ガイドのすべてのバージョンはここに見つけることができます:

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

• Cisco グローバル な テクニカル アシスタンス センタ （TAC）は強くこの技術情報で述べられる物を含む詳細で実用的なナレッジ Firepower 次世代のセキュリティ テクノロジーのためのこの視覚ガイドを、on Cisco 推奨します:

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