DDoS Stress Testing for Increased Resiliency

You’ve heard of DDoS, right? Well, DDoS stress testing is a specific service that helps your organization understand just how well your are prepared for the different DDoS attack vectors that, unfortunately, may come your way. The service consists of simulations of DDoS or high load on your IT and are carried out in a strictly controlled and pre-scheduled manner. What you  get is a detailed report that tells you of network and server issues related to DDoS resiliency. You also get remediation and mitigation advice on how to harden your DDoS mitigation solution or how to implement one, in case you don’t have it yet.


Today, DDoS is as easy to inflict on a victim as buying a pizza on-line. It’s cheap and effective too. By stress testing your IT infrastructure, you will be able to identify and plan for mitigating DDoS-related issues before attacks do happen and harm you. You will also gain insight of your incident response procedures and improve them, or simply gain better control over a DDoS mitigation solution you may have. If you’re looking to purchase such a solution, stress testing may help you choose the right vendor for the job.


The stress testing process usually starts with a verification and customization procedure. Real-time DDoS attack vectors are pointed at the organization’s IT public-facing infrastructure from the outside (real-life scenario) or in a closed environment (on-premise simulation). DDoS attacks simulations should be carried out on all applicable Layers of the OSI model in a fine-grained controlled manner with a “Stop” capability at all times. The process must be supervised by service provider’s support member and a representative of the tested organization at all times.


Confidentiality, integrity, and availability, also known as the CIA (or AIC triad for wanting to avoid association with a certain intelligence agency) triad, is at the heart of Information Security, working together to make sure your data and systems remain secure. It is wrong to assume one part of the triad is more important than another. Every IT system will require a different prioritization of the three, depending on the data, user community, and timeliness required for accessing the data. There are opposing forces to the triad concepts and they are disclosure, alteration, and destruction. Disclosure is when you are faced with unauthorized disclosure of information, alteration constitutes the unauthorized modification of data, and destruction is making systems unavailable.




AVAILABILITY keeps information available when needed. All systems must be usable (available) for business-as-usual operation. Typical availability attacks are the Denial of Service (DoS) or Distributed Denial of Service (DDoS) attacks, whose aim is to deny service (or availability) of a system. Being prepared and informed of weaknesses in your system against DDoS attacks involves stress testing.


Determining the readiness of your organization’s IT infrastructure for DDoS attacks through stress testing must include all known attack vectors and possible sources. Remember, DDoS today is cheap and effective, thus the following characteristics of the testing method and approach must be in place:


  • Attack vectors simulating floods generated by real known botnets
  • Volumetric attacks with unlimited size and adjustable increments
  • Service-centric selection of floods on the Application layer
  • Flexible attack timing and combined vector capability


The attack scope is very important and must (i.) be able to show at least fundamental weaknesses of the target servers and (ii.) comply with your security policies and strategy.


A good stress testing vendor will have the expertise and capacity to employ a wide variety of attack vectors to include, but not limited to various HTTP/HTTPS methods and combinations (GET, POST, HEAD, PUT, DELETE, TRACE, CONNECT, OPTIONS, PATCH, etc.), various attacks on WebDAV protocol, SYN-ACK Floods, ACK or ACK-PUSH Floods, Fragmented ACK Floods, RST/FIN Floods, Same Source/Destination Floods (LAND Attack), Fake Session Attacks, UDP Floods, UDP Fragmentation, ICMP Floods, ICMP Fragmentation Floods, Ping Floods, TOS Floods, IP NULL/TCP NULL Attacks, Smurf/Fraggle Attacks, DNS Floods, NTP Floods, various Amplified (Reflective) attacks, Slow Session Attacks, Slow Read Attacks, Slowloris, HTTP Fragmentation, various types of Excessive Verb (HTTP/HTTPS GET Flood), Excessive Verb – Single Session, Multiple Verb – Single Requests, Recursive GET, Random Recursive GET, various Specially Crafted Packets, etc.


In order to establish perimeter resilience to DDoS attacks, from a risk management point of view, a proper identification and listing of assets under threat is required and must be followed by an assessment of the critical assets’ vulnerability. Generally, DDoS Stress testing is performed either externally, or internally.


As the name suggests, the EXTERNAL approach simulates DDoS attack by deploying resources that are very close in their nature to a real-life attack, i.e. originating from the Internet. The attacking “botnet” is simulated from a stress testing cloud platform. The maximum volume of the simulated test attacks must be discussed with the client and agreed upon prior to starting the tests. Generally, a typical topology for external tests, including a sample legitimate client ( a machine used to perform availability tests), is implemented:




In contrast to external testing, internal DDoS stress testing means performing the simulation in a location within the perimeter of the client network. Flood traffic is generated internally and pointed to resources, which are usually part of a purpose-built test environment. Displayed below is a typical network topology for internal testing, where the Internet is simulated with a local network and includes segmented test targets and a simulated legitimate client PC:




When performing DDoS Stress testing, it is imperative that a detailed test plan is made available in advance and is pre-approved by all parties involved. All tests must be performed in stages, with every stage lasting long enough to perform availability test and measure an approximate download speed from the target server by connecting to it from the simulated client PC. Tests must be designed in such a way that they can be stopped at any time and stage on your request. It is highly recommended to not perform tests on production environment, as their behavior and possible aftereffects depend on specific target server settings.


In our everyday dealings with clients, we have encountered a number of cases where DDoS Stress Testing can be crucial in either choosing the right solution or simply finding out what is wrong with existing ones. Below are some examples of real-world situations, in which we have been able to help.



The Bank had decided to test a number of vendors in order to choose the most appropriate DDoS Mitigation solution for their needs.


We prepared and executed an extensive test scenario with distributed international traffic to stress test the PoC’s of the vendors with magnitudes of around 40 Gbits on both transport and application layers.


PoC deployment DDoS stress testing revealed that not all vendors are equal, but in the end the best suited to the needs of the Bank vendor and solution were selected.



This Telco started bundling DDoS protection with internet provision service to their clients and wanted to ensure protection that was up-to-date with the everchanging attack treat landscape.


We started regular, monthly stress testing on the solution to ensure just that: end clients were protected from the newest attack vectors.


The resulting higher level of preparedness not only increased customer loyalty and brought in new clients. Regarding DDoS protection, the Telco is now ready for their regular yearly external audit at any time.



Despite presently deployed DDoS protection solution, this e-commerce player suffered an attack that lead them to investigate into the reason for it. The protection vendor wanted to know the how’s and why’s as well.


Through deploying an extensive multi-gigabit attack scenario, we were able to replicate the situation under which the solution caved in.


The test report revealed weaknesses in both solution configuration and network architecture. Remedy measures were taken, so the DDoS mitigation solution could perform at its best.



While under loads generated from multiplayer contests, with hard-to-manage traffic peaks caused by prominent sport events, this betting portal was experiencing intermittent availability issues that lead to reputation and monetary loss.


We prepared a specific high load stress test that revealed minor, yet damaging flaws in the production software stack used for online betting.


Post remedy, it was decided to integrate all consecutive production environment releases with regular high load testing to ensure uninterrupted service in the future.