“Is it possible to quantify your own security posture as it relates to denial-of-service? “
That’s the question a customer of ours has been asking themselves, and they came up with plan to measure exactly that. They’re going to DDoS their own production systems. I absolutely love this plan, and admire the architects for their foresight.
When done properly, a self-DDoS test can help you test the following:
- The resilience of your network and services
- The accuracy of your processes and people
- The efficacy of your inline bandwidth service (if you have one)
The customer is particularly interested in the third point. While most denial-of-service attacks today are not volumetric to the point that they fill the ingress pipe, it happens often enough that you must have an external DDoS scrubber as an insurance policy at least. Often you can purchase this service through your bandwidth provider, but if you think about it, do you know what you are really getting? A Self-DDoS test can find out.
Not only is a DDoS test going to provide metrics and show where you network and application weak spots are, it could be a fun exercise if you like to geek out on breaking stuff (and then making it better).
Here are some tips for conducting your own DDoS self-test:
- Plan a test like this by getting buy-in from all the right people. Make sure that no one feels threatened and that everyone understands that the idea is to measure and improve resilience. Mention the Netflix Chaos Monkey if you need to. If you lay the groundwork right, momentum for the test will start building quickly.
- Plan two phases. In the first phase, send a lower volume of traffic necessary to flood your ingress pipe. That is, if you have 1 Gbs in, start with 250Mbs of attack traffic. This will keep you of trouble with your provider and will still provide great metrics and tests results for a first pass. Increase the volume of traffic for phase two, which you can run a few months later.
- Develop your initial tests scripts in a closed lab, where you have the ability to design the test parameters in safe environment.
- Run the test it during a regularly scheduled maintenance window, when customers will not be expecting connectivity anyway.
- Attack the smaller data center from your larger data center. If you have only a single data center, attack from cloud services (but be careful of SLAs and legal agreements).
- To make sure that you don’t impact other customers on the network, you can set ACLs on the internal routers to prevent backscatter (responses to spoofed addresses) from leaking out during your test.
- Use both volumetric and asymmetric attacks. Hping3 and scapy for the former and slowhttptest (and others) for the latter.
- Run your scripts without engaging your service provider DDoS mitigation. Take notes and metrics. Then turn on the mitigation and run the scripts again. This will let you measure the effectiveness your service provider.
- When you run the test on some future Tuesday night, order pizza and drinks and have fun with it!
And lastly, be sure to let me know how it went. I’m always interested in True DDoS Stories.
| Connect with David: | Connect with F5: |
    |   |