Last month, a couple of news stories made the round in mainstream media about some denial of service attacks, or DDoS, against some of the most well known US bank sites. These types of attacks certainly aren't new, and they are happening on a constant basis, but in this case it was newsworthy because the attackers were apparently all from the same area, and going after very precise targets. Of course, many mainstream shows over-hyped the situation, talking about hacking attempts and cyber attacks against our financial system, when in fact any of us who know what a DDoS really is knows that it's two very separate things. But knowing the basics of a DDoS, and being equipped to deal with a large scale attack of this type are also two very different things. While large sites are often attacked, it's important that those corporations and networks do everything they can to deflect them and remain accessible, even under heavy loads. And even if you manage a smaller site, like a small business or the network of a group of people, you never know when someone will decide to go after you. Let's see some of the important details behind what a DDoS truly is, and some methods that can be used to make sure your network is safe from them.
DDoS: Multiple methods
It used to be that a denial of service was the simplest type of attack out there. Someone would start the ping command on their computer, aim it at their target address, and let it run full speed, trying to literally flood the other side with ICMP Echo Requests, or ping packets. Of course, this quickly changed, because in this case, the attacker would need a connection with more bandwidth than the target site. First, they moved on to larger hosts, like compromising a server at a university or research center -- somewhere with a lot of bandwidth -- and sent their attacks from there. But now, botnets are used in almost all cases, because it's simpler for them, and is less apparent, making the attack completely distributed. In fact, malware authors have made a big business of running a botnet. They actually rent their compromised zombie computers, by the hour. If someone wants to bring down a website, all they have to do is pay the botnet owner a certain amount of money, and those thousands of compromised systems are aimed at the target. While a single computer would have no chance of bringing a site down, if 10,000 computers or more all send a request at once, it would bring down any unprotected server.
The type of attack evolved as well. ICMP, what's used by the ping command, is easily blocked. Now, there are various ways that a DDoS attack can be done. First there's what's called a Syn attack, which simply means that the attacker opens a TCP connection, the way you would normally connect to a website, but never finishes the initial handshake. It basically leaves the server hanging. Another clever way is to use DNS. There are a lot of network providers who have their DNS servers configured to allow anyone to launch queries, even people that aren't customers of theirs. Also, because DNS uses UDP, which is a stateless protocol, these two facts make this a potent way to create a denial of service. All the attacker has to do is find open DNS resolvers, craft a fake UDP packet that has a spoofed address, the one of the target site, and send it to the DNS server. While the request comes from the attacker and his botnet, the server thinks that request came from the server instead, and will send the reply to that location. So instead of having the actual botnet conduct the attack, the only thing the target site will see is a bunch of DNS replies coming from many open resolvers, all around the Internet. Also, it's a very scalable type of attack, because you can send a single UDP packet to a DNS server asking for a full dump of a certain domain, and receive a very large reply.
How to protect your network
So as you can see, a DDoS can take multiple forms, and when building a defense against them, it's important to consider these variants. The easiest, although a costly way to defend yourself, is to buy more bandwidth. A denial of service is a game of capacity. If you have 10,000 systems sending 1 Mbps your way that means you're getting 10 Gb of data hitting your server every second. That's a lot of traffic. In this case, the same rules apply as for normal redundancy. You want more servers, spread around various datacenters, and you want to use good load balancing. Having that traffic spread out to multiple servers will help the load, and hopefully your pipes will be large enough to handle all that traffic. But modern DDoS attacks are getting insanely large, and quite often can be much bigger than what your finances will allow in terms of bandwidth. Plus, sometimes it's not your website that will be targeted, a fact that many administrators tend to forget.
One of the most critical pieces of your network is your DNS server. It's a bad idea to leave it as an open resolver, and it should be locked down in order to save you from being used as part of an attack. But in a similar way, what if those servers came under attack? Even if your website is up, if no one can connect to your DNS servers and resolve your domain name, that's just as bad. Most domain registrations are done with two DNS servers, but quite often that may not be enough. Make sure your DNS is protected behind the same type of load balancing that your web and other resources are. There are also companies out there that provide redundant DNS that you can use. For example, many people use content delivery networks to serve files to customers in a distributed way, which is a great way to also protect them against DDoS attacks, but many of those companies also offer enhanced DNS protection as well, which is something you may want to look at.
If you're serving your own data, and managing your network, then there are many things you may want to do to protect it at the network layer. Make sure all your routers drop junk packets, block things like ICMP if you don't need it to go through, and set up good firewalls. For example, it's quite obvious that your website is never going to be asking random DNS servers for queries, so there's no reason to allow UDP port 53 packets heading for your servers. Block everything you can at your network border, where you have the largest pipe, or better yet, get your upstream provider to block them for you. Many Internet providers offer this type of service to businesses, where you can be in touch with their network operating centers and make sure they block any unwanted traffic, and also help you out in the event that you're getting attacked. In a similar way, there are many ways to protect your network from Syn attacks, by increasing your TCP backlog, reducing the Syn-Received timer, or using Syn caches.
Finally, you should also think about ways to mitigate any attack that does reach your site. For example, most modern websites use a lot of dynamic resources. While the actual bandwidth from an attack may be manageable, often what ends up failing is the database, or the custom scripts you may be running. Think about using caching servers to provide as much static content as possible. Have a plan in place to quickly replace dynamic resources with static ones, in the event that you're getting attacked. And make sure to have detection systems in place. The worst thing for any business is for the network or site to go down, so you want to be alerted as soon as an attack starts, and be ready to deal with it. Because of the way it's done, halting a DDoS attack at the source is incredibly difficult. But setting up an infrastructure that is distributed, hardened, and secure is possible, and that's something you should think about when setting up your network.
Patrick Lambert has been working in the tech industry for over 15 years, both as an online freelancer and in companies around Montreal, Canada. A fan of Star Wars, gaming, technology, and art, he writes for several sites including the art news community TideArt. He's always at the forefront of the latest happening in the world of technology. You can find him online at http://dendory.net or on Twitter at @dendory.