Cisco Security Appliance Command Line Configuration Guide, Version 7.2

Preventing Network Attacks

This chapter describes how to prevent network attacks by configuring TCP normalization, limiting TCP and UDP connections, and many other protection features.

This chapter includes the following sections:

•Configuring TCP Normalization

•Configuring Connection Limits and Timeouts

•Preventing IP Spoofing

•Configuring the Fragment Size

•Blocking Unwanted Connections

•Configuring IP Audit for Basic IPS Support

Configuring TCP Normalization

The TCP normalization feature identifies abnormal packets that the security appliance can act on when they are detected; for example, the security appliance can allow, drop, or clear the packets. TCP normalization helps protect the security appliance from attacks. This section includes the following topics:

•TCP Normalization Overview

•Enabling the TCP Normalizer

TCP Normalization Overview

The TCP normalizer includes non-configurable actions and configurable actions. Typically, non-configurable actions that drop or clear connections apply to packets that are always bad. Configurable actions (as detailed in "Enabling the TCP Normalizer" section) might need to be customized depending on your network needs.

See the following guidelines for TCP normalization:

•The normalizer does not protect from SYN floods. The security appliance includes SYN flood protection in other ways.

•The normalizer always sees the SYN packet as the first packet in a flow unless the security appliance is in loose mode due to failover.

Enabling the TCP Normalizer

This feature uses Modular Policy Framework, so that implementing TCP normalization consists of identifying traffic, specifying the TCP normalization actions, and activating TCP normalization on an interface. See Chapter 21, "Using Modular Policy Framework," for more information.

To configure TCP normalization, perform the following steps:

Step 1 To specify the TCP normalization criteria that you want to look for, create a TCP map by entering the following command:

hostname(config)# tcp-map tcp-map-name

For each TCP map, you can customize one or more settings.

Step 2 (Optional) Configure the TCP map criteria by entering one or more of the following commands (see Table 23-1). If you want to use the default settings for all criteria, you do not need to enter any commands for the TCP map. If you want to customize some settings, then the defaults are used for any commands you do not enter. The default configuration includes the following settings:

no check-retransmission 

no checksum-verification 

exceed-mss allow

queue-limit 0 timeout 4

reserved-bits allow

syn-data allow

synack-data drop

invalid-ack drop

seq-past-window drop

tcp-options range 6 7 clear

tcp-options range 9 255 clear

tcp-options selective-ack allow

tcp-options timestamp allow

tcp-options window-scale allow

ttl-evasion-protection 

urgent-flag clear

window-variation allow-connection

Step 3 To identify the traffic, add a class map using the class-map command. See the "Creating a Layer 3/4 Class Map for Through Traffic" section on page 21-5 for more information.

For example, you can match all traffic using the following commands:

hostname(config)# class-map TCPNORM

hostname(config-cmap)# match any

To match specific traffic, you can match an access list:

hostname(config)# access list TCPNORM extended permit ip any 10.1.1.1 255.255.255.255

hostname(config)# class-map TCP_norm_class

hostname(config-cmap)# match access-list TCPNORM

Step 4 To add or edit a policy map that sets the actions to take with the class map traffic, enter the following commands:

hostname(config)# policy-map name

hostname(config-pmap)# class class_map_name

hostname(config-pmap-c)#

where the class_map_name is the class map from Step 1.

For example:

hostname(config)# policy-map TCP_norm_policy

hostname(config-pmap)# class TCP_norm_class

hostname(config-pmap-c)#

Step 5 Apply the TCP map to the class map by entering the following command.

hostname(config-pmap-c)# set connection advanced-options tcp-map-name

Step 6 To activate the policy map on one or more interfaces, enter the following command:

hostname(config)# service-policy policymap_name {global | interface interface_name}

Where global applies the policy map to all interfaces, and interface applies the policy to one interface. Only one global policy is allowed. Interface service policies take precedence over the global service policy for a given feature. For example, if you have a global policy with inspections, and an interface policy with TCP normalization, then both inspections and TCP normalization are applied to the interface. However, if you have a global policy with inspections, and an interface policy with inspections, then only the interface policy inspections are applied to that interface.

For example, to allow urgent flag and urgent offset packets for all traffic sent to the range of TCP ports between the well known FTP data port and the Telnet port, enter the following commands:

hostname(config)# tcp-map tmap

hostname(config-tcp-map)# urgent-flag allow

hostname(config-tcp-map)# class-map urg-class

hostname(config-cmap)# match port tcp range ftp-data telnet

hostname(config-cmap)# policy-map pmap

hostname(config-pmap)# class urg-class

hostname(config-pmap-c)# set connection advanced-options tmap

hostname(config-pmap-c)# service-policy pmap global

Configuring Connection Limits and Timeouts

This section describes how to set maximum TCP and UDP connections, maximum embryonic connections, maximum per-client connections, connection timeouts, dead connection detection, and how to disable TCP sequence randomization. You can set limits for connections that go through the security appliance, or for management connections to the security appliance. This section includes the following topics:

•Connection Limit Overview

•Enabling Connection Limits and Timeouts

Note You can also configure maximum connections, maximum embryonic connections, and TCP sequence randomization in the NAT configuration. If you configure these settings for the same traffic using both methods, then the security appliance uses the lower limit. For TCP sequence randomization, if it is disabled using either method, then the security appliance disables TCP sequence randomization.

Connection Limit Overview

This section describes why you might want to limit connections, and includes the following topics:

•TCP Intercept Overview

•Disabling TCP Intercept for Management Packets for Clientless SSL Compatibility

•Dead Connection Detection (DCD) Overview

•TCP Sequence Randomization Overview

TCP Intercept Overview

Limiting the number of embryonic connections protects you from a DoS attack. The security appliance uses the per-client limits and the embryonic connection limit to trigger TCP Intercept, which protects inside systems from a DoS attack perpetrated by flooding an interface with TCP SYN packets. An embryonic connection is a connection request that has not finished the necessary handshake between source and destination. TCP Intercept uses the SYN cookies algorithm to prevent TCP SYN-flooding attacks. A SYN-flooding attack consists of a series of SYN packets usually originating from spoofed IP addresses. The constant flood of SYN packets keeps the server SYN queue full, which prevents it from servicing connection requests. When the embryonic connection threshold of a connection is crossed, the security appliance acts as a proxy for the server and generates a SYN-ACK response to the client SYN request. When the security appliance receives an ACK back from the client, it can then authenticate the client and allow the connection to the server.

Disabling TCP Intercept for Management Packets for Clientless SSL Compatibility

By default, TCP management connections have TCP Intercept always enabled. When TCP Intercept is enabled, it intercepts the 3-way TCP connection establishment handshake packets and thus deprives the security appliance from processing the packets for clientless SSL. Clientless SSL requires the ability to process the 3-way handshake packets to provide selective ACK and other TCP options for clientless SSL connections. To disable TCP Intercept for management traffic, you can set the embryonic connection limit; only after the embryonic connection limit is reached is TCP Intercept enabled.

Dead Connection Detection (DCD) Overview

DCD detects a dead connection and allows it to expire, without expiring connections that can still handle traffic. You configure DCD when you want idle, but valid connections to persist.

When you enable DCD, idle timeout behavior changes. With idle timeout, DCD probes are sent to each of the two end-hosts to determine the validity of the connection. If an end-host fails to respond after probes are sent at the configured intervals, the connection is freed, and reset values, if configured, are sent to each of the end-hosts. If both end-hosts respond that the connection is valid, the activity timeout is updated to the current time and the idle timeout is rescheduled accordingly.

Enabling DCD changes the behavior of idle-timeout handling in the TCP normalizer. DCD probing resets the idle timeout on the connections seen in the show conn command. To determine when a connection that has exceeded the configured timeout value in the timeout command but is kept alive due to DCD probing, the show service-policy command includes counters to show the amount of activity from DCD.

TCP Sequence Randomization Overview

Each TCP connection has two ISNs: one generated by the client and one generated by the server. The security appliance randomizes the ISN of the TCP SYN passing in both the inbound and outbound directions.

Randomizing the ISN of the protected host prevents an attacker from predicting the next ISN for a new connection and potentially hijacking the new session.

TCP initial sequence number randomization can be disabled if required. For example:

•If another in-line firewall is also randomizing the initial sequence numbers, there is no need for both firewalls to be performing this action, even though this action does not affect the traffic.

•If you use eBGP multi-hop through the security appliance, and the eBGP peers are using MD5. Randomization breaks the MD5 checksum.

•You use a WAAS device that requires the security appliance not to randomize the sequence numbers of connections.

Enabling Connection Limits and Timeouts

To set connection limits and timeouts, perform the following steps:

Step 1 To identify the traffic, add a class map using the class-map command. See the "Creating a Layer 3/4 Class Map for Through Traffic" section on page 21-5 for more information.

For example, you can match all traffic using the following commands:

hostname(config)# class-map CONNS

hostname(config-cmap)# match any

To match specific traffic, you can match an access list:

hostname(config)# access list CONNS extended permit ip any 10.1.1.1 255.255.255.255

hostname(config)# class-map CONNS

hostname(config-cmap)# match access-list CONNS

Step 2 To add or edit a policy map that sets the actions to take with the class map traffic, enter the following commands:

hostname(config)# policy-map name

