How can you defend your service from a distributed denial of service attack?  The Answer is at the grocery store.  Distribute your service to force your adversary to divide his forces or be ineffective.

The Challenge of Distributed Denial of Service Attacks

A Distributed Denial of Service attack (DDoS) aims to flood a computer providing a service (e.g. a web server) with so many requests from so many different sources that your server is overloaded and service is either degraded (i.e. very slow) or denied (by crashing the server).  This is similar to a website running slowly when it is being used a lot by legitimate users, except that the degradation is deliberate and intends to deny legitimate users access to the service temporarily or permenantly.

By sending many requests from many different sources, the attacker amplifies the strength of the attack while making the attack difficult to defend.  If the attacker only used one or a small number of sources, the defender could identify nefarious sources, isolate them, and simply not service such responses.  A botnet of hundreds to thousands of sources makes it difficult for the defender to distinguish legitimate users from nefarious sources, and much more cumbersome to block all of the sources in a reasonable amount of time.

Traditional Defense against DDoS

Typically, the strategy in defending against DDoS has been to do two things:

1. Run your service using computers with a large amount of processing resouces and speed.
2. Employ a system that attempts to detect a DDoS attack and block the sources of the attack.

Limitations of this approach are the cost of running an expensive server with a lot of resources, and moreso the difficulty of identifying nefarious requests.

Demystifying Denial of Service

In order to think of other creative ways to defend against a DDoS attack, I find it useful to develop an analogy of the problem.  This helps me find the root cause and reveal some more fundamental ways to approach a solution.

DDoS: just long line at the supermarket

A service is just giving something to somebody making a request.  When you go to a restaurant and order a sandwich, you are making a request to a person and that person gives you the sandwich.  Or, if you are at a supermarket ready to pay, you need to find a register that will allow you to purchase the goods you have selected.

At the supermarket, it can be frustrating when the registers are understaffed.  Sometimes there will be tens of customers and only one or two registers.  You have spent an hour finding the goods you want to purchase, now you have to wait a long time to pay for them.  Sometimes the line is so long you don’t have time to wait and you leave without the goods you came to purchase.  In this case, the service you wanted to access has been effectively denied.

 

When you are at the supermarket and the lines get long, one of two things will happen.  The manager will call more employees to unmanned registers, creating more registers available to process transactions, or they will do nothing and customers may or may not decide to suffer through the degraded service.  When more registers are manned correctly, the wait time is nominal for customers.  When there is no line of customers (i.e. a customer can proceed directly to a register ready to process a transaction), the service is exceptional.  Many stores will staff the registers to capacity when they expect high-traffic periods.  Stores that only have a single or a few registers have a much lower capacity and cannot handle large crowds of customers.

The stores that do have a lot of registers and staff can handle a very large volume of requests quickly.

Apply the Supermarket Solution: Distributed Service Architecture

We could apply the supermarket solution to DDoS attacks.  Instead of your service being available at a single location (i.e. a single server), why not distribute the service across multiple locations?

If you design your service to be distributed, you might call this approach a Distributed Service Architecture (DSA).  Fight Distributed Denial of Service with a distributed service.  Use the same tactic as the attacker.

This approach would diminish the attacker’s numbers advantage.  The attacker would be forced to attack all servers in the DSA, or a subset of them, and this would divide his “forces.”  Thousands of bots divided among a mere ten DSA servers cuts the number of attacking bots down to hundreds, a manageable load for modest servers.  Launching a DDoS would require a much larger botnet, costing the adversary time and resources.  And should the adversary manage to develop a much larger botnet, you could increase the size of your DSA.  This could make successful DDoS attacks on well-defended services cost prohibitive.

Some Spitball Thoughts on Implementing a Distributed Service Architecture

• With some hard (open source) work by some smart people, DSA’s could become the next option from your web hosting provider. Instead of buying a really fast, single server, why not invest in many modest-performing servers?
• Servers/services with space capacity could lease excess capacity temporarily, and dynamically shed the services of tenets during high capacity or DDoS events.
• Combine a DSA with sophisticated firewalls and services that have been developed over the past 10+ years that were designed for non-DSA structures.

Other Applications of a Distributed Service Architecture and Similar Concepts

• IBM’s DSA boasts data failover and redundancy advantages
• A rose by another name: Denial-of-Service resilient web cluster architecture is specifically designed to withstand DoS attacks.
• Dynamic resource pricing is designed to make DDoS resilient architectures feasible
• A DSA architecture could provide higher capacity for systems during expected high demand times or events