Under Pressure

Any online project – be it a long-lost blog, or a new start-up’s web app – has a very important performance feature called a “maximum load”. This indicator makes itself known when a web app either partially or fully fails to perform its assigned functions to process user requests. For some owners, this may mean losing a portion of their blog-reading audience, and for others, it may mean the loss of clients who opt for a product from a competitor whose online store is up and running.

Each online resource has its own maximum load when it comes to the number of user requests it can process at any one time. That’s why developers and web app owners devote special attention to load procedures and stress tests.

Load testing services today are useful, but sometimes the way they are set up leaves a loophole that malicious users can take advantage of.

Load and stress testing

Data system load testing is a procedure that evaluates the performance features of the system being tested without reaching maximum load. Stress testing, on the other hand, is a similar procedure, but it tests the system with loads at or exceeding maximum load. In most cases, stress tests lead to unwanted behavior by the system being tested, or a service failure – similar to what happens in DDoS (distributed denial of service) attacks.

Load test scenarios used on data systems.

As you can see in the illustration above, load tests are carried out at a level below a system’s maximum load, while stress tests and DDoS attack scenarios are carried out at levels over the maximum load. However, the ultimate goal of performing stress tests and playing out DDoS attack scenarios are completely different from one another. The objective of stress testing is to determine the maximum load of the system being tested, while DDoS attack scenarios are carried out in order to determine what methods are required in order to disrupt the target’s performance to a point at which it ultimately fails.

Stress testing is a critical procedure when the owner of a data system wants to find out how his system will behave if it is subjected to higher-than-maximum loads. Sometimes stress testing is used when owners want to determine how a system’s security resources will cope with a DDoS attack.

Reconnaissance by fire

Stress testing is a part of the process used to boost the protection of external IT resources within the target infrastructure and obtain the following results:

• Determine the current maximum load for external services. If we know the point at which our data system will stop functioning, then we can streamline the processes we do have, or put new ones in place, in order to boost fail-safety. In other words, knowledge is power.
• Test the fail-safety of external services within specific scenarios for distributed attacks aimed at bringing the service down. If we look at our own projects through the eyes of a malicious user, we can draw some conclusions about the need to set up anti-DDoS protection or to somehow improve the effectiveness of solutions that are already in place.

Unlike other stages of web project development, whether it be de-bugging an app or performance testing (to determine how well its functions perform), load tests are important for a different reason that is no less important: these tests are conducted on the actual data system while it is running. Testing a mock-up would be of little or no use to anyone (if that testing procedure is not part of the development process for a high-load project). To really get a true idea about a project’s performance, you need to see the real thing in action. At the same time, testing a project that is currently up and running could cause a temporary loss of service for a particular business process – and that could mean an actual service failure and all of the implications associated with that failure.

For this very purpose, i.e., testing online web apps or external data resources accessible on the Internet (these include email servers, FTP services, etc.), specialized online load testing services have been developed – and they do a pretty good job.

Stress tests

The all “as a service” concept gives web app owners one less thing to worry about when it comes to customizing complex load testing systems, preparing a cloud infrastructure, and other related actions. This is all done in the background, and is now offered as an online service – just enter a username and password, set the load parameters, pay the fee to find out about your computing power, and learn how your web project will behave if and when it is subjected to different scenarios.

Configuración de las pruebas de cargas en uno de los proyectos que se está poniendo a prueba: establecemos situaciones de carga, subimos la carga a su máxima capacidad, pagamos por los servicios de los recursos de prueba y recibimos un informe completo.

Now, the owner of a web resource can simply register for any one of these services to find out how his project will behave when subjected to unusual load volumes. For the particularly lazy, some load testing services even offer a basic test (which doesn’t require registration), and while the service isn’t particularly robust, it can give you a general overview of the service’s interface.

El informe de pruebas incluye una gran cantidad de datos estadísticos; es decir, la intensidad con la que se cargó durante las pruebas.

Resultado de las pruebas de carga de una aplicación web usando un servicio web.

