Testing Your Website Against DDoS Attacks Part 1 - Setup

I recently did a series of webinars to introduce Baffin Bay Networks to potential customers and partners, if you’re interested you can find the recordings here. In order to demonstrate the protection that our Riverview service provides, I needed to figure out how to simulate a few different attacks without resorting to potentially shady ‘booter/stresser services’. In terms of PR moves, feeding a potentially criminal organization is hard to spin. And I needed to do it on a startup budget.

The key requirements for the project were that it be as inexpensive as possible, easily reproducible by anyone in my organization, and provide a realistic test in terms of traffic and requests per second. No ‘SE Demo Magic’ allowed.

At the recent Google Cloud Summit here in Stockholm I discussed this issue with some of Google Engineers manning the Kubernetes booth. (Helpful tip: When mentioning this don’t start the conversation with ‘I need to run a DDoS attack’, use ‘load testing’). The Kubernetes team pointed me to an article titled Distributed Load Testing Using Kubernetes, which serves as the basis for this solution. The original article does fair job laying out the background and setup of the project, but the linked howto on github is pretty out of date with many of the files last being updated 2-3 years ago.

In the next few blog posts, I’ll be showing you how to use Google Cloud to run a load test against a web server, as shown in the webinars linked above. At the end of the series, you’ll have an easy way to run some basic load tests using Locust with traffic coming from different parts of the world.

Before I get into the meat and potatoes of the post, let’s get the disclaimers out of the way.

These instructions should be used ONLY for testing websites that YOU own, or have express permission to test. Please do not use these instructions for any other purposes. It’s a violation of Google’s ToS, and Santa will skip your house this year. I’m not responsible if you break your website.

Why do you need load testing?

What’s the point of testing this, anyway? When discussing DDoS protection, everyone tends to agree that it’s needed. Many of you already have some solution in place. But few organizations ever test the protections outside of a live attack scenario. When I discuss this with customers, there are two main reasons for not testing this:

1. Fear of breaking the production environment.
2. Difficulty in running a proper test.

The first one is common enough. It makes work for a typically understaffed IT department. It slows down the rollout of new functionality. It can really ruin your day. And this is *exactly* why you need to do it. If your organization is of the ‘If it ain’t broke, don’t fix it’ mentality, I can promise that there are people out there who don’t share your views. It is far, far better to find and fix potential issues on your own, than to have an unknown attacker point them out for you. I have blogged about this previously here. The old military adage ‘Train like you fight, and fight like you train’ is applicable. Testing under controlled conditions, in production, is the only way to really know what your risks and weaknesses are.

And that brings us to the second common objection. Testing can be hard. It can be expensive. Getting budget for testing is often a fight. With a bit of effort it is possible to run some basic load testing with little (or no) cost. There are of course, great services out there that can help you with this, though that isn’t the focus of this article.

Setting up your environment.

These instructions are written based on MacOS. They should work on Linux and possibly even Windows 10 with Bash, but it hasn’t been tested. I’d love to hear from you with results on other platforms.

The first thing you’ll need is a Google Cloud Account. Signup is simple and easy, you’ll need a credit card, but it will not be charged. You can sign up here. You’ll get $300 free credit which will be enough to run a few hundred tests.

Next you’ll need to install the Google Cloud SDK/ command line tools. The official instructions are here, however I recommend NOT following the interactive install instructions as piping to bash is a horrible idea in general. Use it as a last resort. After you install, restart your terminal before proceeding. Make sure things are working by issuing the following command:

gcloud config list

Next, install the needed add-on components. The following command will install everything needed.

gcloud components install app-engine-go alpha beta app-engine-php app-engine-python kubectl

Finally, install Docker. We will be using this to modify the Docker images to better suit our needs, as well as update them to more recent software versions. Docker install is simple point and click. Find the instructions here: Docker Install

With this, your environment is ready to go. In the next post, we will create a project in Google Cloud, modify some Docker images, and configure some test cases for Locust to run. 

Don’t miss Part 2 - follow us on LinkedIn!