|
Configuring Cisco Denial of Service Security Features - Part 2 |
||||||||||||||||||||||||||||||||||||||
|
IntroductionThis 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.
Table 1: NAT Types and Features
Cisco IOS 11.2 and above support these features. Some questions to reflect upon:
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 second command translates:
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 172.16.10.1 through 172.16.10.63. 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 10.10.10.1 255.255.255.0 alpha(config-if)#ip nat inside alpha(config-if)#exit alpha(config)#interface ethernet 1 alpha(config-if)#ip address 10.10.20.1 255.255.255.0 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 172.16.10.64 255.255.255.0 alpha(config-if)#ip nat outside alpha(config-if)#exit Next, you define a NAT pool named no-overload with a range of addresses from 172.16.10.1 to 172.16.10.63. This sets up the pool of addresses for dynamic address translation. alpha(config)#ip nat pool no-overload 172.16.10.1 172.16.10.63 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 10.10.10.0 through 10.10.10.31 and 10.10.20.0 through 10.10.20.31. alpha(config)#access-list 1 permit 10.10.10.0 0.0.0.31 alpha(config)#access-list 1 permit 10.10.20.0 0.0.0.31 ______________________________________________________________________________ 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 10.10.10.0 and the first 32 addresses from subnet 10.10.20.0 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 10.10.10.1 255.255.255.0 alpha(config-if)#ip nat inside alpha(config-if)#interface ethernet 1 alpha(config-if)#ip address 10.10.20.1 255.255.255.0 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 172.16.10.64 255.255.255.0 alpha(config-if)#ip nat outside You must define a NAT pool with a range of a single IP address, 172.16.10.1. You must name the pool; here it is ovrld. alpha(config-if)#ip nat pool ovrld 172.16.10.1 172.16.10.1 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 10.10.10.0 through 10.10.10.31 and 10.10.20.0 through 10.10.20.31. alpha(config-if)#access-list 1 permit 10.10.10.0 0.0.0.31 alpha(config-if)#access-list 1 permit 10.10.20.0 0.0.0.31 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
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. Queuing 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:
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
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:
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. ConclusionIn this article, you saw how to configure NAT using the following steps:
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. |
||||||||||||||||||||||||||||||||||||||
