In 2009, the crème de la crème of Web sites are still vulnerable to DDoS (distributed denial of service) attacks. Indeed, entire countries, such as Estonia, have had their Internet capabilities crippled by DDoS attacks. Chances are decent we’ll all get to see a massive DDoS sometime on, or after, April 1st, when the hundreds of thousands of Conficker-infected zombied Windows PCs are put to work.

DoS (Denial of service) attacks are exactly what they sound like: attempts to prevent your server from delivering services. Attackers can do this in many ways. For example, you could describe the old Outlook e-mail worm Melissa and its ilk as DoS agents because they cause their damage by making Outlook clients flood e-mail servers with worm-laden messages to the point that the servers collapse under the load.

This is an important point. People tend to think of DoS attacks as causing havoc by jamming network bandwidth with useless traffic. While that’s certainly one kind of DoS attack, another succeeds by devouring server resources. That means it’s possible for a successful DoS raid to be made over a low-speed modem connection if it attacks server resources. To really protect a network against attacks, both network and servers should be armed and ready

Usually, DoS attacks are aimed straight 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, thanks to armies of zombied Windows PCs, are easier to do than ever

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 are immune to the Ping of Death attack..

Another attack that relies on poor TCP/IP implementation is Teardrop (http://www.physnet.uni-hamburg.de/physnet/security/vulnerability/teardrop.html), 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.

Attempts to whack your system using TCP/IP weaknesses also abound. The most popular of these is the SYN attack (http://www.cert.org/advisories/CA-1996-21.html). 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.

Adding insult to injury, the similar 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. Most up-to-date 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 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 DoS attacks, since some legal applications, like RealVideo, use UDP. In a UDP flood, an attacker spoofs a call to connect one system’s UDP chargen 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 DoS attacks, you might think DoS attacks would be no more difficult to handle than spam. Wrong. Thanks to DDoS attacks that are so simple that any malcontent can co-op dozens or hundreds of machines to launch DoS assaults on your systems.

Sheer volume alone can wash down your barricades and leave your network connection flooded with garbage. With tools like Tribe Force Network (TFN), Trin00 and Stacheldraht, anyone can plant DDoS attack zombies in unprotected systems. Later, the attacker sends out the target information, and, presto! Instant DDoS.

These attacks, devised between 1997 and 1999, are easy to spot. Newer DDoS attacks, however, use “pulsing zombies.” Instead of launching brute force attacks, these send waves of low-bandwidth traffic, which their masters hope will stealth their way past network alarms set for massive attacks.

With hundreds of thousands of PC ready to attack, there may be little need for stealth attacks in the future. A tidal wave of direct attacks isn’t going to be bothered by a few dikes and storm surge walls.

DDoS attacks are only going to increase. As the Internet expands, more people are getting broadband access, giving crackers more unprotected systems to exploit.

Conficker is the natural, evolutionary product of criminal hackers and powerful computers in the hands of ignorant Windows users. I fear that we will all soon regret neglecting network security, as well as Windows’ continued security failures, in the aftermath of the coming DDoS storm. If Conficker doesn’t do it, some other worm soon will.

Some of this story is derived from an earlier story of mine that was first published on CNet in 2001.