ASA with FirePOWER Services Local Management Configuration Guide, Version 6.2

Initiating Active Responses with Intrusion Drop Rules

License: Protection

A drop rule is an intrusion rule or preprocessor rule whose rule state is set to Drop and Generate Events. In an inline deployment, the system responds to TCP or UDP drop rules by dropping the triggering packet and blocking the session where the packet originated. In a passive deployment, the system cannot drop the packet and does not block the session except with the use of active responses.

Tip Because UDP data streams are not typically thought of in terms of sessions, see Using UDP Stream Preprocessing for further explanation of how the stream preprocessor uses the source and destination IP address fields in the encapsulating IP datagram header and the port fields in the UDP header to determine the direction of flow and identify a UDP session.

You can configure the Maximum Active Responses option to initiate one or more active responses to more precisely and specifically close a TCP connection or UDP session when an offending packet triggers a TCP or UDP drop rule.

When active responses are enabled in an inline deployment, the system responds to TCP drop rules by dropping the triggering packet and inserting a TCP Reset (RST) packet in both the client and server traffic. The system cannot drop the packet in a passive deployment; when active responses are enabled in a passive deployment, the system responds to TCP drop rules by sending a TCP reset to both the client and server ends of a TCP connection. When active responses are enabled in inline or passive deployments, the system closes a UDP session by sending an ICMP unreachable packet to each end of the session. Active responses are most effective in inline deployments because resets are more likely to arrive in time to affect the connection or session.

Depending on how you configure the Maximum Active Responses option, the system can also initiate additional active responses if it sees additional traffic from either end of the connection or session. The system initiates each additional active response, up to a specified maximum, after a specified number of seconds have elapsed since the previous response.

See Selecting The TCP Global Option for information on setting the maximum number of active responses.

Note that a triggered resp or react rule also initiates an active response regardless of the configuration of Maximum Active Responses ; however, Maximum Active Responses control whether the system initiates additional active responses for resp and react rules in the same way it controls the maximum number of active responses for drop rules. See Initiating Active Responses with Rule Keywords for more information.

You can also use the config response command to configure the active response interface to use and the number of TCP resets to attempt in a passive deployment. See Setting the Active Response Reset Attempts and Interface for more information.

No preprocessor rules are associated with the following options.

Maximum Active Responses

Specifies a maximum of 1 to 25 active responses per TCP connection. When additional traffic occurs on a connection where an active response has been initiated, and the traffic occurs more than Minimum Response Seconds after a previous active response, the system sends another active response unless the specified maximum has been reached. A setting of 0 disables active responses triggered by drop rules and disables additional active responses triggered by resp or react rules. For more information, see Initiating Active Responses with Intrusion Drop Rules and Initiating Active Responses with Rule Keywords.

Minimum Response Seconds

Until Maximum Active Responses occur, specifies waiting 1 to 300 seconds before any additional traffic on a connection where the system has initiated an active response results in a subsequent active response.

To initiate active responses with drop rules:

Step 1 Select Configuration > ASA FirePOWER Configuration > Policies > Access Control Policy .

The Access Control Policy page appears.

Step 2 Click the edit icon ( ) next to the access control policy you want to edit.

The access control policy editor appears.

Step 3 Select the Advanced tab.

The access control policy advanced settings page appears.

Step 4 Click the edit icon ( ) next to Network Analysis and Intrusion Policies .

The Network Analysis and Intrusion Policies pop-up window appears.

Step 5 Click Network Analysis Policy List .

The Network Analysis Policy List pop-up window appears.

Step 6 Click the edit icon ( ) next to the access control policy you want to edit.

The access control policy editor appears.

Step 7 Select the Advanced tab.

The access control policy advanced settings page appears.

Step 8 Click the edit icon ( ) next to Transport/Network Layer Preprocessor Settings .

The Transport/Network Layer Preprocessor Settings pop-up window appears.

Step 9 You have the following options:

• Specify a value 1 to 25 of Maximum Active Responses per TCP connection. A setting of 0 disables active responses triggered by drop rules and disables additional active responses triggered by resp or react rules.
• Specify a value 1 to 300 of Minimum Response Seconds to wait until either Maximum Active Responses occur or any additional traffic on a connection where the system has initiated an active response results in a subsequent active response.

Step 10 Click OK.

You must apply the access control policy for your changes to take effect; see Deploying Configuration Changes.

Troubleshooting: Logging Session Termination Messages

License: Protection

Support might ask you during a troubleshooting call to configure your system to log a message when an individual connection exceeds the specified threshold. Changing the setting for this option will affect performance and should be done only with Support guidance.

To log session termination messages:

Step 1 Select Configuration > ASA FirePOWER Configuration > Policies > Access Control Policy .

