25.3.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, many intentional. The result of these floods can cause your system to be so busy servicing interrupt requests and network packets that it is unable to process regular tasks in a timely fashion. Many requests will be thrown away as there is no room to queue them. If it is a TCP-based service, they will be resent and will add to the load. Such attacks can also mask an attack on another machine by preventing audit records and remote login requests from being processed in a timely manner. They deny access to a particular service.

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 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 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.

Unfortunately, there is little that you, as an end user or administrator, can do to help make the protocols and daemons more robust in the face of such attacks. The best you can hope to do, at present, is to limit their effect. Partitioning your local network into subnets of only a few dozen machines each is one good approach. That way, if one subnet gets flooded as part of an attack or accident, not all of your machines are disabled.

Another action you can take is to prepare ahead of time for an attack. If you have the budget, buy a network monitor and 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.

One partial help is if the service being attacked is spawned from the inetd with the nowait option. inetd, by default, has 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 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.

25.3.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 an attacker writes a program that literally bombards an NIS server machine with thousands of echo requests every second 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.[11]

[11] Yes, we are leaving out some low-level details here. This form of masquerade is not as simple as we describe it, but it is possible.

A similar type of attack is a broadcast storm. By careful crafting of 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. Broadcast storms rarely result from intentional attack; more often, they result from failing hardware or from software that is under development, buggy, or improperly installed.

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.

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.

25.3.3 Signal Grounding

Physical methods can also be used to disable a network. Grounding the signal on a network cable, introducing some other signal, or removing an Ethernet terminator all have the effect of 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 master machines across the network. For this reason, you should be suspicious of any network outage; it might be masking break-ins on individual machines.

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 eavesdroppers and spoofers to well-defined points on the cable. It also helps reduce the risk of denial of service attacks from signal grounding. Chapter 12, Physical Security, discusses the physical protection of networks.

25.3.4 Clogging

The implementation of the TCP/IP protocols on many versions of UNIX allow them to be abused in various ways. To deny service, one way 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 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).

By analogy, consider what happens when your phone rings. You answer and 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 is little you can do in these situations. Modifications to the operating system sources could result in a tunable time-out, better logging of these problems, and a higher limit on the number of half-open connections allowed before new requests are rejected. However, these modifications are not simple to make.

Firewalls generally do not address this problem either. The best you can achieve is to reject connection attempts from unknown hosts and networks at the firewall. The only other alternative is to rethink the protocols involved, and perhaps set much higher limits on the existing implementations. However, any finite limit can be exceeded. Networks based on virtual circuits (e.g., ATM) may provide a solution by bypassing the protocol problems completely. However, ATM and related technologies probably have their own set of vulnerabilities that we have yet to discover.