Each network can support only a finite amount of network traffic at one time, and this amount is dependent upon a few factors: network speed, equipment types, and their performance. Common communication types of links from an ISP to an organization are ISDN, DSL, broadband (using cable modems), T1, and T3. These link types also reflect different bandwidth capabilities. Common Local Area Network (LAN) topologies use 10BASE-T and 100BASE-T. For further information about network bandwidth and speeds, see http://www.speedguide.net/Cable_modems/bandwidth.shtml.

Denial of service by bandwidth consumption occurs when the entire capacity of the network link is used. When the network bandwidth capacity is reached, new network data cannot be sent. This means new connections to the Internet, file servers, Web servers, email servers, or any other function that requires network communication will not work. Connections that are already established will slow to a crawl, freeze, or be disconnected.

Attacks against bandwidth can occur via specialized attack programs and the misconfiguration of network equipment. The programs used to cause denial of service are discussed later in this chapter in the section “Recent DoS Attacks.” Misconfiguration of network equipment includes any device that connects to the network, such as computer systems, routers, switches, and other devices.

Bandwidth attacks are active; the denial of service occurs only as long as the bandwidth is used fully. As soon as the attacking program stops sending data, or the device is configured properly, bandwidth again becomes available. Most network functionality will return to normal, except for a few connections that might need restarting.

Common attacks include protocol-based exploits that consume network bandwidth by sending crafted network data. The access device, such as a router, can fail as it becomes inundated with more traffic than it can process. Another form of bandwidth attack relies on the reaction of network-connected systems and devices to specific network data. Many or all of the computers on the target network can be made to respond simultaneously to network traffic, such as IP broadcasts (IP packets that are sent to the broadcast address of a network instead of to a specific machine), thereby consuming all of the available bandwidth. The “Smurf” attack is one popular example of this form of attack. This and other forms are outlined in the section “Recent DoS Attacks.”

Like a network, each computer system also has a finite set of resources, including memory, storage, and processor capacities. Resource saturation is when all of one or more of these resources is used up, which leaves nothing for other applications. The SYN flood is a popular example of an attack that uses all the available networking resources on a system.

Each operating system that supports TCP/IP network connectivity has limitations on the number of connections that can be maintained at one time. The SYN flood exploits the three-way handshake of a TCP connection, which is outlined in Chapter 6, “A Brief TCP/IP Primer.” The SYN flood succeeds by creating “half-open” connections on the port on the target server. Half-open connections are those in which the three-way handshake is not completed. Normally, the handshake completes or times out, causing the connection to be deleted. Each port can only support a finite number of half-open connections, and when this number is exceeded, no other new connections can be made. By sending only the first packet of the TCP handshake with invalid or spoofed source addresses, the server responds to the SYN packet with an acknowledgment. Because this acknowledgment goes to a falsified address, the response to it never arrives. This causes a backlog of half-open connections that are waiting to be completed, preventing new connections from being accepted.

The Web server is a good sample target for a denial-of-service attack, although any network service can be targeted. As we have all probably experienced, a busy Web server tends to respond more slowly to our requests. A bit of knowledge about TCP/IP and the Hypertext Transfer Protocol (HTTP) is needed to understand how these attacks work. A single HTTP request and connection is made when the browser connects to the Web server. This request asks the server for a particular file; the server then sends the file, and the connection is closed. Under these circumstances, a Web server can handle a large number of requests because the requests usually take a very short time to complete, and they arrive one after another. As the server receives more simultaneous requests, the application becomes loaded as it processes all of these connections at the same time. Even with this slowdown, the Web server can still function.

To cause the Web server to stop functioning, the attacker needs to increase the time needed to handle these connections, or increase the processing power needed to handle each one. A SYN flood against a Web server makes the server unable to accept new connections by exceeding the maximum number of connections for the port it uses. The SYN flood is difficult to defend against. If the attacker forges packets to look as if they are coming from an unreachable system, the server has no way of knowing that they are not typical traffic. The server then responds as it would to any other connection, and waits for a timeout to occur before it realizes it should close the connection. As outlined in the SYN flood description above, the denial of service occurs when the Web server receives a large number of these forged packets—so many that it cannot handle any more new connections—and is inevitably stuck waiting for these falsified connections to timeout before it can continue processing. Similar attacks are the ICMP flood and the UDP flood, which use other protocols to achieve the same effect.

Another example of resource saturation can occur with the use of external programs such as Common Gateway Interface (CGI) programs with the Web server. Programs that store data in files on the Web server can be exploited to fill the hard disk on the server. The server operating system uses files for much of its normal functionality, and when full, it can often fail to function. Similarly, applications that allocate a lot of memory or require a lot of processing power for complex computations can be exploited to use all of those resources, preventing new processes and applications from functioning. These attacks are not exploitable only via the Web server—any access to the system might allow an attack to succeed. The email bomb discussed in the “Exploitation and Denial of Service” section is a good example of this.

System and application crashes are fast and easy approaches to denial of service, wherein a programming flaw is exploitable and causes the application or operating system to crash. A well-known example of these crashes is the “Ping of Death” attack, which uses oversized ICMP echo requests. The target machine crashes due to improperly implemented handling of this type of network data.

These attacks are also commonly directed against network access devices such as IP routers, cable routers, managed Ethernet switches, VPNs, and other application-specific devices. These devices often support some form of management interface including a Command Line Interface (CLI) and a Web management interface. Through various methods, including a large number of simultaneous connections, buffer overflows in user input routines, and improper data validation, these devices have been made to crash. A denial-of-service attack on an access device has a wider influence than an attack on a single machine, because these devices are typically gateways to multiple networks.

Many of these attacks can be prevented by the safe configuration of the network device. This includes changing factory-set default passwords, setting IP filtering, and configuring the device to allow management from only a select group of machines.

Email bomb packages are programs that automate the process of email-bombing someone. System administrators should be aware of these packages and the filenames associated with them. (Although this knowledge will not prevent your system from being attacked, it might prevent your users from attacking other systems.)

Table 16.1 lists the most popular email bomb packages and filenames associated with them. If you run a network with multiple users, you should scan your drives for those filenames.

Many of these files can be found at http://home.cyberarmy.com/hackshock/bomber.htm.

Kill files, exclusionary schemes, or mail filters are all cures for an email bomb. Using these tools, you can automatically reject mail sent from the source address. There are various ways to implement such an exclusionary scheme. Unix users can find a variety of sources online.

If you use Windows or Mac OS instead, I would recommend any of the mail filter applications listed in Table 16.2. Many of these are shareware, so you can try them before you buy them.

In addition to these packages, you can use the filtering capabilities built into most of the major email packages. You can add filters based on keywords such as “Viagra” that appear in a lot of spam, or you can reject particular senders.

If someone starts bombing you, you can also try a human approach by contacting the attacker’s postmaster. This is generally effective; the user will be counseled that this behavior is unnecessary and will not be tolerated. In most cases, this proves to be a sufficient deterrent. Some providers have strong appropriate usage policies and will immediately terminate the user’s account if it is used inappropriately.

Lastly, know this: Not all ISPs are responsible. Some of them might not care whether their users are email-bombing others. If you encounter this situation, you don’t have many choices. The easiest cure is to disallow any traffic from their entire domain.

In many circumstances, email bombs can result in denial of service. For example, one individual bombed Monmouth University in New Jersey so aggressively that the mail server temporarily died. This resulted in an FBI investigation, and the young man was arrested.

If you experience this level of attack, you should contact the authorities, especially when the attacker varies his origin, thus bypassing mail filters or exclusionary schemes at the router level. Chances are, if the attack is that persistent, your only remedy is to bring in the police.