The Access Control Policy page appears.

Step 2 Click the edit icon ( ) next to the access control policy you want to edit.

The access control policy editor appears.

Step 3 Select the Advanced tab.

The access control policy advanced settings page appears.

Step 4 Click the edit icon ( ) next to Network Analysis and Intrusion Policies .

The Network Analysis and Intrusion Policies pop-up window appears.

Step 5 Click Network Analysis Policy List .

The Network Analysis Policy List pop-up window appears.

Step 6 Click the edit icon ( ) next to the access control policy you want to edit.

The access control policy editor appears.

Step 7 Select the Advanced tab.

The access control policy advanced settings page appears.

Step 8 Click the edit icon ( ) next to Transport/Network Layer Preprocessor Settings .

The Transport/Network Layer Preprocessor Settings pop-up window appears.

Step 9 Expand Troubleshooting Options .

Step 10 Specify for Session Termination Logging Threshold the number of bytes that result in a logged message when the session terminates and the specified number was exceeded.

The upper limit of 1GB is also restricted by the amount of memory on the device allocated for stream processing.

Step 11 Click OK.

You must apply the access control policy for your changes to take effect; see Deploying Configuration Changes.

Understanding IP Fragmentation Exploits

License: Protection

Enabling IP defragmentation helps you detect attacks against hosts on your network, like the teardrop attack, and resource consumption attacks against the system itself, like the Jolt2 attack.

The Teardrop attack exploits a bug in certain operating systems that causes them to crash when trying to reassemble overlapping IP fragments. When enabled and configured to do so, the IP defragmentation preprocessor identifies the overlapping fragments. The IP defragmentation preprocessor detects the first packets in an overlapping fragment attack such as Teardrop, but does not detect subsequent packets for the same attack.

The Jolt2 attack sends a large number of copies of the same fragmented IP packet in an attempt to overuse IP defragmentors and cause a denial of service attack. A memory usage cap disrupts this and similar attacks in the IP defragmentation preprocessor, and places the system self-preservation above exhaustive inspection. The system is not overwhelmed by the attack, remains operational, and continues to inspect network traffic.

Different operating systems reassemble fragmented packets in different ways. Attackers who can determine which operating systems your hosts are running can also fragment malicious packets so that a target host reassembles them in a specific manner. Because the system does not know which operating systems the hosts on your monitored network are running, the preprocessor may reassemble and inspect the packets incorrectly, thus allowing an exploit to pass through undetected. To mitigate this kind of attack, you can configure the defragmentation preprocessor to use the appropriate method of defragmenting packets for each host on your network. See Target-Based Defragmentation Policies for more information.

Note that you can also use adaptive profiles to dynamically select target-based policies for the IP defragmentation preprocessor using host operating system information for the target host in a packet. For more information, see Tuning Preprocessing in Passive Deployments.

Target-Based Defragmentation Policies

License: Protection

A host's operating system uses three criteria to determine which packet fragments to favor when reassembling the packet: the order in which the fragment was received by the operating system, its offset (the fragment's distance, in bytes, from the beginning of the packet), and its beginning and ending position compared to overlap fragments. Although every operating system uses these criteria, different operating systems favor different fragments when reassembling fragmented packets. Therefore, two hosts with different operating systems on your network could reassemble the same overlapping fragments in entirely different ways.

An attacker, aware of the operating system of one of your hosts, could attempt to evade detection and exploit that host by sending malicious content hidden in overlapping packet fragments. This packet, when reassembled and inspected, seems innocuous, but when reassembled by the target host, contains a malicious exploit. However, if you configure the IP defragmentation preprocessor to be aware of the operating systems running on your monitored network segment, it will reassemble the fragments the same way that the target host does, allowing it to identify the attack.

You can configure the IP defragmentation preprocessor to use one of seven defragmentation policies, depending on the operating system of the target host. The following table lists the seven policies and the operating systems that use each one. The First and Last policy names reflect whether those policies favor original or subsequent overlapping packets.

Selecting Defragmentation Options

License: Protection

You can choose to simply enable or disable IP defragmentation; however, Cisco recommends that you specify the behavior of the enabled IP defragmentation preprocessor at a more granular level.

If no preprocessor rule is mentioned in the following descriptions, the option is not associated with a preprocessor rule.

You can configure the global Preallocated Fragments option:

Preallocated Fragments

The maximum number of individual fragments that the preprocessor can process at once. Specifying the number of fragment nodes to preallocate enables static memory allocation.

You can configure the following options for each IP defragmentation policy:

Networks

The IP address of the host or hosts to which you want to apply the defragmentation policy.

