PDF(973.5 KB) View with Adobe Reader on a variety of devices
ePub(1.0 MB) View in various apps on iPhone, iPad, Android, Sony Reader, or Windows Phone
Mobi (Kindle)(843.5 KB) View on Kindle device or Kindle app on multiple devices
Updated:July 25, 2024
Document ID:212700
Bias-Free Language
The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.
This document describes the configuration and operation of Firepower Threat Defense (FTD) Prefilter Policies.
Prerequisites
Requirements
There are no specific requirements for this document.
Components Used
The information in this document is based on these software and hardware versions:
ASA5506X that runs FTD code 6.1.0-195
FireSIGHT Management Center (FMC) that runs 6.1.0-195
Two 3925 Cisco IOSĀ® routers that runs 15.2 images
The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, ensure that you understand the potential impact of any command.
Background Information
A Prefilter Policy is a feature introduced in 6.1 version and serves three main purposes:
Match traffic based on both inner and outer headers
Provide early Access Control which allows a flow to bypass Snort engine completely
Work as a placeholder for Access Control Entries (ACEs) that are migrated from Adaptive Security Appliance (ASA) migration tool.
Configure
Prefilter Policy Use Case 1
A Prefilter Policy can use a Tunnel Rule Type which allows FTD to filter based on both inside and/or outside IP header tunneled traffic. At the time this article was written, tunneled traffic refers to:
Generic Routing Encapsulation (GRE)
IP-in-IP
IPv6-in-IP
Teredo Port 3544
Consider a GRE tunnel as shown in the image.
When you ping from R1 to R2 with the use of a GRE tunnel, the traffic goes through the Firewall looks as shown in the image.
If the firewall is an ASA device, it checks the outer IP header as shown in the image.
If the firewall is a FirePOWER device, it checks the inner IP header as shown in the image.
With prefilter policy, an FTD device can match traffic based on both inner and outer headers.
Main point
Device
Checks
ASA
Outer IP
Snort
Inner IP
FTD
Outer (Prefilter) + Inner IP ( Access Control Policy(ACP))
Prefilter Policy Use Case 2
A Prefilter Policy can use a Prefilter Rule Type which can provide early Access Control and allow a flow to bypass Snort engine completely as shown in the image.
Task 1. Verify Default Prefilter Policy
Task requirement
Verify the default Prefilter Policy
Solution
Step 1. Navigate to Policies > Access Control > Prefilter. A default Prefilter Policy already exists as shown in the image.
Step 2. Choose Edit to see the policy settings as shown in the image.
Step 3. The Prefilter Policy is already attached to the Access Control Policy as shown in the image.
CLI (LINA) Verification
Prefilter rules are added on top of ACLs:
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
Task 2. Block Tunneled Traffic with Tag
Task requirement
Block ICMP traffic that is tunneled inside GRE tunnel.
Solution
Step 1. If you apply these ACP, you can see that Internet Control Message Protocol (ICMP) traffic is blocked, no matter if it goes through the GRE tunnel or not, as shown in the image.
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)
In this case, you can use a Prefilter Policy to meet the task requirement. The logic is as follows:
Tag all packets that are encapsulated inside GRE.
Create an Access Control Policy that matches the tagged packets and blocks ICMP.
From architecture point of view, the packets are checked against the LInux NAtively (LINA) pre-filter rules, then Snort pre-filter rules and ACP, and finally Snort instructs LINA to drop. The first packet makes it through the FTD device.
Step 1. Define a Tag for tunneled traffic.
Navigate to Policies > Access Control > Prefilter and create a new Prefilter Policy. Remember that the default Prefilter Policy cannot be edited as shown in the image.
Inside the Prefilter Policy, define two types of rules:
Tunnel Rule
Prefilter Rule
You can think of these two as totally different features that can be configured in a Prefilter Policy.
For this task, it is necessary to define a Tunnel Rule as shown in the image.
With regards to the Actions:
Action
Description
Analyze
After LINA, the flow is checked by Snort Engine. Optionally, a Tunnel Tag can be assigned to the tunneled traffic.
Block
The flow is blocked by LINA. The outer header is to be checked.
Fastpath
The flow is handled only by LINA without the need to engage the Snort engine.
Step 2. Define the Access Control Policy for the tagged traffic.
Although it cannot be very intuitive at first, the Tunnel Tag can be used by an Access Control Policy Rule as a Source Zone. Navigate to Policies > Access Control and create a Rule that blocks ICMP for the tagged traffic as shown in the image.
Note: The new Prefilter Policy is attached to the Access Control Policy.
Verification
Enable capture on LINA and on 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
From R1, try to ping the remote GRE tunnel endpoint. The ping fails:
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)
The CLISH capture shows that the first echo-request went through FTD and the reply was blocked:
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
Enable CLISH firewall-engine-debug, clear LINA ASP drop counters and do the same test. The CLISH debug shows that for the Echo-Request you matched the prefilter rule and for the Echo-Reply the ACP rule:
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
The ASP drop shows that Snort dropped the packets:
> 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
In the Connection Events, you can see the Prefilter Policy and Rule that you matched as shown in the image.
Task 3. Bypass Snort Engine with Fastpath Prefilter Rules
Network Diagram
Task requirement
Remove current Access Control Policy rules and add an Access Control Policy rule that Blocks all traffic.
Configure a Prefilter Policy rule that bypasses the Snort Engine for traffic sourced from the 192.168.75.0/24 network.
Solution
Step 1. Access Control Policy that Blocks all the traffic is as shown in the image.
Step 2. Add a Prefilter Rule with Fastpath as an action for source network 192.168.75.0/24 as shown in the image.
Step 3. The result is as shown in the image.
Step 4. Save and Deploy.
Enable capture with trace on both FTD interfaces:
firepower# capture CAPI int inside trace match icmp any any
firepower# capture CAPO int outsid trace match icmp any any
Try to ping from R1 (192.168.75.39) to R2 (192.168.76.39) through the FTD. Ping fails:
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)
Cisco Global Technical Assistance Center (TAC) strongly recommends this visual guide for in-depth practical knowledge on Cisco Firepower Next Generation Security Technologies, that includes the ones mentioned in this article: