A couple of months ago, I was on a call with a company that was in the process of evaluating DDoS mitigation services to protect its data centers. This company runs mission critical applications and were looking for comprehensive coverage from various types of attacks, including volumetric, low and slow, encrypted floods, and application-layer attacks.
During the discussion, our team asked a series of technical questions related to their
ISP links, types of applications, physical connectivity, and more. And we
provided an attack demo using our sandbox lab in Mahwah.
Everything was moving along just fine until the customer asked us for a Proof of Concept (PoC), what most would consider a natural next step in the vendor evaluation process.
About That Proof of Concept…
How would you do a DDoS POC? You rack and stack the DDoS mitigation appliance (or
enable the service if it is cloud based), set up some type of management IP
address, configure the protection policies, and off you go!
Well, when we spoke to this company, they said they would be happy to do all of that–at their disaster recovery data center located within a large carrier facility on the east coast. This sent my antenna up and I immediately asked a couple of questions that would turn out to be extremely important for all of us: Do you have attack tools to launch DDoS attacks? Do you take the responsibility to run the attacks? Well, the customer answered “yes” to both.
Being a trained SE, I then asked why they needed to run the PoC in their lab and if there was a way we could demonstrate that our DDoS mitigation appliance can mitigate a wide range of attacks using our PoC script. As it turned out, the prospect was evaluating other vendors and, to compare apples to apples (thereby giving all vendors a fair chance), were already conducting a PoC in their data center with their appliance.
We shipped the PoC unit quickly and the prospect, true to their word, got the unit
racked and stacked, cabled up ready to go. We configured the device then gave
them the green light to launch attacks. And then the prospect told us to launch the attacks; that they
didn’t have any attack tools.
A Bad Idea
Well, most of us in this industry do have DDoS testing tools, so what’s the big deal? As vendors who provide cybersecurity solutions, we shouldn’t have any problems launching attacks over the Internet to test out a DDoS mitigation service…right?
WRONG! Here’s why that’s a bad idea:
- Launching attacks over the Internet is ILLEGAL.
You need written permission from the entity being attacked to launch a DDoS
attack. You can try your luck if you want, but this is akin to running a red
light. You may get away with it, but if you are caught the repercussions are
damaging and expensive.
- Your ISP might block your IP address. Many ISPs
have DDoS defenses within their infrastructure and if they see someone
launching a malicious attack, they might block your access. Good luck sorting
that one out with your ISP!
- Your attacks may not reach the desired testing
destination. Well, even if your ISP doesn’t block you and the FBI doesn’t come
knocking, there might be one or more DDoS mitigation devices between you and
the customer data center where the destination IP being tested resides. These
devices could very well mitigate the attack you launch preventing you from
doing the testing.
Those are three big reasons why doing DDoS testing in a production data center is, simply put, a bad idea. Especially if you don’t have a legal, easy way to generate attacks.
A Better Way
So what are the alternatives? How should you do DDoS testing?
- With DDoS testing, the focus should be on
evaluating the mitigation features –
e.g. can the service detect attacks quickly, can it mitigate immediately, can
it adapt to attacks that are morphing, can it report accurately on the attack
it is seeing, and what is being mitigated, how accurate is the mitigation (what
about false positives). If you run a DDoS PoC in a production environment, you
will spend most of your resources and time on testing the connectivity and
spinning the wheels on operational aspects (e.g. LAN cabling, console cabling,
change control procedures, paperwork, etc.). This is not what you want to test;
you want to test DDoS mitigation! It’s like trying to test how fast a sports car can go on
a very busy street. You will end up testing the brakes, but you won’t get very
far with any speed testing.
- Test things out in your lab. Even better, let the
vendor test it in their lab for you. This will let both parties focus on
the security features rather than get caught up with the headaches of logistics
involved with shipping, change control, physical cabling, connectivity, routing
- It is perfectly legal to use test tools like Kali
Linux, Backtrack etc. within a lab environment. Launch attacks to your heart’s
content, morph the attacks, see how the DDoS service responds.
- If you don’t have the time or expertise to launch
attacks yourself, hire a DDoS testing service. Companies like Redwolf security
or MazeBolt security do this for a living, and they can help you test the DDoS
mitigation service with a wide array of customized attacks. This will cost you
some money, but if you are serious about the deployment, you will be doing
yourself a favor and saving future work.
- Finally, evaluate multiple vendors in parallel.
You can never do this in a production data center. However, in a lab you can
keep the attacks and the victim applications constant, while just swapping in
the DDoS mitigation service. This will give you an apples-to-apples comparison
of the actual capabilities of each vendor and will also shorten your evaluation