You can specify a single IP address or address block, or a comma-separated list of either or both. You can specify up to 255 total profiles, including the default policy. For information on using IPv4 and IPv6 address blocks in the ASA FirePOWER module, see IP Address Conventions.

Note that the default setting in the default policy specifies all IP addresses on your monitored network segment that are not covered by another target-based policy. Therefore, you cannot and do not need to specify an IP address or CIDR block/prefix length for the default policy, and you cannot leave this setting blank in another policy or use address notation to represent any (for example, 0.0.0.0/0 or ::/0).

Note also that for a target-based policy to process traffic, the networks you identify must match or be a subset of the networks, and zones handled by the network analysis policy where you configure the target-based policy. See Customizing Preprocessing with Network Analysis Policies for more information.

Policy

The defragmentation policy you want to use for a set of hosts on your monitored network segment. You can choose among seven policies: BSD, BSD-Right, First, Linux, Last, Solaris, and Windows. See Target-Based Defragmentation Policies for detailed information on these policies.

Timeout

Specifies the maximum amount of time, in seconds, that the preprocessor engine can use when reassembling a fragmented packet. If the packet cannot be reassembled within the specified time period, the preprocessor engine stops attempting to reassemble the packet and discards received fragments.

Minimum TTL

Specifies the minimum acceptable TTL value a packet may have. This option detects TTL-based insertion attacks.

You can enable rule 123:1 to generate events for this option. See Setting Rule States for more information.

Detect Anomalies

Identifies fragmentation problems such as overlapping fragments.

You can enable the following rules to generate events for this option:

• 123:1 through 123:4
• 123:5 (BSD policy)
• 123:6 through 123:8

Overlap Limit

Specifies that when the configured number between 0 (unlimited) and 255 of overlapping segments in a session has been detected, defragmentation stops for that session. You must enable Detect Anomalies to configure this option. A blank value disables this option.

You can enable rule 123:12 to generate events for this option. See Setting Rule States for more information.

Minimum Fragment Size

Specifies that when a non-last fragment smaller than the configured number between 0 (unlimited) and 255 of bytes has been detected, the packet is considered malicious. You must enable Detect Anomalies to configure this option. A blank value disables this option.

You can enable rule 123:13 to generate events for this option. See Setting Rule States for more information.

Configuring IP Defragmentation

License: Protection

You can use the following procedure to configure the IP defragmentation preprocessor. For more information on the IP defragmentation preprocessor configuration options, see Selecting Defragmentation Options.

To configure IP defragmentation:

Step 1 Select Configuration > ASA FirePOWER Configuration > Policies > Access Control Policy .

The Access Control Policy page appears.

Step 2 Click the edit icon ( ) next to the access control policy you want to edit.

The access control policy editor appears.

Step 3 Select the Advanced tab.

The access control policy advanced settings page appears.

Step 4 Click the edit icon ( ) next to Network Analysis and Intrusion Policies .

The Network Analysis and Intrusion Policies pop-up window appears.

Step 5 Click Network Analysis Policy List .

The Network Analysis Policy List pop-up window appears.

Step 6 Click the edit icon ( ) next to the policy you want to edit.

If you have unsaved changes in another policy, click OK to discard those changes and continue. See Resolving Conflicts and Committing Policy Changes for information on saving unsaved changes in another policy.

The Edit Policy page appears.

Step 7 Click Settings in the navigation panel on the left.

The Settings page appears.

Step 8 You have two choices, depending on whether IP Defragmentation under Transport/Network Layer Preprocessors is enabled:

• If the configuration is enabled, click Edit .
• If the configuration is disabled, click Enabled , then click Edit .

The IP Defragmentation page appears. A message at the bottom of the page identifies the policy layer that contains the configuration. See Using Layers in a Network Analysis or Intrusion Policy for more information.

Step 9 Optionally, you can modify the setting for Preallocated Fragments in the Global Settings page area.

Step 10 You have two options:

• Add a new target-based policy. Click the add icon (
) next to Servers on the left side of the page. The Add Target pop-up window appears. Specify one or more IP addresses in the Host Address field and click OK .

You can specify a single IP address or address block, or a comma-separated list of either or both. You can create a total of 255 target-based policies including the default policy. For information on using IP address blocks in the ASA FirePOWER module, see IP Address Conventions.

Note that for a target-based policy to process traffic, the networks you identify must match or be a subset of the networks, and zones handled by the network analysis policy where you configure the target-based policy. See Customizing Preprocessing with Network Analysis Policies for more information.

A new entry appears in the list of targets on the left side of the page, highlighted to indicate that it is selected, and the Configuration section updates to reflect the current configuration for the policy you added.

• Modify the settings for an existing target-based policy. Click the configured address for a policy you have added under Hosts on the left side of the page, or click default .

Your selection is highlighted and the Configuration section updates to display the current configuration for the policy you selected. To delete an existing target-based policy, click the delete icon ( ) next to the policy you want to remove.

Step 11 Optionally, you can modify any of the options in the Configuration page area.

Step 12 Save your policy, continue editing, discard your changes, revert to the default configuration settings in the base policy, or exit while leaving your changes in the system cache. See Resolving Conflicts and Committing Policy Changes for more information.

Configuring Packet Decoding

License: Protection

You can configure packet decoding on the Packet Decoding configuration page. For more information on packet decoding configuration options, see Understanding Packet Decoding.

To configure packet decoding:

Step 1 Select Configuration > ASA FirePOWER Configuration > Policies > Access Control Policy .

The Access Control Policy page appears.

Step 2 Click the edit icon ( ) next to the access control policy you want to edit.

The access control policy editor appears.

Step 3 Select the Advanced tab.

The access control policy advanced settings page appears.

Step 4 Click the edit icon ( ) next to Network Analysis and Intrusion Policies .

The Network Analysis and Intrusion Policies pop-up window appears.

Step 5 Click Network Analysis Policy List .

The Network Analysis Policy List pop-up window appears.

Step 6 Click the edit icon ( ) next to the policy you want to edit.

If you have unsaved changes in another policy, click OK to discard those changes and continue. See Resolving Conflicts and Committing Policy Changes for information on saving unsaved changes in another policy.

The Edit Policy page appears.

Step 7 Click Settings in the navigation panel on the left.

The Settings page appears.

Step 8 You have two choices, depending on whether Packet Decoding under Transport/Network Layer Preprocessors is enabled:

• If the configuration is enabled, click Edit .
• If the configuration is disabled, click Enabled , then click Edit .

The Packet Decoding page appears. A message at the bottom of the page identifies the policy layer that contains the configuration. See Resolving Conflicts and Committing Policy Changes for more information

Step 9 You can enable or disable any of the detection options on the Packet Decoding page. See Understanding Packet Decoding for more information.

Step 10 Save your policy, continue editing, discard your changes, revert to the default configuration settings in the base policy, or exit while leaving your changes in the system cache. See Resolving Conflicts and Committing Policy Changes for more information.

Understanding State-Related TCP Exploits

License: Protection

If you add the flow keyword with the established argument to an intrusion rule, the intrusion rules engine inspects packets matching the rule and the flow directive in stateful mode. Stateful mode evaluates only the traffic that is part of a TCP session established with a legitimate three-way handshake between a client and server. The following diagram illustrates a three-way handshake.

You can configure the system so that the preprocessor detects any TCP traffic that cannot be identified as part of an established TCP session, although this is not recommended for typical use because the events would quickly overload the system and not provide meaningful data.

Attacks like stick and snot use the system’s extensive rule sets and packet inspection against itself. These tools generate packets based on the patterns in Snort-based intrusion rules, and send them across the network. If your rules do not include the flow or flowbits keyword to configure them for stateful inspection, each packet will trigger the rule, overwhelming the system. Stateful inspection allows you to ignore these packets because they are not part of an established TCP session and do not provide meaningful information. When performing stateful inspection, the rules engine detects only those attacks that are part of an established TCP session, allowing analysts to focus on these rather than the volume of events caused by stick or snot.

Selecting The TCP Global Option

License: Protection

The TCP stream preprocessor has one global option that controls how the TCP stream preprocessor functions.

No preprocessor rules are associated with this option.

Packet Type Performance Boost

Enables ignoring TCP traffic for all ports and application protocols that are not specified in enabled intrusion rules, except when a TCP rule with both the source and destination ports set to any has a flow or flowbits option. This performance improvement could result in missed attacks.

Understanding Target-Based TCP Policies

License: Protection

Different operating systems implement TCP in different ways. For example, Windows and some other operating systems require a TCP reset segment to have a precise TCP sequence number to reset a session, while Linux and other operating systems permit a range of sequence numbers. In this example, the stream preprocessor must understand exactly how the destination host will respond to the reset based on the sequence number. The stream preprocessor stops tracking the session only when the destination host considers the reset to be valid, so an attack cannot evade detection by sending packets after the preprocessor stops inspecting the stream. Other variations in TCP implementations include such things as whether an operating system employs a TCP timestamp option and, if so, how it handles the timestamp, and whether an operating system accepts or ignores data in a SYN packet.

Different operating systems also reassemble overlapping TCP segments in different ways. Overlapping TCP segments could reflect normal retransmissions of unacknowledged TCP traffic. They could also represent an attempt by an attacker, aware of the operating system of one of your hosts, to evade detection and exploit that host by sending malicious content hidden in overlapping segments. However, you can configure the stream preprocessor to be aware of the operating systems running on your monitored network segment so it reassembles segments the same way the target host does, allowing it to identify the attack.

You can create one or more TCP policies to tailor TCP stream inspection and reassembly to the different operating systems on your monitored network segment. For each policy, you identify one of thirteen operating system policies. You bind each TCP policy to a specific IP address or address block using as many TCP policies as you need to identify any or all of the hosts using a different operating system. The default TCP policy applies to any hosts on the monitored network that you do not identify in any other TCP policy, so there is no need to specify an IP address, CIDR block, or prefix length for the default TCP policy.

Note that you can also use adaptive profiles to dynamically select target-based policies for the TCP stream preprocessor using host operating system information for the target host in a packet. For more information, see Tuning Preprocessing in Passive Deployments.

The following table identifies the operating system policies and the host operating systems that use each.

Tip The First operating system policy could offer some protection when you do not know the host operating system. However, it may result in missed attacks. You should edit the policy to specify the correct operating system if you know it.

Selecting TCP Policy Options

License: Protection

The following list describes the options you can set to identify and control TCP traffic that the stream preprocessor inspects.

If no preprocessor rule is mentioned in the following descriptions, the option is not associated with a preprocessor rule.

Network

Specifies the host IP addresses to which you want to apply the TCP stream reassembly policy.

You can specify a single IP address or address block. You can specify up to 255 total profiles including the default policy. For information on using IPv4 and IPv6 address blocks in the ASA FirePOWER module, see IP Address Conventions.

Note that the default setting in the default policy specifies all IP addresses on your monitored network segment that are not covered by another target-based policy. Therefore, you cannot and do not need to specify an IP address or CIDR block/prefix length for the default policy, and you cannot leave this setting blank in another policy or use address notation to represent any (for example, 0.0.0.0/0 or ::/0).

Note also that for a target-based policy to process traffic, the networks you identify must match or be a subset of the networks and zones handled by the network analysis policy where you configure the target-based policy. See Customizing Preprocessing with Network Analysis Policies for more information.

Policy

Identifies the TCP policy operating system of the target host or hosts. If you select a policy other than Mac OS , the system removes the data from the synchronization (SYN) packets and disables event generation for rule 129:2.

For more information, see Understanding Target-Based TCP Policies.

Timeout

The number of seconds between 1 and 86400 the intrusion rules engine keeps an inactive stream in the state table. If the stream is not reassembled in the specified time, the intrusion rules engine deletes it from the state table.

Note If your device is deployed on a segment where the network traffic is likely to reach the device’s bandwidth limits, you should consider setting this value higher (for example, to 600 seconds) to lower the amount of processing overhead.

Maximum TCP Window

Specifies the maximum TCP window size between 1 and 1073725440 bytes allowed as specified by a receiving host. Setting the value to 0 disables checking for the TCP window size.

You can enable rule 129:6 to generate events for this option. See Setting Rule States for more information.

Overlap Limit

Specifies that when the configured number between 0 (unlimited) and 255 of overlapping segments in a session has been detected, segment reassembly stops for that session and, if Stateful Inspection Anomalies is enabled and the accompanying preprocessor rule is enabled, an event is generated.

You can enable rule 129:7 to generate events for this option. See Setting Rule States for more information.

Flush Factor

In an inline deployment, specifies that when a segment of decreased size has been detected subsequent to the configured number between 1 and 2048 of segments of non-decreasing size, the system flushes segment data accumulated for detection. Setting the value to 0 disables detection of this segment pattern, which can indicate the end of a request or response. Note that the Inline Normalization Normalize TCP Payload option must be enabled for this option the be effective. See Normalizing Inline Traffic for more information.

Stateful Inspection Anomalies

Detects anomalous behavior in the TCP stack. When accompanying preprocessor rules are enabled, this may generate many events if TCP/IP stacks are poorly written.

You can enable the following rules to generate events for this option:

– 129:1 through 129:5

– 129:6 (Mac OS only)

– 129:8 through 129:11

– 129:13 through 129:19

See Setting Rule States for more information:

TCP Session Hijacking

Detects TCP session hijacking by validating the hardware (MAC) addresses detected from both sides of a TCP connection during the 3-way handshake against subsequent packets received on the session. When the MAC address for one side or the other does not match, if Stateful Inspection Anomalies is enabled and one of the two corresponding preprocessor rules are enabled, the system generates events.

You can enable rules 129:9 and 129:10 to generate events for this option. See Setting Rule States for more information.

Consecutive Small Segments

When Stateful Inspection Anomalies is enabled, specifies a maximum number of 1 to 2048 consecutive small TCP segments allowed. Setting the value to 0 disables checking for consecutive small segments.

You must set this option together with the Small Segment Size option, either disabling both or setting a non-zero value for both. Note that receiving as many as 2000 consecutive segments, even if each segment was 1 byte in length, without an intervening ACK would be far more consecutive segments than you would normally expect.

You can enable rule 129:12 to generate events for this option. See Setting Rule States for more information.

Small Segment Size

When Stateful Inspection Anomalies is enabled, specifies the 1 to 2048 byte TCP segment size that is considered small. Setting the value to 0 disables specifying the size of a small segment.

You must set this option together with the Consecutive Small Segments option, either disabling both or setting a non-zero value for both. Note that a 2048 byte TCP segment is larger than a normal 1500 byte Ethernet frame.

Ports Ignoring Small Segments

When Stateful Inspection Anomalies , Consecutive Small Segments , and Small Segment Size are enabled, optionally specifies a comma-separated list of one or more ports that ignore small TCP segment detection. Leaving this option blank specifies that no ports are ignored.

You can add any port to the list, but the list only affects ports specified in one of the Perform Stream Reassembly on port lists in the TCP policy.

Require TCP 3-Way Handshake

Specifies that sessions are treated as established only upon completion of a TCP three-way handshake. Disable this option to increase performance, protect from SYN flood attacks, and permit operation in a partially asynchronous environment. Enable it to avoid attacks that attempt to generate false positives by sending information that is not part of an established TCP session.

You can enable rule 129:20 to generate events for this option. See Setting Rule States for more information.

3-Way Handshake Timeout

Specifies the number of seconds between 0 (unlimited) and 86400 (twenty-four hours) by which a handshake must be completed when Require TCP 3-Way Handshake is enabled. You must enable Require TCP 3-Way Handshake to modify the value for this option.

Packet Size Performance Boost

Sets the preprocessor to not queue large packets in the reassembly buffer. This performance improvement could result in missed attacks. Disable this option to protect against evasion attempts using small packets of one to twenty bytes. Enable it when you are assured of no such attacks because all traffic is comprised of very large packets.

Legacy Reassembly

Sets the stream preprocessor to emulate the deprecated Stream 4 preprocessor when reassembling packets, which lets you compare events reassembled by the stream preprocessor to events based on the same data stream reassembled by the Stream 4 preprocessor.

Asynchronous Network

Specifies whether the monitored network is an asynchronous network, that is, a network where the system sees only half the traffic. When this option is enabled, the system does not reassemble TCP streams to increase performance.

Perform Stream Reassembly on Client Ports, Server Ports, Both Ports

Specifies for client ports, server ports, or both, a comma-separated list of ports to identify the traffic for the stream preprocessor to reassemble. See Selecting Stream Reassembly Options.

Perform Stream Reassembly on Client Services, Server Services, Both Services

Specifies for client services, server services, or both, services to identify in the traffic for the stream preprocessor to reassemble. See Selecting Stream Reassembly Options.

Troubleshooting Options: Maximum Queued Bytes

Support might ask you during a troubleshooting call to specify the amount of data that can be queued on one side of a TCP connection. A value of 0 specifies an unlimited number of bytes.

Troubleshooting Options: Maximum Queued Segments

Support might ask you during a troubleshooting call to specify the maximum number of bytes of data segments that can be queued on one side of a TCP connection. A value of 0 specifies an unlimited number of data segment bytes.

Reassembling TCP Streams

License: Protection

The stream preprocessor collects and reassembles all the packets that are part of a TCP session’s server-to-client communication stream, client-to-server communication stream, or both. This allows the rules engine to inspect the stream as a single, reassembled entity rather than inspecting only the individual packets that are part of a given stream.

See the following sections for more information:

• Understanding Stream-Based Attacks
• Selecting Stream Reassembly Options

Understanding Stream-Based Attacks

License: Protection

Stream reassembly allows the rules engine to identify stream-based attacks, which it may not detect when inspecting individual packets. You can specify which communication streams the rules engine reassembles based on your network needs. For example, when monitoring traffic on your web servers, you may only want to inspect client traffic because you are much less likely to receive malicious traffic from your own web server.

Selecting Stream Reassembly Options

License: Protection

In each TCP policy, you can specify a comma-separated list of ports to identify the traffic for the stream preprocessor to reassemble. If adaptive profiles are enabled, you can also list services that identify traffic to reassemble, either as an alternative to ports or in combination with ports. See Tuning Preprocessing in Passive Deployments for information on enabling and using adaptive profiles.

You can specify ports, services, or both. You can specify separate lists of ports for any combination of client ports, server ports, and both. You can also specify separate lists of services for any combination of client services, server services, and both. For example, assume that you wanted to reassemble the following:

• SMTP (port 25) traffic from the client
• FTP server responses (port 21)
• telnet (port 23) traffic in both directions

You could configure the following:

• For client ports, specify 23, 25
• For server ports, specify 21, 23

Or, instead, you could configure the following:

• For client ports, specify 25
• For server ports, specify 21
• For both ports, specify 23

Additionally, consider the following example which combines ports and services and would be valid when adaptive profiles are enabled:

• For client ports, specify 23
• For client services, specify smtp
• For server ports, specify 21
• For server services, specify telnet

Although you can also specify all as the argument to provide reassembly for all ports, Cisco does not recommend setting ports to all because it may increase the amount of traffic inspected by this preprocessor and slow performance unnecessarily.

TCP reassembly automatically and transparently includes ports that you add to other preprocessors. However, if you do explicitly add ports to TCP reassembly lists that you have added to other preprocessor configurations, these additional ports are handled normally. This includes port lists for the following preprocessors:

• FTP/Telnet (server-level FTP)
• DCE/RPC
• HTTP Inspect
• SMTP
• Session Initiation Protocol
• POP
• IMAP
• SSL

Negating a port (for example, !77) can improve performance by preventing the TCP stream preprocessor from processing traffic for that port.

Note that reassembling additional traffic types (client, server, both) increases resource demands.

If no preprocessor rule is mentioned in the following descriptions, the option is not associated with a preprocessor rule.

Perform Stream Reassembly on Client Ports

Enables stream reassembly based on ports for the client side of the connection. In other words, it reassembles streams destined for web servers, mail servers, or other IP addresses typically defined by the IP addresses specified in $HOME_NET. Use this option when you expect malicious traffic to originate from clients.

Perform Stream Reassembly on Client Services

Enables stream reassembly based on services for the client side of the connection. Use this option when you expect malicious traffic to originate from clients.

This feature requires Protection and Control licenses.

Perform Stream Reassembly on Server Ports

Enables stream reassembly based on ports for the server side of the connection only. In other words, it reassembles streams originating from web servers, mail servers, or other IP addresses typically defined by the IP addresses specified in $EXTERNAL_NET. Use this option when you want to watch for server side attacks. You can disable this option by not specifying ports.

Perform Stream Reassembly on Server Services

Enables stream reassembly based on services for the server side of the connection only. Use this option when you want to watch for server side attacks. You can disable this option by not specifying services.

This feature requires Protection and Control licenses.

Perform Stream Reassembly on Both Ports

Enables stream reassembly based on ports for both the client and server side of the connection. Use this option when you expect that malicious traffic for the same ports may travel in either direction between clients and servers. You can disable this option by not specifying ports.

Perform Stream Reassembly on Both Services

Enables stream reassembly based on services for both the client and server side of the connection. Use this option when you expect that malicious traffic for the same services may travel in either direction between clients and servers.You can disable this option by not specifying services.

This feature requires Protection and Control licenses.

Configuring TCP Stream Preprocessing

License: Protection

You can configure TCP stream preprocessing, including TCP policies. For more information on the TCP stream preprocessor configuration options, see Selecting TCP Policy Options.

To configure the stream preprocessor to track TCP sessions:

Step 1 Select Configuration > ASA FirePOWER Configuration > Policies > Access Control Policy .

The Access Control Policy page appears.

Step 2 Click the edit icon ( ) next to the access control policy you want to edit.

The access control policy editor appears.

Step 3 Select the Advanced tab.

The access control policy advanced settings page appears.

Step 4 Click the edit icon ( ) next to Network Analysis and Intrusion Policies .

The Network Analysis and Intrusion Policies pop-up window appears.

Step 5 Click Network Analysis Policy List .

The Network Analysis Policy List pop-up window appears.

Step 6 Click the edit icon ( ) next to the policy you want to edit.

If you have unsaved changes in another policy, click OK to discard those changes and continue. See Resolving Conflicts and Committing Policy Changes for information on saving unsaved changes in another policy.

The Edit Policy page appears.

Step 7 Click Settings in the navigation panel on the left.

The Settings page appears.

Step 8 You have two choices, depending on whether TCP Stream Configuration under Transport/Network Layer Preprocessors is enabled:

• If the configuration is enabled, click Edit .
• If the configuration is disabled, click Enabled , then click Edit .

The TCP Stream Configuration page appears. A message at the bottom of the page identifies the policy layer that contains the configuration. See Using Layers in a Network Analysis or Intrusion Policy for more information.

Step 9 Optionally, modify Packet Type Performance Boost under Global Settings. See Selecting The TCP Global Option for more information.