hostname(config-pmap)# class class_map_name

hostname(config-pmap-c)#

where the class_map_name is the class map from Step 1.

For example:

hostname(config)# policy-map CONNS

hostname(config-pmap)# class CONNS

hostname(config-pmap-c)#

Step 3 To set maximum connection limits or whether TCP sequence randomization is enabled, enter the following command:

hostname(config-pmap-c)# set connection {[conn-max n] [embryonic-conn-max n] 
[per-client-embryonic-max n] [per-client-max n] [random-sequence-number {enable | 
disable}]}

where the conn-max n argument sets the maximum number of simultaneous TCP and/or UDP connections that are allowed, between 0 and 65535. The default is 0, which allows unlimited connections.

If two servers are configured to allow simultaneous TCP and/or UDP connections, the connection limit is applied to each configured server separately.

The embryonic-conn-max n argument sets the maximum number of simultaneous embryonic connections allowed, between 0 and 65535. The default is 0, which allows unlimited connections.

The per-client-embryonic-max n argument sets the maximum number of simultaneous embryonic connections allowed per client, between 0 and 65535. The default is 0, which allows unlimited connections.

The per-client-max n argument sets the maximum number of simultaneous connections allowed per client, between 0 and 65535. The default is 0, which allows unlimited connections.

The random-sequence-number {enable | disable} keyword enables or disables TCP sequence number randomization. See the "TCP Sequence Randomization Overview" section section for more information.

You can enter this command all on one line (in any order), or you can enter each attribute as a separate command. The security appliance combines the command into one line in the running configuration.

Step 4 To set connection timeouts, enter the following command:

hostname(config-pmap-c)# set connection timeout {[embryonic hh:mm:ss] {tcp hh:mm:ss 
[reset]] [half-closed hh:mm:ss] [dcd hh:mm:ss [max_retries]]}

where the embryonic hh:mm:ss keyword sets the timeout period until a TCP embryonic (half-open) connection is closed, between 0:0:5 and 1193:00:00. The default is 0:0:30. You can also set this value to 0, which means the connection never times out.

The tcp hh:mm:ss keyword sets the idle timeout between 0:5:0 and 1193:00:00. The default is 1:0:0. You can also set this value to 0, which means the connection never times out. The reset keyword sends a reset to TCP endpoints when the connection times out.

The half-closed hh:mm:ss keyword sets the idle timeout between 0:5:0 and 1193:00:00. The default is 0:10:0. Half-closed connections are not affected by DCD. Also, the security appliance does not send a reset when taking down half-closed connections.

The dcd keyword enables DCD. DCD detects a dead connection and allows it to expire, without expiring connections that can still handle traffic. You configure DCD when you want idle, but valid connections to persist. After a TCP connection times out, the security appliance sends DCD probes to the end hosts to determine the validity of the connection. If one of the end hosts fails to respond after the maximum retries are exhausted, the security appliance frees the connection. If both end hosts respond that the connection is valid, the security appliance updates the activity timeout to the current time and reschedules the idle timeout accordingly. The retry-interval sets the time duration in hh:mm:ss format to wait after each unresponsive DCD probe before sending another probe, between 0:0:1 and 24:0:0. The default is 0:0:15. The max-retries sets the number of consecutive failed retries for DCD before declaring the connection as dead. The minimum value is 1 and the maximum value is 255. The default is 5.

You can enter this command all on one line (in any order), or you can enter each attribute as a separate command. The command is combined onto one line in the running configuration.

Step 5 To activate the policy map on one or more interfaces, enter the following command:

hostname(config)# service-policy policymap_name {global | interface interface_name}

Where global applies the policy map to all interfaces, and interface applies the policy to one interface. Only one global policy is allowed. Interface service policies take precedence over the global service policy for a given feature. For example, if you have a global policy with inspections, and an interface policy with TCP normalization, then both inspections and TCP normalization are applied to the interface. However, if you have a global policy with inspections, and an interface policy with inspections, then only the interface policy inspections are applied to that interface.

The following example sets the connection limits and timeouts for all traffic:

hostname(config)# class-map CONNS

hostname(config-cmap)# match any

hostname(config-cmap)# policy-map CONNS

hostname(config-pmap)# class CONNS

hostname(config-pmap-c)# set connection conn-max 1000 embryonic-conn-max 3000

hostname(config-pmap-c)# set connection timeout tcp 2:0:0 embryonic 0:40:0 half-closed 
0:20:0 dcd

hostname(config-pmap-c)# service-policy CONNS interface outside

You can enter set connection commands with multiple parameters or you can enter each parameter as a separate command. The security appliance combines the commands into one line in the running configuration. For example, if you entered the following two commands in class configuration mode:

