PDA Logo.gif (6595 bytes)

Configuring Cisco Denial of Service Security Features - Part 1


our services

about Peter Davis+Assoc.


security/audit info

Privacy Test

Security & Audit Tools


Windows NT Server IIS

Windows 95


Java, JavaScript and ActiveX

Intrusion Detection Systems

Security Industry Shakeout

Securing Groupware

Client/Server Audit: One Bite At A Time

Configuring Cisco Denial of Service Security Features - Part 1

Configuring Cisco Denial of Service Security Features - Part 2

Configuring Cisco Lock-and-Key

Configuring Cisco Reflexive Access Lists

Dysfunctional Controls: Useless, Impractical, Inefficient and Poorly-Designed

TCPA: Who Can You Trust?

When Getting the Audit Done Is the Only Thing

Palladium: Friend or Foe?

Commentary: Quis Custodiet Ipsos Custodes?

Data Management: Data Destruction and Preservation

Security & Audit Products
Top Ten Security Links 
Security & Audit Checklists
Computer & Security
Security & Audit Bibliography
Search Page

legal info

privacy info


You're watching the World Series and Matt Williams of the Diamondbacks is at bat. The count is 3-2, 2 out and the sacks are full. The phone rings and the ring indicates a long distance call. Obviously, the caller isn't watching the game. You answer the phone, only to find no one there. You curse and slam the phone down. Several seconds later, it happens again. You repeat the process. This series of events occurs several more times until out of frustration you turn off the ringer and let all the calls go to voicemail. At work the next morning, your buddy says, "Where were you I tried to call last night to make sure you were watching the game." (If you are a Canadian, substitute Stanley Cup finals for World Series, Mats Sundin for Matt and Leafs for Diamondbacks, and so on. If you live anywhere else, substitute World Cup, Reynaldo, et cetera.) The point is that the unknown caller was tying up your phone line and denying your buddy access to you. It got so bad you had to take your phone off-line. You can see that it is very hard to protect against this type of attack, save going off-line. Well, you could take this story and create a simple analogy using your router. Someone starts flooding your router or network with dubious packets. The packets cause the system to crash or consume all available resources. Your legitimate clients can't get through nor do anything. When someone hits your router with a denial of service attack, they hold up critical resources by blocking the door to lawful business activity. A denial of service attack is an attack against your network availability.

This article and the companion article describe how to protect your network against some of the well-known denial of service attacks. You will learn how to configure your router to protect TCP servers from directed broadcasts; IP source routing; ICMP redirects; and TCP SYN-flooding attacks, a type of denial of service attack.

Controlling the Hostile Environment

The attacks discussed in this article and the companion article are relatively sophisticated ones, but they are by no means out of the reach of today’s crackers. In fact, they can readily get scripts, programs or code to launch attacks against you. You often can thwart these attacks when the public network providers involved have taken proper security measures. So, you should evaluate your level of trust in the security measures used by all the providers carrying your traffic. Ultimately, you cannot avoid some denial of service attacks, no matter your diligence. In this case, you need to add vigilance to your arsenal. You must notice the attack, and begin the process of tracking it back to its source, or find a way to stop it. Being aware is a good start, so let's look at some advice on protecting your organization against known denial of service attacks.

Controlling Directed Broadcasts