Step 10 You have two options:

• Add a new target-based policy. Click the add icon (
) next to Hosts on the left side of the page. The Add Target pop-up window appears. Specify one or more IP addresses in the Host Address field and click OK .

You can specify a single IP address or address block. You can create a total of 255 target-based policies including the default policy. For information on using IP address blocks in the ASA FirePOWER module, see IP Address Conventions.

Note that for a target-based policy to process traffic, the networks you identify must match or be a subset of the networks and zones handled by the network analysis policy where you configure the target-based policy. See Customizing Preprocessing with Network Analysis Policies for more information.

A new entry appears in the list of targets on the left side of the page, highlighted to indicate that it is selected, and the Configuration section updates to reflect the current configuration for the policy you added.

• Modify the settings for an existing target-based policy. Click the configured address for a policy you have added under Hosts on the left side of the page, or click default .

Your selection is highlighted and the Configuration section updates to display the current configuration for the policy you selected. To delete an existing target-based policy, click the delete icon ( ) next to the policy you want to remove.

Step 11 Optionally, modify any of the TCP policy options under Configuration.

For specific instructions on modifying settings for stream reassembly based on client services, server services, or both go to step 12 ; otherwise, go to step 15 .

For more information, see Selecting TCP Policy Options, and Selecting Stream Reassembly Options.

Step 12 To modify settings for stream reassembly based on client, server, or both services, click inside the field you want to modify or click Edit next to the field.

The pop-up window for the field you selected appears.

For example, the following graphic shows the Perform Stream Reassembly on Both Services pop-up window.

 

Note that you can enable adaptive profiles to monitor traffic for the stream preprocessor to reassemble based on services discovered on your network. See Tuning Preprocessing in Passive Deployments for more information.

Step 13 You have two choices:

• To add services to monitor, select one or more services from the Available list on the left, then click the right arrow ( > ) button.
• To remove a service, select it from the Enabled list on the right, then click the left arrow ( < ) button.

Use Ctrl or Shift while clicking to select multiple service detectors. You can also click and drag to select multiple adjacent service detectors.

Step 14 Click OK to add the selections.

The TCP Stream Configuration page is displayed and the services are updated.

Step 15 Optionally, expand the Troubleshooting Options and modify either of the TCP stream preprocessing policy settings only if asked to do so by Support. For more information, see Selecting TCP Policy Options.

Step 16 Save your policy, continue editing, discard your changes, revert to the default configuration settings in the base policy, or exit while leaving your changes in the system cache. See Resolving Conflicts and Committing Policy Changes for more information.

---

 

Configuring UDP Stream Preprocessing

License: Protection

You can configure UDP stream preprocessing.

To configure the stream preprocessor to track UDP sessions:

Step 1 Select Configuration > ASA FirePOWER Configuration > Policies > Access Control Policy .

The Access Control Policy page appears.

Step 2 Click the edit icon ( ) next to the access control policy you want to edit.

The access control policy editor appears.

Step 3 Select the Advanced tab.

The access control policy advanced settings page appears.

Step 4 Click the edit icon ( ) next to Network Analysis and Intrusion Policies .

The Network Analysis and Intrusion Policies pop-up window appears.

Step 5 Click Network Analysis Policy List .

The Network Analysis Policy List pop-up window appears.

Step 6 Click the edit icon ( ) next to the policy you want to edit.

If you have unsaved changes in another policy, click OK to discard those changes and continue. See Resolving Conflicts and Committing Policy Changes for information on saving unsaved changes in another policy.

The Edit Policy page appears.

Step 7 Click Settings in the navigation panel on the left.

The Settings page appears.

Step 8 You have two choices, depending on whether UDP Stream Configuration under Transport/Network Layer Preprocessors is enabled:

• If the configuration is enabled, click Edit .
• If the configuration is disabled, click Enabled , then click Edit .

The UDP Stream Configuration page appears. A message at the bottom of the page identifies the policy layer that contains the configuration. See Using Layers in a Network Analysis or Intrusion Policy for more information.

Step 9 Optionally, configure a Time out value to specify the number of seconds between 1 and 86400 the preprocessor keeps an inactive stream in the state table. If additional datagrams are not seen in the specified time, the preprocessor deletes the stream from the state table.

Step 10 Optionally, select Packet Type Perf ormance Boost to ignore UDP traffic for all ports and application protocols that are not specified in enabled rules, except when a UDP rule with both the source and destination ports set to any has a flow or flowbits option. This performance improvement could result in missed attacks.

Step 11 Save your policy, continue editing, discard your changes, revert to the default configuration settings in the base policy, or exit while leaving your changes in the system cache. See Resolving Conflicts and Committing Policy Changes for more information.