Rate Limiting
With some types of DoS attacks, there's not much you can do to stop the flow of the attack, especially in a distributed DoS (DDos) attack in which the hacker is spoofing the source addresses and using an unsuspecting company or ISP as the reflector in the attack. Tracing this kind of attack to the hacker can be difficult.
In this situation, your first concern should be limiting the impact of the attack on your network, which can be done with rate limiting. Rate limiting enables you to assign a bandwidth restriction to a category of traffic, such as ICMP, UDP, or specific connection types. This section focuses on three solutions for rate limiting: ICMP rate limiting, committed access rate (CAR), and class-based policing (CBP) using Network-Based Application Recognition (NBAR).
TIP
Rate limiting is best used on the ISP's router that connects to your network. In other words, if you are experiencing a flood attack that is saturating your Internet link, implementing rate limiting on your perimeter router will not do much good. Instead, you work with your ISP to put this in place on the ISP's router. Rate limiting is something you configure to restrict the amounts of various outbound traffic. As an example, if you were a reflector in a Smurf attack, you could use rate limiting as a temporary solution to limit the flood of traffic that you are sending to a victim's network. Of course, you will want to try to track down the culprit and stop the attack.
ICMP Rate Limiting
Many attacks create a DoS attack by sending a flood of traffic to a device or devices that do not exist, causing an intervening router to reply back with an ICMP unreachable message for each unknown destination. A good example of this is a worm attack, such as an attack by the SQL Slammer worm. Through this process, the worm, purposefully or inadvertently, tries to find other machines with the same weakness. It typically does this through a ping sweep. Most worms are not intelligent about how they do this: They continually scan the same networks, trying to find the same security hole or holes that the worm used initially to subvert one of your devices.
Using Other Solutions
To prevent the overwhelming number of ICMP unreachables that your router would generate in a worm attack, you can filter the specific kind of traffic, with an ACL that looks for ICMP unreachable messages, like this:
Router(config)# <--permit and deny other types of traffic--> Router(config)# access-list 100 deny icmp any any unreachable Router(config)# <--permit and deny other types of traffic-->
With the SQL Slammer worm attack, you can set up an ACL to block UDP traffic destined to port 1434, like this:
Router(config)# <--permit and deny other types of traffic--> Router(config)# access-list 100 deny udp any any eq 1434 Router(config)# <--permit and deny other types of traffic-->
This example blocks all Microsoft SQL traffic and is configured on the external interface of your perimeter router.
NOTE
Of course, if the worm is inside your network, and if either of these two ACLs is applied on your perimeter router inbound on its external interface, these ACLs will not help you much. For these to be effective, you must set up similar ACLs on all or most of your routers throughout your network. Plus, with the first ACL, you might need to allow certain ICMP unreachable messages to specific devices, making this configuration more difficult to implement.
Another possible solution was discussed in Chapter 4, which covered many services that you should disable. One of these is the generation of ICMP unreachable messages by the router. For example, on a perimeter router, you could configure the following on its interfaces (at least, the external interface):
Router(config)# interface type [slot_#/]port_# Router(if-config)# no ip unreachables
Again, the problem with this approach is that you need to enable this on all of the routers (and their interfaces) in your network to prevent the generation of ICMP unreachable messages. In many cases, this presents additional problems: For example, it becomes much more difficult to use tools such as ping and traceroute to track down problems because your routers are not generating ICMP unreachable messages.
Using the ICMP Rate-Limiting Feature
Starting in 12.0 of the Cisco IOS, Cisco implemented a default rate limit of one ICMP unreachable packet that a router would generate in a 500-millisecond (ms) interval. This prevents a router from responding to thousands of packets with unreachable destinations with a separate ICMP message for each of these access requests.
In Cisco IOS 12.1, you can tune this operation manually with the following command:
Router(config)# ip icmp rate-limit unreachable [df] milliseconds
First, notice that this is a global configuration mode command: it applies to any ICMP unreachable message responses on any interface. Second, the df parameter is used to restrict the number of ICMP unreachable messages generated by the router when the fragmentation of the packet is needed and the DF bit in the IP packet header is set. Third, you can specify only the time interval for ICMP unreachable messages (in milliseconds). This can range from 1 to 4,294,967,295. During the specified interval, the Cisco IOS generates only one ICMP unreachable message for the first packet that requires one; for other unreachable events, the router ignores them until the configured time period expires.
Here is a simple example:
Router(config)# ip icmp rate-limit unreachable 1000
In this example, only one ICMP unreachable message is generated each second.
CAR
The main problem with the ip icmp rate-limit command is that it works only for ICMP unreachable messages. To deal with other kinds of traffic, including ICMP unreachables, you can use committed access rate (CAR). CAR enables you to limit traffic entering or leaving an interface, and it can match on any of the following criteria: all IP traffic, IP precedence value, MAC address, or information that matches a permit statement in either a standard or an extended ACL.
CAR typically is implemented at the perimeter of your network for egress traffic, and it enables you to have different rate-limiting policies for different types of traffic. For example, you might have different rate limits for ICMP traffic compared to HTTP traffic to a web server.
CAUTION
Using an ACL to specify matching traffic can be process intensive. In addition, if you specify more than one policy, your router will have an additional CPU utilization hit; try to limit the number of policies that you define. Because of these issues, you should use CAR with caution. Typically, I use CAR when I know that I am under attack and want a quick-and-dirty solution to prevent the unwanted traffic while giving valid users and connections the bandwidth that they need. When the attack has been mitigated, I remove the CAR configuration.
CAR Configuration
This section focuses on using CAR to deal with DoS traffic. Here are the commands to set up CAR:
Router(config-if)# interface type [slot_#]port_#
Router(config-if)# rate-limit {input | output}
[access-group [rate-limit] acl-index] bps burst_normal burst_max
conform-action action exceed-action action
Use either a rate-limit, a standard, or an extended ACL to match on the traffic for rate limiting by using one of these three respective commands:
Router(config-if)# access-list rate-limit ACL_# {precedence_value |
MAC_address | mask precedence_mask}
or
Router(config-if)# access-list ACL_# {deny | permit}
source_IP_address [source-wildcard_mask]
or
Router(config-if)# access-list ACL_# {deny | permit} protocol
source source_wildcard destination destination-wildcard
[precedence precedence][tos tos] [log]
The standard and extended ACLs can be numbered or named.
NOTE
CAR requires that CEF be enabled on your router first.
rate-limit Command
Configuration of CAR is done on a router's interface with the rate-limit command. This command specifies the rate policy to be used for the matching traffic. The input and output parameters specify the direction in which CAR should be performed.
ACL Parameter
Optionally, you can specify an ACL number or name with the access-group parameter, which is used to examine specific traffic. You can use three different kinds of ACLs with CAR: rate-limit, standard, and extended (these are listed as the last three separate statements in the previous code examples). A rate-limit ACL enables you to match on a specific precedence value, a range of precedence values, or a specific MAC address. A standard ACL enables you to match on only source IP addresses. An extended ACL enables you to match on many types of traffic, such as the IP protocol, source and destination addresses, source and/or destination protocol information, precedence values, ToS values, and other fields supported by an ACL. The use of the log parameter, when combined with CAR, displays the actual matching process, but this is not recommended because of performance issues.
Rate Parameters
Three rate functions are defined in your CAR configuration:
The average rate, specified in bits per second (bps), for the matching traffic. This is measured by a long-term average of the transmitted rate of traffic on the interface. Traffic under this rate is considered to be conforming.
The normal burst size, specified in bits per second (bps). This determines how long traffic can burst above the average rate before it is considered nonconforming.
The excessive burst rate, specified in bits per second (bps). Traffic that exceeds the excessive burst rate is considered nonconforming.
As you can see from these rate parameters, this is similar to Frame Relay's traffic-shaping parameters. However, one important point about the Frame Relay's parameters is that they are used for traffic shaping: CAR's parameters are used for rate limiting.
Rate Actions
When there is a match in an ACL or traffic type, the Cisco IOS can take the actions described in Table 17-3 for conforming (conform-action parameter) or nonconforming (exceed-action parameter) traffic.
Table 17-3 CAR Actions
|
Action Parameter |
Explanation |
|
continue |
Evaluates the next rate-limit command on the interface |
|
drop |
Drops the packet |
|
transmit |
Transmits the packet |
|
set prec-continue precedence_value |
Sets the precedence value in the IP header to the specified value, and then evaluates the next rate-limit command on the interface |
|
set prec-transmit precedence_value |
Sets the precedence value in the IP header to the specified value and transmits the packet |
Normally, you use the continue, transmit, and set parameters for conforming traffic; you use the drop command for nonconforming traffic. Remember that you are using CAR, in this instance, to limit the effect of DoS attacks. The options of setting a precedence value can be used in further CAR rate-limit commands on the interface or by other interfaces on this router or other routers.
Verifying CAR
After you have set up CAR, you can use one of the following three commands to verify its operation:
Router# show access-lists Router# show access-lists rate-limit [ACL_#] Router# show interfaces [interface_type_and_#] rate-limit
Example 17-15 displays sample output using the last command.
Example 17-15 Using the show interfaces rate-limit Command for a Specified Interface
Router# show interfaces ethernet2/0 rate-limit Ethernet2/0 Input matches: access-group rate-limit 100 params: 64000 bps, 8000 limit, 8000 extended limit conformed 0 packets, 0 bytes; action: transmit exceeded 0 packets, 0 bytes; action: drop last packet: 9383444ms ago, current burst: 0 bytes last cleared 01:32:00 ago, conformed 0 bps, exceeded 0 bps
In this example, ACL 100 is used to define rate limiting. The average rate is 64,000 bps, and the two burst sizes are set to 8,000 bps, limiting the burst for traffic specified in permit statements in ACL 100.
Rate Limiting for ICMP and Smurf Attacks
Now that you have a basic understanding of the configuration of CAR, take a look at a couple of examples of its use for dealing with DoS attacks. In this section, I show you how to use CAR to limit the impact of the Smurf attack. In this example, the customer has a T1 connection and is experiencing a Smurf attack. The customer has talked to the ISP about the problem, and it has decided to implement rate limiting on its interfaces, to limit the scope of the attack as it tries to track down the originator of the attack. Example 17-16 shows the code used on the ISP router.
Example 17-16 Using CAR on the ISP Router to Rate-Limit Smurf Traffic
ISP(config)# access-list 100 permit icmp any any echo ISP(config)# access-list 100 permit icmp any any echo-reply ISP(config)# interface serial0 ISP(config-if)# rate-limit output access-group 100 64000 4000 4000 conform-action transmit exceed-action drop
In Example 17-16, ICMP echos and echo replies are limited to 64 kbps of bandwidth, with a burst size of 4 kbps of bandwidth. Example 17-17 shows the code used on the customer's router.
Example 17-17 Using CAR on the Customer Router to Rate-Limit Smurf Traffic
Customer(config)# access-list 100 permit icmp any any echo Customer(config)# access-list 100 permit icmp any any echo-reply Customer(config)# interface serial0 Customer(config-if)# rate-limit output access-group 100 64000 4000 4000 conform-action transmit exceed-action drop
Notice something interesting about the customer's router configuration: It is the same as the ISP's, applied in the same direction (out). If the attack is being started from the Internet to the company, the customer's configuration is not necessary. However, if the attack is occurring in both directions, possibly because an internal customer device was compromised and used as a reflector, setting up rate limiting in both directions is typically necessary.
TIP
Remember that in DoS flood situations, you need to contact your ISP promptly and have it implement rate limiting in the outbound direction of its router's interface that connects to you. Using the configuration in Example 17-17 on your router still will cause you bandwidth problems on your link to the ISP if the attack is occurring from the outside; however, if your ISP is not cooperative, you can use this configuration on your perimeter router in the ingress direction, restricting the Smurf traffic to your internal devices.
Rate Limiting for TCP SYN and Other TCP Floods
You also can use rate limiting to limit the effect of TCP SYN flood attacks. Example 17-18 shows a configuration for a T1 link, which assumes that the hacker's source IP address is 201.1.1.1.
Example 17-18 Using CAR to Rate-Limit TCP SYN Floods
Router(config)# access-list 100 deny tcp any host 192.1.1.1 established Router(config)# access-list 100 permit tcp any host 192.1.1.1 Router(config)# interface serial0 Router(config-if)# rate-limit input access-group 100 8000 4000 4000 conform-action transmit exceed-action drop
Example 17-18 assumes that the configuration is applied on the customer's router. Notice something interesting about the ACL in this example. It uses the established keyword to block out all TCP packets except TCP SYN, which is used to establish connections, from being rate limited. Also, it restricts the TCP SYNs from any attacking host to the 192.1.1.1 server; other traffic sent to other internal servers is not rate limited by this configuration.
How to Choose a Rate Limit
If you suspect that you are under a TCP SYN flood or ICMP flood attack, you will want to set up rate limiting for your traffic. If you are not sure of the source of the attack, you can set up rate limiting to the full bandwidth of the link and then use the show interfaces rate-limit command to determine how you actually should set the rates in the rate-limit command.
Here is a simple example. Assume that you have a T1 connection to the Internet and that you suspect that your web servers in your DMZ are under some kind of TCP SYN flood attack; however, you are not absolutely sure. In this situation, configure CAR (assuming a T1 link) as displayed in Example 17-19.
Example 17-19 Configuring CAR for a T1 Link
Router(config)# access-list 100 permit tcp any host eq www established Router(config)# access-list 101 permit tcp any host eq www Router(config)# interface serial0 Router(config-if)# rate-limit output access-group 100 1544000 64000 64000 conform-action transmit exceed-action drop Router(config-if)# rate-limit output access-group 101 64000 16000 16000 conform-action transmit exceed-action drop
In Example 17-19, there are two ACL statements. The first ACL statement looks for any web traffic that is established. The second one looks only for any web traffic. Notice that, with the rate limiting, the first rate-limit command allows full bandwidth for already established connections (ACL #101); the second command limits the initial setup of the HTTP connection (the TCP SYNs).
A couple things should be pointed out about this configuration. First, in the first rate-limit command, you need to replace the 1,544,000 bps value to match the actual speed of your interface. Second, do not choose arbitrary rate-limiting values for the second rate-limit command for the TCP SYN setup of the web connections. Before you define any limits, you should understand your traffic patterns: Putting in a value that is too small or too large might create additional problems. Use the show interfaces rate-limit command to tune this process.
TIP
Before implementing CAR, make sure that you have a baseline of traffic flowing through the router under normal circumstances, categorized by traffic type and destination addresses.
Rate Limiting for W32.Blaster Worm
As you might have experienced firsthand, dealing with a worm attack can be a hair-raising experience, especially because most worm attacks either purposefully or inadvertently cause a DoS attack, sucking up bandwidth and causing problems for other applications and services in your network. Assuming that you know the protocols and ports that these worms are using, you can set up rate limiting, using CAR, to limit the bandwidth that they can use.
Consider the W32 Blaster worm as an example. Example 17-20 shows a sample CAR configuration to rate limit the bandwidth to traffic on the ports used by the worm.
Example 17-20 Using CAR to Rate Limit the W32 Blaster Worm
Router(config)# access-list 199 permit udp any any eq 135 Router(config)# access-list 199 permit udp any any eq 139 Router(config)# access-list 199 permit tcp any any eq 135 Router(config)# access-list 199 permit tcp any any eq 135 Router(config)# access-list 199 permit udp any any eq 445 Router(config)# access-list 199 permit tcp any any eq 445 Router(config)# access-list 199 deny ip any any Router(config)# interface vlan10 Router(config-if)# rate-limit input access-group rate-limit 199 256000 64000 64000 conform-action transmit exceed-action drop
NOTE
It is important to point out that you typically are not allowing the previous ports into your network—at least, you should not be. Therefore, this kind of rate limiting typically is done internal to your network on which you have a worm infection that is running rampant. In the previous example, this was done on a 3550 Catalyst switch, to limit the bandwidth for these connections and to limit the impact of the worm. Also make sure that whatever bandwidth limits you have imposed are high enough to allow at least some legitimate traffic of the same type, but low enough to allow other types of traffic. When you have eradicated the worm from your network by updating your antivirus software and applying the appropriate patches, remove the CAR configuration for this traffic because it also can affect legitimate traffic.
NBAR
I discussed NBAR in Chapter 10, "Filtering Web and Application Traffic," and Chapter 15, "Routing Protocol Protection." In Chapter 10, I used NBAR to drop P2P traffic. In Chapter 15, I used NBAR to route unwanted or undesirable traffic to a null interface. You also can use NBAR to limit packet rates of either undesirable traffic or flooding traffic. The configuration of NBAR for rate limiting is actually very similar to using it for policing, with a few minor differences.
NOTE
Cisco recommends using NBAR instead of other rate-limiting features when trying to deal with DoS attacks.
File-Sharing and P2P Programs
I have walked into many environments where P2P programs are using up a lot of a company's bandwidth, but the company's security policy does not explicitly prohibit their use. In one particular situation, many managers and officers of the corporation used these as well as Instant Messenger products and wanted to continue their use, even though they did not really add to the company's bottom line. In this situation, I recommended that the director of networking implement rate limiting for these kinds of products. In this situation, employee file sharing was much slower in their downloads, but employees still were able to access P2P sites, as well as legitimate applications that did not suffer from the burden of these programs.
Smurf Example
Instead of rehashing the syntax of the NBAR configuration commands, which were covered in Chapter 10, I display in this section an example configuration and focus on one new command, police, which specifies the policing action to take. This section uses the Smurf attack as an example. Example 17-21 shows the code.
Example 17-21 Using NBAR to Rate Limit Smurf Traffic
Router(config)# access-list 100 permit icmp any any echo (1) Router(config)# access-list 100 permit icmp any any echo-reply Router(config)# class-map match-any smurf-attacks (2) Router(config-cmap)# match access-group 100 Router(config-cmap)# exit Router(config)# policy-map mark-smurf (3) Router(config-pmap)# class smurf-attacks Router(config-pmap-c)# set ip dscp 1 Router(config-pmac-c)# exit Router(config)# interface ethernet1 Router(config-if)# description ***To the ISP*** Router(config-if)# service-policy input mark-smurf (4) Router(config-if)# exit Router(config)# class-map match-any smurf-marked (5) Router(config-cmap)# match dscp 1 Router(config-cmap)# exit Router(config)# police-map limit-smurfs (6) Router(config-pmap)# class smurf-marked Router(config-pmap-c)# police 64000 4000 4000 conform-action transmit exceed-action drop violation drop Router(config)# interface ethernet0 Router(config-if)# description ***To the Internal Network*** Router(config-if)# service-policy output limit-smurfs (7)
The following is an explanation of the configuration in Example 17-21, with reference to the numbering on the right side:
ACL 100 defines the traffic that I am limiting. Smurf uses ICMP echos and echo replies.
The class-map command looks for this traffic with the match access-group command.
The policy map marks all packets matched in the class-map command with a DSCP value of 1.
The policy map is activated on the perimeter router's external interface, marking traffic as it comes from the Internet and enters this network.
Remember that NBAR cannot perform two policies on one interface, such as mark and drop, or mark and limit. Therefore, a separate policy must be created. In Step 5, a second class map is created, looking for the packets (ICMP) that had their DSCP value set to 1.
The police-map command specifies the policy to be applied to this traffic. In this instance, I first reference the class map, which matches on packets with the DSCP value set to 1. Second, the police command is used to enforce rate limiting. This is very similar to CAR's rate-limit command. The only difference between this command and the police command is that the latter command supports an additional parameter, violation, which is optional and specifies the action to take if both the normal and excessive burst sizes are violated. In the previous example, ICMP traffic is limited to an average throughput of 64 kbps, with a burst of 4 kbps. If either of these limits is exceeded, the policy is to drop these excessive ICMP messages.
The last step is to activate the second policy map on the router's internal interface (or interfaces, if there is more than one internal interface). After it is activated on the internal interface, the second policy map enforces rate limiting for packets that have their DSCP value set to 1.
Use the show policy-map interface command to examine the matching process on Ethernet1 and the policing process on Ethernet0.
As I mentioned in Chapters 10 and 15, NBAR is a multifunctional tool that can be very useful in implementing security measures, which is not what Cisco initially had in mind when offering this feature. Given the last example, you easily can modify it to suite other types of attacks, such as an attack by the SQL Slammer worm. You only need to modify the ACL that looks for the offending traffic.
You even can use this process to limit the bandwidth for other types of traffic that are not necessary for business purposes, such as instant messenger, P2P, and other programs. This approach still allows your users to use these programs, but it limits the bandwidth that they can use. In this situation, however, your first class map looks for the traffic and is applied to the inside interface of your perimeter router, and the policing policy is applied to the external interface.
W32.Blaster Worm Example
In the "CAR" section, I discussed how to use rate limiting to limit the effectiveness of the W32.Blaster worm. I use this worm as an example to set up NBAR to implement rate limiting. Example 17-22 shows the basic configuration for NBAR to rate limit the W32.Blaster worm.
Example 17-22 Using NBAR to Rate Limit the W32.Blaster Worm
Router(config)# ip nbar port-map netbios1 tcp 135 139 445 (1) Router(config)# ip nbar port-map netbios2 udp 135 139 445 Router(config)# class-map match-any w32blaster-attack (2) Router(config-cmap)# match protocol netbios1 Router(config-cmap)# match protocol netbios2 Router(config-cmap)# exit Router(config)# policy-map mark-w32blaster (3) Router(config-pmap)# class w32blaster-attack Router(config-pmap-c)# set ip dscp 1 Router(config-pmac-c)# exit Router(config)# interface ethernet1 Router(config-if)# description ***To the ISP*** Router(config-if)# service-policy input mark-w32blaster (4) Router(config-if)# exit Router(config)# class-map match-any mark-w32blaster (5) Router(config-cmap)# match dscp 1 Router(config-cmap)# exit Router(config)# police-map limit-w32blaster (6) Router(config-pmap)# class w32blaster-marked Router(config-pmap-c)# police 64000 4000 4000 conform-action transmit exceed-action drop violation drop Router(config)# interface ethernet0 Router(config-if)# description ***To the Internal Network*** Router(config-if)# service-policy output limit-w32blaster (7)
In Statement 1, the first two commands create a custom protocol for NBAR, called netbios, which includes both TCP and UDP ports 135, 139, and 445. Statement 2 points to the custom protocol that you defined for NBAR. All of the other Statements (3 through 7) refer to the same steps that you performed in setting up NBAR for Smurf attacks.
NOTE
Setting up NBAR to rate limit other types of attacks, including other worms, necessitates that you set up rate limiting similar to the Smurf or W32.Blaster configuration.