• Blog
  • About Esrun
  • Blackhat SEO Scripts
  • Contact

Keep-Alive DoS Script

March 19, 2011 on 6:25 pm | 10 Comments

Denial of service attack using limited bandwidth

Keep-Dead DoS

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!

How to perform a denial of service attack with limited bandwidth

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.

Choose your target wisely

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.

Attacking a freshly installed VPS

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 Internet - 100 requests (10 sequential connections, 10 requests per connection)

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


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

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%

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.

Attacking a shared hosting server

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.

DSL Connection - 5000 requests (50 sequential connections, 2 second delay between connection, 100 requests per connection).

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.

Download Keep-Dead – Denial of service script

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.

Video: Keep-Dead in Action

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.

Video 2: Keep-Dead VS. WordPress served by Nginx

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


RSS feed for comments on this post. TrackBack URI

  1. Great idea and concept. I was able to completely nuke one of my servers in just under 25 seconds… server load went to the roof, had to stop the server and reboot services… also made me happy to see that an old custom security script I had running was able to detect and block the attack (but not fast enough though)… it took the script 7 minutes to recognize the attack and block it, but that was 7 minutes with the server collapsed! Thanks, great script!

    Comment by El Doc — 20th March, 2011 #

  2. Thanks for the feedback El Doc! I appreciate you taking the time to test it out and give feedback. When I get time, I think i’ll tidy up the script and provide support for multiple sockets at once, creating a stronger attack.

    Comment by admin — 21st March, 2011 #

  3. How does that look against nginx or lighttpd which use an asynchronous handling for requests?

    Comment by Viðarr — 22nd March, 2011 #

  4. @Viðarr: Good question. I just installed nginx on another port, enabled FastCGI for php scripts and installed a fresh copy of WordPress.

    During the attack, the CPU went through the roof but RAM stayed relatively stable.

    After about 40 seconds the FastCGI server had crashed, essentially knocking the site offline.

    Comment by admin — 22nd March, 2011 #

  5. Nginx isn’t even at fault here, of course WordPress uncached isn’t going to handle much traffic at all, let alone behind a single php-cgi worker. As you noticed Nginx stayed up, it just couldn’t connect to the crashed php backend.

    Comment by Kbeezie — 22nd March, 2011 #

  6. Heya, yup. I’m not sure if you saw my above comment. But I said that it’s actually FastCGI that’s failing before Nginx. But since Nginx relies on this, I still consider it a success.

    Considering the attack is based on random searches, how will caching help protect against the attack?

    Comment by admin — 22nd March, 2011 #

  7. Caching (especially with something like W3 Total cache since you mentioned random searches) which significantly reduce the load/strain on PHP (since W3TC can also cache database objects and so forth).

    With just straight file caching (like say WP super cache), would be affected greatly with such attack, however if you’re running a more modern setup of PHP fastcgi deployment (ie: PHP-FPM, not a single php-cgi process), then the results would be an incredibly slow site… but still remaining up.

    From the link I provided above you’ll see I hit an uncached copy of wordpress with the siege benchmark tool, it stayed up but with some failed requests at around 150 concurrent users, but thats mainly because I was using FPM, not a single php-cgi process. With your setup, siege would have surely taken it down early on.

    Comment by Kbeezie — 22nd March, 2011 #

  8. Kbeezie, I can’t seem to find the link, would you mind sending it over again?
    Thanks for the feedback btw, I’m looking to improve and test the script against different scenarios, so it’s definitely useful.

    I’ll get nginx going again with PHP-FPM and see how it goes. Then I’ll look into the caching and see what difference that also makes.


    Comment by admin — 22nd March, 2011 #

  9. […] Si tiene una pizca de conocimiento, descargar el KeepAlive DoS Script. (Más información sobre KeepAlive) […]

    Pingback by Operación Hidroaysén — 10th May, 2011 #

  10. very nice guys, i was looking for a low tech script to test on my webservers, comes in pretty handy with all the lowlifes trying to use slowloris over TOR nowadays etc. since most servers use apache its a really good testing tool.


    Comment by random admin — 1st September, 2011 #

Leave a comment

XHTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code lang=""> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>