The recent wave of DDoS attacks  on banking web sites, and the Spamhaus DDoS attack (which was three to five times greater than the biggest attacks against U.S. banks) is reinforcing that, while the attacks aren’t particularly sophisticated, they do warrant our attention. If targeted the attacks can be extremely disruptive to online operations. To protect against DDoS attacks, it’s important to understand their root cause. 

DDoS's take many forms but at the core, they're essentially a battle of resources. The attackers will attempt to exhaust resources on the server through “reasonably” valid requests. I use this term loosely because they will exploit certain assumptions that the network or web server will make to tie up the maximum resources per request. After that, it's just a matter of getting enough additional manpower to do the same thing at once to clog up the server's resources. 

This differs from the normal DoS (Denial of Service) in which the attacker finds a single request that can consume massive amounts of resources or take down the server.

One popular mechanism for DDoS attacks is the "SlowLoris" attack, which is a piece of software written by Robert Hansen (RSnake). Wikipedia does a great job of explaining it as such:

Slowloris tries to keep many connections to the target web server open and hold them open as long as possible. It accomplishes this by opening connections to the target web server and sending a partial request. Periodically, it will send subsequent HTTP headers, adding to—but never completing—the request. Affected servers will keep these connections open, filling their maximum concurrent connection pool, eventually denying additional connection attempts from clients.

Another popular way to do this is to simply flood the server with TCP packets (some that say you want to create a connection, some that say that a connection is already going on, some that say to close a connection that doesn't exist, etc.) The server is forced to handle each of these TCP packets and determine how to deal with them. Similar to the slowloris attack, the server will try to hold on to the connection as long as possible if you try to partially open the connection. For most popular web servers every connection maps to a process on the server so you can exhaust the Process ID space on the server if you're quick enough. There's a tool that Anonymous made popular called the Low Orbit Ion Cannon that make this easy.

Servers are inherently designed to handle a large number of connections, so it’s difficult for one individual to knock over a server; however, with enough people or a botnet, it can be brought to its knees. If it takes a server the same amount of time and resources to create and send a request as is does to receive and process the request then it is truly a battle of who has the most resources. Taking down something like Amazon or Cloudflare is going to be nearly impossible.

To help mitigate the risk of DDoS attacks, organizations should consider moving their servers to an infrastructure that scales – and scales fast. Amazon allows you to add virtual servers when a potential DDoS attack is happening.  Cloudflare tries to do this in real time.  Cloudflare, ironically, was the target of a few DDoS attacks last year, which tried to saturate the network. The attackers hit throughput of 90Gbps, which is an insane amount of traffic.  At that speed, assuming your computer could keep up you could download six full length high definition movies in ONE
SECOND; or  I could  transfer the entire contents of my hard drive in less than ONE MINUTE. Cloudfare recently wrote a couple of good blog articles about how they handled the attacks: and

Additionally, one of Security Innovation’s Principal Security Engineers, Marcus Hodges, wrote a library for python called BlackMamba, which makes it easier to write a client to create a huge number of requests for fast scanning or DDoS attack simulation. Note, it does require a lot of hardware to conduct this simulation, but this library can help level the playing field making it easier for you to write a very fast, parallel asynchronous python script for testing.

Get the Newsletter

Every two weeks we'll send you our latest articles along with usable insights into the state of software security.

Posts by Topic