Keep-Alive DoS Script

I spent some time reading through the HTTP protocol, for another project. After playing around, I discovered that even with very limited bandwidth, you can perform an effective denial of service(DoS) attack against a web server.

Back in the day, when botnets were a rarity and bandwidth came at a premium, most DoS attacks relied on tying up services (e.g Apache) with fake requests. It didn’t take long for software makers to adapt to these attacks and come up with effective filters.

Now days, the DoS attacks you read about in the news are usually distributed across thousands of computers and use pure brute force to wipe their target off the internet by sending so much traffic to the remote server that it simply has no bandwidth left to serve legitimate requests.

The good news is that there’s still a middle ground!

There are three components that make up this attack.

Keep-Alive is part of the HTTP/1.1 protocol and allows you to send many requests during one connection (usually no more than 100). This is good for two reasons. Firstly, you can flood a remote server with tonnes of requests without triggering a firewall defence based on the amount of connections you’ve opened to the server. Secondly, there’s an overhead with every connection you open, only having to open 1 connection means you can make the most of your limited bandwidth.

When your browser loads a webpage, it usually sends a GET or POST request to the remote server. The server will act on the request and return the data to your browser. If you’re performing an attack against a remote web server, the last thing you want is to receive the output for every request you make! You’ll run out of bandwidth long before you manage to cause any problems for the web server. The solution? Use HEAD instead of GET/POST. This will cause the web server to action your request in exactly the same way but not return the data to you.

This attack is based on eating up the remote servers CPU and RAM, not out gunning them with bandwidth. You need to target your requests at a resource intensive page. For example, the search function of a blog or forum can create quite a load on the server while it scans through the database looking for your request. If you do target a search feature then you should randomise your search terms so that the server doesn’t benefit from any caching it may have implemented.

I threw together a DoS script based on the above 3 factors and aimed it at a US VPS server I have. It’s a clean install of Ubuntu with a fresh copy of WordPress installed. I targeted a search page on the blog.

Chart 1 - 3G Connection - 1000 requests (10 sequential connections, 100 requests per connection). Increases CPU usage to 25%

Chart 2 - 3G Connection - 5000 requests (50 sequential connections, 100 requests per connection). Increases CPU usage to 65%

Chart 3 - DSL Connection - 1000 requests (10 sequential connections, 100 requests per connection). Increases CPU usage to 96%

DSL Connection - 5000 requests (50 sequential connections, 100 requests per connection). I wasn't able to collect the statistics for Chart 4 because the attack caused the server to freeze up within about 20 seconds. I grabbed this screenshot before it died.

The next test was to see what the script could do to a beefy shared hosting server. The server in question has 8 cores, each running at 2.27GHz and the machine is equipped with 62GB of RAM.

Chart 5 - DSL Connection - 5000 requests (50 sequential connections, 2 second delay between connections, 100 requests per connection). Increases CPU usage to ~85%

In this test, I added a delay between connections to string out the attack for a longer period of time. You’ll notice that the traffic doesn’t die back down to it’s original value like the other charts. This is due to the server becoming unresponsive during the attack which prevented me from continuing collecting stats. The server recovered about 120 seconds after the attack had stopped.

Now don’t go thinking you’re going to take down Paypal.com from one computer with a 3G internet connection. But taking down a single VPS/Dedicated server using your DSL connection? Yes, it’s doable.

This method is especially effective against busy servers, such as shared hosting servers. They’re usually overcrowded and don’t require much to topple over. If your connection isn’t fast enough to completely deplete the servers resources and topple it in one hit, you should consider lowering the amount of requests but keeping the attack going for as long as possible. It wont take long before your requests, combined with the backlog of genuine requests. bring the server to a grinding halt.

This is quite a difficult attack for a server to detect and block automatically since it looks similar to legitimate traffic. A modern web browser loading a page with a lot of components could quite easily make the same number of requests, in the same style, as this attack would.

Remember that during my tests, I opened only ONE connection at a time. You could easily launch a few instances from one machine and still fly under the radar with regards to firewalls and Apache protection.

You can download Keep-Dead.php which is a functional script demonstrating the power of the above concept. Open the script in a text editor and adjust the top configuration options  Although Keep-Dead is primarily meant to be launched from the command prompt, it can also be uploaded to a regular shared hosting plan and launched through the web browser.

The script uses a single socket at a time, to fly under the radar. You could likely launch 3-4 instances of the script and still avoid automated protection against the attack.

I recommend watching the video in full screen so that you can clearly see the live stats of the remote server which is being attacked (top right). You can also see how little bandwidth is used in the 3G connection monitor (top left). Considering how quickly the CPU spiked and the RAM was depleted, I could most likely have performed the attack while using even less bandwidth.

This video shows the before and after of an attack on a WordPress site being served by Nginx.

Share |