Denial of Service - Security Series #13

So I have not written about security in a long time. I should change that. I never finished my "Security Series", mostly because there is ALWAYS more to talk about when it comes to application security.

Today I want to talk a little bit about Denial of Service(DoS). This will be a brief overview with a few tips to get you started at an application level. For a bigger look at DoS, you can check out some of these resources.

What is a Denial of Service

A Denial of Service (DoS) attack occurs when a perpetrator explicitly tries to prevent legitimate access to a resource, system, or service. This is often done through the exploitation of weaknesses or vulnerabilities in the system that result in making the system unusable or bringing it down completely. While a Denial of Service attack is explicit and intentional, a Denial of Service can still occur through accidents, ignorance and irresponsibility.

I was first exposed to the idea of Denial of Serivce in 2005 when I read this (very long, but worthwhile) story about two resourceful and determined individuals who took on an extortion ring who were serving up DoS attacks against online casinos who refused to pay the blackmailers. DoS attacks are scary, because they can be difficult to stop. But there are some things we can do to at least make them a little harder to do.

How can DoS Attacks be done?

DoS'ing can occur in numerous ways. They can be intentional and malicious or accidental. They can happen via a flood of network traffic, buffer overflows, physical connection disruptions or by causing the application to work harder than it should.

A Distributed Denial of Service (DDoS) event can also occur when the flood of resource requests come from multiple sources (in some cases 10's of thousands).

Let's look at a few specific examples of how a DoS'ing or DDoS'ing could happen. This is by no means a comprehensive list.

  1. You have a simple application on a host with limited resources. Like a shared host or a small VPS. You run a blog there and one of your post makes it to the front page of Slashdot, Digg or Reddit and suddenly you start receiving tens of thousands of requests for that resource. Your server cannot handle the traffic and grinds to a halt. This is an example of an accidental DDoS attack, in this cause it is sometimes call 'The Slahdot Effect' or 'The Digg Effect'.
  2. Again, you have a blog running on a server with limited resources, and you make a snide comment about Rails developers. One of the developers gets exceptionally upset that you would dare trod on his religion, so he writes of a fully MVC architectured, object-oriented application that will repeatedly hit your blog with requests until it crashes your server. This is a malicious DoS attack.
  3. You piss off your neighbor by putting a compost heap too near to his yard, so he cuts your cable line with his hedge trimmers, denying you service to your cable AND internet. Quite malicious and not accidental
  4. You write a program that accesses a public API. In your code you, without thinking, program it to repeatedly try accessing the API until it succeeds. The API becomes unavailable for maintenance and you bring down the rest of their websites when your application repeatedly hammers it with requests. You may also bring down your own site or make it unusable with the repeated requests.
  5. You run a popular website that becomes the target of a botnet attack. The botnet repeatedly makes page requests from 10's of thousands of remote machines. Even your dedicated set of load balanced and clustered servers cannot handle the traffic and grinds to a halt
  6. You run a crappy little website on a shared host for your mom's used book store, and every weekend at around the same time, her site goes down for 2-3 hours. You spend hours on the phone with the shared host's tech support trying to figure out WTF is going on. Later you find out that one of the sites that she is sharing a server with releases a popular podcast on the server every week at that time. Turns out the number of simultaneous download requests from industrious automated downloaders is enough to kill it. Unsurprising, but frustrating. This is another accidental DoS. It could also happen if a poorly written program uses up too many resources on a poorly managed server.

So what can we do about it?

Well, when it comes to DDoS attacks, there really isn't much, short of using a Content Delivery Network(CDN), that we can do about it. And even a CDN won't help in all situations. A DDoS attack can throws so much traffic at your servers that there isn't much you can do but hope it stops.

As for mitigating the risk of amateur DoS attacks and even some more professional attacks there are a few things you can do. This is not a complete list, this list is more about what we can do at the web application and CFML server level. More can be done at the web server and network levels that I am not well versed on.

  • IP Blocking - This can be done at numerous levels. For a small to medium size site you could do it in your Application.cfc by storing a list of temporarily blocked IPs in the Application or Server scopes. If you start getting hit with an unreasonable amount of traffic from a single IP, or even a few of them, then temporarily block them by adding the IP to the list. This will add overhead because the check will need to be made on each request.

    Another option is to have ColdFusion write a .htaccess file with blocked IPs. The .htaccess would more easily facilitate permanent bans

  • Most larger, modern applications have some ability to reinitialize itself through a passed in parameter, like "reinit=1" which can be appended to the URL string. This is very convenient during development and update deployment, but the reinitialization can be VERY time consuming and processor intensive for the server. If a hacker knows this, they can use that to more easily bring your server down with fewer requests. You can solve this by having a reinitialization password instead. Something like "reinit=Sup3r@w3s0m3"
  • In general, keep your page load times short. If you have any single page that takes an exceptionally long time to process or load, then that can be exploited in the same way as the reinit command. Also using caching wisely can help prevent accidental DDoS, like the Slahsdot/Digg/Reddit example.
  • In the ColdFusion administrator, under Server Settings > Settings, set the Timeout Requests after ( seconds ) to something smaller than the 60 second default. Typically 10-15 seconds should suffice. This will mitigate the risk of attackers being able to attack your site by passing in parameters that will allow a DoS through demanding more resources than the machine can handle. For pages that still require more than 10-15 seconds to load, which hopefully there are very few of, you can use <cfsetting>to override this setting.
  • Also in the administrator under Server Settings > Settings, look at the settings for Request Size Limits. The default post data size of 100mb, is quite large. This could be used in a DoS attack to suck up bandwidth by sending dozens of large POST requests at a time, or it could be used to attempt to fill the hard drive of the server with huge files. Either way, unless you need to allow such large upload sizes, you might want to consider lowering it to the size of the maximum upload you would like to allow. I think 10mb is a good number.
  • Where possible, get off of shared hosting. You don't necessarily have to go to a dedicated host to mitigate some of the risk. A VPS will help, but it cannot eliminate all of the risk. Not even close. I run this blog on a VPS, and it has been DoS'ed several times simply by being indexed by search engine bots. I have since made improvements that have mitigated some of that risk, but it could still happen. To learn more about what you can do to prevent this type of issue, take a look at Charlie Arehart's post or Ben Nadel's posts on the topic


As I said, this is not a complete list. These are a few little things you can do to help mitigate the risk of a DoS attack succeeding and more likely to help prevent you from accidentally DoSing yourself or from getting Slashdotted. None of these things will really stop a determined hacker from bringing down your site or server. The best DoS defense happens at the network layer or through the use of a CDN.

Robert Rawlins's Gravatar Hey! Thanks for this insight, I always enjoy reading these security posts and DoS is something which has always been of concern to me as if done properly it is certainly very difficult to combat.

We've all seen this kind of thing recently, Facebook and Twitter both suffering from hours and hours of downtime just a few weeks ago and they have a large amount of resources available to them, nobody is amune from a well staged attack.

The one thing that frightens me the most as due to the nature of the attack being largely network based it's not really a vulnerability in the application so is hard to protect against, if someone wants to bring you down then inevitably they probably will.

Thanks for pointing out a few nice tips on how to help configure things to at least minimize the risk :-)

# Posted By Robert Rawlins | 9/11/09 8:41 AM
Jason Dean's Gravatar @Robert,

Thanks for the comment. I think you are right on every point. It is so hard to combat these types of attacks without throwing time, money and resources at them. Any little "free" things we can to do help mitigate the risks are great.
# Posted By Jason Dean | 9/11/09 8:45 AM
kelly's Gravatar We are here to get some of the best way to get the madden mobile coins here and we have been looking at hopeful for some coins.
# Posted By kelly | 3/18/18 5:49 AM
BlogCFC was created by Raymond Camden. This blog is running version 5.9.1. Contact Blog Owner