The recent trend towards email-based viruses also presents a denial-of-service condition. The automation and integration of newer applications allows greater flexibility and increased functionality, but also presents security risks if not used appropriately. Windows-based macro and Visual Basic Script (VBS) viruses demonstrate this clearly. The VBS.LoveLetter, “I Love You” and “Anna Kournikova” viruses, and the Klez and VBS.SST worms show the fine line between viruses and denial of service. All of these viruses exploit the capabilities of Microsoft’s Outlook mail client to automatically execute executable code contained in messages. The virus code replicates and sends itself to many other recipients, magnifying the problem and resulting in widespread infection and loss of service as files are deleted and mail servers cease functioning. Disabling Windows Scripting Host can help alleviate the problem of automatic execution. See http://www.sophos.com/support/faqs/wsh.html for further information.

List-linking attacks have similar effects to email bombs, but their appearance is more inconspicuously malignant. In list linking, the target subscribes you to dozens of mailing lists, which can fill your mailbox and possibly the mail server with data.

Mail-bombing packages automate the process of list linking. For example, Kaboom and Avalanche are two well-known email bomb packages that offer point-and-click list linking. The results of such linking can be disastrous. Most mailing lists generate at least 50 mail messages daily, and some of those include binary attachments. If the attacker links you to 100 lists, you will receive 5,000 email messages per day. Furthermore, you must manually unsubscribe from each mailing list once you are linked. Moreover, attackers often choose times when you are known to be away, such as when you are on vacation. Thus, while you are absent, thousands of messages accrue in your mailbox. This can amount to a denial-of-service attack, particularly if your system administrator puts quotas on mailboxes.

List linking is particularly insidious because a simple mail filter doesn’t really solve the problem—it just sweeps it under the rug. Here’s why: The mail keeps coming until you unsubscribe from the lists. In fact, it will generally keep coming for a minimum of six months. Some mailing lists request that you renew your membership every six months or after some other specified period of time. This typically entails sending a confirmation message to the list server. In such a message, you request an additional six months of membership. Naturally, if you fail to provide such a confirmation message, you will eventually be taken off the list. However, in this scenario, your first opportunity to get off the list will not occur for six months. Therefore, no matter how irritating it might be, you should always deal with list linking immediately.

The cure for list linking is to unsubscribe from all lists you have been linked to. Doing this is more difficult than it sounds for a variety of reasons. One reason is that new lists seldom include instructions to unsubscribe. Therefore, you might be forced to trace down that information on the Web. If so, expect several hours of downtime.

Your ability to quickly and effectively unsubscribe from all lists will also depend largely on your email package. If your email client has powerful search functions that allow you to scan subject and sender headings, you can gather the list server addresses very quickly. However, if you use an email client that has no extended search functions, you are facing an uphill battle. If you are currently in this situation and have been list linked, communication with the maintainer of the list is often useful. Most mailing lists function by programs that automate most of the functionality the list provides. Contact with a real person is vital in the event of list linking. Should all attempts to unsubscribe fail, the user can implement permanent mail filtering, or, in the worst case scenario, a new email address might be warranted.

Another issue related to mail bombing and list linking, as well as the overall presence of unsolicited commercial email (UCE) or spam, is the capability of the attacker to relay mail. In order to obscure their identity, most mail bombs arrive from fictitious users. The attacker’s capability to falsify his identity arises from the configuration of various ISPs’ mail servers. Mail relaying allows a mail server to be used to send mail to foreign networks.

As part of the transaction for sending a mail message, the software used to send mail connects to the mail server. The recipient’s address and the sender’s address are specified, and the message is then transmitted. Mail relaying occurs when either the sender’s address or the system from which the sender connects to the server is not on the same network as the server. Mail servers that are configured to allow relaying allow foreign users and systems to send mail to any other user. Servers that are configured to disallow relaying will not allow messages with sender addresses on unknown networks, or from systems on those networks.

In general, mail relaying is seen as a security risk and is disabled. For those systems that allow relaying, little can be done to prevent its misuse. Filtering packages are incapable of supplying the needed security. Filtering by domain name or IP addresses might disallow legitimate email from being sent—this is not the desired outcome. For example, filtering to stop UCE from AOL will likely disallow millions of users’ email from being delivered.

The issue of mail relaying is complex, because messages such as mail bombs and UCE are syntactically the same as legitimate mail messages. Therefore, it is important to be aware of this issue as it relates to denial of service because it is one piece of the prevention puzzle.

A variety of mail relaying blocking systems exist. Distributed Sender Boycott List (DSBL, http://dsbl.org/, formerly ORBZ), Mail Abuse Prevention System (MAPS, http://www.mail-abuse.org/), Relay Stop List (RSL, http://relays.visi.com/), and Open Relay DataBase (ORDB, http://www.ordb.org/) are a few. They work by compiling a list of sites they believe spammers can use to relay mail. They then recommend that you block any email coming from these sites to stop spam.

Unfortunately, this is a case where the solution may be just as bad or worse than the original problem. First of all, some of the lists have been called “personal vendetta lists.” Apparently, some sites have been listed that should not have been, and some of these sites have even sued (see http://www.stoporbs.org/ for more information). Also, take a look at the FAQs for a couple of blocking lists: http://relays.osirusoft.com/faq.html and http://www.dorkslayers.com/faq.html. Honestly, after reading these, there is no way I’d trust these lists as being rational in their decisions.

Although these lists’ purpose is to prevent denial of service from spammers, they create a whole new denial of service where you can’t get mail to and from legitimate contacts. Businesses need to be especially careful in using such a list, because when their customers can no longer send them email, they are likely to take their business elsewhere. Crackers who want to cause problems for an entire site can work at getting the site listed on one of these lists.

The following flood attacks are general mechanisms that are still common today, although the technology has been available for quite some time.

Teardrop was an early DoS attack that spawned several variants. This set the stage for many new DoS attacks and approaches to DoS tool creation.

The LAND attack sent tremors through the Internet community, primarily because of the sheer number of systems affected. In particular, it was learned that certain network hardware was also vulnerable to the attack, including routers.

You should contact your vendor regarding fixes. It can take time to route out all LAND variations because so many mutations have cropped up. One version crashes Windows 95 and NT, even with Service Pack 3 installed. Windows NT is currently up to Service Pack 6a. If your systems are current, this attack does not pose a threat. Workarounds for Cisco hardware can be found at http://www.securityfocus.com. Otherwise, contact your respective vendor.

If your operating system is Windows 95, get the patch for the original LAND attack as well as several mutations. That patch can be found by searching for “land” under the Windows 95 knowledge base at http://support.microsoft.com/.

Winnuke will kill any unpatched Windows 95 or Windows NT box, forcing a reboot. This attack has gone through several mutations and is available for many build operating systems. The “nukenabber” tool helps to identify the presence of this tool on a network.

Nukenabber is a small, compact port sniffer written by [email protected]. The program listens on ports 139, 138, 137, 129, and 53. These are all ports on which DoS attacks have been implemented in the past. Nukenabber notifies you when your machine is under Winnuke attack. The program is available at http://www.dynamsol.com/puppet/nukenabber.html.

DNSKiller will kill a Windows NT 4.0 box’s DNS server. The source code was written for a Linux environment. However, it can also run well on BSD-ish platforms. For more information, see http://archives.neohapsis.com/archives/bugtraq/1997_1/0152.html.

arnudp100.c is a program that forges UDP packets, and can be used to implement a DoS attack on UDP ports 7, 13, 19, and 37. To understand the attack, I recommend examining “Defining Strategies to Protect Against UDP Diagnostic Port Denial-of-Service Attacks,” by Cisco Systems. Another good source for this information is CERT Advisory CA-96.01.