Load testing as a web service is admittedly a very useful and convenient tool. However, the way these testing procedures are carried out aren’t exactly as harmless as they seem at first glance.

Testing or DDoS?

Let’s try to take a look at one of these online load testing services, but from the point of view of a malicious user. Let’s imagine that we aren’t concerned at all about the ethical aspects of a distributed attack taking a service offline, and that our only goal is to make a competitor’s web resource unavailable. Can we achieve that using online load testing services?

As an experiment, I chose several popular testing services and used my own blog which is running on Amazon’s EC2 cloud service – not the worst service out there. The result was that even when I used the free test mode, which offers a very small amount of computing resource services, the load turned out to be sufficient to considerably drive up my blog’s response time.

The test mode of an online load testing service can imitate visits of up to 10,000 users per month, which can be fatal for many small-scale web projects. Even 50 users over the course of a three-minute interval can cause problems for some basic online projects.

At the same time, many online load testing services don’t require any confirmation that it is in fact the owner of the web resource who is requesting the load test, as opposed to a malicious user, and there are no additional requests for identification other than a phone number or credit card.

Of the six online testing services we reviewed, only one asks the user to upload a special file to the resource that will be tested – once the service gains access to that resource, it confirms that the administrator of the resource being tested is aware of the procedure. Furthermore, two of the online testing services that we reviewed allow users to perform load testing without any kind of registration whatsoever – all you have to do is enter the URL of the test subject.

The ease of use of these tools makes it possible to have anyone anonymously “test” someone else’s website or other online project without any registration issues or even the consent from the owner of the resource. The very fact that you can test any online resource without registering and without having to pay any fees for that service makes these types of services potentially very attractive tools for launching DDoS attacks.

Pruebas de carga en un recurso de Internet usando un servicio que no requiere inscripción Sólo visita el sitio, escribe la URL del recurso que quieres poner a prueba y revisa el informe con el resultado.

Potential threats

In our opinion, online load testing services can serve as a tool for someone to anonymously carry out DDoS attack scenarios. The quick creation of load scenarios, the simplicity, and the user-friendliness of these services combined with the pool of computing resources are ultimately what distinguish this type of “botnet”. Malicious users can easily create several independent accounts and assign all of them to perform “load tests” on one site at the same time.

We know that the most effective DDoS attacks are those where it is basically impossible to distinguish legitimate traffic from illegitimate traffic (generated by bots). It’s enough to imagine that the number of blog readers has grown from one hundred per day up to one hundred thousand, while they are all behaving like your typical user, spending time reviewing the content of each page, trying to post comments, viewing photographs, and are also located in different areas from one another. How is an untrained blogger supposed to know who’s for real and who’s an imposter?

Some services provide a demonstrative load test without requiring any type of registration, and that can mean that the owner of a small-time botnet comprised of just 50-100 machines can use these services to boost the power of a DDoS attack hundreds of times over. One bot can generate 10 independent requests for a load test with various web services. That means, then, that they can independently generate hundreds of requests. The result? The target in this type of attack will become completely overwhelmed by the volume of what looks like “legitimate” traffic.

What can be done?

How can the illegitimate use of online load testing services be prevented? For starters, we’ll point out that the owners of these very services have removed themselves from any liability whatsoever in the user agreement:

“The Use of the Service and the ability to produce accurate and effective results from it highly depends on the User’s expertise in operating the Service. Therefore, you shall be responsible for ensuring that you are competent to write the scripts required to receive optimal results from the Service…”

In other words: you are responsible for your own actions.

That doesn’t mean that it’s impossible to prevent the unlawful use of these types of services. Online load testing services should, essentially, request the consent of the owners of the online resources to be tested. For example, they can request that a unique code or a special banner be posted on the web resource to be tested, and only after that code is read can the load test be performed. Online load testing services can also employ CAPTCHA when working with a web resource. These types of basic verification services would make it much more difficult for bots to send automated requests to generate and inflate a web resource’s load.