PDA Logo.gif (6595 bytes)

Configuring Cisco Denial of Service Security Features - Part 2


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


This article is the second of two that describes how to protect your network against some of well-known denial of service attacks. You will learn how to configure network address translation. Also, you will how to prevent packet flooding through queuing and traffic policing.

About Network Address Translation

When you isolate your network from the outside world; you can use any address you choose. While it is prudent to use the private addresses specified in RFC 1918 (refer to http://www.normos.org/ietf/rfc/rfc1918.txt), nothing will happen when you do not. The problems occur when you connect your network to the outside world. Then, you must use unique IP addresses. Should you decide not to change your non-unique addresses or to use the private addresses specified in the RFC, you will need to do network address translation (NAT).

You can use network address translation to translate the private address ranges dynamically to globally unique addresses. NAT allows you to translate these non-routable addresses statically or dynamically to Internet-routable addresses. A NAT sits between your network and the Internet, or between two organization's networks, and translates IP addresses from private or illegal addressees to globally unique external addresses. The benefit of NAT for your organization is that you do not need to have a one-to-one relationship for your addresses. You can translate a large number of illegal addresses into a small number of legal ones.

You also can benefit from NAT by hiding your internal network. The attackers cannot see your internal network behind the router. Should you use private addresses, the attackers could not send packets to those addresses anyhow.

To facilitate simple Internet access, your organization need only translate Inside Local addresses to Inside Global addresses. Your router running the NAT service will change any source address in packets going out of your organization from an Inside Local to an Inside Global address. The router will maintain a dynamic table that associates these addresses to each other.

Configuring and Deploying NAT

The following steps guide you through defining what you want NAT to do and how to configure it.

  1. Define NAT inside and outside interfaces. You need to establish which interfaces are inside and which are outside. Think of inside as referring to your internal network and outside as referring to the Internet side of the router. Try answering these questions about your interfaces:

  • Do users exist off multiple interfaces?

  • Are there multiple interfaces going to the Internet?

  1. Define what you're trying to accomplish with NAT.

  • Are you trying to allow internal users to access the Internet?

  • Are you trying to allow the Internet to access internal devices (such as a mail server or web server)?

  • Are you trying to redirect TCP traffic to another TCP port or address?

  • Are you using NAT during a network transition? For example, you changed a server's IP address and until you can update all the clients, you want the non-updated clients to access the server using the original IP address and you want the updated clients to access the same server using the new address.

  • Are you using NAT to allow overlapping networks to communicate?

  1. Configure NAT in order to accomplish what you defined above. Based on what you defined in Step 2, you need determine what features to use. Table 1 summarizes the following NAT features.

  • Static address translation: A one-to-one mapping of an internal address to an external legal address. Use this in the case where you have systems, such as a web server, accessible from the outside world. So, you could assign a private IP address to your web server, but you would need to translate the address to make it accessible to your clients.

  • Dynamic address translation: Translates local address to external address from a pool. You need to set up the pool of outside addresses for allocation equal to the number of addresses you need to translate. The router will create the translations a required.

  • Address overloading: Allows you to conserve IP addresses by allowing multiple addresses to translate to the same address. With overloading, you could make it look like all Internet traffic has the same source address. Address overloading uses TCP and UDP port numbers to track what traffic belongs to which internal host.

  • Any combination of the above.

Table 1: NAT Types and Features

NAT Types Address Mapping Public-to-Private Address Mapping Required Public Addresses
Static NAT Static One-to-one One public IP address per host.
Traditional or dynamic NAT Dynamic One-to-one One public IP address per host simultaneously accessing the external network.
NAPT or overloading Dynamic One-to-many One public IP address per 64,000 simultaneous session.

Cisco IOS 11.2 and above support these features. Some questions to reflect upon:

  • What type of addressing scheme are you using on the inside network?

  • How many inside devices do you need to statically translate?

  • Should you use overloading only or use it once the router exhausts all the addresses in the NAT pool?

  1. Verify NAT operation.

Defining NAT Inside and Outside Interfaces

The first step in deploying NAT is to define NAT inside and outside interfaces. You may find it easy to define your internal network as inside and the external network as outside. However, the terms internal and external are subject to debate as well.

For instance, you may want to allow internal users to access the Internet, but you may not have enough valid addresses to accommodate everyone. If all communication with devices in the Internet will originate from the internal devices, then you need a single valid address or a pool of valid addresses.

To configure network address translation, you use the ip nat {inside | outside} command as follows.

alpha(config)#ip nat inside

alpha(config)#ip nat outside

The first command translates:

  • the source of IP packets traveling inside to outside
  • the destination of the IP packets traveling outside to inside

The second command translates:

  • the source of the IP packets traveling outside to inside
  • the destination of the IP packets traveling inside to outside

Say you want NAT to allow certain devices (the first 31 from each subnet) on the inside to originate communication with devices on the outside by translating their invalid address to a valid address or pool of addresses. You have defined the pool as the range of addresses through

Now you're ready to configure NAT. To accomplish what's defined above, you need to use dynamic NAT. With dynamic NAT, the translation table in the router is initially empty and gets populated once traffic that needs translation passes through the router. This is different to static NAT, where you statically configure a translation and place it in the translation table without the need for any traffic. The first thing you need to do is define the Ethernet segments 0 and 1 with an IP address and as a NAT inside interface.

alpha(config)#interface ethernet 0

alpha(config-if)#ip address

alpha(config-if)#ip nat inside


alpha(config)#interface ethernet 1

alpha(config-if)#ip address

alpha(config-if)#ip nat inside

The next commands define serial 0 with an IP address and as a NAT outside interface.

alpha(config-if)#interface serial 0

alpha(config-if)#ip address

alpha(config-if)#ip nat outside


Next, you define a NAT pool named no-overload with a range of addresses from to This sets up the pool of addresses for dynamic address translation.

alpha(config)#ip nat pool no-overload prefix 24

The format of this command is ip nat pool name start-ip-address end-ip-address {netmask netmask | prefix-length prefix-length} {type rotary}. Keywords type rotary specify that the range of addresses in the address pool identify real inside hosts amongst which TCP load distribution will occur.

Use the next command to indicate that the IOS will translate the source address for any packets it receives on the inside interface permitted by access-list 1 to an address out of the NAT pool "no-overload."

alpha(config)#ip nat inside source list 1 pool no-overload

The format of this command is ip nat source {list {access-list-number | name} pool name [overload] | static local-ip-address global-ip-address].

You must now create access-list 1 and permit packets with source addresses ranging from through and through

alpha(config)#access-list 1 permit

alpha(config)#access-list 1 permit


Caution. Do not configure access lists referenced by NAT commands with permit any. Using permit any can result in NAT consuming too many router resources, which can cause network problems.


Notice in the above configuration that only the first 32 addresses from subnet and the first 32 addresses from subnet are permitted by access-list 1. Therefore, the IOS will translate only these source addresses. There may be other devices with other addresses on the inside network, but the IOS won't translate them.

Once you have set up the access list to define those addresses needing translation, you should set up the translation parameters in global configuration mode:

alpha(config)#ip nat translation timeout 3600

alpha(config)#ip nat translation tcp-timeout 3600

alpha(config)#ip nat translation udp-timeout 240

alpha(config)#ip nat translation finrst-timeout 30

alpha(config)#ip nat translation dns-timeout 45

The above commands solve one of the problems in using NAT. NAT has trouble determining when a connection ends, so that the IOS can free the allocated IP addresses. For TCP, this is relatively simple, but UDP is a little more difficult. The first command sets the translation timeout to one hour; the default is 24 hours. The second line sets the TCP timeout to one hour as well; the default is 24 hours. This keyword specifies when TCP port translations will time out. The udp-timeout keyword works the same as the tcp-timeout keyword, however, the default timeout for UDP is 5 minutes. You set it to four minutes with the command above. The finrst-timeout keyword specifies the timeout value that applies to the FIN and RST TCP packets used to terminate a connection. The default is 60 seconds and you have set it to 30 seconds. Finally, the dns-timeout keyword specifies how long it will take for connections to a DNS server to time out. The default value is 60 seconds but you lowered it to 45 seconds. Should you want to use the defaults you need do nothing. But you might want to change them, as the defaults are very conservative. You should realize that the timeouts don't work with static or overload translation. More often than not, you will use overloading or static translations, so you usually don't need to worry about timeout values. But they exist, and they are helpful for dynamic translations.

In this next example, you can configure NAT to translate each of the inside devices to the same valid address. This method is known as overloading. Again, you define Ethernet 0 and Ethernet 1 with an IP address and as a NAT inside interface.

alpha(config)#interface ethernet 0

alpha(config-if)#ip address

alpha(config-if)#ip nat inside

alpha(config-if)#interface ethernet 1

alpha(config-if)#ip address

alpha(config-if)#ip nat inside

Next, you define serial 0 with an IP address and as a NAT outside interface.

alpha(config-if)#interface serial 0

alpha(config-if)#ip address

alpha(config-if)#ip nat outside

You must define a NAT pool with a range of a single IP address, You must name the pool; here it is ovrld.

alpha(config-if)#ip nat pool ovrld prefix 24

Next, indicate that any packets received on the inside interface permitted by access-list 1 will have the source address translated to an address out of the NAT pool named ovrld. The IOS will overload translations allowing multiple inside hosts to share the same valid IP address.

alpha(config-if)#ip nat inside source list 1 pool ovrld overload

Next write the access lists to permits packets with source addresses ranging from through and through

alpha(config-if)#access-list 1 permit

alpha(config-if)#access-list 1 permit

Take note that the NAT pool ovrld only has a range of one address. The keyword overload used in the ip nat inside source list 1 pool ovrld overload command allows NAT to translate multiple inside devices to the single address in the pool.

You also could use the ip nat inside source list 1 interface serial 0 overload command, which configures NAT to overload on the address you assigned to the serial 0 interface.

When you configure overloading, the router maintains enough information from higher-level protocols (for example, TCP or UDP port numbers) to translate the global address back to the correct local address. When multiple local addresses map to one global address, the TCP or UDP port numbers of each inside host distinguish between the local addresses.

The final step is to verify that NAT is operating as intended.

Verifying NAT Operation

Once you've configured NAT, verify that it's operating as intended and expected. You can do this in a number of ways: using a network analyzer, debug commands, or show commands. You can use the show commands shown in Table 2.

Table 2: Show Commands

Command Description
show ip nat statistics Displays NAT statistics. You will see the active total translations, outside interfaces, inside interfaces, hits or translations, misses or creations, and expired translations.
show ip nat translations [verbose] Displays NAT translations. The verbose keyword optionally displays additional information for every table entry, including the age of the entry and the last time used.

NAT often increases the complexity of debugging tasks, since you will have translated addresses.

Queuing and Traffic Policing

Cisco provides other technologies that can help you battle denial of service attacks and enhance performance. You can manage traffic flows in a network by enabling queuing and traffic policing methods to limit particular traffic. This section focuses on queuing and traffic policing.


Collectively known as queuing technologies, these features can help manage congestion on a router interface by determining the order for transmitting packets out based on priorities you put on those packets. You can control the traffic allowed through a router interface in preference to other traffic. These technologies are useful when you have more data to send than the router can actually send or when you have traffic congestion on an interface. When you have no congestion, using queuing techniques serves little purpose. There are four types of queues:

  1. First in, first out (FIFO)
  2. Weighted fair queuing (WFQ)
  3. Custom queuing (CQ)
  4. Priority queuing (PQ)

FIFO is the fastest queuing method and is the default for interfaces with speeds greater than 2.048 Mbps (E1 capacity).

WRQ uses a scheduling method that provides a fair allocation of bandwidth to all network traffic. The method applies a priority to traffic so it can classify traffic into conversations and determine traffic requirements for each conversation vis--vis other conversations. It uses a flow-based algorithm that moves interactive traffic (such as Telnet) to the front of the queues to reduce response time and fairly shares the remaining bandwidth amongst high-traffic flows.

There is one Weighted Fair Queuing command you need.

alpha(config)#fair-queue discard-threshold dynamic-queue-number reserved-conversations-number

The defaults for the parameters are 64, 256 and 0. Don't change the values unless you have a good reason.

CQ allows you to create up to 16 queues and to specify the number of bytes to forward from each queue. You can allocate resources to applications that require a certain fixed amount of bandwidth. Additionally, you can specify the maximum number of packets in each queue, further allowing you control the traffic available to each queue. CQ cycles through each queue in a round-robin fashion. When a queue is empty, it moves to the next queue. When it is not, CQ services each queue until either the byte count limit for the queue is reached or the queue is empty. There are actually 17 queues, with Queue 0 reserved for the system.

There are four Custom Queuing commands you need.

alpha(config)#queue-list list-number interface interface-type interface-number queue-number

This command assigns packets arriving on an interface to a queue.

alpha(config)#queue-list list-number protocol protocol-name queue-number queue-keyword keyword-value

Possible values for queue-keyword are shown in Table 3.

Table 3: Keywords

Keyword Description
gt Greater than a certain byte count.
lt Less than a certain byte count.
tcp TCP port to match (either source or destination).
udp UDP port to match (either source or destination).
fragments IP fragments.

Use this command to assign packets with a certain packet size to a queue.

alpha(config)#queue-list list-number queue queue-number byte-count byte-count-number

You can use this command to set the number of bytes that you allow each queue to transfer when the router services it.

alpha(config)#queue-list list-number queue queue-number limit limit-number

Finally, this command allows you to set the number of packets stored in a queue.


Note. When using custom queuing, don't forget to specify a default queue.


Once, you create queues and assign appropriate byte-count and packet-limit sizes, you apply the queue to an interface using the following commands:

alpha(config)#interface interface-type interface-number

alpha(config-if)#custom-queue-list list-number

PQ is similar to CQ, except an individual queue can dominate other queues. You don’t have 16 queues but rather high, medium, normal and low. The router will service all the traffic in a higher-level queue before servicing a lower-level queue. You can classify how the router places traffic in a queue based on protocol, protocol access list, incoming interface, or packet size. The IOS always places interface keepalives in the high priority queue. You must explicitly allocate all other traffic; otherwise they end up in the normal queue.

There are four Priority Queuing commands you need.

alpha(config)#priority-list list-number protocol protocol-name {high | medium | normal | low} queue-keyword keyword-value

This command allows you to assign a particular protocol (AppleTalk, IP, IPX, etc) to one of the priority queues. You can optionally specify a keyword like list to specify the use of an access list or one of the keywords in Table 3.

alpha(config)#priority-list list-number interface interface-name {high | medium | normal | low}

You can use this command to assign packets arriving on a particular router interface to a queue.

alpha(config)#priority-list list-number default {high | medium | normal | low}

Use this command to set up a default queue where you don't have explicit queue statements.

alpha(config)#priority-list list-number queue-limit [high-limit [medium-limit [normal-limit [low-limit]]]]

This command allows you to change the packet-limit counts for each of the queues. The limit is any value from 0 to 32,767. The default values for the queues are 20, 40, 60, and 80 datagrams respectively.

Once, you create queues and assign appropriate byte-count and packet-limit sizes, you apply the queue to an interface using the following commands:

alpha(config)#interface interface-type interface-number

alpha(config-if)#priority-group list-number


Note. When creating a priority list, don't forget to specify a default queue.


A complete discussion of queuing is beyond the scope of this article, but let's look at how you could use priority queuing. You want to ensure that your application running on TCP port 666 gets sufficient bandwidth.

alpha(config)#interface serial0

alpha(config-if)#priority-group 1

alpha(config-if)#priority-list 1 protocol ip high tcp 666

alpha(config-if)#priority-list 1 protocol ip normal

alpha(config-if)#priority-list 1 queue-limit 40 40 60 80

This devilishly simple set of commands provides our application precedence over other applications. It also sets queue limits.

Use your imagination and you can see how you can limit the impact of denial of service attacks on your organization by placing them in low priority queues.

Traffic Policing

Traffic policing refers to the features that allow a device to strictly limit the amount of traffic the router will send or receive on an interface. Cisco calls their traffic policing software committed access rate (CAR). CAR services limit the input or output transmission rate on an interface based on various criteria. Typically, you would configure CAR at the edge of your network such as the Internet connection between ISP's or between an ISP and a customer. Cisco recommends that you use CAR on your routers to limit inbound levels of ICMP traffic. You also can reduce the amount of SYN traffic to help against SYN flooding and Distributed DoS attacks.

CAR can limit traffic based on IP precedence, incoming interface, or an IP access list. You can configure the action that CAR takes when traffic exceeds its allocated limit, such as dropping the connection or resetting its precedence value.

Configuring CAR

When configuring CAR, you must first determine the average bits per second (bps) for normal traffic flow. Then, you define a normal burst rate and an exceed burst rate. You allow traffic to burst above the normal rate up to the normal burst rate. The router may discard any traffic exceeding the normal rate plus the normal burst rate. The probability that it will discard the traffic increases until the traffic reaches the value of the normal rate plus the exceed burst rate. Once traffic exceeds the value of the normal rate plus the exceed burst rate, the router will discard all traffic. Wow, may be some numbers will help with that. Your normal rate is 512,000 bps or 64,000 Bps, the normal burst is 56,000 bps and the exceed rate is 64,000 bps. Traffic up to 568,000 bps, which is 512,000 + 56,000, still meets the thresholds. Traffic between 568,001 and 576,000 exceed the thresholds and the router may discard the traffic. The router will discard all traffic above 576,000 bps.

To configure CAR, you only need the following interface command.

alpha(config-if)#rate-limit {input | output} [access-group [rate-limit] acl-index] bps burst-normal burst-max conform-action action exceed-action action

The conform and exceed actions are one of the following:

  • continue; that is, continue with the next rate-limit command.
  • drop.
  • set-prec-continue; that is, set the IP precedence and continue with the next rate-limit command.
  • set-prec-transmit; that is, set the IP precedence and transmit packet.
  • transmit.

So, should you want to apply the example you first saw in this section, you would use the following two commands starting in global configuration mode.

alpha(config)#interface serial0

alpha(config-if)#rate-limit input 512000 56000 64000 conform-action transmit exceed-action drop

When you are defining CAR for multiple traffic classes, you also must define CAR access lists to classify the traffic you want CAR to police. Following is the command and an example.

alpha(config-if)#access-list rate-limit acl-index {precedence | mac-address | mask prec-mask}

alpha(config-if)#access-list rate-limit 100 4000.le01.4337

Should you wish, you can use a standard or extended IP access list instead of the preceding rate-limit access list.


In this article, you saw how to configure NAT using the following steps:

  1. Define NAT inside and outside interfaces.
  2. Define what you are trying to accomplish with NAT.
  3. Configure NAT in order to accomplish what you defined in Step 2.
  4. Verify NAT operation.

Finally, you learnt how queuing and traffic policing could help in your battle against those attackers bent on denying service to your legitimate clients.

Another feature Cisco introduced in IOS version is Hot Standby Router Protocol (HSRP). This protocol accommodates a circuit failure in your router. HSRP will allow you to take two or more routers and make them appear to the network as a single point or a "virtual router" to use as the default gateway. Use the standby command.

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: