24.4 Network Denial of Service Attacks

Networks are also vulnerable to denial of service attacks. In attacks of this kind, someone prevents legitimate users from using the network. The three common types of network denial of service attacks are service overloading, message flooding, and signal grounding, or jamming. A fourth kind of attack, SYN flood attacks (which we call clogging) is less common, but possible.

24.4.1 Service Overloading

Service overloading occurs when floods of network requests are made to a server daemon on a single computer. These requests can be initiated in a number of ways, both accidental and intentional. Service overloading can have many results:

Your system can become so busy servicing interrupt requests from incoming network packets that it is unable to perform other tasks in a timely fashion. Many requests will be thrown away as there is no room to queue them. Invariably, the legitimate requests will be resent, further adding to your computer's load.
If a service that causes a daemon to fork( ) or otherwise start a new process is under attack, your system may spawn so many new processes that it has no process table entries remaining to perform useful work.
If a service that allocates significant amounts of memory is under attack, your server may run out of swap space.
If a service that performs a large amount of computation is under attack, your server may not have sufficient CPU resources available to perform other tasks.

The overload caused by an overloading attack may be the ultimate goal of the attacker. Alternatively, the attack may be planned to mask an attack somewhere else. For example, a machine that records audit records may be attacked to prevent a login or logout from being logged in a timely manner. The overloading attack may be staged merely to distract management's attention or clog communications lines while something else, such as a car bombing, is taking place.

You can use a network monitor to reveal the type, and sometimes the origin, of overload attacks. If you have a list of machines and the low-level network address (i.e., Ethernet board-level address, not IP address), this may help you track the source of the problem if it is local with regards to your network. Isolating your local subnet or network while finding the problem may also help. If you have logging on your firewall or router, you can quickly determine if the attack is coming from outside your network or inside^[10]—you cannot depend on the source IP address in the packet being correct.

^[10] We are unaware of any firewall offering reliable protection against denial of service attacks of this kind.

Although you cannot prevent overload attacks, there are many measures that you can take to limit their damage or make your system more robust against them:

Prepare for the attack: Install monitoring, logging, and other analysis systems so that if an attack takes place, you will be able to rapidly diagnose the type of attack and, we hope, the source. Have (protected) spare taps on your subnet so you can quickly hook up and monitor network traffic. Have printed lists of machine low-level and high-level addresses available so you can determine the source of the overload by observing packet flow.
Partition your network into multiple subnets: This way, if one subnet is flooded as part of an attack or accident, not all of your machines are disabled.
Provide for multiple Internet connections to your organization: These connections may include some that are not advertised but are kept in reserve.
Use a modern version of the inetd daemon: Such versions, by default, have a "throttle" built in. If too many requests are received in too short a time for any of the services it monitors, it will start rejecting requests and send syslog a message that the service is failing. This is done under the assumption that some bug has been triggered to cause all the traffic. This has the side-effect of disabling your service as surely as if all the requests were accepted for processing. However, it may prevent the server itself from failing, and it results in an audit record showing when the problem occurred. Throttling options available in inetd are summarized in Table 24-2.

Table 24-2. Throttling options available when invoking the inetd daemon
Option	Purpose
-c `maximum`	Specifies the maximum number of simultaneous invocations allowed for each service. This may be overridden on a per-service basis by specifying the max-child option in the configuration file /etc/inetd.conf.
-C `rate`	Specifies the maximum number of connections that will be allowed from each IP address within a minute. This may be overridden on a per-service basis by specifying the "max-connections-per-ip-per-minute" option in the inetd configuration file.
-R `rate`	Specifies the maximum number of times that a service can be invoked in a minute. The default is 256. A rate of 0 disables this check.

DDoS attacks

Although this chapter is about all kinds of denial of service attacks, the most pernicious network attacks are distributed denials of service (DDoS) attacks.

In a DDoS attack, the attacker overloads network services or floods the network with messages, but does so from a large number of different attack hosts distributed around the Internet. Because the attack packets do not come from a single system, it is difficult to block them with a packet filtering firewall without cutting off your hosts from the whole of the Internet.

DDoS attacks are usually coordinated through slave processes (zombies or Trojans) installed in compromised hosts that allow the attacker to remotely direct the hosts to attack a target. A key to preventing DDoS attacks (and potential liability) is keeping your systems protected from compromise so that they can not be used as zombies in further attacks. At the network level, implementing ingress and egress filtering to prevent packets with bogus source addresses from leaving the local network can prevent local machines from participating in DDoS attacks. This strategy is discussed in RFC 2827.

However, DDoS attacks do not require the use of special software on the intermediate system. One form of DDoS attack involves simply sending ICMP echo ("ping") messages with forged source addresses to many computers around the Internet. The ICMP echo messages are returned to the victim computer. Another version simply initiates a number of TCP connection attempts from nonexistent IP addresses. The target machine consumes resources initiating and verifying the connection attempt, which can paralyze a machine if enough requests come in.

Sometimes a DDoS attack can be defeated in progress by changing the IP address and hostname of the machine being attacked. If the attack software is using a hardcoded victim address or hostname, changing these can protect the victim host, and packets directed at the old address can be filtered at the external router or by the organization's ISP.

One of the best known DDoS attacks took place in February 2000 and targeted web servers at high-profile companies, including Amazon and Yahoo. An analysis of trinoo, the Trojan that was used to compromise and control the zombies that participated in the attack, can be found at http://www.sans.org/resources/idfaq/trinoo.php.

Make sure the limits specified in your configuration file are reasonable

For example, if you are running the Apache web server, a sudden increase in the amount of requests to your server can cause a large number of http processes to be fork( )ed off. The total number of simultaneous connections is controlled by the parameter MaxClients in the Apache configuration file httpd.conf.

Many Apache distributions have MaxClients set at the value of 200, meaning that a maximum of 200 separate http processes might exist. If each httpd process has a memory of 8 MB, that could conceivably take 1.6 GB of swap space. On the other hand, if each http process takes 20 MB, then you would need 40 GB of swap space—probably more than your system has.

24.4.2 Message Flooding

Message flooding occurs when a user slows down the processing of a system on the network, to prevent the system from processing its normal workload, by "flooding" the machine with network messages addressed to it. These may be requests for file service or login, or they may be simple echo-back requests. Whatever the form, the flood of messages overwhelms the target, so it spends most of its resources responding to the messages. In extreme cases, this flood may cause the machine to crash with errors or lack of memory to buffer the incoming packets. This attack denies access to a network server.

A server that is being flooded may not be able to respond to network requests in a timely manner. An attacker can take advantage of this behavior by writing a program that answers network requests in the server's place. For example, an attacker could flood an NIS server and then issue his own replies for NIS requests—specifically, requests for passwords.

Suppose that an attacker writes a program that bombards an NIS server machine every second with thousands of echo requests directed to the echo service. The attacker simultaneously attempts to log into a privileged account on a workstation. The workstation would request the NIS passwd information from the real server, which would be unable to respond quickly because of the flood. The attacker's machine could then respond, masquerading as the server, and supply bogus information, such as a record with no password. Under normal circumstances, the real server would notice this false packet and repudiate it. However, if the server machine is so loaded that it never receives the packet, or fails to receive it in a timely fashion, it cannot respond. The client workstation would believe the false response to be correct and process the attacker's login attempt with the false passwd entry.

A similar type of attack is a broadcast storm. By carefully crafting network messages, you can create a special message that instructs every computer receiving the message to reply or retransmit it. The result is that the network becomes saturated and unusable. Prior to the late 1990s, broadcast storms almost always resulted from failing hardware or from software that was under development, buggy, or improperly installed. Today, most broadcast storms are intentional; examples include the so-called smurf and fraggle attacks.

Broadcasting incorrectly formatted messages can also bring a network of machines to a grinding halt. If each machine is configured to log the reception of bad messages to disk or console, they could broadcast so many messages that the clients can do nothing but process the errors and log them to disk or console.

Once again, preparing ahead with a monitor and breaking your network into subnets will help you prevent and deal with this kind of problem, although such planning will not eliminate the problem completely. In addition, some packet-filtering firewalls (separate appliances or incorporated within the Unix kernel of each server) can perform connection rate throttling to reduce the impact of these kinds of attacks.

It is important that all routers and firewalls be correctly configured to prevent the forwarding of broadcast packets from unauthorized hosts. Check your vendor documentation for information on how to do this. CERT/CC advisory CA-1998-01, available from its web site, provides details on how to configure many common systems to stop such forwarding.

Finally, border routers should be equipped with egress filters so that they will not send packets out of a network unless the packet has a valid source IP address located within the network. Most attack software that initiates denial of service attacks use randomly generated source addresses to decrease the likelihood that they will be intercepted. As a result, egress filters will frequently stop computers within your network from participating in distributed denial of service attacks—and if they are still involved, it will make it much easier to trace them because the attack packets will have proper return addresses.

24.4.3 Signal Grounding and Jamming

Physical attacks can also be used to disable a network.

Networks based on actual Ethernet coaxial cable (as opposed to twisted pairs of copper wire) are susceptible to signal-grounding attacks. Such attacks involve grounding the signal on a network cable, introducing some other signal, or removing an Ethernet terminator. Each of these attacks results in preventing clients from transmitting or receiving messages until the problem is fixed. This type of attack can be used not only to disable access to various machines that depend on servers to supply programs and disk resources, but also to mask break-in attempts on machines that report bad logins or other suspicious behavior to audit machines on the network. For this reason, you should be suspicious of any network outage—it might be masking break-ins on individual machines. And indeed, the susceptibility of traditional Ethernet to these kinds of problems is one of the reasons that coax-based networks have been largely superseded by networks based on twisted pair.

Another method of protection, which also helps to reduce the threat of eavesdropping, is to protect the network cable physically from tapping. This protection reduces the threat of eavesdropping and spoofing to well-defined points on the cable. It also helps reduce the risk of denial of service attacks from signal grounding, as well as reduce the chance that the fiber or cable might be cut. Chapter 8 discusses the physical protection of networks.

Wireless networks are susceptible to jamming. For example, a leaky microwave oven can effectively disrupt a wireless network based on the Wi-Fi (802.11) technology, as both microwave ovens and Wi-Fi systems use the same band of the 2.4 GHz spectrum.^[11]

^[11] This should make you feel more comfortable sitting next to an 802.11 base station—simply envision putting a raw egg in your microwave on "low power" for a few hours. Luckily, your internal organs aren't like an egg, right?

24.4.4 Clogging (SYN Flood Attacks)

The implementation of the TCP/IP protocols on many versions of Unix allow them to be abused in various ways. One way to deny service is to use up the limit of partially open connections. TCP connections open on a multi-way handshake to open a connection and set parameters. If an attacker sends multiple requests to initiate a connection ("SYN" packets) but then fails to follow through with the subsequent parts of the connection, the recipient will be left with multiple half-open connections that are occupying limited resources. Usually, these connection requests have forged source addresses that specify nonexistent or unreachable hosts that cannot be contacted. Thus, there is also no way to trace the connections back. They remain until they time out (or until they are reset by the intruder). Such attacks are often called SYN flood attacks or, more simply, clogging.

By analogy, consider what happens when your phone rings, and no one answers when you pick up. You say "Hello," but no one responds. You wait a few seconds, then say "Hello" again. You may do this one or two more times until you "time out" and hang up. However, during the time you are waiting for someone to answer your "Hello" (and there may be no one there), the phone line is tied up and can process no other incoming calls.

There are many solutions to the problems of SYN floods:

Some operating systems will automatically detect when they are being subjected to a SYN flood attack and will lower the timeout for SYN packets.
Alternatively, if the table of half-open connections is filled, the operating system can choose to randomly drop one of the entries from the table. As the table usually fills up only when the system is under attack, the odds are overwhelming that one of the attacker's SYN packets will be dropped.
Finally, the server can use SYN cookies. When SYN cookies are used, the SYN+ACK that is sent from the TCP server to the TCP client contains enough information for the server to reconstruct its half of the TCP connection, allowing the server to flush the original SYN from its tables. When the ACK is received from the client, the server reconstructs the original SYN, the TCP three-way handshake connection is completed, and the connection starts up. This effectively makes TCP setup a stateless process.
SYN cookies were invented by Daniel Bernstein and are described in detail at http://cr.yp.to/syncookies.html. A SYN cookies implementation is included with the FreeBSD and Linux systems. The Linux SYN cookies must be specially enabled with this command:
```
echo "1" > /proc/sys/net/ipv4/tcp_syncookies
```
If you run a Linux system, you may wish to add this command to your startup scripts.
Many firewalls and routers have limits set in them to "throttle" the number of connections coming in. Check your vendor documentation.
Some operating systems allow you to change the queuing behavior for half-open connections. You can increase the size of the queue, and decrease the time before a half-open connection times out. Again, this is nonstandard in form, and some vendor versions require manipulation of kernel variables with a symbolic debugger. Thus, we aren't going to show specific examples (variables change, as do commands). Instead, if you are potentially a target, check with your vendor for specifics.

24.4.5 Ping of Death and Other Malformed Traffic Attacks

In the past, bugs in low-level network drivers have caused many systems to fail when presented with a single malformed packet or HTTP query. For example, the infamous "Ping of Death" caused both Windows and Unix systems to crash when they received an ICMP ping packet that was longer than a specific threshold value. Many networked devices, including printer servers, home firewalls, and even routers, have crashed when they are probed for IIS or Apache vulnerabilities.

In general, the only way to protect against this malformed traffic is to use a proxy firewall and be sure that your systems are properly updated.