Home » Data Management

The Math Behind A DDOS Attack

Posted 21 Jan 2011 | Comments Off on The Math Behind A DDOS Attack | 1,858 views

The scenario is quite common. A web server that has been running well suddenly starts acting sluggish, and then suddenly it falls over. The site is down. System administrators are investigating, and managers are wondering if the site is being hacked. Eventually, the system administrator finds some content that was promoted that really needed to be stress tested more. The content is disabled, and the server starts responding normally. Then the questions start coming. It was just a simple web application. How could it affect a site that answers millions of requests in a day? How do a few lines of PHP code result in a self-inflicted denial of service attack?

The answer is really a simple matter of math. A denial of service situation event occurs when the resources required to fulfill requests is greater than the resources that are available. At it’s most basic, a server needs CPU, memory, disk, and network to complete web requests. The actual quantities of each that are needed will vary depending on the type of request. A database-driven request will probably require more CPU and memory, while a video stream will require more network and disk. A denial of service event can occur when any single resource is saturated.

When analyzing the situation, it’s best to manage both sides of the inequality. Minimize the amount of resources that a request can consume, while also maximizing resources available to web services. Unfortunately in an emergency situation, the right side of the equality is usually fixed. Resources are typically available based on budget requirements. This leave web developers and system administrators with the left side- managing resources required to provide web services.

Web server tuning is an art. Many tuning guides are available online, but their effectiveness really depends on the content being served. The tuning that Twitter performs for 140 character tweets is completely different than YouTube’s video streams. In order for web server tuning to be effective, it must match the content. Also, the effect of parameter changes must be completely understood before they are made.

Let’s examine simple PHP application running under Apache. We launch Phase 2 of our new service. Our new widget worked pretty well in testing, but we discover that the new features require some tuning because the PHP maximum execution time is set to low, and we can render all the data in the default 30 second timeout. We need at least 60 seconds. (Wow, that’s a long wait.) It’s a common scenario, and the application developers first instinct is to increase the time limit.

What are the implications of such a change? Let’s examine some of the math. So we know that this new widget can engage a httpd process for 30 seconds before it gives up. What’s the MaxClients setting on the server? If MaxClients is set to 30 (yes, it’s unrealistically low), and our new widget draws at 30 concurrent clients within a 30 second window (1 client per second), then our server is dead. Ok, so we decide to bump up the timeout, and a single client can engage a httpd process for 60 seconds. If those same 30 concurrent clients visit in 60 seconds (.5 clients per second), then our server is dead.

Uh oh. That just made our server more sensitive to those Phase 2 widgets. So what do we do? We can increase MaxClients in the httpd.conf file to respond to more parallel requests. Hopefully the server has enough CPU and memory to handle the additional processes. Time to check how much memory the server allows each PHP process. If the calculations do not work out, it’s time to scale back the Phase 2 widgets, and it’s time to consider removing them entirely or limiting them to special customers. The other option is to make more resources available. What was the budget limit?

As you can see from our overly simplified example, performance tuning causes a ripple effect. One tune may improve or fix something, but it will draw resources. Saturate that resource, and we’ve effectively pushed the problem somewhere else. As traffic increases, the configuration tolerances must be more precise. Over-allocating resources on a low traffic server is not will manifest itself as a problem like it will on a high traffic service. Proper performance tuning requires in depth knowledge of the content being served. A generic one-size-fits-all tuning guide may actually make things worse. Performance metrics and baselines are the key.

Comments are closed.