Cisco Security Appliance Command Line Configuration Guide, Version 7.2
Preventing Network Attacks
Downloads: This chapterpdf (PDF - 440.0KB) The complete bookPDF (PDF - 13.04MB) | Feedback

Preventing Network Attacks

Table Of Contents

Preventing Network Attacks

Configuring TCP Normalization

TCP Normalization Overview

Enabling the TCP Normalizer

Configuring Connection Limits and Timeouts

Connection Limit Overview

TCP Intercept Overview

Disabling TCP Intercept for Management Packets for Clientless SSL Compatibility

Dead Connection Detection (DCD) Overview

TCP Sequence Randomization Overview

Enabling Connection Limits and Timeouts

Preventing IP Spoofing

Configuring the Fragment Size

Blocking Unwanted Connections

Configuring IP Audit for Basic IPS Support


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

Table 23-1 tcp-map Commands 

Command
Notes

check-retransmission

Prevents inconsistent TCP retransmissions.

checksum-verification

Verifies the checksum.

exceed-mss {allow | drop}

Sets the action for packets whose data length exceeds the TCP maximum segment size.

(Default) The allow keyword allows packets whose data length exceeds the TCP maximum segment size.

The drop keyword drops packets whose data length exceeds the TCP maximum segment size.

invalid-ack {allow | drop}

Sets the action for packets with an invalid ACK. You might see invalid ACKs in the following instances:

In the TCP connection SYN-ACK-received status, if the ACK number of a received TCP packet is not exactly same as the sequence number of the next TCP packet sending out, it is an invalid ACK.

Whenever the ACK number of a received TCP packet is greater than the sequence number of the next TCP packet sending out, it is an invalid ACK.

The allow keyword allows packets with an invalid ACK.

(Default) The drop keyword drops packets with an invalid ACK.

Note TCP packets with an invalid ACK are automatically allowed for WAAS connections.

queue-limit pkt_num [timeout seconds]

Sets the maximum number of out-of-order packets that can be buffered and put in order for a TCP connection, between 1 and 250 packets. The default is 0, which means this setting is disabled and the default system queue limit is used depending on the type of traffic:

Connections for application inspection (the inspect command), IPS (the ips command), and TCP check-retransmission (the TCP map check-retransmission command) have a queue limit of 3 packets. If the security appliance receives a TCP packet with a different window size, then the queue limit is dynamically changed to match the advertised setting.

For other TCP connections, out-of-order packets are passed through untouched.

If you set the queue-limit command to be 1 or above, then the number of out-of-order packets allowed for all TCP traffic matches this setting. For example, for application inspection, IPS, and TCP check-retransmission traffic, any advertised settings from TCP packets are ignored in favor of the queue-limit setting. For other TCP traffic, out-of-order packets are now buffered and put in order instead of passed through untouched.

The timeout seconds argument sets the maximum amount of time that out-of-order packets can remain in the buffer, between 1 and 20 seconds; if they are not put in order and passed on within the timeout period, then they are dropped. The default is 4 seconds. You cannot change the timeout for any traffic if the pkt_num argument is set to 0; you need to set the limit to be 1 or above for the timeout keyword to take effect.

reserved-bits {allow | clear | drop}

Sets the action for reserved bits in the TCP header.

(Default) The allow keyword allows packets with the reserved bits in the TCP header.

The clear keyword clears the reserved bits in the TCP header and allows the packet.

The drop keyword drops the packet with the reserved bits in the TCP header.

seq-past-window {allow | drop}

Sets the action for packets that have past-window sequence numbers, namely the sequence number of a received TCP packet is greater than the right edge of the TCP receiving window.

The allow keyword allows packets that have past-window sequence numbers. This action is only allowed if the queue-limit command is set to 0 (disabled).

(Default) The drop keyword drops packets that have past-window sequence numbers.

synack-data {allow | drop}

Sets the action for TCP SYNACK packets that contain data.

The allow keyword allows TCP SYNACK packets that contain data.

(Default) The drop keyword drops TCP SYNACK packets that contain data.

syn-data {allow | drop}

Sets the action for SYN packets with data.

(Default) The allow keyword allows SYN packets with data.

The drop keyword drops SYN packets with data.

tcp-options {selective-ack | timestamp | window-scale} {allow | clear}

Or

tcp-options range lower upper {allow | clear | drop}

Sets the action for packets with TCP options, including the selective-ack, timestamp, or window-scale TCP options.

(Default) The allow keyword allows packets with the specified option.

(Default for range) The clear keyword clears the option and allows the packet.

The drop keyword drops the packet with the specified option.

The selective-ack keyword sets the action for the SACK option.

The timestamp keyword sets the action for the timestamp option. Clearing the timestamp option disables PAWS and RTT.

The widow-scale keyword sets the action for the window scale mechanism option.

The range keyword specifies a range of options. The lower argument sets the lower end of the range as 6, 7, or 9 through 255.

The upper argument sets the upper end of the range as 6, 7, or 9 through 255.

ttl-evasion-protection

Disables the TTL evasion protection. Do not enter this command it you want to prevent attacks that attempt to evade security policy.

For example, an attacker can send a packet that passes policy with a very short TTL. When the TTL goes to zero, a router between the security appliance and the endpoint drops the packet. It is at this point that the attacker can send a malicious packet with a long TTL that appears to the security appliance to be a retransmission and is passed. To the endpoint host, however, it is the first packet that has been received by the attacker. In this case, an attacker is able to succeed without security preventing the attack.

urgent-flag {allow | clear}

Sets the action for packets with the URG flag. The URG flag is used to indicate that the packet contains information that is of higher priority than other data within the stream. The TCP RFC is vague about the exact interpretation of the URG flag, therefore end systems handle urgent offsets in different ways, which may make the end system vulnerable to attacks.

The allow keyword allows packets with the URG flag.

(Default) The clear keyword clears the URG flag and allows the packet.

window-variation {allow | drop}

Sets the action for a connection that has changed its window size unexpectedly. The window size mechanism allows TCP to advertise a large window and to subsequently advertise a much smaller window without having accepted too much data. From the TCP specification, "shrinking the window" is strongly discouraged. When this condition is detected, the connection can be dropped.

(Default) The allow keyword allows connections with a window variation.

The drop keyword drops connections with a window variation.


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.