Smurf, the extremely common and popular denial of service attack, uses IP directed broadcasts as do related attacks. An IP directed broadcast is where a machine sends a datagram to the broadcast address of a subnetwork where it is not directly attached. In a Smurf attack, the attacker sends ICMP echo requests from a falsified source address to a directed broadcast address, causing all the hosts on the target subnet to send replies to the spoofed source. In other words, instead of directing a PING request to a single host as is normally done, the attacker sends the PING to an address ending in either 0 or 255 (for example, or, which causes the PING to go to all hosts in the network. So, when all the machines respond to the PING, they send the response back to the falsified address, that is, the intended victim. By sending a continuous stream of such requests, the attacker can create a much larger stream of replies, which can completely inundate the host, whose address the attacker is spoofing.

If you configure your router's interface with the no ip directed-broadcast command, the router will drop directed broadcasts that would otherwise have exploded into link-layer broadcasts at that interface.

alpha(config-if)#no ip directed-broadcast

Do networks out there act in this manner? You bet. Visit http://www.netscan.org to view a list of what that site calls the "most egregious offenders", those sites that have failed to configure their routers and firewalls to disable IP directed broadcasts. This organization performs network scans to find those sites that could unintentionally act as a Smurf amplifier. You can find a similar list at http//www.pulltheplug.com/broadcasts.html. Make sure you configure your router so you don't end up on their lists!

Cisco also recommends that you use the ip verify unicast reverse-path global configuration command to prevent denial of service attacks such as Smurf. This forces a match of the routing entries in the Cisco Express Forwarding (CEF) table against the source IP address of the incoming packets. When there is no return route out of the interface, the router will drop the packet. You must enable CEF on your router as well.

To find out whether you are a potential Smurf amplifier, get yourself Fyodor's nmap program and run the following command:

nmap -n -sP -PI -o smurf.log '209.12.*.0,63,64,127,128,191,192,255'

Controlling TCP and UDP Small Services

By default, Cisco devices up through IOS version 11.3 offer the small TCP and UDP services: echo, chargen, and discard. You rarely will use these services, especially the UDP versions, for legitimate purposes, but attackers will use them to launch denial of service and other attacks that you could otherwise prevent by packet filtering. In fact, the notorious Fraggle denial of service attack exploits echo (port 7) over UDP.


Note. Perhaps you have not heard of Fraggle, Bonk, Boink, Land, Teardrop, Teardrop 2, New Teardrop, Bubonic, Smurf, Papa Smurf, Ping of Death, and the rest of the gang. Well, mosey on over to http://www.rootshell.com. This web site offers thousands of exploit scripts, code and programs for your downloading pleasure. Makes gift giving a lot easier this year!


For example, an attacker might send a DNS packet, falsifying the source address to a DNS server, which is otherwise unreachable, and falsifying the source port as the DNS service port (port 53). Should the attacker send such a packet to the Cisco’s UDP echo port, this is equivalent to the router sending a DNS packet to the server in question. So, the router would not apply any outgoing access list checks to this packet, since the router would consider it locally generated by the router itself.

Although you can avoid most abuses of the small services or make them less dangerous by anti-spoofing access lists; you should disable the services in any router that is part of your firewall system or lies in a high security portion of your organization. Since you rarely use the services, adopt the policy of disabling the services on all routers of any description.

Cisco disabled the small services by default in IOS 12.0 and later software. In earlier software, you may disable them using the following commands.

alpha(config)#no service tcp-small-servers

alpha(config)#no service udp-small-servers

Controlling IP Source Routing

The IP protocol supports source routing options that allow the sender of an IP datagram to control the route that datagram will take toward its ultimate destination, and generally the route that any reply will take. Network professionals rarely use these options for legitimate purposes in real networks. When an address uses source routing, it can send and receive traffic through the firewall router. You should use the following command unless you know that your network absolutely needs source routing.

alpha(config)#no ip source-route

Controlling ICMP Redirects

Your anti-spoofing access list should filter out all ICMP redirects, regardless of source or destination address. An ICMP redirect message instructs an end node to use a specific router as its path to a particular destination. In a properly functioning IP network, a router will send redirects only to hosts on its own local subnets, no end node will ever send a redirect, and no redirect will ever traverse more than one network hop. However, an attacker may violate these rules; some attacks are based on this. So write the following rule to block redirects.

alpha(config)#ip access-list access-list-number deny icmp any any redirect

Controlling Unreachable Messages

By default when a router receives a non-broadcast packet with an unrecognized protocol whose destination address belongs to that router, it will send an ICMP Protocol Unreachable message back to the source. A router also will send back an ICMP Host Unreachable message should it receive a packet whose destination address is unknown. While seemingly reasonable, this opens the router up to DoS attacks using ICMP. When a router spends all its time responding with ICMP messages, it cannot do much real processing.

You should prevent your router from sending out ICMP Host and Protocol Unreachable messages with the following interface command:

alpha(config-if)#no ip unreachable

Controlling Proxy ARP

A Proxy ARP is where a device answers an ARP request destined for another device when it knows that MAC address. When a proxy ARP device, say a router, sees an ARP request for a host on a different network, the router responds to the ARP and then forwards the request to the remote network. Attackers have used proxy ARP to launch a DoS attack that uses available bandwidth and router resources responding to repeated ARP requests. You can disable Proxy ARP with the following interface configuration command.

alpha(config-if)#no ip proxy-arp

Managing the Floods

Locating your router in the fluvial flood plain of the Mississippi River is probably not a good idea. But a deluge of water is not the flood referenced here. Many denials of service rely on floods of useless packets. Refer to Figure 1 that shows the three-way handshake. The three-way handshake concludes to a natural conclusion with each node setting the right acknowledgement numbers and code bits. But look at the picture again. What do you suppose happens when the receiving host B cannot send the acknowledgement packet back because the source address is unresolveable? Host B will start a process and eventually time it out. But if Host A is dastardly, it could send so many packets that the receiving system consumes all its resources. This may cause the system to crash or it may just consume all the resources on the system so legitimate clients cannot get in.

Figure 1.


These floods congest network links, slow down hosts, and can overload routers as well. Cisco provides the TCP Intercept feature specifically to reduce the impact of SYN flooding attacks on hosts. The feature is available in certain software versions for many routers with model numbers of 4000 or greater. SYN flood protection can be complex, and results may vary depending on flood rate, router speed and memory size, and the hosts you use.

About TCP Intercept

TCP Intercept tracks, intercepts and validates TCP connection requests. This shields your host from direct contact by a nontrusted network or host. The TCP intercept feature implements software to protect TCP servers from TCP SYN-flooding attacks, which are a type of denial of service attack. SYN-flooding occurs when a hacker floods a server with a barrage of requests for connection. Since these messages have unreachable return addresses, the server cannot establish the connections. The resulting volume of unresolved open connections eventually overwhelms the server and can cause it to deny service to valid requests, thereby preventing legitimate users from connecting to your Web site, accessing e-mail, using FTP service, and so on.

The TCP intercept feature helps prevent SYN-flooding attacks by intercepting and validating TCP connection requests. TCP Intercept operates in one of two modes: intercept or watch mode, but the default is Intercept. In Intercept mode, the TCP intercept software intercepts TCP synchronization (SYN) packets from clients to servers that match an extended access list. The software establishes a connection with the client on behalf of the destination server, and when successful, establishes the connection with the server on behalf of the client and knits the two half-connections together transparently. Thus, connection attempts from unreachable hosts will never reach the server. The software continues to intercept and forward packets throughout the duration of the connection.

In the case of illegitimate requests, the software's aggressive timeouts on half-open connections and its thresholds on TCP connection requests protect destination servers while still allowing valid requests.

When establishing your security policy using TCP intercept, you can choose to intercept all requests or only those coming from specific networks or destined for specific servers. You can also configure the connection rate and threshold of outstanding connections.

You can choose to operate TCP intercept in Watch mode, as opposed to intercept mode. In Watch mode, the software passively watches the connection requests flowing through the router. If a connection fails to get established in a configurable interval, the software intervenes and terminates the connection attempt.

The router cannot handle TCP options negotiated on handshake (such as RFC 1323 on window scaling) since the TCP intercept software does not know what the server can do or will negotiate.

Exceeding preset thresholds in either mode causes aggressive behavior mode to start. During aggressive behavior mode, new connection attempts force a drop of an existing partial connection. Additionally, the retransmission and watch timeouts are cut in half. When the number of incomplete connections surpasses 1,100 or it gets a surge of over 1,100 connections in 60 seconds (by default), the router will delete the oldest connection request and then reduce retransmission time by 50 percent. Dropping back below another set of thresholds causes the router to revert back to normal.

Configuring TCP Intercept

Now that you know TCP Intercepts concepts, it is time to configure the router. You perform the following tasks to configure TCP intercept. You must perform the first task, while the rest are optional.

  • Enable TCP Intercept
  • Set the TCP Intercept Mode
  • Set the TCP Intercept Drop Mode
  • Change the TCP Intercept Timers
  • Change the TCP Intercept Aggressive Thresholds
  • Monitor and Maintain TCP Intercept

Enabling TCP Intercept

To enable TCP intercept, you must do these two steps:

  1. Define an IP extended access list.
  2. Enable the TCP intercept.

This means you perform the following tasks in global configuration mode:

alpha(config)#access-list access-list-number {deny | permit} tcp any destination destination-wildcard

alpha(config)#ip tcp intercept list {access-list-number | name}

You can define an access list to intercept all requests or only those coming from specific networks or destined for specific servers. The access-list-number is a value from 100 to 199. Typically the access list will define the source as any and define specific destination networks or servers. That is, you do not attempt to filter on the source addresses because you don't necessarily know from where to intercept packets. You identify the destination in order to protect destination servers.

If the IOS finds no access list match, the router allows the request to pass with no further action.

Setting the TCP Intercept Mode

As mentioned, TCP Intercept can operate in either active Intercept mode or passive Watch mode. The default is Intercept mode.

In Intercept mode, the software actively intercepts each incoming connection request (SYN) and responds on behalf of the server with an ACK and SYN, then waits for an ACK of the SYN from the client. When the router receives that ACK, the original SYN is set to the server and the software performs a three-way handshake with the server. When this is complete, the router joins the two half-connections.

In Watch mode, the router allows connection requests to pass through the router to the server but watches until they become established. If they fail to become established within 30 seconds (configurable with the ip tcp intercept watch-timeout command), the software sends a Reset to the server to clear up its state.

To set the TCP intercept mode, perform the following task in global configuration mode:

alpha(config)#ip tcp intercept mode {intercept | watch}

Setting the TCP Intercept Drop Mode

When under attack, the TCP intercept feature becomes more aggressive in its protective behavior. Should the number of incomplete connections exceed 1,100 or the number of connections arriving in the last one minute exceeds 1,100, each new arriving connection causes the router to delete the oldest partial connection. Also, the software reduces the initial retransmission timeout by half to 0.5 seconds (so the total time trying to establish a connection is cut in half).

By default, the software drops the oldest partial connection. Alternatively, you can configure the software to drop a random connection. To set the drop mode, perform the following task in global configuration mode:

alpha(config)#ip tcp intercept drop-mode {oldest | random}

Changing the TCP Intercept Timers

By default, the software waits for 30 seconds for a watched connection to reach established state before sending a Reset to the server. To change this value, perform the following task in global configuration mode:

alpha(config)#ip tcp intercept watch-timeout seconds

By default, the software waits for 5 seconds from receipt of a reset or FIN-exchange before it ceases to manage the connection. To change this value, perform the following task in global configuration mode:

alpha(config)#ip tcp intercept finrst-timeout seconds

By default, the software still manages a connection for 24 hours after no activity. To change this value, perform the following task in global configuration mode:

alpha(config)#ip tcp intercept connection-timeout seconds

The value for the seconds keyword in all the commands above is a number from 1 to 2,147,483.

Changing the TCP Intercept Aggressive Thresholds

Two factors determine when aggressive behavior begins and ends: total incomplete connections and connection requests during the last one-minute sample period. Both thresholds have default values that you can reconfigure.

When activity exceeds a threshold, the TCP intercept assumes the server is under attack and goes into aggressive mode. When in aggressive mode, the following occurs:

  • Each new arriving connection causes the oldest partial connection to be deleted. (You can change to a random drop mode.)

  • The router reduces the initial retransmission timeout by half to 0.5 seconds, and so the total time trying to establish the connection is cut in half. When not in aggressive mode, the code does an exponential back off on its retransmissions of SYN segments. The initial retransmission timeout is 1 second. The subsequent timeouts are 2 seconds, 4 seconds, 8 seconds, and 16 seconds. The code retransmits 4 times before giving up, so it gives up after 31 seconds without an acknowledgment.

  • When in watch mode, the router reduces the watch timeout by half. If the default is in place, the watch timeout becomes 15 seconds.

You can change the drop strategy from the oldest connection to a random connection with the ip tcp intercept drop-mode command.


Note. The two factors determining aggressive behavior are related and work together. When either of the high values is exceeded, aggressive behavior begins. When both quantities fall below the low value, aggressive behavior ends.


You can change the threshold for triggering aggressive mode based on the total number of incomplete connections. The default values for low and high are 900 and 1100 incomplete connections, respectively. To change these values, perform the following tasks in global configuration mode:

alpha(config)#ip tcp intercept max-incomplete low number

alpha(config)#ip tcp intercept max-incomplete high number

You can also change the threshold for triggering aggressive mode based on the number of connection requests received in the last 1-minute sample period. The default values for low and high are 900 and 1100 connection requests, respectively. To change these values, perform the following tasks in global configuration mode:

alpha(config)#ip tcp intercept one-minute low number

alpha(config)#ip tcp intercept one-minute high number

The value for the number keyword in all the commands above is a number from 1 to 2,147,483,647.

Now that you know all the commands, let's look at some simple examples. The following applies the TCP Intercept feature to access list 1 with the following features:

  • Waits 30 seconds for connection to reach established state before sending a Reset.
  • Waits 5 seconds from FIN or RST before ending connection management.
  • Manages connection for 24 hours after inactivity.

alpha(config)#ip tcp intercept list 1

alpha(config)#ip tcp intercept watch-timeout 30

alpha(config)#ip tcp intercept finrst-timeout 5

alpha(config)#ip tcp intercept connection-timeout 86400

The following configuration defines extended IP access list 100, causing the software to intercept packets for all TCP servers on the subnet:

alpha(config)#ip tcp intercept list 100

alpha(config)#access-list 100 permit tcp any

Monitoring and Maintaining TCP Intercept

To display TCP intercept information, perform either of the following tasks in EXEC mode:

alpha#show tcp intercept connections

This command displays incomplete connections and established connections.

alpha#show tcp intercept statistics

This command displays TCP intercept statistics.


In this article, you learnt how to protect your organization against directed broadcasts; echo-, chargen-, and discard-based attacks, attacks needing source routing, ICMP redirect and unreachable, proxy ARP and SYN flooding. In the follow-on article, you will learn about network address translation and queuing and policing.

One final thought on denial of service attacks. There are things you can do to ensure your organization doesn't become an unwitting accomplice to attacks on other networks. For example, set up egress filtering on your border or firewall routers to prevent suspicious traffic from leaving your network. A few simple commands to ensure that traffic leaving your network did truly originate in your network will severely hamper attackers abusing networks using your network without your knowledge. Be a considerate netizen.

Abridged version of a document originally published by Auerbach Publications 2002. This subject also is covered in Securing and Controlling Cisco Routers from Auerbach Publications/CRC Press.

Tell a friend about this page!
Their Name:
Their Email:
Your Name:
Your Email: