Is It Legal to Evaluate a DDoS Mitigation Service?


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.

[You may also like: DDoS Protection Requires Looking Both Ways]

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?

[You may also like: 8 Questions to Ask in DDoS Protection]

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.

[You may also like: 5 Must-Have DDoS Protection Technologies]

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 etc.
  • 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 activereach, 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 cycle.

Read “The Trust Factor: Cybersecurity’s Role in Sustaining Business Momentum” to learn more.

Download Now


  1. Great article, Dileep and thank you for bringing more attention to this topic. You must have had a good mentor but you started loosing me about not testing in production though.

    In my experience, organizations measure RISK a bit differently. For DDoS, I like to associate the idea of Web App Pen Testing for Web Vuls, as this newer industry of Legit Stressors for DDoS testing. When you are scanning web apps for vuls, you do this both for internal enterprise applications (not client/web facing) and production applications (client/web facing). If you are doing any testing in QA/LAB/DEV for Web Apps, its normally done with IAST/SAST/DAST tools or if you are brave, RASP tech. This means, you cannot limit yourself to just one facet of the business, from a risk perspective. You must evaluate all HTTP/HTTPS risk across the business enterprise, products and/or platforms. I am confident RadWare InfoSec does this before you push new code or hardware or application services for general use by employee’s, partners, or paying customers.

    To say that a business should “NEVER” test in production or it “doesn’t add value” is a bold statement and maybe misguided?

    Any business, making a RISK based purchasing decision for DDoS and wants to evaluate aka POC, in a presale cycle, a lab or production, it should be recommended in a phased approach. If they only want it in the LAB, express what they are missing with not testing it in Production. If it’s testing in PRODUCTION over production routers and ISP links but against /32 or /24 or multiple IP’s at one time 😉 😉 😉 that are only “TEST” hosts or services, then there is a compromise.

    I do agree that generating “intended” DDoS attack traffic, against a production router, across multiple diverse production ISPs, against a Production Host is not a good idea, UNLESS, you know what the side effects are if it doesn’t work out as expected!!!

    Unfortunately, I don’t care what anyone says and I’ll quote an old mentor of mine (Deon, I see you), DDoS is NOT a perfect science. These attacks are designed to look legitimate and follow most “normal” RFC convention. Even if you configure or pre-stage thresholds on CPE or cloud based technologies, something can always go wrong. Take for instance one of the vendors you mentioned in your blog (won’t be named but did allot of work with them over the years), configured 64 bit processors on their new infrastructure and did not notify the supply chain from the agreed 32 bit processes that generated a 10x magnitude more in attack capacity and rate than they originally agreed on. What was 7 Gbps turned to 70 Gbps. There is also the idea that these devices that are used in legit stressor environments do not always receive disconnect or “STOP” messages. Which means, it’s hard to stop the attack! So, how do vendors compromise the agreement of disclosing details about the attack test details (attacking IPs, rate of attack, attack vectors, attack destination IP or Port+service, or not disclosing details and the side adverse effects that now are part of the collateral damage for all parties involved.

    If a business has allocated a certain about of time and resource funding for the DDoS test but exceed those figures, how do they appropriate time and money back to the business? Many things come to mind but in all, this is a very important topic and should be discussed more with organizations like FS-ISAC and other non-profit sharing groups.

    NOTE: Like DDoS mitigation providers, Legit and Malicious DDoS Stressors exist. I recommend doing a thorough evaluation of what you are getting yourself into before committing to executives or the board about doing these controlled events and by all means, understand these tests do not really replicate REAL WORLD!

    • HI DB – Many Thanks for reading my Blog and for your comments! My recommendations are specific to evaluation of DDoS mitigation services in the proof of concept phase. Of course it is fine to test the effectiveness of an already deployed DDoS mitigation – most of our customers do it on a quarterly basis.


Please enter your comment!
Please enter your name here