DDoS Attacks: What Can You Do?

The perilous Internet has fostered some pretty frightening things. The ever-lasting hot topics include Denial of Service (DoS) attacks, viruses, phishing and other types of scams.

While writing May’s article on IRC botnets, we realized that the most frightening attack isn’t discussed in detail very often. Distributed Denial of Service (DDoS) attacks are the same as a DoS attack, in that someone is simply sending you packets as fast as possible, but DDoS attacks can come from thousands of computers at once. Most people do not realize how effective DDoS attacks can really be.

Attackers use automated methods to infect hundreds of thousands of computers. They can be configured to start attacking a victim immediately, or more recently, they can be controlled remotely via IRC. When the compromised computers are controlled interactively, the attacker can command them to try and infect others before beginning the main DDoS attack. Once a large army is built, the fun begins. If the attacker points enough hosts toward one target, the result will be catastrophic for smaller ISPs, and possibly even the backbone provider your ISP connects to.

Cisco provides a few methods to help alleviate DoS attacks, but they are all useless in a truly large attack. Committed Access Rate (CAR) is an IOS feature that can rate-limit packets based on a number of criteria. Basically, you’d want to rate-limit the number of packets per second that get sent to the computer that is under attack. More specifically, if you know what host is executing the attack, you can simply drop all traffic from that IP address. But we’re talking about real-world DDoS attacks here, and you simply cannot do that for the 100,000 computers that are attacking.

Cisco’s answer to DDoS attacks involve rate-limiting and Reverse Path Forwarding (RPF). Unicast RPF basically looks in the routing table to verify that the source of a packet is valid. If the routing table entry indicates that an outgoing packet toward the questionable source would have used the same interface the packet just came in on, then the packet is valid. This type of check is valuable, but it really doesn’t help in this case. Most DDoS traffic is “valid” in this sense. So that’s about it. Cisco’s last suggestion is to contact law enforcement, but we all know how that would go:

“100,000 Internet hosts are attacking you?”

“Yes, sir, please help.”

The only logical response to that is: “You can try to contact every ISP on the planet and request that they turn off Internet access for their infected hosts.” Cisco also offers a ” DDoS Protection Service,” but this is laughable in the event of a large attack.

Now that we’ve established that there’s nothing a company can do to stop a large-scale DDoS attack, let’s turn the table and look at this from a service provider’s perspective.

Small- to medium-sized ISPs will probably have noticed the huge increase in traffic when this DDoS attack happened. In many cases, it will be disrupting service for more than just your company. The ISP’s only option is to drop all packets destined for your company. If the ISP can do this effectively at their borders, then no other customers will be affected. If the ISP is willing to work with you, it is possible that they can simply drop packets destined for the target of the DDoS attack, assuming there is only one target.

If you’re lucky, only one machine is targeted for the DDoS attack, and an upstream service provider will block traffic to the target for you. This would work nicely, except we’re forgetting one important point: there are possibly 100,000 or more machines on university networks attacking you. Chances are your ISP will not have a large enough Internet connection to facilitate the DDoS traffic as well as real traffic. Whether they drop packets or not, they will still make it all the way to your ISP’s borders, eating up bandwidth along the way.

The next step is for your ISP to ask their ISPs to drop traffic destined for the targets. Larger ISPs will normally oblige these requests, and assuming their routers are hefty enough, this can allow the smaller ISP to operate while the DDoS attack marches on.

This doesn’t help you, though. Someone is going to have to block traffic to the targets of this attack, which means that you’re effectively cut off from the Internet. There’s really nothing else that can be done in this large-scale attack scenario. Hopefully there is only one target, and your ISP (or your ISP’s ISP) is willing to block packets destined to that one server.

Tier 1 ISPs have 10Gb/s (or larger) links to many different exchanges. When a DDoS attack of sufficient size happens to transit a tier 1 ISP, they will suffer as well. Looking at our example, where your company is under attack and your ISP is effectively crippled, we hope that the upstream ISP has enough bandwidth to block these packets. Tier 1 ISPs like Sprint and UUNet have million dollar routers that can take the punishment, right?

No, they cannot.

The North American Network Operator’s Group holds quarterly meetings to discuss Internet operations. At the last NANOG meeting in Seattle, AOL network engineer Vijay Gill spoke about large-scale DDoS attacks.

Mr. Gill noted that attacks of less than 2Gb/s aren’t even worth worrying about, which is amusing in itself: Most large universities on the Internet don’t even have enough bandwidth to raise the eyebrows of AOL’s engineers. Unfortunately, when there are thousands of compromised university computers attacking a single target, even the Tier 1 ISPs can crumble. According to Gill, “you simply cannot throw away all the packets quick enough, no matter how fast your router is. There is nothing you can do.”

It all boils down to Mr. Gill’s assessment. If enough computers are attacking, your ISP and possibly a few backbone providers will be affected. Their last concern is to keep your company’s website up during this attack — they will be having to deal with their own routers and congested links.

There is nothing you can do.

Latest Articles

Follow Us On Social Media

Explore More