hostname(config-pmap-c)# set connection conn-max 600

hostname(config-pmap-c)# set connection embryonic-conn-max 50

the output of the show running-config policy-map command would display the result of the two commands in a single, combined command:

set connection conn-max 600 embryonic-conn-max 50

Preventing IP Spoofing

This section lets you enable Unicast Reverse Path Forwarding on an interface. Unicast RPF guards against IP spoofing (a packet uses an incorrect source IP address to obscure its true source) by ensuring that all packets have a source IP address that matches the correct source interface according to the routing table.

Normally, the security appliance only looks at the destination address when determining where to forward the packet. Unicast RPF instructs the security appliance to also look at the source address; this is why it is called Reverse Path Forwarding. For any traffic that you want to allow through the security appliance, the security appliance routing table must include a route back to the source address. See RFC 2267 for more information.

For outside traffic, for example, the security appliance can use the default route to satisfy the Unicast RPF protection. If traffic enters from an outside interface, and the source address is not known to the routing table, the security appliance uses the default route to correctly identify the outside interface as the source interface.

If traffic enters the outside interface from an address that is known to the routing table, but is associated with the inside interface, then the security appliance drops the packet. Similarly, if traffic enters the inside interface from an unknown source address, the security appliance drops the packet because the matching route (the default route) indicates the outside interface.

Unicast RPF is implemented as follows:

•ICMP packets have no session, so each packet is checked.

•UDP and TCP have sessions, so the initial packet requires a reverse route lookup. Subsequent packets arriving during the session are checked using an existing state maintained as part of the session. Non-initial packets are checked to ensure they arrived on the same interface used by the initial packet.

To enable Unicast RPF, enter the following command:

hostname(config)# ip verify reverse-path interface interface_name

Configuring the Fragment Size

By default, the security appliance allows up to 24 fragments per IP packet, and up to 200 fragments awaiting reassembly. You might need to let fragments on your network if you have an application that routinely fragments packets, such as NFS over UDP. However, if you do not have an application that fragments traffic, we recommend that you do not allow fragments through the security appliance. Fragmented packets are often used as DoS attacks. To set disallow fragments, enter the following command:

hostname(config)# fragment chain 1 [interface_name]

Enter an interface name if you want to prevent fragmentation on a specific interface. By default, this command applies to all interfaces.

Blocking Unwanted Connections

If you know that a host is attempting to attack your network (for example, system log messages show an attack), then you can block (or shun) connections based on the source IP address and other identifying parameters. No new connections can be made until you remove the shun.

Note If you have an IPS that monitors traffic, such as an AIP SSM, then the IPS can shun connections automatically.

To shun a connection manually, perform the following steps:

Step 1 If necessary, view information about the connection by entering the following command:

hostname# show conn

The security appliance shows information about each connection, such as the following:

TCP out 64.101.68.161:4300 in 10.86.194.60:23 idle 0:00:00 bytes 1297 flags UIO

Step 2 To shun connections from the source IP address, enter the following command:

hostname(config)# shun src_ip [dst_ip src_port dest_port [protocol]] [vlan vlan_id]

If you enter only the source IP address, then all future connections are shunned; existing connections remain active.

To drop an existing connection, as well as blocking future connections from the source IP address, enter the destination IP address, source and destination ports, and the protocol. By default, the protocol is 0 for IP.

For multiple context mode, you can enter this command in the admin context, and by specifying a VLAN ID that is assigned to an interface in other contexts, you can shun the connection in other contexts.

Step 3 To remove the shun, enter the following command:

hostname(config)# no shun src_ip [vlan vlan_id]

Configuring IP Audit for Basic IPS Support

The IP audit feature provides basic IPS support for a security appliance that does not have an AIP SSM. It supports a basic list of signatures, and you can configure the security appliance to perform one or more actions on traffic that matches a signature.

To enable IP audit, perform the following steps:

Step 1 To define an IP audit policy for informational signatures, enter the following command:

hostname(config)# ip audit name name info [action [alarm] [drop] [reset]]

Where alarm generates a system message showing that a packet matched a signature, drop drops the packet, and reset drops the packet and closes the connection. If you do not define an action, then the default action is to generate an alarm.

Step 2 To define an IP audit policy for attack signatures, enter the following command:

hostname(config)# ip audit name name attack [action [alarm] [drop] [reset]]

Where alarm generates a system message showing that a packet matched a signature, drop drops the packet, and reset drops the packet and closes the connection. If you do not define an action, then the default action is to generate an alarm.

Step 3 To assign the policy to an interface, enter the following command:

ip audit interface interface_name policy_name

Step 4 To disable signatures, or for more information about signatures, see the ip audit signature command in the Cisco Security Appliance Command Reference.