Protection Against Attacks
Now that you have a basic understanding of ACL configuration and their additional features, the rest of this chapter focuses on some important filtering rules that you should implement on your router. In this section, I assume that your router is acting either as a perimeter router or as the main perimeter firewall.
Bogon Blocking and Spoofing
A bogon is a network or route prefix that should not appear in an Internet routing table. Many types of bogon addresses exist, including the following:
Addresses that should be used only internally, such as RFC 1918 addresses.
Loopback addresses (127.0.0.0/8).
Reserved IANA addresses.
Multicast addresses (224.0.0.0/4).
Research addresses (240.0.0.0/4).
DHCP local address (169.254.0.0/16). This is what your PC uses if it cannot find a DHCP server from which to acquire its addressing information.
Documentation/test network (192.0.2.0/24).
TIP
This list of bullets is not all-inclusive. IANA is responsible for address assignments and has a list of all addresses that are currently in use; those that are not in use should be blocked. To see the current list of IANA addresses, visit http://www.iana.org/assignments/ipv4-address-space. One problem with this list is that it lists all addresses and, if they are used, who they are assigned to. I typically use the bogon list at the website http://www.cymru.com/Documents/bogon-list.html. This site keeps the list up-to-date and includes only bogon addresses.
You will want to check this list periodically; some addresses that were assigned to an ISP sometimes are taken back (and placed on the bogon list), and some addresses sometimes are assigned (and should be removed from the bogon list).
As a good example of a bogon, imagine that someone from the Internet is trying to forward traffic to you with an RFC 1918 source address or an address that currently is unassigned by the IANA. These commonly are used in distributed DoS (DDoS) attacks.
You can block these addresses in four common ways:
ACL filtering
BGP prefix filtering (discussed in Chapter 15, "Routing Protocol Protection")
Black hole routing (discussed in Chapter 15)
Route policy filtering with route maps (discussed in Chapter 15)
This section focuses on using ACLs and filtering bogon addresses.
The first question that you might ask is, what kind of advantage does bogon filtering provide? Rob Thomas of Team Cymru, who has done frequent work with bogons and network attacks, has found that 66 percent of DDoS attacks use bogons. Of this 66 percent, more than half of these attacks use source addresses from a Class D or E address space. Therefore, blocking these addresses will stop more than 60 percent of DDoS attacks right at your front door?your perimeter router. If you want to read more about Rob's study, "60 Days of Basic Naughtiness," visit http://www.cymru.com/Presentations/60Days.ppt.
Essentially, bogon filtering typically is used to prevent spoofing attacks. As you recall from Chapter 1, "Security Threats," in a spoofing attack, the hacker tries to hide his source IP address. Bogon filtering filters out the addresses that are basically bogus addresses or impossible addresses. RFC 2267 discusses filtering of spoofed addresses.
Ingress Filtering
As you recall from Chapter 4, "Disabling Unnecessary Services," the Cisco IOS AutoSecure feature automatically creates a bogon filter and applies it to your perimeter or firewall router's interface connected to the public network. Consider the network shown previously in Figure 7-5 as an example. Example 7-22 shows an example of an ingress ACL filtering traffic as it comes from the Internet and into your network.
Example 7-22. Using an Ingress ACL to Filter Bogons
Router(config)# ip access-list extended ingress-filter Router(config-ext-nacl)# remark Unassigned IANA addresses Router(config-ext-nacl)# deny ip 1.0.0.0 0.255.255.255 any Router(config-ext-nacl)# deny ip 2.0.0.0 0.255.255.255 any Router(config-ext-nacl)# deny ip 5.0.0.0 0.255.255.255 any Router(config-ext-nacl)# deny ip 7.0.0.0 0.255.255.255 any Router(config-ext-nacl)# deny ip 23.0.0.0 0.255.255.255 any Router(config-ext-nacl)# deny ip 27.0.0.0 0.255.255.255 any Router(config-ext-nacl)# deny ip 31.0.0.0 0.255.255.255 any Router(config-ext-nacl)# deny ip 36.0.0.0 0.255.255.255 any Router(config-ext-nacl)# deny ip 37.0.0.0 0.255.255.255 any Router(config-ext-nacl)# deny ip 39.0.0.0 0.255.255.255 any Router(config-ext-nacl)# deny ip 41.0.0.0 0.255.255.255 any Router(config-ext-nacl)# deny ip 42.0.0.0 0.255.255.255 any Router(config-ext-nacl)# deny ip 49.0.0.0 0.255.255.255 any Router(config-ext-nacl)# deny ip 50.0.0.0 0.255.255.255 any Router(config-ext-nacl)# deny ip 58.0.0.0 0.255.255.255 any Router(config-ext-nacl)# deny ip 59.0.0.0 0.255.255.255 any Router(config-ext-nacl)# deny ip 60.0.0.0 0.255.255.255 any Router(config-ext-nacl)# deny ip 70.0.0.0 0.255.255.255 any Router(config-ext-nacl)# deny ip 71.0.0.0 0.255.255.255 any Router(config-ext-nacl)# deny ip 72.0.0.0 0.255.255.255 any Router(config-ext-nacl)# deny ip 73.0.0.0 0.255.255.255 any Router(config-ext-nacl)# deny ip 74.0.0.0 0.255.255.255 any Router(config-ext-nacl)# deny ip 75.0.0.0 0.255.255.255 any Router(config-ext-nacl)# deny ip 76.0.0.0 0.255.255.255 any Router(config-ext-nacl)# deny ip 77.0.0.0 0.255.255.255 any Router(config-ext-nacl)# deny ip 78.0.0.0 0.255.255.255 any Router(config-ext-nacl)# deny ip 79.0.0.0 0.255.255.255 any Router(config-ext-nacl)# deny ip 83.0.0.0 0.255.255.255 any Router(config-ext-nacl)# deny ip 84.0.0.0 0.255.255.255 any Router(config-ext-nacl)# deny ip 85.0.0.0 0.255.255.255 any Router(config-ext-nacl)# deny ip 86.0.0.0 0.255.255.255 any Router(config-ext-nacl)# deny ip 87.0.0.0 0.255.255.255 any Router(config-ext-nacl)# deny ip 88.0.0.0 0.255.255.255 any Router(config-ext-nacl)# deny ip 89.0.0.0 0.255.255.255 any Router(config-ext-nacl)# deny ip 90.0.0.0 0.255.255.255 any Router(config-ext-nacl)# deny ip 91.0.0.0 0.255.255.255 any Router(config-ext-nacl)# deny ip 92.0.0.0 0.255.255.255 any Router(config-ext-nacl)# deny ip 93.0.0.0 0.255.255.255 any Router(config-ext-nacl)# deny ip 94.0.0.0 0.255.255.255 any Router(config-ext-nacl)# deny ip 95.0.0.0 0.255.255.255 any Router(config-ext-nacl)# deny ip 96.0.0.0 0.255.255.255 any Router(config-ext-nacl)# deny ip 97.0.0.0 0.255.255.255 any Router(config-ext-nacl)# deny ip 98.0.0.0 0.255.255.255 any Router(config-ext-nacl)# deny ip 99.0.0.0 0.255.255.255 any Router(config-ext-nacl)# deny ip 100.0.0.0 0.255.255.255 any Router(config-ext-nacl)# deny ip 101.0.0.0 0.255.255.255 any Router(config-ext-nacl)# deny ip 102.0.0.0 0.255.255.255 any Router(config-ext-nacl)# deny ip 103.0.0.0 0.255.255.255 any Router(config-ext-nacl)# deny ip 104.0.0.0 0.255.255.255 any Router(config-ext-nacl)# deny ip 105.0.0.0 0.255.255.255 any Router(config-ext-nacl)# deny ip 106.0.0.0 0.255.255.255 any Router(config-ext-nacl)# deny ip 107.0.0.0 0.255.255.255 any Router(config-ext-nacl)# deny ip 108.0.0.0 0.255.255.255 any Router(config-ext-nacl)# deny ip 109.0.0.0 0.255.255.255 any Router(config-ext-nacl)# deny ip 110.0.0.0 0.255.255.255 any Router(config-ext-nacl)# deny ip 111.0.0.0 0.255.255.255 any Router(config-ext-nacl)# deny ip 112.0.0.0 0.255.255.255 any Router(config-ext-nacl)# deny ip 113.0.0.0 0.255.255.255 any Router(config-ext-nacl)# deny ip 114.0.0.0 0.255.255.255 any Router(config-ext-nacl)# deny ip 115.0.0.0 0.255.255.255 any Router(config-ext-nacl)# deny ip 116.0.0.0 0.255.255.255 any Router(config-ext-nacl)# deny ip 117.0.0.0 0.255.255.255 any Router(config-ext-nacl)# deny ip 118.0.0.0 0.255.255.255 any Router(config-ext-nacl)# deny ip 119.0.0.0 0.255.255.255 any Router(config-ext-nacl)# deny ip 120.0.0.0 0.255.255.255 any Router(config-ext-nacl)# deny ip 121.0.0.0 0.255.255.255 any Router(config-ext-nacl)# deny ip 122.0.0.0 0.255.255.255 any Router(config-ext-nacl)# deny ip 123.0.0.0 0.255.255.255 any Router(config-ext-nacl)# deny ip 124.0.0.0 0.255.255.255 any Router(config-ext-nacl)# deny ip 125.0.0.0 0.255.255.255 any Router(config-ext-nacl)# deny ip 126.0.0.0 0.255.255.255 any Router(config-ext-nacl)# deny ip 197.0.0.0 0.255.255.255 any Router(config-ext-nacl)# deny ip 201.0.0.0 0.255.255.255 any Router(config-ext-nacl)# remark RFC 1918 private addresses Router(config-ext-nacl)# deny ip 10.0.0.0 0.255.255.255 any Router(config-ext-nacl)# deny ip 172.16.0.0 0.15.255.255 any Router(config-ext-nacl)# deny ip 192.168.0.0 0.0.255.255 any Router(config-ext-nacl)# remark Other bogons Router(config-ext-nacl)# deny ip 224.0.0.0 15.255.255.255 any Router(config-ext-nacl)# deny ip 240.0.0.0 15.255.255.255 any Router(config-ext-nacl)# deny ip 0.0.0.0 0.255.255.255 any Router(config-ext-nacl)# deny ip 169.254.0.0 0.0.255.255 any Router(config-ext-nacl)# deny ip 192.0.2.0 0.0.0.255 any Router(config-ext-nacl)# deny ip 127.0.0.0 0.255.255.255 any Router(config-ext-nacl)# remark Internal networks Router(config-ext-nacl)# deny ip 200.1.1.0 0.0.0.255 any Router(config-ext-nacl)# remark Allow Internet to specific services Router(config-ext-nacl)# remark permit <what you need to permit> Router(config-ext-nacl)# deny ip any any Router(config-ext-nacl)# exit Router(config)# interface ethernet1 Router(config-if)# ip access-group ingress-filter in
The first part of the ACL blocks the IANA unassigned addresses. The second part blocks the RFC 1918 private addresses. The third part blocks other bogon addresses, such as multicast, research, network 0, DHCP local addresses, and loopback addresses. The fourth part blocks internal network addresses. This commonly is forgotten. Make sure that you prevent source addresses coming into your network that have the same addresses that you are using. This is an obvious DDoS attack. In the example in Figure 7-2, no one from the Internet should be using a source address of 200.1.1.0/24 because this is what IANA or the ISP assigned you.
One specialized form of DoS attack is called Land.c, or Land, for short. In this attack, the hacker sends traffic to a destination with a source address that matches that of the destination. When the destination receives the packet, it tries to respond to itself. In one variant of this attack, the hacker uses the same port number for the source and destination ports. For example, if a hacker was executing a Land.c attack against the e-mail server in Figure 7-2, the hacker would use a source and destination address of 200.1.1.11, and a source and destination port number of 25. In most cases, this would only eat up extra CPU cycles on the e-mail server. However, with certain TCP/IP protocol stacks, this might cause the machine to crash, especially under a heavy load. This bug was discovered a long time ago, and most operating systems that were affected have been patched. If you prevent traffic coming into your network that has a source address that you are using, you have prevented Land attacks (as I did at the bottom of the ingress ACL filter under the "Internal networks" remark).
NOTE
One question that I commonly am asked is "Why use deny statements to block this when the implicit deny will do this anyway?" Well, in some cases, your implicit deny will block this traffic. However, if you omit the deny statements that I listed in the code example, you basically are permitting anyone to send traffic to your permitted internal services with any kind of source address. Typically, these permit statements use the keyword any for the source address. Therefore, you want to put these bogon deny statements at the beginning, to prevent bogon DoS attacks against your internal resources.
Egress Filtering
The previous example shows you how to block bogus traffic coming into your network. However, as you recall from Chapter 1, most security threats (more than 60 percent), originate from inside your network. Therefore, you need to take precautions about restricting traffic leaving your network as well. In this case, you are concerned about two things: what address is in the source field and what address is in the destination field.
To restrict traffic leaving your network, you could use a filter similar to the one I created for ingress filtering on your Cisco IOS perimeter router/firewall in Example 7-22. However, it would be much simpler to create an ACL that specifies exactly what source addresses are allowed out and lets the implicit deny drop everything else. For example, if you allow all your internal traffic out, use a code example as shown in Example 7-23.
Example 7-23. Using an Egress ACL to Allow Only Valid Addresses to Exit
Router(config)# ip access-list extended egress-filter Router(config-ext-nacl)# permit ip 200.1.1.0 0.0.0.255 any Router(config-ext-nacl)# deny ip any any Router(config-ext-nacl)# exit Router(config)# interface ethernet1 Router(config-if)# ip access-group egress-filter out
Notice that this is applied on the external (public) interface in the outbound direction (see Figure 7-2).
CAUTION
You also can apply this egress filter on ethernet0 in the inbound direction. However, if your devices are using private addresses and your router is performing NAT on them, you have to allow these private addresses into the router. This is prone to error because some addresses you translate and some you do not. My personal preference is to filter the traffic as it leaves the interface. If you are using address translation, make sure that the address you specify is the public address in your extended ACL (assuming that the ACL is on the public interface applied outbound).
One problem arises with the previous egress filter. If a hacker can compromise one of your internal devices and gain unauthorized access to it, he might implement a DoS attack from it, attempting to send traffic to bogon network numbers. Some of this you already are preventing because internal routers will not forward certain kinds of traffic, such as multicasts, unless you have configured a multicast routing protocol. However, many network administrators set up a default route to route traffic to destinations that routers do not have in their routing tables. You definitely do not want a default route routing traffic to unassigned addresses. Therefore, you either can filter this in the egress filter, denying the bogon destination addresses and placing these statements before your permit statement, or you can use a static route for these bogon networks and point it to a null interface, commonly called black hole routing (I discuss this latter option in Chapter 15).
Internal Spoofing AttackI once dealt with a company that forgot to filter destination bogon addresses from internal machines. A hacker was able to compromise one of these devices and began flooding traffic to 169.254.0.0/16, a bogon network. The routers routed this to the default gateway (perimeter) router and then out to the ISP. Besides saturating the Internet link, the company got a nasty call from the ISP asking why it was bombarding the ISP access router with bogon traffic. It took a couple of hours to figure out which internal machine was compromised and to boot out the hacker. In the mean time, the company immediately fixed its egress ACL to block this kind of traffic. One difficulty that it had in tracking the hacked device was that the hacker was using both source and destination address spoofing, continually changing his source IP address to a range of valid IP addressed used in the network. From an analytical view, that was pretty cool to see in action, but it was a real pain in tracking down the culprit device. |
Example 7-24 shows a sample ACL to prevent traffic from being sent to bogon addresses for your egress filter, as well as to prevent spoofing attacks with bogon addresses as the source IP address in the packet header.
Example 7-24. Using an Egress Filter to Block Bogons
Router(config)# ip access-list extended egress-filter Router(config-ext-nacl)# remark Unassigned IANA addresses Router(config-ext-nacl)# deny ip any 1.0.0.0 0.255.255.255 Router(config-ext-nacl)# deny ip any 2.0.0.0 0.255.255.255 Router(config-ext-nacl)# deny ip any 5.0.0.0 0.255.255.255 Router(config-ext-nacl)# deny ip any 7.0.0.0 0.255.255.255 Router(config-ext-nacl)# deny ip any 23.0.0.0 0.255.255.255 Router(config-ext-nacl)# deny ip any 27.0.0.0 0.255.255.255 <--output omitted--> Router(config-ext-nacl)# remark RFC 1918 private addresses Router(config-ext-nacl)# deny ip any 10.0.0.0 0.255.255.255 Router(config-ext-nacl)# deny ip any 172.16.0.0 0.15.255.255 Router(config-ext-nacl)# deny ip any 192.168.0.0 0.0.255.255 Router(config-ext-nacl)# remark other bogons Router(config-ext-nacl)# deny ip any 224.0.0.0 15.255.255.255 Router(config-ext-nacl)# deny ip any 240.0.0.0 15.255.255.255 Router(config-ext-nacl)# deny ip any 0.0.0.0 0.255.255.255 Router(config-ext-nacl)# deny ip any 169.254.0.0 0.0.255.255 Router(config-ext-nacl)# deny ip any 192.0.2.0 0.0.0.255 Router(config-ext-nacl)# remark block bogons as source addresses Router(config-ext-nacl)# deny ip 1.0.0.0 0.255.255.255 any Router(config-ext-nacl)# deny ip 2.0.0.0 0.255.255.255 any Router(config-ext-nacl)# deny ip 5.0.0.0 0.255.255.255 any Router(config-ext-nacl)# deny ip 7.0.0.0 0.255.255.255 any Router(config-ext-nacl)# deny ip 23.0.0.0 0.255.255.255 any Router(config-ext-nacl)# deny ip 27.0.0.0 0.255.255.255 any <--output omitted--> Router(config-ext-nacl)# remark Internal networks--allow out Router(config-ext-nacl)# permit ip 200.1.1.0 0.0.0.255 any Router(config-ext-nacl)# deny ip any any Router(config-ext-nacl)# exit Router(config)# interface ethernet1 Router(config-if)# ip access-group egress-filter out
As you can see from the ingress and egress filters, there are a lot of ACL statements. However, these statements prevent only certain kinds of DDoS attacks. You still have a lot of ACL statements to add to prevent other types of attacks, so do not relax yet. Note that in Example 7-24, I have cut out some of the ACL commands for bogon filtering (<--output omitted-->) for brevity sake.
NOTE
Cisco IOS routers also support another solution to deal with certain kinds of address spoofing: IP unicast reverse-path forwarding verification. This provides a more efficient process in filtering spoofed packets, but it also has disadvantages. I discuss this feature in Chapter 15.
DoS and Distributed DoS Attacks
As discussed in Chapter 1, denial-of-service (DoS) attacks attempt to limit the operation of a device, possibly even causing it to crash. DoS attacks come in many flavors and can use different protocols, such as ICMP, TCP, and UDP. This section discusses some of the most common types of DoS attacks and what you can do with ACLs to prevent or, at a minimum, limit your exposure.
TCP SYN Floods
As I briefly discussed in Chapter 1, TCP SYN flood attacks are a type of DoS attack that attempts to overwhelm a resource with TCP connection requests. In this instance, the hacker typically uses either real or spoofed source IP addresses. In this kind of attack, the hacker floods a device with TCP SYN segments, with no intention of completing the connection.
I already discussed how you can prevent spoofing with ACLs. If the hacker is using a real IP address, the hacker's software basically ignores the SYN/ACK message that the service responds with. This section discusses why you cannot use an ACL to limit your exposure to a TCP SYN flood attack.
Unfortunately, an ACL solution is not fancy and does not provide much protection. Consider the network previously shown in Figure 7-5 for this example, which illustrates the limitations that ACLs have with TCP SYN flood attacks. Example 7-25 shows a snippet of code dealing with the TCP SYN flood issue.
Example 7-25. Attempting to Use ACLs to Deal with TCP SYN Floods
Router(config)# ip access-list extended tcp-syn-flood Router(config-ext-nacl)# permit tcp any 200.1.1.0 0.0.0.255 established Router(config-ext-nacl)# permit tcp any host 200.1.1.11 eq 25 <--output omitted--> Router(config-ext-nacl)# deny ip any any Router(config-ext-nacl)# exit Router(config)# interface ethernet1 Router(config-if)# ip access-group tcp-syn-flood in
In this example, the configuration focuses on only the TCP SYN flood problem. Obviously, many other statements are needed in this ACL. The first permit command basically allows returning traffic from internal TCP connection requests to outside resources. Remember my warning about using the established parameter: It does not implement a stateful firewall function, so a hacker can take advantage of this and use a different type of TCP flood attack by setting the appropriate control flags in the TCP segment header, such as ACK. This provides only limited protection to network 200.1.1.0/24. However, the second statement poses more problems. Because you want to allow Internet users access to specific resources, such as an e-mail server, you must let TCP SYNs into your network.
CAUTION
Unfortunately, there is no way that an extended ACL can prevent a TCP SYN flood attack to the e-mail server in this example. However, you can use other Cisco IOS features, such as TCP Intercept and CBAC inspection, which both are covered in Chapter 17, "DoS Protection."
Smurf and Fraggle Attacks
Smurf is a DoS attack that uses ICMP echos. The name Smurf is used because this was what the original hacker application was called. A hacker using Smurf uses two things that can create a massive DoS attack against your resources.
Smurf in Action
First, the hacker puts a directed broadcast into the destination field of the IP packet header. Directed broadcasts, unlike local broadcasts, are routable. Depending on the user's device, a directed broadcast can be either the first or the last address in a network or subnet. Typically, it is the last address. For example, with network 192.168.1.0/24, the directed broadcast address could be 192.168.1.0 or 192.168.1.255. Second, instead of using his own address as the source address of the packet, the hacker replaces it with the address of the device that he wants to attack. If the destination network or networks do not filter the directed broadcast, all the destinations on the segment of the directed broadcast respond with an echo reply to the source address in the packet (the victim).
Figure 7-6 illustrates the process of a Smurf attack. In this example, the hacker wants to attack the internal server (200.1.2.1). The attacker then finds a network that allows directed broadcasts into the network. This could be the same network (not likely) or another network connected to the Internet (most likely). The hacker then sends an ICMP echo with a destination-directed broadcast to the segment that will initiate the attack and puts a source address in the packet header of the actual victim (200.1.2.1). When the destinations on 200.1.1.0/24 receive the echo-directed broadcast, each device responds to the source address with an echo reply. These devices commonly are called reflectors because they are being used to reflect the attack to the actual victim. In this example, only three user devices?200.1.1.1, 200.1.1.2, and 200.1.1.3?send an echo reply to 200.1.2.1.
Figure 7-6. Smurf Attack
In the example in Figure 7-6, sending one echo and generating three echo replies is negligible?I would not even bat an eye about this attack. However, the hacker is not going to send one echo. Assume that, in this example, the hacker had a fractional T1 connection to the Internet, perhaps 512 kbps. He uses up all of his bandwidth sending directed broadcast ICMP echos to network 200.1.1.0/24. When these devices receive these, they respond by each generating 512 kbps of echo replies to the victim, resulting in 1.5 Mbps of echo replies flooding the internal server. The devices that respond to the echo requests commonly are called amplifiers because they generate x amount of more traffic than originally was sent to them, where x is the based on the number of devices in the network or subnet of the directed broadcast address. In this example, the server obviously is affected by this attack, but if it has a Fast Ethernet connection and a fast processor, the attack does not affect it that much.
However, most hackers typically use directed broadcast addresses from multiple networks. Consider a different example to illustrate how overpowering a Smurf attack can be. In this example, the hacker is using 512 kbps of bandwidth. Assume that the hacker has found three networks on the Internet that allow amplifiers (responses to directed broadcasts). Each of these network segments has 100 hosts. The hacker splits up his echo requests by sending an equal portion (about 170 kbps) to each of these amplified segments. Each host on these segments (300 in total) responds to the victim. The victim, unfortunately, is clobbered with 300 sets of echo replies at 170 kbps each, resulting in more than 51 Mbps of echo replies to the server. The server definitely will feel this. As you can see in this example, through amplification, a hacker easily can flood a network.
NOTE
Interestingly enough, Internet Relay Chat (IRC) servers are the devices most often hit with these kinds of attacks. This is probably because the hacker was banned from the server for inappropriate language or actions. Hackers like to hang out on these servers, and the hacker responds with this simple yet efficient attack. Note that in this attack there are two victims: the amplifiers and the victim, who takes the biggest brunt of the assault.
Attack Prevention
Fraggle is very similar to Smurf, but it uses UDP echos instead of ICMP echos?basically, someone recoded Smurf to work with UDP. Given the huge impact that both of these two programs have, you might be wondering what you can do to prevent these kinds of massive attacks. You can do five basic things to limit the affect of this kind of attack:
Shut down networks with amplifiers.
Disable directed broadcast addresses.
Perform ingress and egress filtering of directed broadcast addresses.
Perform rate limiting through CAR. This does not prevent the attack, but it does limit the amount of bandwidth that the ICMP and UDP echos (or replies) can use. CAR is discussed further in Chapter 17.
Use IP unicast reverse-path forwarding verification to prevent IP spoofing. This feature is covered in Chapter 15.
RFC 2267 discusses these solutions in a general sense. The best solution to this problem is to have all networks connected to the Internet block directed broadcast traffic. You would think that everyone already is doing this, but you would be making a bad assumption. To see a list of networks that are known amplifiers, visit http://www.netscan.org. You will find that more than 8600 networks (at the time of this writing) support amplification. As you can see, until every ISP and network administrator takes this problem seriously, these kinds of amplification attacks will not disappear.
Second, you want to make sure that your network is not one of the networks that support amplification; you do not want hackers to use your network to instigate a Smurf or Fraggle attack. To prevent amplification, you can do few things. For Fraggle, disable TCP and UDP small servers on all the routers in your network. I discussed how to do this in Chapter 4. For Smurf, you can do one of two things (preferably both). I discuss these in the next two sections.
TIP
You can test whether you are an amplifier by going to http://www.powertech.no/smurf, which scans your network for amplification.
Disable Directed Broadcasts
First, on all your routers, disable directed broadcast processing. This is done by going into each router and, on each interface, disabling directed broadcasts with the no ip directed-broadcast command. If you miss a router or an interface on a router, directed broadcasts typically will be forwarded by other routers. For example, assume that you have a network, 192.168.1.0/24, that is subnetted into four networks: 192.168.1.0/26, 192.168.1.64/26, 192.168.1.128/26, and 192.168.1.192/26. All routers connected to these subnets understand what addresses are host addresses and what are broadcast addresses; however, you might have other routers in your network that are connected not to these subnets, but to others, such as 192.168.2.0/24, 192.168.3.0/24, and so on. These routers do not understand the subnetting of the 192.168.1.0/24 network unless you use a routing protocol that supports VLSM and is not performing summarization. Therefore, if you miss even one router's interface in your network with the no ip directed-broadcast command, you might accidentally make yourself an amplifier.
As of Cisco IOS 12.0, this is the default configuration on a Cisco router's interface: Directed broadcasts are disabled. I know of only one situation in which using the directed broadcast option is valid: In a network where Samba (an SMB server for UNIX) or NT is used, some stations use a directed broadcast to find resources on remote segments. Disabling directed broadcasts breaks connectivity. The fix for this is to implement WINS instead of using directed broadcasts.
Filter Directed Broadcasts
The second filtering solution that you want to implement is ingress and egress filtering. Sometimes you can get away with a simple filter such as the one in Example 7-26.
Example 7-26. Using an ACL to Block Smurf and Fraggle
Router(config)# ip access-list extended smurf-fraggle Router(config-ext-nacl)# deny icmp any any echo Router(config-ext-nacl)# deny icmp any any echo-reply Router(config-ext-nacl)# deny udp any any eq echo Router(config-ext-nacl)# deny udp eq echo any Router(config-ext-nacl)# remark --> add your other ACL statements here as necessary Router(config-ext-nacl)# deny ip any any Router(config-ext-nacl)# exit Router(config)# interface ethernet1 Router(config-if)# ip access-group smurf-fraggle in Router(config-if)# ip access-group smurf-fraggle out
In this example, the first two deny statements drop all ICMP echos and echo requests. The second two deny statements drop all UDP echo requests. The problem with the first two deny statements is that this means you cannot get back any echo replies for testing. Therefore, you might want to tweak this configuration by allowing echo replies only to certain internal management devices.
The second solution is to use an extended ACL to filter all directed broadcast addresses. This can be a cumbersome task, especially if you have many subnets in your network. Using Figure 7-5 as an example, this is easy: Just block 200.1.1.0 and 200.1.1.255. Example 7-27 shows how to block these directed broadcast addresses.
Example 7-27. Using an ACL to Block Directed Broadcast Addresses
Router(config)# ip access-list extended no-broadcasts-in Router(config-ext-nacl)# remark This command prevents spoofing Router(config-ext-nacl)# deny ip 200.1.1.0 0.0.0.255 any Router(config-ext-nacl)# remark These two commands block directed broadcast addresses Router(config-ext-nacl)# deny ip any host 200.1.1.0 Router(config-ext-nacl)# deny ip any host 200.1.1.255 Router(config-ext-nacl)# remark --> add your other ACL statements here as necessary Router(config-ext-nacl)# deny ip any any Router(config-ext-nacl)# exit Router(config)# ip access-list extended no-broadcasts-out Router(config-ext-nacl)# deny ip any host 200.1.1.0 Router(config-ext-nacl)# deny ip any host 200.1.1.255 Router(config-ext-nacl)# deny ip host 200.1.1.0 any Router(config-ext-nacl)# deny iphost 200.1.1.255 any Router(config-ext-nacl)# remark --> add your other ACL statements here as necessary Router(config-ext-nacl)# deny ip any any Router(config-ext-nacl)# exit Router(config)# interface ethernet1 Router(config-if)# ip access-group no-broadcasts-in in Router(config-if)# ip access-group no-broadcasts-out out
In this example, I am filtering directed broadcasts in both directions on the public interface of the router in Figure 7-5. The first statement in the first ACL prevents spoofing of internal addresses by an Internet hacker. The second and third statements drop any traffic destined to the two internal broadcast addresses. In the second ACL, there are two sets of commands. The first two prevent your devices from sending directed broadcasts to the Internet?basically, from becoming the victim (reflector) of an amplification attack. The second two statements prevent your devices from generating packets with source-directed broadcast addresses, just in case the hacker is inside your network and wants to trick someone on the outside into sending stuff back into your network. As you can see, in a simple one-segment network, you have to set up a few filtering rules. In a large network, however, you might have a few hundred networks or subnets, which equates to twice as many filtering statements.
TIP
Even though each deny statement is not necessary (in other words, you probably could accomplish the same thing without all of these statements in your ACL), I typically place these commands in the ACL so that, when using the show access-lists command, I can see the number of matches. If they are incrementing rapidly, I know that I am the amplifier or victim of a Smurf (or Fraggle) attack. I discuss this further in the next subsection.
Are You Being Attacked?
To determine whether you are under attack, use the show access-lists command, which shows you the number of matches on a statement. If you see one of these deny statements incrementing extremely fast, you are under attack. If you see the ICMP echos incrementing, someone is trying to use you as an amplifier. If you see the ICMP echo replies incrementing, you are the intended victim. By adding the log-input parameter to the deny ACL statement(s) from the last section, you can see from which interface the packets are coming from. Here is an example of this output using the network shown in Figure 7-2:
%SEC-6-IPACCESSLOGDP: list smurf-fraggle denied icmp
200.1.1.1 (Ethernet0) -> 199.1.1.1 (0/0), 1 packet
%SEC-6-IPACCESSLOGDP: list smurf-fraggle denied icmp
200.1.1.2 (Ethernet0) -> 199.1.1.1 (0/0), 1 packet
%SEC-6-IPACCESSLOGDP: list smurf-fraggle denied icmp
200.1.1.3 (Ethernet0) -> 199.1.1.1 (0/0), 1 packet
In this example, you can see that network 200.1.1.0/24 (off Ethernet0) is acting as the amplifier and is sending echo replies to the victim (199.1.1.1). In this case, the administrator now knows that he is the amplifier and can set up the necessary measures to prevent this in the future. However, if someone else was the amplifier, you could use the whois database to find the names of the administrators of the amplifiers, contact them, and hope that they will help you by fixing their security hole. It is important to remember that the amplifiers are typically ignorant victims?they do not realize that they are amplifiers causing mayhem with other people's networks. Therefore, you should be as courteous as possible.
TIP
When under attack, you first need to determine whether you are the amplifier. If you are the amplifier, contact your ISP and try to determine where the packets are coming from. In some rare instances, you might be able to track the attack back to a specific ISP, which, in turn, might be able to find the attacker; this is a really slim chance, but you might as well try. Next, find out what internal network is amplifying and prevent this with the methods I already have discussed.
If you are the victim, implement CAR to reduce the amount of amplified traffic. Contact your ISP and have it do the same thing. You can use the whois database registry to determine who the amplifiers are (based on the source IP address in the echo replies). This database officially is called the Internet Routing Registry (IRR). In the Europe, visit http://www.ripe.net/whois. In Asia-Pacific, visit http://www.apnic.net/. In the United States and the rest of the world, visit http://www.arin.net/whois. These databases list contact information of companies and ISPs that are assigned IP addresses. Contact the administrators of the source addresses in the attack and notify them that they are amplifiers. Have your ISP do the same thing. Sometimes pressure from multiple sources works better when dealing with the amplifier.
NOTE
One question that I commonly am asked is whether you can track down the hacker who instigated the Smurf or Fraggle attack. Unfortunately, in most cases, you will not be able to do this. To ultimately solve this problem, ISPs and the networks that connect to those ISPs need to perform filtering to prevent IP spoofing. When everyone performs this, almost all IP spoofing tasks will be a historical footnote in the history books.
Simple Reconnaissance Attacks
Many network threats begin with a reconnaissance attack. In a reconnaissance attack, the hacker tries to illicit information about your network, including what IP addresses are in use. Two very basic tools that are useful in this situation are ping and traceroute. Ping, which uses ICMP messages, is useful in testing connectivity, but it also can help a hacker learn what devices are reachable (and hackable) in your network. Therefore, you should limit what types of ICMP messages are allowed in and out of your network.
Ingress Filtering of ICMP Traffic
This next example uses the network in Figure 7-5 to illustrate how to restrict ICMP traffic from entering your network. For ingress filtering, you should at least configure Example 7-28 in your ingress filter.
Example 7-28. Restricting ICMP Traffic with an Ingress Filter
Router(config)# ip access-list extended ICMP-in Router(config-ext-nacl)# remark <permit or deny other traffic> Router(config-ext-nacl)# remark <put these statements here> Router(config-ext-nacl)# deny icmp any any echo Router(config-ext-nacl)# deny icmp any any redirect Router(config-ext-nacl)# deny icmp any any mask-request Router(config-ext-nacl)# permit icmp any host 200.1.1.5 echo-reply Router(config-ext-nacl)# deny icmp any any echo-reply Router(config-ext-nacl)# permit icmp any 200.1.1.0 0.0.0.255 Router(config-ext-nacl)# remark <permit or deny other traffic> Router(config-ext-nacl)# remark <put these statements here> Router(config-ext-nacl)# exit Router(config)# interface ethernet1 Router(config-if)# ip access-group ICMP-in in
In this example, the first ACL statement blocks ICMP echos, which is also useful in preventing DoS attacks such as Smurf. The second ACL statement blocks ICMP redirects. As you recall from Chapter 4, this also can be done with the no ip redirects command. One issue with this command is that it needs to be configured on all interfaces of all routers on which redirect attacks are possible. Some hackers use redirect messages to corrupt routing information. The third deny statement prevents subnet mask requests. Hackers can use this message to learn what subnets you have, including the directed broadcasts of these addresses. When this is known, the hacker can implement a DoS Smurf or Fraggle attack.
The first permit statement in this ACL allows echo reply messages to be sent only to the administrator's PC?this is necessary so that the administrator can test connectivity to devices on the Internet, but no one else can (the deny statement after the permit). By doing this, you are dropping traffic from amplifiers in a Smurf attack. Following this, the second permit statement allows remaining ICMP traffic into the internal network. In this example, all other ICMP messages can be sent to the any of the devices in 200.1.1.10/24. You can be more restrictive than this, but certain message types, such as a parameter problem, a packet that is too big, and others, are needed to ensure that traffic can be sent between certain devices.
Egress Filtering of ICMP Traffic
Besides filtering traffic in the ingress direction, you want to restrict egress ICMP traffic, especially to prevent someone inside your network from executing an attack against an outside destination. You should permit certain ICMP message types so that connections can be established between certain devices. Again, this example uses Figure 7-5 to illustrate the configuration of an egress filter, which is displayed in Example 7-29.
Example 7-29. Restricting ICMP Traffic with an Egress Filter
Router(config)# ip access-list extended ICMP-out Router(config-ext-nacl)# remark <permit or deny other traffic> Router(config-ext-nacl)# remark <put these statements here> Router(config-ext-nacl)# permit icmp host 200.1.1.5 any echo Router(config-ext-nacl)# permit icmp 200.1.1.0 0.0.0.255 any parameter-problem Router(config-ext-nacl)# permit icmp 200.1.1.0 0.0.0.255 any packet-too-big Router(config-ext-nacl)# permit icmp 200.1.1.0 0.0.0.255 any source-quench Router(config-ext-nacl)# deny icmp any any Router(config-ext-nacl)# remark <permit or deny other traffic> Router(config-ext-nacl)# remark <put these statements here> Router(config-ext-nacl)# exit Router(config)# interface ethernet1 Router(config-if)# ip access-group ICMP-out out
In this example, the first permit statement allows the management station (200.1.1.5) to send echo messages, through ping, to test connectivity to devices on the Internet. The second permit statement allows internal devices to send problems with packet headers to devices on the Internet sending traffic inbound. The packet-too-big parameter in the permit statement allows MTU discovery along the path between the source and destination, and the source quench statement allows devices to adapt to congestion. All other ICMP messages are dropped.
Traceroute
Traceroute traces the path of routers along the way to the destination. It is very useful in troubleshooting routing problems. However, hackers can use this to find what routers exist in your network. To prevent traceroute into your network, you need to block UDP ports 33,400 through 34,400, as in Example 7-30.
Example 7-30. Filtering Traceroute Traffic
Router(config)# ip access-list extended traceroute Router(config-ext-nacl)# remark <permit or deny other traffic> Router(config-ext-nacl)# remark <put these statements here> Router(config-ext-nacl)# deny udp any any range 33400 34400 Router(config-ext-nacl)# remark <permit or deny other traffic> Router(config-ext-nacl)# remark <put these statements here> Router(config-ext-nacl)# exit Router(config)# interface ethernet1 Router(config-if)# ip access-group traceroute in
Because you cannot be sure what specific port traceroute uses, you must filter the range of ports, as shown in the previous deny statement.
If you are concerned about internal devices performing traceroute, you can use the same deny command listed previously in an egress filter; however, you need to allow the external replies to the traceroute queries. This can pose a problem because the source port used is a random one. Unfortunately, when using normal extended ACLs, you must open a large range of UDP ports to allow the returning traffic back into your network in your ingress filter. Therefore, if you want to deny external users from performing traceroute but want to allow a few internal users, I recommend a stateful firewall solution, such as reflexive ACLs (see Chapter 8) or CBAC (see Chapter 9).
Distributed DoS Attacks
In a distributed DoS attack, multiple sources are flooding traffic, whether it be ICMP, TCP control flag segments (such as SYN), or UDP floods. This can be something as simple as a hacker sending multiple streams of directed broadcasts to different subnets and having those subnets respond with echo replies to the victim. However, many DDoS attacks are much more sophisticated than the simple Smurf or Fraggle attacks.
NOTE
This section covers only the most common types of DDoS attacks. For more information about DDoS attacks, visit the Packet Storm website: http://packetstormsecurity.nl/distributed/. The site has a comprehensive list of DDoS attacks, as well as the tools that hackers user to execute these attacks.
DDoS Components
Most DDoS attacks contain three components:
Client
Handler
Agent
The client is the hacker who is orchestrating the attack. A sophisticated hacker might have a partner or two who join in the process. The client controls one or more handlers. A handler is a compromised device that the hacker has gained unauthorized access to and has installed a special program on. This program allows the client to control this machine remotely. The client then downloads hacking programs to the handler to use in other attacks. Handlers control agents, which also are compromised devices with special programs installed. Handlers pass down hacking software to the agents that will be used in a DDoS attack. Basically, the hacker on the client sends messages to the handler, which then tells the agents (the troops) what and how to attack the victim.
DDoS Process
Figure 7-7 illustrates the components and how they work together. In this example, the hacker has compromised three devices and is using them as handlers. He communicates to them through a special control program and has downloaded the Smurf, Fraggle, TCP SYN flood, and unauthorized access programs to each. The hacker also has compromised many agents and has set up a control relationship between certain handlers and agents. For example, in Figure 7-7, Handler A controls Agent A1 and Agent A2. The hacker has decided to gain control of a victim and convert it to an agent. In this example, it is a web server. The hacker wants to hide this unauthorized access attack, so he sets up a DDoS attack that hopefully will hide his unauthorized attempts. He sends instructions to his handlers to execute the attack. Handler A is responsible for telling his agents to implement a Fraggle attack against the server, Handler B is responsible for telling his clients to implement a Smurf attack against the server, and Handler C is responsible for implementing a TCP SYN flood and an unauthorized attack through its controlled agents. The hacker is hoping that, through this massive flood of ICMP echo replies (Smurf), UDP echo replies (Fraggle), and the TCP SYN flood, the administrators of the web server (and its network) will be so overwhelmed dealing with this attack, especially with all of the security alarms going off, that the hacker quickly can execute an unauthorized access attack and gain access to the server unnoticed.
Figure 7-7. Common DDoS Attack
In reality, a hacker probably will use a feint attack, in which he centers his flood attack on one part of the network and tries to slip by to gain unauthorized access to other devices in the network. By gaining access to other devices, the hacker converts them to handlers and agents, expanding his DDoS army. If a hacker has compromised many hosts, it becomes very difficult to track down who actually is executing the attack, especially if the hacker can find networks that support amplification.
DDoS ExperienceMy first experience with a DDoS attack happened when I was performing consulting work for a company in the late 1990s. When it happened, it caught everyone off guard. No one, including myself, had ever seen anything like this. All of us thought that it was a coincidence that two Smurf attacks were happening simultaneously. But when this went from two to three and eventually up to eight networks (amplifiers) in the Smurf attack, we knew that something unusual was occurring. After examining the information on the CERT website, we realized that, besides distracting us with this huge flood of traffic, a hacker (or hackers) was trying to compromise some of our systems to join the DDoS army. This was one of my best learning experiences, especially seeing how the hacker was attempting to exploit security holes in certain systems that we were maintaining, how he was setting them up as handlers and agents, and how the handlers and agents communicated with each other. Besides being a hair-raising and hair-pulling experience, it was cool to see how well the hacker planned and executed his actions. |
The Five Main DDoS Attacks
Hackers use five main DDoS programs to implement their attacks:
Tribe Flood Network (TFN)
Tribe Flood Network 2K (TFN2K)
Trinoo
Stacheldraht
Trinity
When the hacker starts, he attempts to find devices that he can convert into handlers and agents. To do this, he scans hundreds, if not thousands, of devices, looking for specific security flaws that will allow him to gain unauthorized access. Typically, he is looking for SUN UNIX or Linux devices. When he finds devices with the security flaw, his specialized scanning software automatically executes a script that gains unauthorized access to the system and downloads the handler and agent programs, as well as any attack programs that he deems necessary. When he finds a susceptible device, breaking in and compromising the device takes less than a handful of seconds. The compromised host then does the same thing that the hacker was doing: It begins to scan and look for hosts that it can compromise. This process is repeated in the same way. As you can see from this process, in a short time, the hacker can build an army of devices. I have heard of stories of a hacker adding more than 2200 machines to his DDoS army in less than an hour, which is amazing (but not funny if you are the victim).
TFN
Two varieties of TFN exist: TFN and TFN2K. TFN is a DDoS program that was developed by a German hacker in mid-1999. When it spreads, the clients are capable of launching all types of DoS attacks, including ICMP, UDP floods, TCP SYN floods, and Smurf attacks.
After TFN is installed, the hacker can use a variety of connection methods to control the clients, including Telnet. Communication between the compromised devices is done with ICMP echo messages, in which specific header fields and the data payload contain the "instructions" for what is to be done or pass basic status information. Encryption is optional for hiding the contents, but if it is used, it is very weak.
Because ICMP echo reply messages are the heart of the TFN communication system, detecting this attack is difficult. The best way to block TFN is to restrict the flow of ICMP echo reply packets. Again, this example uses the network in Figure 7-5. Example 7-31 shows a basic ACL configuration to block this traffic.
Example 7-31. Blocking TFN with ACLs
Router(config)# ip access-list extended TFN-in Router(config-ext-nacl)# rem
