What's behind these attacks? People tend to think of DDoS as causing havoc by jamming network bandwidth with useless traffic. While that's certainly one kind of DDoS attack, others work by devouring server resources. That means it's possible for a successful DDoS raid to be made no matter how much bandwidth you have because it attacks your servers' resources. To really protect a network against attacks, both your Internet connection and your servers need defenses.
Usually, DDoS attacks are aimed at your network's TCP/IP infrastructure. These assaults come in three varieties: those that exploit weaknesses in a given TCP/IP stack implementation; those that target TCP/IP weaknesses; and the tried and true brute force attack.
These days, the last, method thanks to botnet armies of zombied Windows PCs that make it easy to do, are the most popular. Why be fancy when you can just bury your enemies' sites under waves of bad data requests?
Low Orbit Ion Cannon is a brute-force program. All it does is crank out multiple simultaneous requests for a Web page that's unlikely to exist on the site. The only thing that's "interesting' about this attack is that it uses Twitter to co-ordinate its users' attacks.
If do you want to know how DDoS attacks manage their assaults, here's my 20,000 foot overview of DDoS techniques.
The canonical example of an attack that goes after TCP/IP implementation weaknesses is the Ping of Death attack. In this exploit, your enemy creates an IP packet that exceeds the IP standard's maximum 65,536-byte size. When this bloated packet arrives it crashes systems that are using a vulnerable TCP/IP stack and operating system.
All modern operating systems and stacks should be immune to the Ping of Death attack, but every now and again I find someone running something that can still be smacked around by the Ping of Death. The moral of the story is that you should always update your network equipment and software. Just because it's still running after all these years doesn't mean that it's safe.
Another attack that relies on poor TCP/IP implementation is Teardrop, which exploits defects in the way systems reassemble IP packet fragments. On their way from hither to yon on the Internet, an IP packet may be broken up into smaller pieces. Each of these still has the original IP packet's header, as well as an offset field that identifies which bytes of the original packet it contains. With this information, an ordinary broken packet is reassembled at its destination and network continues uninterrupted. When a Teardrop attack hits, your server is bombarded with IP fragments that have overlapping offset fields. If your server or router can't disregard these fragments and attempts to reassemble them, your box will go castors up quickly. If your systems are up-to-date, or if you have a firewall that blocks Teardrop packets, you shouldn't have any trouble.
Another oldie but badie DDoS attach method is the SYN attack. SYN works by taking advantage of the protocol handshake between two Internet applications. It's designed to work by starting an application session by sending a TCP SYN (synchronization) packet to another program. That application then replies with a TCP SYN-ACK acknowledgment packet; the first program then responds with an ACK (acknowledgment). Once the applications have made their handshake, they're ready to work with each other.
A SYN attack overwhelms its victim with a flood of TCP SYN packets. Every SYN packet forces the targeted server to produce a SYN-ACK response and then wait for the appropriate ACK. This quickly leads to a situation where outstanding SYN-ACKs pile up behind each other in a backlog queue. When the backlog queues fill up, the system stops acknowledging incoming SYN requests.
If the SYN attack includes SYN packets with bad source IP addresses, the situation grows worse more quickly. In such a case, when the SYN-ACKs are sent out, the ACK never comes back. The quickly overfilling backlog queue usually puts an end to legitimate application SYN requests getting through.
A variation on this the Land attack employs spoofed SYN packets, with IP addresses forged to look like they come from within your network. Now, the SYN attacks appear to be coming from within your firewall, adding to your problems.
Again, most modern operating systems and firewalls can stop SYNing in its tracks. Another easy way to prevent SYNing is to set your firewall to block all incoming packets with known bad source IP addresses. This list should include external packets that bear spoofed IP addresses from the following IP ranges, which are reserved for internal use only: 10.0.0.0 to 10.255.255.255, 127.0.0.0 to 127.255.255.255, 172.16.0.0 to 172.31.255.255, and 192.168.0.0 to 192.168.255.255.
But why should your enemies worry about sneaking in the back windows when they can simply bulldoze your systems? That's the approach that the Smurf attack and the User Datagram Protocol (UDP) flood use.
When you're Smurfed, your enemy floods your router with Internet Control Message Protocol (ICMP) echo request packets-a special kind of ping packet. Each packet's destination IP address is also your broadcast address, which causes your router to broadcast the ICMP packets to all your network's hosts. Needless to say, with a large network, this quickly leads to an electronic traffic jam of mammoth proportions. And as with the Land attack, if the cracker combines Smurfing with spoofing, matters get even worse.
The simple way to avoid Smurfing is to turn off broadcast addressing at your router or switch and set your firewall to block ICMP echo requests. You may also be able to set your server so it won't respond to requests to send ICMP packets to IP broadcast addresses. These changes won't interfere with your network's normal operations because few applications need IP's broadcast features.
It's not as easy to deal with UDP flood DDoS attacks, since some applications, like Domain Name System (DNS) and Simple Network Management Protocol (SNMP), use UDP. In a UDP flood, an attacker spoofs a call to connect one system's UDP chargen (character generator) service, a test program that generates characters for received packets, with another system's UDP echo service. The result? Chargen's semi-random characters are reflected back and forth between systems, starving legitimate applications' bandwidth needs.
One way to prevent UDP attacks is to disable or filter all UDP services request for your host. As long as you allow non-service UDP requests, normal applications that require UDP or use it as a backup data transport protocol will continue to work normally.
With all these ways to stop DDoS attacks, you might think DDoS attacks would be no more difficult to handle than spam. Wrong. When any malcontent can co-op hundreds to tens-of-thousands of PCs to launch DDoS assaults on your Web sites, there are no easy, cheap ways to defense against them. All they had to do is ask for Web pages, which may or may not exist, and have all of them do as many times in a second as they can manage.
Malware like Conficker puts hundreds of thousands of Windows PC at the hands of would-be attackers. The resulting tidal waves of direct attacks won't be bothered by a few dikes and storm surge walls. You can only change servers, which is what WikiLeaks tried with Amazon Web Services, or vastly increase your Web hosting site resources in an attempt to stem the flood.
I fear, no, I know, we're only going to see more such DDoS attacks. As the Internet expands, more people are getting broadband access, giving crackers more unprotected Windows systems to exploit. Worse still, thanks to programs like Low Orbit Ion Cannon, you too can get together some like-minded friends, and put down any mid-sized Web site that bugs you.