Above, we've covered resource exhaustion attacks on CPU time, memory and disk space consumption. That leaves us with network bandwidth, which we'll exhaust next.
Consider anonymous FTP, where a remote user can cause megabytes of data to be sent to him in response to a command of a few bytes. If the system administrator doesn't limit the total bandwidth taken up by FTP transfers somehow, an attacker with a high-bandwidth network connection can easily eat up all the victim's bandwidth.
In fact, this is roughly how the infamous distributed denial of service attacks work that took down Amazon.com and other online shops in 2000. However, rather than have one attacker with lots of bandwidth, they used a network of lots of sites with average network bandwidth; their combined throughput effectively marginalized any other traffic the victim sites may have been able to handle.9.5
While these distributed DoS attacks (DDoS for short) have about the grace of Sylvester Stallone wielding a sledge hammer, there are other attacks that have about the same impact, but which I can't help but calling elegant.
One typical example is the smurf attack, named after the exploit program that circulated on the net. Smurf would use other people's networks as ``multiplier'' to create huge amounts of network traffic by sending ICMP echo requests packets to multiplier's broadcast address. This traffic was directed to the victim's network by using a fake source address on the echo request packets.
Another very similar attack involved the echo service. This is a builtin service of inetd listening on port 7. If you send a UDP packet to this service on say hostA, inetd will send back another UDP packet to you containing exactly the same payload as you sent. Things get interesting when you fake the IP sender's address, and specify some other host hostB, and a port number of 7 instead. In this case, the response from hostA will go to UDP port 7 on hostB. If that host has the echo service enabled as well, the packet will be received and returned to the sender, which is port 7 on hostA. This goes on indefinitely, until the packet is dropped by some intermediate router. Things get real nasty if the attacker uses broadcast addresses as the sender and/or recipient of the initial packet. If he keeps up supplying a few ``fresh´´ packets every few seconds, network meltdown is instantaneous.
There are several defenses against these attacks. One is administrative; which is to configure the firewall to drop all packets sent to the broadcast address of some (sub-)network. Which is admittedly tedious, because the firewall admin needs to be involved every time an existing network is split up into two smaller subnets (because this creates a new broadcast address). However, this is the only defense against the smurf attack. Today, there are even several ``research'' projects on the net that regularly scan large portions of the Internet for these ``open multiplier'' networks, and notify the administrative contacts of those found vulnerable.
An application should protect itself against the UDP echo attack by ignoring any UDP packets from ports below 512. Applications normally do not send packets from such a low port unless they explicitly bind to it. However, ports in this range are reserved for network servers. And coincidentally, all known services that are prone to such ping-pong effects live in that range. This is how inetd's builtin services such as echo, chargen and time defend themselves against the echo attack today. They simply drop any UDP packets from port numbers less than 512.
XXX: Mention network attacks involving directory traversal