This document describes the various actions available on the Firepower Threat Defense (FTD) Access Control Policy (ACP) and Prefilter Policy. Furthermore, the background operation of each action is examined along with its interaction with other features like Flow Offload and protocols that open secondary connections.
Cisco recommends that you have knowledge of these topics:
The information in this document is based on these software and hardware versions:
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.
This document can be also used with these hardware and software versions:
Note: Flow Offload is only supported on FPR4100 and FPR9300 platforms.
FTD is a unified software image that consists of 2 main engines:
This figure shows how the 2 engines interact:
The FTD policy is configured on FMC when off-box (remote) management is used or Firepower Device Manager (FDM) when local management is used. In both scenarios, the ACP is deployed as:
The FTD ACP contains one or more rules and each rule can have one of these actions and as shown in the image:
Similarly, a Prefilter Policy can contain one or more rules and the possible actions are shown in the image:
Prefilter Policy got introduced in 6.1 version and serves 2 main purposes:
The Prefilter Rules are deployed on FTD as L3/L4 Access Control Elements (ACEs) and are placed above the ACP configured L3/L4 ACEs as shown in the image:
Note: Prefilter v/s ACP rules = first match is applied.
Consider the topology shown in the image:
The ACP contains a Block rule which uses a L4 condition (Destination Port TCP 80) as shown in the image:
The deployed policy in Snort:
268435461 deny any 192.168.1.40 32 any any 192.168.2.40 32 80 any 6
The deployed policy in LINA. Note that the rule is pushed as deny action:
firepower# show access-list … access-list CSM_FW_ACL_ line 9 remark rule-id 268435461: L4 RULE: Rule1 access-list CSM_FW_ACL_ line 10 advanced deny tcp host 192.168.1.40 host 192.168.2.40 eq www rule-id 268435461 event-log flow-start (hitcnt=0) 0x6149c43c
Verify Behavior:
When host-A (192.168.1.40) tries to open an HTTP session to host-B (192.168.2.40) the TCP synchronize (SYN) packets are dropped by the FTD LINA engine without reaching the Snort Engine or the destination:
firepower# show capture capture CAPI type raw-data buffer 33554432 trace trace-count 100 interface INSIDE [Capturing - 430 bytes] match ip host 192.168.1.40 any capture CAPO type raw-data buffer 33554432 trace trace-count 100 interface OUTSIDE [Capturing - 0 bytes] match ip host 192.168.1.40 any
firepower# show capture CAPI 1: 11:08:09.672801 192.168.1.40.32789 > 192.168.2.40.80: S 3249160620:3249160620(0) win 2920 <mss 1460,sackOK,timestamp 4060517 0> 2: 11:08:12.672435 192.168.1.40.32789 > 192.168.2.40.80: S 3249160620:3249160620(0) win 2920 <mss 1460,sackOK,timestamp 4063517 0> 3: 11:08:18.672847 192.168.1.40.32789 > 192.168.2.40.80: S 3249160620:3249160620(0) win 2920 <mss 1460,sackOK,timestamp 4069517 0> 4: 11:08:30.673610 192.168.1.40.32789 > 192.168.2.40.80: S 3249160620:3249160620(0) win 2920 <mss 1460,sackOK,timestamp 4081517 0>
firepower# show capture CAPI packet-number 1 trace 1: 11:08:09.672801 192.168.1.40.32789 > 192.168.2.40.80: S 3249160620:3249160620(0) win 2920 <mss 1460,sackOK,timestamp 4060517 0> ... Phase: 4 Type: ACCESS-LIST Subtype: log Result: DROP Config: access-group CSM_FW_ACL_ global access-list CSM_FW_ACL_ advanced deny tcp host 192.168.1.40 host 192.168.2.40 eq www rule-id 268435461 event-log flow-start access-list CSM_FW_ACL_ remark rule-id 268435461: ACCESS POLICY: ACP1 - Mandatory access-list CSM_FW_ACL_ remark rule-id 268435461: L4 RULE: Rule1 Additional Information: <- No Additional Information = No Snort Inspection Result: input-interface: INSIDE input-status: up input-line-status: up output-interface: OUTSIDE output-status: up output-line-status: up Action: drop Drop-reason: (acl-drop) Flow is denied by configured rule
The ACP contains a Block rule which uses a L7 condition (Application HTTP) as shown in the image:
The deployed policy in Snort:
268435461 deny any 192.168.1.40 32 any any 192.168.2.40 32 any any any (appid 676:1)
Appid 676:1 = HTTP
The deployed policy in LINA.
Note: The rule is pushed as a permit action because LINA cannot determine that the session uses HTTP. On FTD the Application Detection mechanism is in Snort engine.
firepower# show access-list … access-list CSM_FW_ACL_ line 9 remark rule-id 268435461: L7 RULE: Rule1 access-list CSM_FW_ACL_ line 10 advanced permit ip host 192.168.1.40 host 192.168.2.40 rule-id 268435461 (hitcnt=0) 0xb788b786
For a Block Rule that uses Application as a condition, the trace of a real packet shows that the session is dropped by the LINA due to Snort engine verdict.
Note: In order for the Snort engine to determine the application it has to inspect a few packets (usually 3-10 which depends on the application decoder). Thus a few packets are allowed through the FTD and they make it to the destination. The allowed packets are still subject to the Intrusion Policy check based on the Access Policy > Advanced > 'Intrusion Policy used before Access Control rule is determined' option.
Verify Behavior:
When host-A (192.168.1.40) tries to establish an HTTP session with host-B (192.168.2.40) the LINA ingress capture shows:
firepower# show capture CAPI 8 packets captured 1: 11:31:19.825564 192.168.1.40.32790 > 192.168.2.40.80: S 357753151:357753151(0) win 2920 <mss 1460,sackOK,timestamp 5450579 0> 2: 11:31:19.826403 192.168.2.40.80 > 192.168.1.40.32790: S 1283931030:1283931030(0) ack 357753152 win 2896 <mss 1380,sackOK,timestamp 5449236 5450579> 3: 11:31:19.826556 192.168.1.40.32790 > 192.168.2.40.80: P 357753152:357753351(199) ack 1283931031 win 2920 <nop,nop,timestamp 5450580 5449236> 4: 11:31:20.026899 192.168.1.40.32790 > 192.168.2.40.80: P 357753152:357753351(199) ack 1283931031 win 2920 <nop,nop,timestamp 5450781 5449236> 5: 11:31:20.428887 192.168.1.40.32790 > 192.168.2.40.80: P 357753152:357753351(199) ack 1283931031 win 2920 <nop,nop,timestamp 5451183 5449236> ...
The egress capture:
firepower# show capture CAPO 5 packets captured 1: 11:31:19.825869 192.168.1.40.32790 > 192.168.2.40.80: S 1163713179:1163713179(0) win 2920 <mss 1380,sackOK,timestamp 5450579 0> 2: 11:31:19.826312 192.168.2.40.80 > 192.168.1.40.32790: S 354801457:354801457(0) ack 1163713180 win 2896 <mss 1460,sackOK,timestamp 5449236 5450579> 3: 11:31:23.426049 192.168.2.40.80 > 192.168.1.40.32790: S 354801457:354801457(0) ack 1163713180 win 2896 <mss 1460,sackOK,timestamp 5452836 5450579> 4: 11:31:29.426430 192.168.2.40.80 > 192.168.1.40.32790: S 354801457:354801457(0) ack 1163713180 win 2896 <mss 1460,sackOK,timestamp 5458836 5450579> 5: 11:31:41.427208 192.168.2.40.80 > 192.168.1.40.32790: S 354801457:354801457(0) ack 1163713180 win 2896 <mss 1460,sackOK,timestamp 5470836 5450579>
Trace shows that the first packet (TCP SYN) is allowed by the Snort since the Application Detection verdict is pending:
firepower# show capture CAPI packet-number 1 trace 1: 11:31:19.825564 192.168.1.40.32790 > 192.168.2.40.80: S 357753151:357753151(0) win 2920 <mss 1460,sackOK,timestamp 5450579 0> ... Phase: 4 Type: ACCESS-LIST Subtype: log Result: ALLOW Config: access-group CSM_FW_ACL_ global access-list CSM_FW_ACL_ advanced permit ip host 192.168.1.40 host 192.168.2.40 rule-id 268435461 access-list CSM_FW_ACL_ remark rule-id 268435461: ACCESS POLICY: ACP1 - Mandatory access-list CSM_FW_ACL_ remark rule-id 268435461: L7 RULE: Rule1 Additional Information: This packet will be sent to snort for additional processing where a verdict will be reached ... Phase: 10 Type: FLOW-CREATION Subtype: Result: ALLOW Config: Additional Information: New flow created with id 23194, packet dispatched to next module … Phase: 12 Type: SNORT Subtype: Result: ALLOW Config: Additional Information: Snort Trace: Packet: TCP, SYN, seq 357753151 AppID: service unknown (0), application unknown (0) Firewall: starting rule matching, zone -1 -> -1, geo 0 -> 0, vlan 0, sgt 65535, user 9999997, icmpType 0, icmpCode 0 Firewall: pending rule-matching, id 268435461, pending AppID NAP id 1, IPS id 0, Verdict PASS Snort Verdict: (pass-packet) allow this packet Result: input-interface: OUTSIDE input-status: up input-line-status: up output-interface: OUTSIDE output-status: up output-line-status: up Action: allow
The same for the TCP SYN/ACK packet:
firepower# show capture CAPO packet-number 2 trace 2: 11:31:19.826312 192.168.2.40.80 > 192.168.1.40.32790: S 354801457:354801457(0) ack 1163713180 win 2896 <mss 1460,sackOK,timestamp 5449236 5450579> … Phase: 3 Type: FLOW-LOOKUP Subtype: Result: ALLOW Config: Additional Information: Found flow with id 23194, using existing flow … Phase: 5 Type: SNORT Subtype: Result: ALLOW Config: Additional Information: Snort Trace: Packet: TCP, SYN, ACK, seq 1283931030, ack 357753152 AppID: service unknown (0), application unknown (0) Firewall: starting rule matching, zone -1 -> -1, geo 0 -> 0, vlan 0, sgt 65535, user 9999997, icmpType 0, icmpCode 0 Firewall: pending rule-matching, id 268435461, pending AppID NAP id 1, IPS id 0, Verdict PASS Snort Verdict: (pass-packet) allow this packet Result: input-interface: INSIDE input-status: up input-line-status: up output-interface: INSIDE output-status: up output-line-status: up Action: allow
Snort returns a DROP verdict after inspecting the third packet:
firepower# show capture CAPI packet-number 3 trace 3: 11:31:19.826556 192.168.1.40.32790 > 192.168.2.40.80: P 357753152:357753351(199) ack 1283931031 win 2920 <nop,nop,timestamp 5450580 5449236> Phase: 3 Type: FLOW-LOOKUP Subtype: Result: ALLOW Config: Additional Information: Found flow with id 23194, using existing flow Phase: 5 Type: SNORT Subtype: Result: DROP Config: Additional Information: Snort Trace: Packet: TCP, ACK, seq 357753152, ack 1283931031 AppID: service HTTP (676), application unknown (0) Firewall: starting rule matching, zone -1 -> -1, geo 0(0) -> 0, vlan 0, sgt 65535, user 9999997, url http://192.168.2.40/128k.html Firewall: block rule, id 268435461, drop Snort: processed decoder alerts or actions queue, drop NAP id 1, IPS id 0, Verdict BLACKLIST, Blocked by Firewall Snort Verdict: (black-list) black list this flow Result: input-interface: INSIDE input-status: up input-line-status: up Action: drop Drop-reason: (firewall) Blocked or blacklisted by the firewall preprocessor
You can also run the command system support trace from FTD CLISH mode. This tool provides 2 functions:
Here is the output:
> system support trace Please specify an IP protocol: tcp Please specify a client IP address: 192.168.1.40 Please specify a client port: Please specify a server IP address: 192.168.2.40 Please specify a server port: Enable firewall-engine-debug too? [n]: y Monitoring packet tracer debug messages Tracing enabled by Lina 192.168.2.40-80 - 192.168.1.40-32791 6 Packet: TCP, SYN, seq 2620409313 192.168.2.40-80 - 192.168.1.40-32791 6 AppID: service unknown (0), application unknown (0) 192.168.1.40-32791 > 192.168.2.40-80 6 AS 1 I 0 New session 192.168.1.40-32791 > 192.168.2.40-80 6 AS 1 I 0 Starting with minimum 2, 'Rule1', and SrcZone first with zones -1 -> -1, geo 0 -> 0, vlan 0, inline sgt tag: untagged, ISE sgt id: 0, svc 0, payload 0, client 0, misc 0, user 9999997, icmpType 0, icmpCode 0 192.168.1.40-32791 > 192.168.2.40-80 6 Firewall: starting rule matching, zone -1 -> -1, geo 0 -> 0, vlan 0, sgt 65535, user 9999997, icmpType 0, icmpCode 0 192.168.1.40-32791 > 192.168.2.40-80 6 AS 1 I 0 pending rule order 2, 'Rule1', AppID 192.168.1.40-32791 > 192.168.2.40-80 6 Firewall: pending rule-matching, 'Rule1', pending AppID 192.168.1.40-32791 > 192.168.2.40-80 6 NAP id 1, IPS id 0, Verdict PASS Trace buffer and verdict reason are sent to DAQ's PDTS Tracing enabled by Lina 192.168.2.40-80 - 192.168.1.40-32791 6 Packet: TCP, SYN, ACK, seq 3700371680, ack 2620409314 192.168.2.40-80 - 192.168.1.40-32791 6 AppID: service unknown (0), application unknown (0) 192.168.1.40-32791 > 192.168.2.40-80 6 AS 1 I 0 Starting with minimum 2, 'Rule1', and SrcZone first with zones -1 -> -1, geo 0 -> 0, vlan 0, inline sgt tag: untagged, ISE sgt id: 0, svc 0, payload 0, client 0, misc 0, user 9999997, icmpType 0, icmpCode 0 192.168.1.40-32791 > 192.168.2.40-80 6 Firewall: starting rule matching, zone -1 -> -1, geo 0 -> 0, vlan 0, sgt 65535, user 9999997, icmpType 0, icmpCode 0 192.168.1.40-32791 > 192.168.2.40-80 6 AS 1 I 0 pending rule order 2, 'Rule1', AppID 192.168.1.40-32791 > 192.168.2.40-80 6 Firewall: pending rule-matching, 'Rule1', pending AppID 192.168.1.40-32791 > 192.168.2.40-80 6 NAP id 1, IPS id 0, Verdict PASS Trace buffer and verdict reason are sent to DAQ's PDTS Tracing enabled by Lina 192.168.2.40-80 - 192.168.1.40-32791 6 Packet: TCP, ACK, seq 2620409314, ack 3700371681 192.168.2.40-80 - 192.168.1.40-32791 6 AppID: service HTTP (676), application unknown (0) 192.168.1.40-32791 > 192.168.2.40-80 6 AS 1 I 0 Starting with minimum 2, 'Rule1', and SrcZone first with zones -1 -> -1, geo 0(0) -> 0, vlan 0, inline sgt tag: untagged, ISE sgt id: 0, svc 676, payload 0, client 686, misc 0, user 9999997, url http://192.168.2.40/128k.html, xff 192.168.1.40-32791 > 192.168.2.40-80 6 Firewall: starting rule matching, zone -1 -> -1, geo 0(0) -> 0, vlan 0, sgt 65535, user 9999997, url http://192.168.2.40/128k.html 192.168.1.40-32791 > 192.168.2.40-80 6 AS 1 I 0 match rule order 2, 'Rule1', action Block 192.168.1.40-32791 > 192.168.2.40-80 6 AS 1 I 0 deny action 192.168.1.40-32791 > 192.168.2.40-80 6 Firewall: block rule, 'Rule1', drop 192.168.1.40-32791 > 192.168.2.40-80 6 Snort: processed decoder alerts or actions queue, drop 192.168.1.40-32791 > 192.168.2.40-80 6 AS 1 I 0 Deleting session 192.168.1.40-32791 > 192.168.2.40-80 6 NAP id 1, IPS id 0, Verdict BLACKLIST 192.168.1.40-32791 > 192.168.2.40-80 6 ===> Blocked by Firewall
Summary
Normally, you would configure an Allow rule to specify additional inspections like an Intrusion Policy and/or a File Policy. In this first scenario here, is demonstrated the operation of an Allow rule when L3/L4 condition is applied.
Consider this topology as shown in the image:
This policy is applied as shown in the image:
The deployed policy in Snort. Note that the rule is deployed as an allow action:
# Start of AC rule. 268435461 allow any 192.168.1.40 32 any any 192.168.2.40 32 80 any 6
The policy in LINA.
Note: The rule is deployed as a permit action which essentially means redirect to Snort for further inspection.
firepower# show access-list … access-list CSM_FW_ACL_ line 9 remark rule-id 268435461: L7 RULE: Rule1 access-list CSM_FW_ACL_ line 10 advanced permit tcp host 192.168.1.40 host 192.168.2.40 eq www rule-id 268435461 (hitcnt=1) 0x641a20c3
In order to see how a flow that matches an Allow rule is handled by FTD there are a few ways:
LINA capture vs Snort capture-traffic:
Verify Behavior:
Clear the Snort statistics, enable system support trace from CLISH and initiate an HTTP flow from host-A (192.168.1.40) to host-B (192.168.2.40). All the packets are forwarded to the Snort engine and get the PASS verdict by the Snort:
firepower# clear snort statistics
> system support trace Please specify an IP protocol: Please specify a client IP address: 192.168.1.40 Please specify a client port: Please specify a server IP address: 192.168.2.40 Please specify a server port: Enable firewall-engine-debug too? [n]: Monitoring packet tracer debug messages Tracing enabled by Lina 192.168.2.40-80 - 192.168.1.40-32797 6 Packet: TCP, SYN, seq 361134402 192.168.2.40-80 - 192.168.1.40-32797 6 AppID: service unknown (0), application unknown (0) 192.168.1.40-32797 > 192.168.2.40-80 6 Firewall: allow rule, 'Rule1', allow 192.168.1.40-32797 > 192.168.2.40-80 6 NAP id 1, IPS id 0, Verdict PASS Trace buffer and verdict reason are sent to DAQ's PDTS Tracing enabled by Lina 192.168.2.40-80 - 192.168.1.40-32797 6 Packet: TCP, SYN, ACK, seq 1591434735, ack 361134403 192.168.2.40-80 - 192.168.1.40-32797 6 AppID: service unknown (0), application unknown (0) 192.168.1.40-32797 > 192.168.2.40-80 6 Firewall: allow rule, 'Rule1', allow 192.168.1.40-32797 > 192.168.2.40-80 6 NAP id 1, IPS id 0, Verdict PASS Trace buffer and verdict reason are sent to DAQ's PDTS Tracing enabled by Lina 192.168.2.40-80 - 192.168.1.40-32797 6 Packet: TCP, ACK, seq 361134403, ack 1591434736 192.168.2.40-80 - 192.168.1.40-32797 6 AppID: service HTTP (676), application unknown (0) 192.168.1.40-32797 > 192.168.2.40-80 6 Firewall: allow rule, 'Rule1', allow 192.168.1.40-32797 > 192.168.2.40-80 6 NAP id 1, IPS id 0, Verdict PASS
Snort statistics reflect the above Snort PASS verdicts:
> show snort statistics Packet Counters: Passed Packets 54 Blocked Packets 0 Injected Packets 0 Packets bypassed (Snort Down) 0 Packets bypassed (Snort Busy) 0 Flow Counters: Fast-Forwarded Flows 0 Blacklisted Flows 0 ...
Passed Packets = Inspected by the Snort engine
Similar behavior is seen when the Allow rule is deployed as follows.
Only a L3/L4 condition as shown in the image:
A L7 condition (e.g. Intrusion Policy, File Policy, Application etc) as shown in the image:
Summary
In order to summarize, this is how a flow is handled by an FTD deployed on a FP4100/9300 when an Allow rule is matched as shown in the image:
Note: Management Input Output (MIO) is the Supervisor engine of the firepower chassis.
There are specific scenarios where the FTD Snort engine gives a WHITELIST verdict (fast-forward) and the rest of the flow is offloaded to the LINA engine (in some cases then is offloaded to the HW Accelarator - SmartNIC). These are:
The above can be visualized to:
or in some cases to:
Main Points
Use Cases
You would configure an Allow rule when you need L7 inspection by Snort Engine such as:
If you don't want to apply any L7 actions at Snort level (e.g. Intrusion Policy, File Policy, Application Detection, URL Filtering, Security Intelligence etc) then it is recommended to use the Trust action in your rule.
Consider the topology as shown in the image:
This policy is applied as shown in the image:
The Trust rule as it is deployed in FTD Snort engine:
# Start of AC rule. 268435461 fastpath any 192.168.1.40 32 any any 192.168.2.40 32 80 any 6
Note: The number 6 is the protocol (TCP).
The rule in FTD LINA:
access-list CSM_FW_ACL_ line 10 advanced permit tcp host 192.168.1.40 host 192.168.2.40 eq www rule-id 268435461 (hitcnt=0) 0x641a20c3
Verify Behavior:
Initiate an HTTP session from host-A (192.168.1.40) to host-B (192.168.2.40) while you are running the system support trace CLI tool. There is only one packet (the TCP SYN) that is forwarded to Snort engine. Snort engine sends to LINA the WHITELIST verdict which essentially offloads the rest of the flow to the LINA itself:
> system support trace Please specify an IP protocol: tcp Please specify a client IP address: 192.168.1.40 Please specify a client port: Please specify a server IP address: 192.168.2.40 Please specify a server port: Enable firewall-engine-debug too? [n]: Monitoring packet tracer debug messages Tracing enabled by Lina 192.168.2.40-80 - 192.168.1.40-32791 6 Packet: TCP, SYN, seq 69186463 192.168.2.40-80 - 192.168.1.40-32791 6 AppID: service unknown (0), application unknown (0) 192.168.1.40-32791 > 192.168.2.40-80 6 Firewall: trust/fastpath rule, 'Rule1', allow 192.168.1.40-32791 > 192.168.2.40-80 6 NAP id 1, IPS id 0, Verdict WHITELIST
LINA capture shows the flow which goes through it:
> show capture CAPI 29 packets captured 1: 19:14:29.214817 192.168.1.40.32791 > 192.168.2.40.80: S 69186463:69186463(0) win 2920 <mss 1460,sackOK,timestamp 3139222 0> 2: 19:14:29.215549 192.168.2.40.80 > 192.168.1.40.32791: S 413254738:413254738(0) ack 69186464 win 2896 <mss 1380,sackOK,timestamp 3137895 3139222> 3: 19:14:29.215687 192.168.1.40.32791 > 192.168.2.40.80: P 69186464:69186662(198) ack 413254739 win 2920 <nop,nop,timestamp 3139223 3137895> 4: 19:14:29.216038 192.168.2.40.80 > 192.168.1.40.32791: . 413254739:413256107(1368) ack 69186662 win 2698 <nop,nop,timestamp 3137896 3139223> 5: 19:14:29.216053 192.168.2.40.80 > 192.168.1.40.32791: P 413256107:413257475(1368) ack 69186662 win 2698 <nop,nop,timestamp 3137896 3139223> 6: 19:14:29.216144 192.168.1.40.32791 > 192.168.2.40.80: . ack 413257475 win 2736 <nop,nop,timestamp 3139224 3137896> 7: 19:14:29.216251 192.168.2.40.80 > 192.168.1.40.32791: P 413257475:413258843(1368) ack 69186662 win 2698 <nop,nop,timestamp 3137896 3139224> …
when you trace the first packet, you can see the WHITELIST verdict:
firepower# show capture CAPI packet-number 1 trace 1: 19:14:29.214817 192.168.1.40.32791 > 192.168.2.40.80: S 69186463:69186463(0) win 2920 <mss 1460,sackOK,timestamp 3139222 0> … Phase: 4 Type: ACCESS-LIST Subtype: log Result: ALLOW Config: access-group CSM_FW_ACL_ global access-list CSM_FW_ACL_ advanced permit tcp host 192.168.1.40 host 192.168.2.40 eq www rule-id 268435461 access-list CSM_FW_ACL_ remark rule-id 268435461: ACCESS POLICY: ACP1 - Mandatory access-list CSM_FW_ACL_ remark rule-id 268435461: L7 RULE: Rule1 Additional Information: This packet will be sent to snort for additional processing where a verdict will be reached … Phase: 12 Type: SNORT Subtype: Result: ALLOW Config: Additional Information: Snort Trace: Packet: TCP, SYN, seq 69186463 AppID: service unknown (0), application unknown (0) Firewall: trust/fastpath rule, id 268435461, allow NAP id 1, IPS id 0, Verdict WHITELIST Snort Verdict: (fast-forward) fast forward this flow
For the rest of the flow (e.g. TCP SYN/ACK) you see:
firepower# show capture CAPO packet-number 2 trace 2: 19:14:29.215503 192.168.2.40.80 > 192.168.1.40.32791: S 60351089:60351089(0) ack 1577779944 win 2896 <mss 1460,sackOK,timestamp 3137895 3139222> … Phase: 3 Type: FLOW-LOOKUP Subtype: Result: ALLOW Config: Additional Information: Found flow with id 25353, using existing flow Phase: 4 Type: SNORT Subtype: Result: ALLOW Config: Additional Information: Snort Verdict: (fast-forward) fast forward this flow
Snort statistics confirm this:
> show snort statistics Packet Counters: Passed Packets 0 Blocked Packets 0 Injected Packets 0 Packets bypassed (Snort Down) 0 Packets bypassed (Snort Busy) 0 Flow Counters: Fast-Forwarded Flows 1 Blacklisted Flows 0 ... 0
Snort-level capture also confirms this:
> capture-traffic Please choose domain to capture traffic from: 0 - management0 1 - Router Selection? 1 Please specify tcpdump options desired. (or enter '?' for a list of supported options) Options: -n 19:04:17.429711 IP 192.168.1.40.32791 > 192.168.2.40.80: Flags [S], seq 69186463, win 2920, options [mss 1380,sackOK,TS val 2527484 ecr 0], length 0
Tip: The 'n' parameter does not convert IP addresses to names.
Consider this ACP rule as shown in the image:
The rule as it is deployed in FTD Snort engine:
268435461 fastpath any 192.168.1.40 32 any any 192.168.2.40 32 any any any (appid 676:1)
The rule in FTD LINA:
access-list CSM_FW_ACL_ line 10 advanced permit ip host 192.168.1.40 host 192.168.2.40 rule-id 268435461 (hitcnt=0) 0xb788b786
Verify Behavior
Initiate an HTTP session from host-A (192.168.1.40) to host-B (192.168.2.40) while you run system support trace CLI tool. There are a few packets (2 in this case) that are sent to Snort engine and get the PASS Verdict while the AppID is pending. After Snort determines the Application it forwards the WHITELIST Verdict to LINA and the rest of the flow is handled by LINA:
> system support trace Please specify an IP protocol: tcp Please specify a client IP address: 192.168.1.40 Please specify a client port: Please specify a server IP address: 192.168.2.40 Please specify a server port: Enable firewall-engine-debug too? [n]: Monitoring packet tracer debug messages Tracing enabled by Lina 192.168.2.40-80 - 192.168.1.40-32836 6 Packet: TCP, SYN, seq 3970971741 192.168.2.40-80 - 192.168.1.40-32836 6 AppID: service unknown (0), application unknown (0) 192.168.1.40-32836 > 192.168.2.40-80 6 Firewall: starting rule matching, zone -1 -> -1, geo 0 -> 0, vlan 0, sgt 65535, user 9999997, icmpType 0, icmpCode 0 192.168.1.40-32836 > 192.168.2.40-80 6 Firewall: pending rule-matching, 'Rule1', pending AppID 192.168.1.40-32836 > 192.168.2.40-80 6 NAP id 1, IPS id 0, Verdict PASS Trace buffer and verdict reason are sent to DAQ's PDTS Tracing enabled by Lina 192.168.2.40-80 - 192.168.1.40-32836 6 Packet: TCP, SYN, ACK, seq 18638120, ack 3970971742 192.168.2.40-80 - 192.168.1.40-32836 6 AppID: service unknown (0), application unknown (0) 192.168.1.40-32836 > 192.168.2.40-80 6 Firewall: starting rule matching, zone -1 -> -1, geo 0 -> 0, vlan 0, sgt 65535, user 9999997, icmpType 0, icmpCode 0 192.168.1.40-32836 > 192.168.2.40-80 6 Firewall: pending rule-matching, 'Rule1', pending AppID 192.168.1.40-32836 > 192.168.2.40-80 6 NAP id 1, IPS id 0, Verdict PASS Trace buffer and verdict reason are sent to DAQ's PDTS Tracing enabled by Lina 192.168.2.40-80 - 192.168.1.40-32836 6 Packet: TCP, ACK, seq 3970971742, ack 18638121 192.168.2.40-80 - 192.168.1.40-32836 6 AppID: service HTTP (676), application unknown (0) 192.168.1.40-32836 > 192.168.2.40-80 6 Firewall: starting rule matching, zone -1 -> -1, geo 0(0) -> 0, vlan 0, sgt 65535, user 9999997, url http://192.168.2.40/16k.html 192.168.1.40-32836 > 192.168.2.40-80 6 Firewall: trust/fastpath rule, 'Rule1', allow 192.168.1.40-32836 > 192.168.2.40-80 6 NAP id 1, IPS id 0, Verdict WHITELIST
LINA capture shows that the packet # 3 had the HTTP GET method:
firepower# show capture CAPI dump 1: 11:24:38.895888 192.168.1.40.32836 > 192.168.2.40.80: S 3970971741:3970971741(0) win 2920 <mss 1460,sackOK,timestamp 320516154 0> 0x0000 2c33 118d 570e 00c0 a801 2800 0800 4500 ,3..W.....(...E. 0x0010 0038 c03d 0000 4006 35e2 c0a8 0128 c0a8 .8.=..@.5....(.. 0x0020 0228 8044 0050 ecb0 385d 0000 0000 9002 .(.D.P..8]...... 0x0030 0b68 630e 0000 0204 05b4 0402 080a 131a .hc............. 0x0040 b03a 0000 0000 .:.... 2: 11:24:38.896682 192.168.2.40.80 > 192.168.1.40.32836: S 18638120:18638120(0) ack 3970971742 win 2896 <mss 1380,sackOK,timestamp 320514827 320516154> 0x0000 00c0 a801 2800 2c33 118d 570e 0800 4500 ....(.,3..W...E. 0x0010 0038 1d1e 0000 4006 d901 c0a8 0228 c0a8 .8....@......(.. 0x0020 0128 0050 8044 011c 6528 ecb0 385e 9012 .(.P.D..e(..8^.. 0x0030 0b50 3efb 0000 0204 0564 0402 080a 131a .P>......d...... 0x0040 ab0b 131a b03a .....: 3: 11:24:38.896849 192.168.1.40.32836 > 192.168.2.40.80: P 3970971742:3970971940(198) ack 18638121 win 2920 <nop,nop,timestamp 320516155 320514827> 0x0000 2c33 118d 570e 00c0 a801 2800 0800 4500 ,3..W.....(...E. 0x0010 00fa c03e 0000 4006 351f c0a8 0128 c0a8 ...>..@.5....(.. 0x0020 0228 8044 0050 ecb0 385e 011c 6529 8018 .(.D.P..8^..e).. 0x0030 0b68 0f62 0000 0101 080a 131a b03b 131a .h.b.........;.. 0x0040 ab0b 4745 5420 2f31 366b 2e68 746d 6c20 ..GET /16k.html 0x0050 4854 5450 2f31 2e30 0d0a 486f 7374 3a20 HTTP/1.0..Host:
...
Snort statistics confirm the above:
> show snort statistics Packet Counters: Passed Packets 2 Blocked Packets 0 Injected Packets 0 Packets bypassed (Snort Down) 0 Packets bypassed (Snort Busy) 0 Flow Counters: Fast-Forwarded Flows 1 Blacklisted Flows 0 ...
On FTD which runs on FP4100/9300 appliance scenarios 1 and 2 can be visualized as shown in the image:
In case you want the FTD to apply Security Intelligence (SI) checks to all flows SI is already enabled at ACP level and you can specify the SI sources (TALOS, feeds, lists etc). On the other hand, in case you want to disable it, you disable SI for Networks globally per ACP, SI for URL and SI for DNS. The SI for Networks and URL is disabled as shown in the image:
In this case the Trust rule is deployed to LINA as full trust:
> show access-list
... access-list CSM_FW_ACL_ line 9 remark rule-id 268435461: L4 RULE: Rule1 access-list CSM_FW_ACL_ line 10 advanced trust ip host 192.168.1.40 host 192.168.2.40 rule-id 268435461 event-log flow-end (hitcnt=0) 0x5c1346d6
Note: As from 6.2.2 FTD supports TID. TID works in a way similar to SI, but in case SI is disabled, it does not ‘force’ packet redirection to Snort engine for TID inspection.
Verify the behavior
Initiate an HTTP session from host-A (192.168.1.40) to host-B (192.168.2.40). Since this an FP4100 and supports Flow Offload in hardware these things happen:
The FTD LINA connection table shows the flag ‘o’ which means the flow was offloaded to HW. Also note the absence of ‘N’ flag. This essentially means 'no Snort redirection':
firepower# show conn 1 in use, 15 most used TCP OUTSIDE 192.168.2.40:80 INSIDE 192.168.1.40:32809, idle 0:00:00, bytes 949584, flags UIOo
Snort statistics shows only logging events at the start and at the end of the session:
firepower# show snort statistics Packet Counters: Passed Packets 0 Blocked Packets 0 Injected Packets 0 Packets bypassed (Snort Down) 0 Packets bypassed (Snort Busy) 0 Flow Counters: Fast-Forwarded Flows 0 Blacklisted Flows 0 Miscellaneous Counters: Start-of-Flow events 1 End-of-Flow events 1
FTD LINA logs show that for each session there were 2 flows (one per each direction) offloaded to HW:
Sep 27 2017 20:16:05: %ASA-7-609001: Built local-host INSIDE:192.168.1.40 Sep 27 2017 20:16:05: %ASA-6-302013: Built inbound TCP connection 25384 for INSIDE:192.168.1.40/32809 (192.168.1.40/32809) to OUTSIDE:192.168.2.40/80 (192.168.2.40/80) Sep 27 2017 20:16:05: %ASA-6-805001: Offloaded TCP Flow for connection 25384 from INSIDE:192.168.1.40/32809 (192.168.1.40/32809) to OUTSIDE:192.168.2.40/80 (192.168.2.40/80) Sep 27 2017 20:16:05: %ASA-6-805001: Offloaded TCP Flow for connection 25384 from OUTSIDE:192.168.2.40/80 (192.168.2.40/80) to INSIDE:192.168.1.40/32809 (192.168.1.40/32809) Sep 27 2017 20:16:05: %ASA-6-805002: TCP Flow is no longer offloaded for connection 25384 from OUTSIDE:192.168.2.40/80 (192.168.2.40/80) to INSIDE:192.168.1.40/32809 (192.168.1.40/32809) Sep 27 2017 20:16:05: %ASA-6-805002: TCP Flow is no longer offloaded for connection 25384 from INSIDE:192.168.1.40/32809 (192.168.1.40/32809) to OUTSIDE:192.168.2.40/80 (192.168.2.40/80) Sep 27 2017 20:16:05: %ASA-6-302014: Teardown TCP connection 25384 for INSIDE:192.168.1.40/32809 to OUTSIDE:192.168.2.40/80 duration 0:00:00 bytes 1055048 TCP FINs Sep 27 2017 20:16:05: %ASA-7-609002: Teardown local-host INSIDE:192.168.1.40 duration 0:00:00
On FTD which runs on FP4100/9300 appliance scenarios 1 and 2 can be visualized as shown in the image:
Use Cases
Consider the topology as shown in the image:
Consider also the policy as shown in the image:
This is the deployed policy in FTD Snort engine (ngfw.rules file):
# Start of tunnel and priority rules. # These rules are evaluated by LINA. Only tunnel tags are used from the matched rule id. 268437506 deny any 192.168.1.40 32 any any 192.168.2.40 32 any any any (tunnel -1
In LINA:
access-list CSM_FW_ACL_ line 1 remark rule-id 268437506: PREFILTER POLICY: FTD_Prefilter access-list CSM_FW_ACL_ line 2 remark rule-id 268437506: RULE: Prefilter1 access-list CSM_FW_ACL_ line 3 advanced deny ip host 192.168.1.40 host 192.168.2.40 rule-id 268437506 event-log flow-start (hitcnt=0) 0x76476240
when you trace a virtual packet, it shows that the packet is dropped by LINA and never forwarded to Snort:
firepower# packet-tracer input INSIDE icmp 192.168.1.40 8 0 192.168.2.40 … Phase: 4 Type: ACCESS-LIST Subtype: log Result: DROP Config: access-group CSM_FW_ACL_ global access-list CSM_FW_ACL_ advanced deny ip host 192.168.1.40 host 192.168.2.40 rule-id 268437506 event-log flow-start access-list CSM_FW_ACL_ remark rule-id 268437506: PREFILTER POLICY: FTD_Prefilter access-list CSM_FW_ACL_ remark rule-id 268437506: RULE: Prefilter1 Additional Information: Result: input-interface: INSIDE input-status: up input-line-status: up output-interface: OUTSIDE output-status: up output-line-status: up Action: drop Drop-reason: (acl-drop) Flow is denied by configured rule
Snort statistics show:
firepower# show snort statistics Packet Counters: Passed Packets 0 Blocked Packets 0 Injected Packets 0 Packets bypassed (Snort Down) 0 Packets bypassed (Snort Busy) 0 Flow Counters: Fast-Forwarded Flows 0 Blacklisted Flows 0 Miscellaneous Counters: Start-of-Flow events 0 End-of-Flow events 0 Denied flow events 1
LINA ASP drops show:
firepower# show asp drop Frame drop: Flow is denied by configured rule (acl-drop) 1
Use Cases
You can use Prefilter Block rule when you want to block traffic based on L3/L4 conditions and without the need to do any Snort inspection to the traffic.
Consider the Prefilter Policy rule as shown in the image:
This is the deployed policy in FTD Snort engine:
268437506 fastpath any 192.168.1.40 32 any any 192.168.2.40 32 80 any 6 (tunnel -1)
In FTD LINA:
access-list CSM_FW_ACL_ line 1 remark rule-id 268437506: PREFILTER POLICY: FTD_Prefilter access-list CSM_FW_ACL_ line 2 remark rule-id 268437506: RULE: Prefilter1 access-list CSM_FW_ACL_ line 3 advanced trust tcp host 192.168.1.40 host 192.168.2.40 eq www rule-id 268437506 event-log flow-end (hitcnt=0) 0xf3410b6f
Verify Behavior
When host-A (192.168.1.40) tries to open an HTTP session to host-B (192.168.2.40) a few packets go through LINA and the rest are offloaded to SmartNIC. In this case ‘system support trace’ with firewall-engine-debug enabled shows:
> system support trace Please specify an IP protocol: tcp Please specify a client IP address: 192.168.1.40 Please specify a client port: Please specify a server IP address: 192.168.2.40 Please specify a server port: Enable firewall-engine-debug too? [n]: y Monitoring packet tracer debug messages 192.168.1.40-32840 > 192.168.2.40-80 6 AS 1 I 8 Got end of flow event from hardware with flags 04000000
LINA logs show the offloaded flow:
Oct 01 2017 14:36:51: %ASA-7-609001: Built local-host INSIDE:192.168.1.40 Oct 01 2017 14:36:51: %ASA-7-609001: Built local-host OUTSIDE:192.168.2.40 Oct 01 2017 14:36:51: %ASA-6-302013: Built inbound TCP connection 966 for INSIDE:192.168.1.40/32840 (192.168.1.40/32840) to OUTSIDE:192.168.2.40/80 (192.168.2.40/80) Oct 01 2017 14:36:51: %ASA-6-805001: Offloaded TCP Flow for connection 966 from INSIDE:192.168.1.40/32840 (192.168.1.40/32840) to OUTSIDE:192.168.2.40/80 (192.168.2.40/80) Oct 01 2017 14:36:51: %ASA-6-805001: Offloaded TCP Flow for connection 966 from OUTSIDE:192.168.2.40/80 (192.168.2.40/80) to INSIDE:192.168.1.40/32840 (192.168.1.40/32840)
LINA captures show 8 packets going through:
firepower# show capture capture CAPI type raw-data buffer 33554432 trace trace-count 100 interface INSIDE [Capturing - 3908 bytes] match ip host 192.168.1.40 host 192.168.2.40 capture CAPO type raw-data buffer 33554432 trace trace-count 100 interface OUTSIDE [Capturing - 3908 bytes] match ip host 192.168.1.40 host 192.168.2.40
firepower# show capture CAPI 8 packets captured 1: 14:45:32.700021 192.168.1.40.32842 > 192.168.2.40.80: S 3195173118:3195173118(0) win 2920 <mss 1460,sackOK,timestamp 332569060 0> 2: 14:45:32.700372 192.168.2.40.80 > 192.168.1.40.32842: S 184794124:184794124(0) ack 3195173119 win 2896 <mss 1380,sackOK,timestamp 332567732 332569060> 3: 14:45:32.700540 192.168.1.40.32842 > 192.168.2.40.80: P 3195173119:3195173317(198) ack 184794125 win 2920 <nop,nop,timestamp 332569060 332567732> 4: 14:45:32.700876 192.168.2.40.80 > 192.168.1.40.32842: . 184794125:184795493(1368) ack 3195173317 win 2698 <nop,nop,timestamp 332567733 332569060> 5: 14:45:32.700922 192.168.2.40.80 > 192.168.1.40.32842: P 184795493:184796861(1368) ack 3195173317 win 2698 <nop,nop,timestamp 332567733 332569060> 6: 14:45:32.701425 192.168.2.40.80 > 192.168.1.40.32842: FP 184810541:184810851(310) ack 3195173317 win 2698 <nop,nop,timestamp 332567733 332569061> 7: 14:45:32.701532 192.168.1.40.32842 > 192.168.2.40.80: F 3195173317:3195173317(0) ack 184810852 win 2736 <nop,nop,timestamp 332569061 332567733> 8: 14:45:32.701639 192.168.2.40.80 > 192.168.1.40.32842: . ack 3195173318 win 2697 <nop,nop,timestamp 332567734 332569061>
FTD Flow-offload statistics show 22 packets offloaded to HW:
firepower# show flow-offload statistics Packet stats of port : 0 Tx Packet count : 22 Rx Packet count : 22 Dropped Packet count : 0 VNIC transmitted packet : 22 VNIC transmitted bytes : 15308 VNIC Dropped packets : 0 VNIC erroneous received : 0 VNIC CRC errors : 0 VNIC transmit failed : 0 VNIC multicast received : 0
You can also use the 'show flow-offload flow' command to see additional information related to the offloaded flows. Here is an example:
firepower# show flow-offload flow
Total offloaded flow stats: 2 in use, 4 most used, 20% offloaded, 0 collisions
TCP intfc 103 src 192.168.1.40:39301 dest 192.168.2.40:20, static, timestamp 616063741, packets 33240, bytes 2326800
TCP intfc 104 src 192.168.2.40:20 dest 192.168.1.40:39301, static, timestamp 616063760, packets 249140, bytes 358263320
firepower# show conn
5 in use, 5 most used
Inspect Snort:
preserve-connection: 1 enabled, 0 in effect, 4 most enabled, 0 most in effect
TCP OUTSIDE 192.168.2.40:21 INSIDE 192.168.1.40:40988, idle 0:00:00, bytes 723, flags UIO
TCP OUTSIDE 192.168.2.40:21 INSIDE 192.168.1.40:40980, idle 0:02:40, bytes 1086, flags UIO
TCP OUTSIDE 192.168.2.40:80 INSIDE 192.168.1.40:49442, idle 0:00:00, bytes 86348310, flags UIO N1
TCP OUTSIDE 192.168.2.40:20 INSIDE 192.168.1.40:39301, idle 0:00:00, bytes 485268628, flags Uo <- offloaded flow
TCP OUTSIDE 192.168.2.40:20 INSIDE 192.168.1.40:34713, idle 0:02:40, bytes 821799360, flags UFRIO
In order to see all the packets on FP4100/9300 that go through FTD (offloaded + LINA) there is need to enable capture at chassis level as shown in the image:
Chassis backplane capture shows both directions. Due to FXOS capture architecture (2 capture points per direction) every packet is shown twice as shown in the image:
Based on the above:
Use Cases
In case a Prefilter Policy Fastpath action is applied on traffic going through an inline-set (NGIPS interfaces) the following points should be taken into consideration:
Here is an example of a packet trace in case of Prefilter Fastpath action applied on an inline-set:
firepower# packet-tracer input inside tcp 192.168.1.40 12345 192.168.1.50 80 detailed Phase: 1 Type: NGIPS-MODE Subtype: ngips-mode Result: ALLOW Config: Additional Information: The flow ingressed an interface configured for NGIPS mode and NGIPS services will be applied Forward Flow based lookup yields rule: in id=0x2ad7ac48b330, priority=501, domain=ips-mode, deny=false hits=2, user_data=0x2ad80d54abd0, cs_id=0x0, flags=0x0, protocol=0 src ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=any dst ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=any, dscp=0x0 input_ifc=inside, output_ifc=any Phase: 2 Type: ACCESS-LIST Subtype: log Result: ALLOW Config: access-group CSM_FW_ACL_ global access-list CSM_FW_ACL_ advanced trust ip object 192.168.1.0 object 192.168.1.0 rule-id 268438531 event-log flow-end access-list CSM_FW_ACL_ remark rule-id 268438531: PREFILTER POLICY: PF1 access-list CSM_FW_ACL_ remark rule-id 268438531: RULE: 1 Additional Information: Forward Flow based lookup yields rule: in id=0x2ad9f9f8a7f0, priority=12, domain=permit, trust hits=1, user_data=0x2ad9b23c5d40, cs_id=0x0, use_real_addr, flags=0x0, protocol=0 src ip/id=192.168.1.0, mask=255.255.255.0, port=0, tag=any, ifc=any dst ip/id=192.168.1.0, mask=255.255.255.0, port=0, tag=any, ifc=any, vlan=0, dscp=0x0 input_ifc=any, output_ifc=any Phase: 3 Type: NGIPS-EGRESS-INTERFACE-LOOKUP Subtype: Resolve Egress Interface Result: ALLOW Config: Additional Information: Ingress interface inside is in NGIPS inline mode. Egress interface outside is determined by inline-set configuration Phase: 4 Type: FLOW-CREATION Subtype: Result: ALLOW Config: Additional Information: New flow created with id 7, packet dispatched to next module Module information for forward flow ... snp_fp_ips_tcp_state_track_lite snp_fp_ips_mode_adj snp_fp_tracer_drop snp_ifc_stat Module information for reverse flow ... snp_fp_ips_tcp_state_track_lite snp_fp_ips_mode_adj snp_fp_tracer_drop snp_ifc_stat Result: input-interface: inside input-status: up input-line-status: up Action: allow
The above can be visualized as:
Consider the Prefilter Policy which contains an Analyze rule as shown in the image:
The ACP contains only the default rule which is set to Block All Traffic as shown in the image:
This is the deployed policy in FTD Snort engine (ngfw.rules file):
# Start of tunnel and priority rules. # These rules are evaluated by LINA. Only tunnel tags are used from the matched rule id. 268435460 allow any 192.168.1.40 32 any any 192.168.2.40 32 any any any (tunnel -1) 268435459 allow any any 1025-65535 any any 3544 any 17 (tunnel -1) 268435459 allow any any 3544 any any 1025-65535 any 17 (tunnel -1) 268435459 allow any any any any any any any 47 (tunnel -1) 268435459 allow any any any any any any any 41 (tunnel -1) 268435459 allow any any any any any any any 4 (tunnel -1) # End of tunnel and priority rules. # Start of AC rule. 268435458 deny any any any any any any any any (log dcforward flowstart) # End of AC rule.
This is the deployed policy in FTD LINA engine:
access-list CSM_FW_ACL_ line 3 advanced permit ip host 192.168.1.40 host 192.168.2.40 rule-id 268435460 (hitcnt=0) 0xb788b786
Verify Behavior
In order to test with packet-tracer, it shows that the packet is allowed by LINA, is forwarded to Snort engine (due to permit action) and Snort Engine returns a Block verdict since the default action from AC is matched.
Note: Snort does not evaluate traffic based on tunnel rules
When you trace a packet it reveals the same:
firepower# packet-tracer input INSIDE icmp 192.168.1.40 8 0 192.168.2.40 ... Phase: 4 Type: ACCESS-LIST Subtype: log Result: ALLOW Config: access-group CSM_FW_ACL_ global access-list CSM_FW_ACL_ advanced permit ip host 192.168.1.40 host 192.168.2.40 rule-id 268435460 access-list CSM_FW_ACL_ remark rule-id 268435460: PREFILTER POLICY: Prefilter_Policy1 access-list CSM_FW_ACL_ remark rule-id 268435460: RULE: Prefilter_Rule1 Additional Information: This packet will be sent to snort for additional processing where a verdict will be reached … Phase: 14 Type: SNORT Subtype: Result: DROP Config: Additional Information: Snort Trace: Packet: ICMP AppID: service ICMP (3501), application unknown (0) Firewall: starting rule matching, zone -1 -> -1, geo 0 -> 0, vlan 0, sgt 65535, user 9999997, icmpType 8, icmpCode 0 Firewall: block rule, id 268435458, drop Snort: processed decoder alerts or actions queue, drop NAP id 1, IPS id 0, Verdict BLACKLIST, Blocked by Firewall Snort Verdict: (black-list) black list this flow Result: input-interface: INSIDE input-status: up input-line-status: up output-interface: OUTSIDE output-status: up output-line-status: up Action: drop Drop-reason: (firewall) Blocked or blacklisted by the firewall preprocessor
If the goal is to allow the packet to traverse through the FTD, there is need to add a rule in ACP. The Action can be either Allow or Trust which depends on the goal (e.g. if you want to apply a L7 inspection you must use Allow action) as shown in the image:
The deployed policy in FTD Snort engine:
# Start of AC rule. 268435461 allow any 192.168.1.40 32 any any 192.168.2.40 32 any any any 268435458 deny any any any any any any any any (log dcforward flowstart) # End of AC rule.
In LINA engine:
access-list CSM_FW_ACL_ line 3 advanced permit ip host 192.168.1.40 host 192.168.2.40 rule-id 268435460 (hitcnt=1) 0xb788b786
Verify Behavior
Packet-tracer shows that the packet matches rule 268435460 in LINA and 268435461 in Snort engine:
firepower# packet-tracer input INSIDE icmp 192.168.1.40 8 0 192.168.2.40 ... Phase: 4 Type: ACCESS-LIST Subtype: log Result: ALLOW Config: access-group CSM_FW_ACL_ global access-list CSM_FW_ACL_ advanced permit ip host 192.168.1.40 host 192.168.2.40 rule-id 268435460 access-list CSM_FW_ACL_ remark rule-id 268435460: PREFILTER POLICY: Prefilter_Policy1 access-list CSM_FW_ACL_ remark rule-id 268435460: RULE: Prefilter_Rule1 Additional Information: This packet will be sent to snort for additional processing where a verdict will be reached … Phase: 14 Type: SNORT Subtype: Result: ALLOW Config: Additional Information: Snort Trace: Packet: ICMP AppID: service ICMP (3501), application unknown (0) Firewall: starting rule matching, zone -1 -> -1, geo 0 -> 0, vlan 0, sgt 65535, user 9999997, icmpType 8, icmpCode 0 Firewall: allow rule, id 268435461, allow NAP id 1, IPS id 0, Verdict PASS Snort Verdict: (pass-packet) allow this packet … Result: input-interface: INSIDE input-status: up input-line-status: up output-interface: OUTSIDE output-status: up output-line-status: up Action: allow
In case the ACP contains a Trust rule then you have this as shown in the image:
Snort:
# Start of AC rule. 268435461 fastpath any 192.168.1.40 32 any any 192.168.2.40 32 any any any 268435458 deny any any any any any any any any (log dcforward flowstart) # End of AC rule.
LINA:
access-list CSM_FW_ACL_ line 3 advanced permit ip host 192.168.1.40 host 192.168.2.40 rule-id 268435460 (hitcnt=2) 0xb788b786
Remember that since the SI is enabled by default, the Trust rule is deployed as permit action on LINA so at least a few packets are redirected to Snort engine for inspection.
Verify Behavior
Packet-tracer shows that the Snort engine Whitelists the packet essentially offloading the rest flow to LINA:
firepower# packet-tracer input INSIDE icmp 192.168.1.40 8 0 192.168.2.40 ... Phase: 4 Type: ACCESS-LIST Subtype: log Result: ALLOW Config: access-group CSM_FW_ACL_ global access-list CSM_FW_ACL_ advanced permit ip host 192.168.1.40 host 192.168.2.40 rule-id 268435460 access-list CSM_FW_ACL_ remark rule-id 268435460: PREFILTER POLICY: Prefilter_Policy1 access-list CSM_FW_ACL_ remark rule-id 268435460: RULE: Prefilter_Rule1 Additional Information: This packet will be sent to snort for additional processing where a verdict will be reached … Phase: 14 Type: SNORT Subtype: Result: ALLOW Config: Additional Information: Snort Trace: Packet: ICMP AppID: service ICMP (3501), application unknown (0) Firewall: starting rule matching, zone -1 -> -1, geo 0 -> 0, vlan 0, sgt 65535, user 9999997, icmpType 8, icmpCode 0 Firewall: trust/fastpath rule, id 268435461, allow NAP id 1, IPS id 0, Verdict WHITELIST Snort Verdict: (fast-forward) fast forward this flow … Result: input-interface: INSIDE input-status: up input-line-status: up output-interface: OUTSIDE output-status: up output-line-status: up Action: allow
In this scenario the SI was disabled manually.
The rule is deployed in Snort as follows:
# Start of AC rule. 268435461 fastpath any 192.168.1.40 32 any any 192.168.2.40 32 any any any 268435458 deny any any any any any any any any (log dcforward flowstart) # End of AC rule.
In LINA the rule is deployed as full trust. A packet though must match the permit rule (see the ACE hit-counts) that is deployed due to Analyze Prefilter rule and the packet is inspected by the Snort engine:
access-list CSM_FW_ACL_ line 3 advanced permit ip host 192.168.1.40 host 192.168.2.40 rule-id 268435460 (hitcnt=3) 0xb788b786 ... access-list CSM_FW_ACL_ line 13 advanced trust ip host 192.168.1.40 host 192.168.2.40 rule-id 268435461 event-log flow-end (hitcnt=0) 0x5c1346d6 ... access-list CSM_FW_ACL_ line 16 advanced deny ip any any rule-id 268435458 event-log flow-start (hitcnt=0) 0x97aa021a
Verify Behavior
firepower# packet-tracer input INSIDE icmp 192.168.1.40 8 0 192.168.2.40 ... Phase: 4 Type: ACCESS-LIST Subtype: log Result: ALLOW Config: access-group CSM_FW_ACL_ global access-list CSM_FW_ACL_ advanced permit ip host 192.168.1.40 host 192.168.2.40 rule-id 268435460 access-list CSM_FW_ACL_ remark rule-id 268435460: PREFILTER POLICY: Prefilter_Policy1 access-list CSM_FW_ACL_ remark rule-id 268435460: RULE: Prefilter_Rule1 Additional Information: This packet will be sent to snort for additional processing where a verdict will be reached ... Phase: 14 Type: SNORT Subtype: Result: ALLOW Config: Additional Information: Snort Trace: Packet: ICMP AppID: service ICMP (3501), application unknown (0) Firewall: starting rule matching, zone -1 -> -1, geo 0 -> 0, vlan 0, sgt 65535, user 9999997, icmpType 8, icmpCode 0 Firewall: trust/fastpath rule, id 268435461, allow NAP id 1, IPS id 0, Verdict WHITELIST Snort Verdict: (fast-forward) fast forward this flow … Result: input-interface: INSIDE input-status: up input-line-status: up output-interface: OUTSIDE output-status: up output-line-status: up Action: allow
Main Points
Use Cases
There are protocols like FTP, SIP etc which negotiates and open secondary connections dynamically. FTD opens pinholes for the secondary connections at 2 levels independently:
Additionally, when Snort opens a pinhole it signals LINA to open the same pinhole in case it is not already open.
With protocols that negotiate and open secondary connections you must use Allow action in ACP and never use Trust. The reason is that since Snort also opens pinholes it needs to inspect a few packets (the number depends on the application) before you open a pinhole at Snort level. If you use a Trust action, most of the times only a few packets are sent to Snort engine for inspection and the flow is offloaded to LINA before Snort has the time to check the protocol negotiation phase and open the needed pinholes at Snort level. The result is LINA to open pinholes, but Snort to drop the secondary connections (e.g. FTD Data channel).
Note: For protocols that require pinholes to be opened by FTD ensure that the ACP Rule matches an Application.
If the rule uses a Protocol Port as a condition then the Snort engine will not open a pinhole and flows like FTD Data will be dropped by FTD
For more details check the following document:
NGFW Policy Order of Operations
firepower# show access-list | include elements access-list CSM_FW_ACL_; 7 elements; name hash: 0x4a69e3f3
How rules are deployed:
Allow vs Trust
Note: As from 6.3 FTD software code Dynamic flow offload can offload connections that meet additional criteria including Trusted packets that require Snort inspection. Check the 'Offload Large Connections (Flows)' section from the Firepower Management Center Configuration Guide for more details