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:

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^[350]—you cannot depend on the source IP address in the packet being correct.

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:

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.

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.^[351]

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:

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.