To get a “view from the other side” of how our customers experience MazeBolt’s BaseLine DDoS Testing, I decided to join a customer onsite during testing.
I wanted to learn more about DDoS testing from the customers’ perspective and what aspects they find most valuable.
The online gaming company I visited takes DDoS threats very seriously. The security team had a clear mission from management to ensure they would be fully prepared in the event of a real DDoS attack.
They had just invested in a Scrubbing Service with their ISP and wanted to understand if their investment would live up to the promise of protection.
Pre-Test: Scoping the Test & Understanding the Infrastructure
A few days earlier, our tech team mapped out the customer’s infrastructure, based on the information they were provided.
With this clear picture, they were able to highlight possible areas of vulnerability during a ISP DDoS attack.
If DDoS mitigation — cloud or on-premise — isn’t configured correctly, a network’s stateful devices downstream from the mitigation, e.g. WAFs or firewalls, would be the first devices to fail.
As a rule, the more defensive security infrastructure in place, the more complex the mitigation strategy becomes. Therefore, scoping the network and test planning are key to ultimately understanding the points of failure in your DDoS mitigation strategy.
Testing and Simulating a Real DDoS Attack
I took the chance before the test began to ask the customer how they thought they would do. Given the investment they had made, they were confident their vendor would perform as expected.
During testing, the customer has access to MazeBolt’s user interface that provides the customer with a real time report of the current attacks running and the rates achieved.
The customer logged into his MazeBolt account; once MazeBolt confirmed connectivity to the customer’s website and the customer had confirmed access to the devices in the network, the customer gave the go-ahead to begin testing.
Testing typically begins at lower rates, validating that the various defenses work at lower rates, before ramping up to the desired maximum thresholds.
The first test began well, and, as expected, there was no major excitement. The grin on the customer’s face was evident.
This customer’s ISP was providing Cloud Scrubbing Services, meaning that all illegitimate traffic was supposed to be blocked before getting to the customer’s environment.
Unfortunately, the subsequent ICMP Flood showed that the ISP had not configured the scrubbing service correctly, resulting in immediate impact on the firewall with CPU usage up to 100%.
The resulting downtime was a cause for concern. From the graphs in the MazeBolt UI clearly showing the traffic being generated, it was evident that the ISP’s misconfiguration of the scrubbing service was the cause of the inaccessibility to the customer’s website. With this knowledge, our tech team was able to provide recommendations for the customer to relay to their ISP.
Failing to Configure is Planning to Fail – A Note on Configurations
DDoS mitigation equipment always needs configuration even at the ISP level. This configuration is highly dependent on the individual environment. So, while ISPs provide mitigation to their customers, each customer’s unique setup has to be taken into account fully when configuring the mitigation.
Successful configuration of even a straight-forward DDoS mitigation system in any environment is not easy. In a complex environment, the number of possible configurations for the different devices compounds exponentially.
The only way to verify correct configuration is to test, test, and test again.
Conclusion
DDoS attacks, are not a matter of if, but rather a matter of when.
Instead of waiting to see how their mitigation system would hold up during a real attack, the customer took a proactive approach to ensure that they were prepared and that their financial and time investments in mitigation solutions were well justified.
By testing their network, the customer gained visibility into their mitigation’s vulnerabilities and could fix them proactively.
This test took 3 hours, and, in that time, MazeBolt ran 18 tests (BaseLine DDoS Testing), testing the underlying mitigation mechanisms responsible for more than 95% of DDoS attacks in the wild.
More importantly, they were on their way to ensuring a significantly improved and working DDoS mitigation strategy was in place.
It was evident from my experience that during BaseLine testing, the customer experiences what a real DDoS attack feels like, and this allows them to proactively prepare. They can measure the effects the attacks have on their infrastructure and, most importantly, they are able to do this all in a controlled environment, without all the uncertainties that accompany a real attack.
