Chapter 14
Bypassing Inspection and Trusting Traffic
If you do not want FTD to inspect certain traffic, because, for example, it is completely trusted, you can configure FTD to bypass inspection for that particular traffic while it continues deep packet inspection for the rest of the network. Doing so offloads the FTD hardware resources, reduces overall processing delay, and improves network performance. This chapter describes the options for bypassing Firepower inspection of any particular traffic.
Bypassing Inspection and Trusting Traffic Essentials
A Firepower system offers the following tools to bypass deep packet inspection:
Fastpath rule: Enabled through a prefilter policy
Trust rule: Activated over an access control policy
While their goals are identical—to bypass deep packet inspection—the architecture and implementation of each tool is different, as described in the following sections.
The Fastpath Rule
A prefilter policy allows you to bypass traffic before a packet even reaches the ASA and Firepower engines. This functionality is known as Fastpath. A rule enabled with the Fastpath action is also known as a fastpath rule. You can apply the Fastpath action on the following rule types, which filter packets based on the outermost header data, and therefore do not offer deep packet inspection:
Tunnel rule: A tunnel rule, as the name suggests, filters tunnel traffic that is encapsulated by an additional IP header. As of this writing, a tunnel rule supports GRE, IP-in-IP, IPv6-in-IP, and Teredo encapsulation protocols, as discussed in Chapter 13, “Handling Encapsulated Traffic.”
Prefilter rule: A prefilter rule is able to filter traffic based on basic networking criteria. As of this writing, it supports a rule condition based on an IP address, a port number, a VLAN tag, and an interface.
Rules in a prefilter policy support three types of actions—Fastpath, Analyze, and Block. Whereas the Fastpath action bypasses traffic from further inspection, the Analyze action forwards the traffic to the next level of inspection, and the Block action drops a packet without any additional security check.
Figure 14-1 shows the position of a fastpath rule in an FTD workflow. When a packet matches a fastpath rule, it bypasses the Firepower deep packet inspection completely.
The Trust Rule
An access rule is known as a trust rule when you assign the Trust action to it. A trust rule can bypass traffic without performing any deep packet inspection and network discovery. To ensure the entitlements, the trusted traffic, however, checks for identity and quality of service (QoS) requirements.
Besides the simple filtering conditions that are available in a prefilter rule, an access rule offers additional granular filters. For example, you can match and trust traffic based on network conditions, applications, URLs, users, and so on. Unlike a prefilter rule, an access rule uses the innermost header of a packet to filter traffic.
Figure 14-2 shows the position of a trust rule and a fastpath rule in an FTD workflow. When a packet matches a trust rule or a fastpath rule, it bypasses various inspection components.
Best Practices for Bypassing Inspection
To bypass inspection, if you want to filter traffic based on simple conditions, such as network address, port number, VLAN tags, and interface objects, you should use a prefilter rule instead of an access rule with Trust action.
Fulfilling Prerequisites
This chapter assumes that an FTD device is deployed between a client and a server. The client can access the server by using Secure Shell (SSH) and Telnet services. The configuration examples in this chapter use both of these services to verify the action of the fastpath and trust rules.
Note
The method to initiate a Telnet or SSH connection varies, depending on the client software or operating system you use. This book does not recommend any particular client, and therefore it does not display any Telnet or SSH client commands.
Figure 14-3 shows a simple topology that is used in this chapter to demonstrate bypassing inspection.
Implementing Fastpath Through a Prefilter Policy
The default prefilter policy that comes with an FTD device out of the box provides limited configurable options. However, you can create your own prefilter policy, which supports a custom prefilter rule based on basic filtering conditions, such as network address, port numbers, VLAN tags, and interface objects.
A custom prefilter rule supports three types of actions: Analyze, Block, and Fastpath. As an example, the following sections demonstrate how to create a custom prefilter policy, add a custom prefilter rule to it, and fastpath any traffic over port 22—the default port for the SSH protocol.
Configuring Traffic Bypassing
The configurations for bypassing traffic can be divided into two parts:
Configuring a prefilter policy
Invoking the prefilter policy into an access control policy
Configuring a Prefilter Policy
To configure a custom prefilter rule for traffic over port 22, follow these steps:
Step 1. Navigate to Policies > Access Control > Prefilter. The Prefilter Policy page appears.
Step 2. Click the New Policy button to create a new prefilter policy. If you created a custom tunnel and prefilter policy in Chapter 13, you can reuse that policy for this exercise. Just use the pencil icon to edit the policy and delete any tunnel rule you created earlier.
Figure 14-4 shows the list of available policies in the Prefilter Policy page. The top one, custom tunnel and prefilter policy, is from Chapter 13. The bottom one, default prefilter policy, comes with FTD by default. You can also create a brand-new prefilter policy by clicking the New Policy button.
Step 3. In the prefilter policy editor page, click the Add Prefilter Rule button (see Figure 14-5). A configuration window appears.
Step 4. Give a name to the rule and set the Action dropdown to Fastpath.
Step 5. Click the Port tab and select SSH from the Available Ports list.
Step 6. Click the Add to Destination button to select port 22 as the destination port. Figure 14-6 shows the creation of a custom prefilter rule, named Shell Prefilter. The rule uses Fastpath action, and selects the default port for the SSH protocol (port 22) as the destination port.
Note
You could save the rule right here, and it would enable any traffic that is transferred over port 22 to bypass further inspection. However, if you want to enable traffic originated from only a particular subnet to bypass inspection, proceed with the next steps.
Step 7. Select the Networks tab. By default, FTD has preconfigured objects for some common networks, such as private IP addresses, multicast addresses, and so on. If they match with your network-addressing scheme, you can select them here. Alternatively, you can create a network object on the fly. Otherwise, you can just add an IP address directly as a source or destination.
Figure 14-7 illustrates the options available for defining the source and destination for a prefilter rule.
Step 8. Click on the green plus icon. The New Network Objects popup window appears.
Step 9. As shown in Figure 14-8, create a custom network object, Corporate-Network, for the 192.168.1.0/24 subnet and click Save.
Step 10. Once you have saved a new network object, it is available for selection. You may need to click the refresh icon for it to show up in the list. Click the Add to Source button to select your custom network object as the source network. This enables the FTD device to match traffic coming from your desired subnet. Figure 14-9 shows a custom network object, Corporate-Network, selected as the source network.
Step 11. Optionally, enable logging for every time a fastpath rule triggers. This helps you to determine whether a policy is operational. To do this, go to the Logging tab and select either Log at Beginning of Connection or Log at End of Connection. (However, do not select both as doing so can affect the system performance.)
Step 12. Click the Add button to complete the rule configuration, and you return to the policy editor page. Click the Save button to save the changes.
Do not select the Deploy button at this stage because you have to make sure this new prefilter policy is invoked by the required access control policy. The next section, “Invoking a Prefilter Policy in an Access Control Policy,” describes how to do that. For now, just click the Save button to store the changes.
Figure 14-10 shows a complete view of the Shell Prefilter rule. It also illustrates the buttons that you should and should not click at this stage.
Invoking a Prefilter Policy in an Access Control Policy
To invoke a custom prefilter policy in your desired access control policy, follow these steps:
Step 1. Navigate to Policies > Access Control > Access Control. The Access Control Policy page appears.
Step 2. To edit the policy that you want to deploy on your FTD device, use the pencil icon next to the name of a policy to open the access control policy editor page.
Step 3. Look at the top-left side of the policy editor page. You should be able to find a link to the currently selected prefilter policy. Click this link. By default, an access control policy uses the default prefilter policy.
Figure 14-11 confirms that this access control policy invokes the prefilter rules from the default prefilter policy. Click the name of the prefilter policy to make a change.
Step 4. After you click the link, the Prefilter Policy popup window appears. It presents the available prefilter policies in a dropdown.
Step 5. Select Custom Tunnel and Prefilter Policy and click OK (see Figure 14-12).
You could save and deploy the access control policy at this stage. However, to determine whether an access control policy inspects a connection, you can enable the logging for the default action. This helps in understanding the life cycle of a packet and troubleshooting any potential issues. Here are the steps:
Step 1. Go to the Rules tab of the access control policy editor page.
Step 2. Select the logging icon that is next to the Default Action dropdown (see Figure 14-13).
Step 3. Select either Log at Beginning of Connection or Log at End of Connection. (However, do not select both as doing so can affect the system performance.)
Step 4. Click the OK button to return to the policy editor page.
Step 5. Click Save to save the changes, and then click Deploy to deploy the changes to your FTD device.
Verifying the Prefilter Rule Configuration
By using the CLI, you can verify whether a prefilter rule is active on an FTD device. Example 14-1 shows the list of access rules that are active on an FTD device. The custom prefilter rule shell prefilter is positioned on top of any other access rules because a prefilter policy acts on traffic before any security policies.
Example 14-1 Position of a Prefilter Rule on the Active Ruleset
> 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_; 7 elements; name hash: 0x4a69e3f3
access-list CSM_FW_ACL_ line 1 remark rule-id 268440577: PREFILTER POLICY: Custom
Tunnel and Prefilter Policy
access-list CSM_FW_ACL_ line 2 remark rule-id 268440577: RULE: Shell Prefilter
access-list CSM_FW_ACL_ line 3 advanced trust tcp object Corporate-Network any
object-group SSH rule-id 268440577 event-log both (hitcnt=0) 0xe9257885
access-list CSM_FW_ACL_ line 3 advanced trust tcp 192.168.1.0 255.255.255.0 any eq
ssh rule-id 268440577 event-log both (hitcnt=0) 0xad5d48f9
access-list CSM_FW_ACL_ line 4 remark rule-id 268438529: PREFILTER POLICY: Custom
Tunnel and Prefilter Policy
access-list CSM_FW_ACL_ line 5 remark rule-id 268438529: RULE: DEFAULT TUNNEL ACTION
RULE
access-list CSM_FW_ACL_ line 6 advanced permit ipinip any any rule-id 268438529
(hitcnt=0) 0xf5b597d6
access-list CSM_FW_ACL_ line 7 advanced permit 41 any any rule-id 268438529
(hitcnt=0) 0x06095aba
access-list CSM_FW_ACL_ line 8 advanced permit gre any any rule-id 268438529
(hitcnt=0) 0x52c7a066
access-list CSM_FW_ACL_ line 9 advanced permit udp any eq 3544 any range 1025 65535
rule-id 268438529 (hitcnt=0) 0x46d7839e
access-list CSM_FW_ACL_ line 10 advanced permit udp any range 1025 65535 any eq 3544
rule-id 268438529 (hitcnt=0) 0xaf1d5aa5
access-list CSM_FW_ACL_ line 11 remark rule-id 268434432: ACCESS POLICY: AC Policy -
Default/1
access-list CSM_FW_ACL_ line 12 remark rule-id 268434432: L4 RULE: DEFAULT ACTION
RULE
access-list CSM_FW_ACL_ line 13 advanced permit ip any any rule-id 268434432
(hitcnt=34) 0xa1d3780e
>
Enabling Tools for Advanced Analysis
Before you run live SSH traffic, you need to enable a few debugging tools so you can better understand the action of a rule and the flow of a packet. Follow these steps:
Step 1. Capture the SSH traffic from the ASA firewall engine:
> capture ssh_traffic trace interface INSIDE_INTERFACE match tcp any any eq 22
You can run the show capture command to confirm that the capture process is running. 0 bytes in the output indicates that the FTD has not received any packets:
> show capture
capture ssh_traffic type raw-data trace interface INSIDE_INTERFACE
[Capturing - 0 bytes]
match tcp any any eq ssh
>
To clear any previously captured packets from the memory and to restart the capture from the next matched packets, run the clear capture command.
> clear capture /all
Step 2. Begin the capture of TCP traffic from the Firepower Snort engine. This helps you determine whether the Snort engine sees any bypassed traffic. Example 14-2 shows the command to capture TCP traffic from an inline pair.
Example 14-2 Capturing Traffic from the Firepower Snort Engine
> capture-traffic
Please choose domain to capture traffic from:
0 - br1
1 - INSIDE_OUTSIDE_PAIR inline set
Selection? 1
Please specify tcpdump options desired.
(or enter '?' for a list of supported options)
Options: -n tcp
Because the current CLI terminal has entered the Packet Capture Mode, you need to access the FTD from a different terminal. You can connect through SSH or a console connection. On the second terminal connection to the FTD, perform the following steps.
Step 3. Reset the counters for Snort statistics, which helps you determine the exact number of events for your test traffic:
> clear snort statistics
Step 4. Enable debugging for the firewall engine, which allows you to determine the actions applied to any traffic. Example 14-3 shows the command that generates debugging data when FTD inspects TCP traffic.
Example 14-3 Collecting Debugging Data from the Firewall Engine
> system support firewall-engine-debug
Please specify an IP protocol: tcp
Please specify a client IP address:
Please specify a client port:
Please specify a server IP address:
Please specify a server port:
Monitoring firewall engine debug messages
Analyzing the Fastpath Action
It’s a good idea to verify the action of the custom prefilter policy. Since the prefilter policy has a rule to bypass SSH traffic, you need to generate SSH traffic between the client (192.168.1.2) and server (192.168.1.200) to verify the Fastpath action. Follow these steps:
Step 1. Connect to the server (192.168.1.200) from the host (192.168.1.2), using an SSH client. The FTD should fastpath the SSH traffic.
Step 2. Go to the Analysis > Connection > Events page; you should be able view a connection event for the Fastpath action. Figure 14-14 shows a connection event triggered by the shell prefilter—a custom prefilter rule.
Step 3. Go to the CLI terminal where firewall-engine-debug is running. Check the status of the tool. You should see some logs (see Example 14-4).
Example 14-4 Bypassed Connection Generates Event Logs and Increases Counters
! The firewall-engine-debug tool receives events from hardware in real time.
> system support firewall-engine-debug
Please specify an IP protocol: tcp
Please specify a client IP address:
Please specify a client port:
Please specify a server IP address:
Please specify a server port:
Monitoring firewall engine debug messages
192.168.1.2-48506 > 192.168.1.200-22 6 AS 5 I 0 Got start of flow event from
hardware with flags 84000001
192.168.1.2-48506 > 192.168.1.200-22 6 AS 5 I 0 Got end of flow event from hardware
with flags 84000001
^C
Caught interrupt signal
Exiting.
>
! The Snort statistics keeps a record of these events under the Miscellaneous
Counters section.
> show snort statistics
Packet Counters:
Passed Packets 0
Blocked Packets 0
Injected Packets 0
Flow Counters:
Fast-Forwarded Flows 0
Blacklisted Flows 0
Flows bypassed (Snort Down) 0
Flows bypassed (Snort Busy) 0
Miscellaneous Counters:
Start-of-Flow events 1
End-of-Flow events 1
Denied flow events 0
Frames forwarded to Snort before drop 0
Inject packets dropped 0
>
Step 4. Go to the terminal where the capture-traffic command is running, and analyze the captured packets. Example 14-5 demonstrates that the Firepower Snort engine does not see any SSH traffic. However, the ASA Firewall engine can see and capture that traffic.
Example 14-5 Firewall and Firepower Engines Showing Different Behavior During Capture
> capture-traffic
Please choose domain to capture traffic from:
0 - br1
1 - INSIDE_OUTSIDE_PAIR inline set
Selection? 1
Please specify tcpdump options desired.
(or enter '?' for a list of supported options)
Options: -n tcp
! If the Firepower Snort engine would see traffic, it would appear here.
! Press the Control+C keys to exit from the capture-traffic tool.
^C
Caught interrupt signal
Exiting.
! Check the status of the capture on the ASA Firewall engine.
> show capture ssh_traffic
61 packets captured
1: 13:00:22.730156 192.168.1.2.48506 > 192.168.1.200.22: S 1199563799:
1199563799(0) win 29200 <mss 1460,sackOK,timestamp 4732110 0,nop,wscale 7>
2: 13:00:22.730492 192.168.1.200.22 > 192.168.1.2.48506: S 2739603340:
2739603340(0) ack 1199563800 win 28960 <mss 1460,sackOK,timestamp 1446067
4732110,nop,wscale 7>
3: 13:00:22.730659 192.168.1.2.48506 > 192.168.1.200.22: . ack 2739603341
win 229 <nop,nop,timestamp 4732110 1446067>
4: 13:00:22.730949 192.168.1.2.48506 > 192.168.1.200.22: P 1199563800:
1199563841(41) ack 2739603341 win 229 <nop,nop,timestamp 4732110 1446067>
5: 13:00:22.731132 192.168.1.200.22 > 192.168.1.2.48506: . ack 1199563841
win 227 <nop,nop,timestamp 1446067 4732110>
.
.
! You can see all of the SSH packets generated by your connection. The above output
shows only the first TCP three way handshake, as an example. The remaining outputs
are omitted for brevity.
Example 14-6 analyzes the flow of a packet that bypasses the FTD inspection due to the Fastpath action on the shell prefilter rule. Note the absence of the Snort inspection phase in this trace data.
Example 14-6 Analyzing a Packet Flow That Follows the Fastpath Action
> show capture ssh_traffic packet-number 1 trace
61 packets captured
1: 13:00:22.730156 192.168.1.2.48506 > 192.168.1.200.22: S 1199563799:
1199563799(0) win 29200 <mss 1460,sackOK,timestamp 4732110 0,nop,wscale 7>
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: 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
Phase: 4
Type: ACCESS-LIST
Subtype: log
Result: ALLOW
Config:
access-group CSM_FW_ACL_ global
access-list CSM_FW_ACL_ advanced trust tcp object Corporate-Network any object-group
SSH rule-id 268440577 event-log both
access-list CSM_FW_ACL_ remark rule-id 268440577: PREFILTER POLICY: Custom Tunnel
and Prefilter Policy
access-list CSM_FW_ACL_ remark rule-id 268440577: RULE: Shell Prefilter
object-group service SSH tcp
port-object eq ssh
Additional Information:
Phase: 5
Type: NGIPS-EGRESS-INTERFACE-LOOKUP
Subtype: Resolve Egress Interface
Result: ALLOW
Config:
Additional Information:
Ingress interface INSIDE_INTERFACE is in NGIPS inline mode.
Egress interface OUTSIDE_INTERFACE is determined by inline-set configuration
Phase: 6
Type: FLOW-CREATION
Subtype:
Result: ALLOW
Config:
Additional Information:
New flow created with id 81, packet dispatched to next module
Result:
input-interface: INSIDE_INTERFACE
input-status: up
input-line-status: up
Action: allow
1 packet shown
>
Establishing Trust Through an Access Policy
A trust rule can bypass traffic without performing any deep packet inspection and network discovery. It supports granular filters based on Security Intelligence data, application fingerprints, URL filtering, user identities, and so on. In the following sections, you will learn how to trust Telnet traffic as an example of trusting a TCP protocol.
Warning
This chapter uses Telnet service to demonstrate the flow of a TCP packet. However, you should not trust any connection unless you have a complete understanding of the particular traffic and its source and destination.
Configuring Trust with an Access Policy
This section describes how to trust the default port of the Telnet protocol, port 23. Follow these steps:
Step 1. Navigate to Policies > Access Control > Access Control. The access control policy page appears.
Step 2. To edit the policy that you want to deploy on your FTD device, use the pencil icon next to the name of a policy to open the access control policy editor page.
Step 3. Click the Add Rule button to create a new access rule (see Figure 14-15). The Add Rule window appears.
Step 4. Give a name to the access rule and select the Trust action.
Step 5. To define the condition of the access rule, go to the Networks tab and select Corporate-Network as the source network. Figure 14-16 shows the configuration of the Telnet access rule, which trusts any Telnet traffic coming from 192.168.1.0/24, the internal corporate network.
Step 6. On the Ports tab, select Telnet as the destination ports (see Figure 14-17).
Step 7. Optionally, go to the Logging tab to enable logging so that you can determine when FTD trusts a connection. Select either Log at Beginning of Connection or Log at End of Connection. (However, do not select both as doing so can affect the system performance.)
Step 8. Click the Add button to complete the trust rule configuration. You are returned to the policy editor page.
Step 9. Click the Save button to save the changes, and then click the Deploy button to activate the rule.
Verifying the Trust Rule Configuration
Using the CLI, you can verify whether a trust rule is active on an FTD device. Example 14-7 shows the list of access rules that are active on an FTD device. The trust rule Telnet access is placed below the prefilter rule shell prefilter.
Example 14-7 Position of a Trust Rule on the Active Ruleset
> 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_; 8 elements; name hash: 0x4a69e3f3
access-list CSM_FW_ACL_ line 1 remark rule-id 268440577: PREFILTER POLICY: Custom
Tunnel and Prefilter Policy
access-list CSM_FW_ACL_ line 2 remark rule-id 268440577:
RULE: Shell Prefilter
access-list CSM_FW_ACL_ line 3 advanced trust tcp
object Corporate-Network any object-group SSH rule-id 268440577 event-log both (hitcnt=4) 0xe9257885
access-list CSM_FW_ACL_ line 3 advanced trust tcp 192.168.1.0 255.255.255.0 any eq
ssh rule-id 268440577 event-log both (hitcnt=4) 0xad5d48f9
access-list CSM_FW_ACL_ line 4 remark rule-id 268438529: PREFILTER POLICY: Custom
Tunnel and Prefilter Policy
access-list CSM_FW_ACL_ line 5 remark rule-id 268438529: RULE: DEFAULT TUNNEL ACTION
RULE
access-list CSM_FW_ACL_ line 6 advanced permit ipinip any any rule-id 268438529
(hitcnt=0) 0xf5b597d6
access-list CSM_FW_ACL_ line 7 advanced permit 41 any any rule-id 268438529
(hitcnt=0) 0x06095aba
access-list CSM_FW_ACL_ line 8 advanced permit gre any any rule-id 268438529
(hitcnt=0) 0x52c7a066
access-list CSM_FW_ACL_ line 9 advanced permit udp any eq 3544 any range 1025 65535
rule-id 268438529 (hitcnt=0) 0x46d7839e
access-list CSM_FW_ACL_ line 10 advanced permit udp any range 1025 65535 any eq 3544
rule-id 268438529 (hitcnt=0) 0xaf1d5aa5
access-list CSM_FW_ACL_ line 11 remark rule-id 268440580: ACCESS POLICY: AC Policy -
Mandatory/1
access-list CSM_FW_ACL_ line 12 remark rule-id 268440580: L7
RULE: Telnet Access
access-list CSM_FW_ACL_ line 13 advanced permit tcp object Corporate-Network any
object-group TELNET rule-id 268440580 (hitcnt=3) 0x388a3b9d
access-list CSM_FW_ACL_ line 13 advanced permit tcp 192.168.1.0 255.255.255.0 any eq
telnet rule-id 268440580 (hitcnt=3) 0x4a6c1f4c
access-list CSM_FW_ACL_ line 14 remark rule-id 268434432: ACCESS POLICY: AC Policy -
Default/1
access-list CSM_FW_ACL_ line 15 remark rule-id 268434432: L4 RULE: DEFAULT ACTION
RULE
access-list CSM_FW_ACL_ line 16 advanced permit ip any any rule-id 268434432
(hitcnt=144) 0xa1d3780e
>
Enabling Tools for Advanced Analysis
Before you generate live Telnet traffic, you need to enable a few debugging tools, which will help you understand the action of a rule and the flow of a packet. Follow these steps:
Step 1. Capture the Telnet traffic from the ASA firewall engine:
> capture telnet_traffic trace interface INSIDE_INTERFACE match tcp any any
eq 23
You can run the show capture command to confirm that the capture process is running. 0 bytes in the output indicates that the FTD device has not received any packets:
> show capture
capture telnet_traffic type raw-data trace interface INSIDE_INTERFACE
[Capturing - 0 bytes]
match tcp any any eq telnet
>
If the FTD device is running a capture for SSH traffic that you enabled earlier, you can remove it by using the no keyword with the capture command, as it not necessary for this example:
> no capture ssh_traffic
To clear any previously captured packets from memory and to restart the capture from the next matched packets, run the clear capture command.
> clear capture /all
Step 2. Begin the capture of TCP traffic from the Firepower Snort engine. This helps you to determine whether the Snort engine sees any bypassed traffic. Example 14-8 shows the command to capture TCP traffic from an inline pair.
Example 14-8 Capturing Traffic from the Firepower Snort Engine
> capture-traffic
Please choose domain to capture traffic from:
0 - br1
1 - INSIDE_OUTSIDE_PAIR inline set
Selection? 1
Please specify tcpdump options desired.
(or enter '?' for a list of supported options)
Options: -n tcp
Because the current CLI terminal has entered the Packet Capture Mode, you need to access the FTD from a new separate terminal. You can connect through an SSH client or a console terminal. On the second terminal connection to the FTD, perform the following steps.
Step 3. Reset the counters for Snort statistics, which helps you determine the exact number of events for your test traffic:
> clear snort statistics
Step 4. Enable debugging for the firewall engine. This helps you determine the actions applied to any traffic. Example 14-9 shows the command that generates debugging data when FTD inspects TCP traffic.
Example 14-9 Collecting Debugging Data from the Firewall Engine
> system support firewall-engine-debug
Please specify an IP protocol: tcp
Please specify a client IP address:
Please specify a client port:
Please specify a server IP address:
Please specify a server port:
Monitoring firewall engine debug messages
In the next section, you will generate traffic to analyze the action of a trust rule. Both tools that you have just enabled on two different terminals—capture-traffic and firewall-engine-debug—will display data in real time when the traffic will go through the FTD.
Analyzing the Trust Action
It’s a good idea to verify the action of the trust rule you created. Because the access control policy has a rule to bypass Telnet traffic, you need to generate Telnet traffic between the client (192.168.1.2) and server (192.168.1.200) to verify the trust action.
Step 1. Connect to the server (192.168.1.200) from the host (192.168.1.2), using a Telnet client. The FTD device should trust the Telnet traffic.
Step 2. Go to the Analysis > Connection > Events page; you should be able view a connection event for the Trust action. Figure 14-18 shows a new connection event triggered by the Telnet access rule—an access rule with a Trust action.
Step 3. Go to the CLI terminal where firewall-engine-debug is running (you enabled it in the previous section, “Enabling Tools for Advanced Analysis”). Check the status of the tool. You should see some logs. Example 14-10 shows analysis of the debugging data from an FTD when an access rule applies the Trust action on the Telnet traffic.
Example 14-10 Trusted Connection Generating Event Logs
! The firewall-engine-debug tool shows that the "Telnet Access" rule applies Trust
action.
> system support firewall-engine-debug
Please specify an IP protocol: tcp
Please specify a client IP address:
Please specify a client port:
Please specify a server IP address:
Please specify a server port:
Monitoring firewall engine debug messages
192.168.1.2-55822 > 192.168.1.200-23 6 AS 5 I 1 New session
192.168.1.2-55822 > 192.168.1.200-23 6 AS 5 I 1 using HW or preset rule order 3,
'Telnet Access', action Trust and prefilter rule 0
192.168.1.2-55822 > 192.168.1.200-23 6 AS 5 I 1 Deleting session
^C
Caught interrupt signal
Exiting.
>
Step 4. Go to the terminal where the capture-traffic command is running (you enabled it in the previous section, “Enabling Tools for Advanced Analysis”), and analyze the captured packets. Example 14-11 shows that the Firepower Snort engine starts trusting the Telnet traffic after the initial TCP three-way handshake is complete. Therefore, the traffic does not appear in the capture-traffic output. However, the ASA firewall engine can see and capture all the traffic.
Example 14-11 Firewall and Firepower Engines Showing Different Actions During Capture
! The Firepower Snort engine stops seeing traffic after the initial TCP three-way
handshake.
> capture-traffic
Please choose domain to capture traffic from:
0 - br1
1 - INSIDE_OUTSIDE_PAIR inline set
Selection? 1
Please specify tcpdump options desired.
(or enter '?' for a list of supported options)
Options: -n tcp
17:19:49.089991 IP 192.168.1.2.55822 > 192.168.1.200.23: Flags [S], seq 1700253547,
win 29200, options [mss 1460,sackOK,TS val 7177698 ecr 0,nop,wscale 7], length 0
17:19:49.089991 IP 192.168.1.200.23 > 192.168.1.2.55822: Flags [S.], seq 495495803,
ack 1700253548, win 28960, options [mss 1460,sackOK,TS val 3421593 ecr 7177698,
nop,wscale 7], length 0
17:19:49.109979 IP 192.168.1.2.55822 > 192.168.1.200.23: Flags [.], ack 1, win 229,
options [nop,nop,TS val 7177701 ecr 3421593], length 0
17:19:49.109979 IP 192.168.1.2.55822 > 192.168.1.200.23: Flags [P.], ack 1, win 229,
options [nop,nop,TS val 7177701 ecr 3421593], length 27
! Nothing appears after the above packets, because they are trusted.
^C
Caught interrupt signal
Exiting.
>
! However, the ASA Firewall engine sees all of the traffic generated by the telnet
connection.
> show capture telnet_traffic
78 packets captured
1: 17:19:49.096766 192.168.1.2.55822 > 192.168.1.200.23: S 1700253547:
1700253547(0) win 29200 <mss 1460,sackOK,timestamp 7177698 0,nop,wscale 7>
2: 17:19:49.109781 192.168.1.200.23 > 192.168.1.2.55822: S 495495803:
495495803(0) ack 1700253548 win 28960 <mss 1460,sackOK,timestamp 3421593
7177698,nop,wscale 7>
3: 17:19:49.110086 192.168.1.2.55822 > 192.168.1.200.23: . ack 495495804
win 229 <nop,nop,timestamp 7177701 3421593>
4: 17:19:49.110391 192.168.1.2.55822 > 192.168.1.200.23: P 1700253548:
1700253575(27) ack 495495804 win 229 <nop,nop,timestamp 7177701 3421593>
5: 17:19:49.110651 192.168.1.200.23 > 192.168.1.2.55822: . ack 1700253575
win 227 <nop,nop,timestamp 3421596 7177701>
6: 17:19:49.116037 192.168.1.200.23 > 192.168.1.2.55822: P 495495804:
495495816(12) ack 1700253575 win 227 <nop,nop,timestamp 3421597 7177701>
7: 17:19:49.116159 192.168.1.2.55822 > 192.168.1.200.23: . ack 495495816
win 229 <nop,nop,timestamp 7177703 3421597>
.
.
! Output is Omitted for Brevity
When a packet matches a prefilter rule with the Fastpath action, the packet does not go through the Snort inspection phase. You verified that earlier in this chapter by analyzing the trace data of a captured packet.
Now, this section demonstrates that the Firepower Snort engine processes the initial TCP handshake before it begins trusting the rest of a connection. Therefore, the initial packets appear in the capture-traffic output. You can verify the cause of this behavior by looking into the tracing data. You should see two different Snort verdicts: The first Telnet packet is allowed, and the subsequent flows are fast-forwarded.
Example 14-12 shows an analysis of the first packet of a trusted TCP connection. The Snort verdict is to allow this packet.
Example 14-12 Analyzing the First Packet of a Trusted Telnet Connection
> show capture telnet_traffic packet-number 1 trace
78 packets captured
1: 17:19:49.096766 192.168.1.2.55822 > 192.168.1.200.23: S 1700253547:
1700253547(0) win 29200 <mss 1460,sackOK,timestamp 7177698 0,nop,wscale 7>
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: 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
Phase: 4
Type: ACCESS-LIST
Subtype: log
Result: ALLOW
Config:
access-group CSM_FW_ACL_ global
access-list CSM_FW_ACL_ advanced permit tcp object Corporate-Network any
object-group TELNET rule-id 268440580
access-list CSM_FW_ACL_ remark rule-id 268440580: ACCESS POLICY: AC Policy -
Mandatory/1
access-list CSM_FW_ACL_ remark rule-id 268440580: L7 RULE: Telnet Access
object-group service TELNET tcp
port-object eq telnet
Additional Information:
This packet will be sent to snort for additional processing where a verdict will be
reached
Phase: 5
Type: NGIPS-EGRESS-INTERFACE-LOOKUP
Subtype: Resolve Egress Interface
Result: ALLOW
Config:
Additional Information:
Ingress interface INSIDE_INTERFACE is in NGIPS inline mode.
Egress interface OUTSIDE_INTERFACE is determined by inline-set configuration
Phase: 6
Type: FLOW-CREATION
Subtype:
Result: ALLOW
Config:
Additional Information:
New flow created with id 282, packet dispatched to next module
Phase: 7
Type: EXTERNAL-INSPECT
Subtype:
Result: ALLOW
Config:
Additional Information:
Application: 'SNORT Inspect'
Phase: 8
Type: SNORT
Subtype:
Result: ALLOW
Config:
Additional Information:
Snort Verdict: (pass-packet) allow this packet
Result:
input-interface: INSIDE_INTERFACE
input-status: up
input-line-status: up
Action: allow
1 packet shown
>
Example 14-13 shows an analysis of the third and fourth packets of a trusted TCP connection. The Snort verdicts for both packets are to fast-forward them.
Example 14-13 Analyzing the Subsequent Packets of a Trusted Telnet Connection
! Packet Number 3:
> show capture telnet_traffic packet-number 3 trace
78 packets captured
3: 17:19:49.110086 192.168.1.2.55822 > 192.168.1.200.23: . ack 495495804
win 229 <nop,nop,timestamp 7177701 3421593>
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 282, using existing flow
Phase: 4
Type: EXTERNAL-INSPECT
Subtype:
Result: ALLOW
Config:
Additional Information:
Application: 'SNORT Inspect'
Phase: 5
Type: SNORT
Subtype:
Result: ALLOW
Config:
Additional Information:
Snort Verdict: (fast-forward) fast forward this flow
Result:
input-interface: INSIDE_INTERFACE
input-status: up
input-line-status: up
Action: allow
1 packet shown
>
! Packet Number 4:
> show capture telnet_traffic packet-number 4 trace
78 packets captured
4: 17:19:49.110391 192.168.1.2.55822 > 192.168.1.200.23: P 1700253548:
1700253575(27) ack 495495804 win 229 <nop,nop,timestamp 7177701 3421593>
Phase: 1
Type: CAPTURE
Subtype:
Result: ALLOW
Config:
Additional Information:
MAC Access list
.
.
! Output is Omitted for Brevity
.
.
Phase: 5
Type: SNORT
Subtype:
Result: ALLOW
Config:
Additional Information:
Snort Verdict: (fast-forward) fast forward this flow
Result:
input-interface: INSIDE_INTERFACE
input-status: up
input-line-status: up
Action: allow
1 packet shown
>
Example 14-14 shows statistics of the passed packet and fast-forwarded flows. In this example, an FTD device passes two Telnet packets before it fast-forwards (trusts) the rest of the flows of a connection.
Example 14-14 Counters for a Trusted Telnet Connection
! The Snort statistics keep a record of these events using two types of counters.
> show snort statistics
Packet Counters:
Passed Packets 2
Blocked Packets 0
Injected Packets 0
Flow Counters:
Fast-Forwarded Flows 1
Blacklisted Flows 0
Flows bypassed (Snort Down) 0
Flows bypassed (Snort Busy) 0
Miscellaneous Counters:
Start-of-Flow events 0
End-of-Flow events 0
Denied flow events 0
Frames forwarded to Snort before drop 0
Inject packets dropped 0
>
Using the Allow Action for Comparison
The Allow action passes a packet after it matches all the conditions in an access rule. Unlike the Trust action, the Allow action does not fast-forward any packets. All the packets in a connection are subject to inspection. To verify this behavior, deploy an access rule with the Allow action. As described here, you can redeploy the previously created Telnet access rule by changing the action type from Trust to Allow.
Figure 14-19 shows an access rule with the Allow action. The rule allows Telnet traffic when it originates from the corporate network 192.168.1.0/24.
After deploying the Telnet access rule, if you connect from host 192.168.1.2 to server 192.168.1.200, you should be able to access the server. This time, the FMC shows an Allow action for it.
Figure 14-20 shows a connection event with the Allow action. FTD generates this event if you enable logging for the Telnet access rule and the rule matches with a Telnet packet.
To verify the operation of the Allow action, you follow the same steps that you performed earlier in this chapter for Fastpath and Trust actions. However, you can just view the Snort statistics to determine whether the Allow action passed all the packets or fast-forwarded them.
Example 14-15 proves that the Allow action inspects and passes all the packets. It does not fast-forward any packets the way the Trust action does with traffic.
Example 14-15 Statistics of Packets After an Allowed Connection
> show snort statistics
Packet Counters:
Passed Packets 78
Blocked Packets 0
Injected Packets 0
Flow Counters:
Fast-Forwarded Flows 0
Blacklisted Flows 0
Flows bypassed (Snort Down) 0
Flows bypassed (Snort Busy) 0
Miscellaneous Counters:
Start-of-Flow events 0
End-of-Flow events 0
Denied flow events 0
Frames forwarded to Snort before drop 0
Inject packets dropped 0
>
Summary
This chapter discusses the techniques for bypassing packet inspection. It provides the steps for configuring different methods. The chapter also shows how to analyze the flows of bypassed packets to demonstrate how an FTD device acts with different bypassing options. This chapter also shows various debugging tools, which help you to determine whether the bypass process is working as designed.
Quiz
1. Which of the following rules can bypass one or more types of security inspection?
a. Prefilter rule
b. Tunnel rule
c. Access rule
d. All of the above
2. Which of the following commands shows a statistic of the bypassed packets?
a. show trust statistics
b. show snort statistics
c. show bypass statistics
d. show fastpath statistics
3. You are running the capture-traffic command on FTD. When you initiate a connection between two hosts, you do not see any packet in the capture output, but the hosts can connect successfully. Which of the following scenarios may be related?
a. Traffic between two hosts is inspected by the Snort engine, but events are suppressed.
b. Traffic between two hosts is trusted by the access control policy.
c. Traffic between two hosts is fastpathed by the prefilter policy.
d. None of the above. If the traffic goes through an FTD device and the hosts are connected, FTD must see the traffic.
4 What is the difference between a prefilter rule and an access rule?
a. A prefilter rule matches for traffic prior to an access rule.
b. A prefilter rule analyzes traffic based on the outermost header of a packet, whereas an access rule analyzes the innermost header.
c. A prefilter rule supports limited options to create a rule condition, whereas an access rule offers many granular options.