Containers can be an excellent mechanism for mitigating Distributed Denial of Service (DDoS) attacks. However, discussions around the subject of using containers for the prevention of DDoS attacks are sometimes shortsighted. In order to use containers effectively for this purpose, you need to understand some specifics about DDoS attacks, and how containers can help mitigate their effects. (No, the ability to scale your infrastructure is not enough on its own for handling DDoS threats.)
In this post, I outline what you need to know in order to build containers into your anti-DDoS defenses.
There are two primary ways in which containers can sometimes help to keep a denial of service attack from being successful.
First, containers are really easy to reset to a pristine state, which can help if a containerized application was found to be participating in a botnet.
Second, containers support massive scalability. As such, it is theoretically possible to scale a containerized application to the point that it is able to absorb the flood of requests generated by the attack, while also continuing to service legitimate requests.
Why Scalability Is Not Enough for DDoS Prevention
Although container scalability can be helpful in mitigating DDoS attacks, scalability alone may not be enough. In fact, relying solely on container scalability is more likely to touch off something of an arms race. Attackers know that containers are ridiculously scalable, and therefore build bigger botnets in an effort to overcome the limits of scalability.
Containers can of course achieve a level of scalability that is nearly unlimited. The problem is that this scalability comes at a cost. Public cloud providers, for example, bill customers based on the resources that they consume. As such, it is conceivable that a denial of service attack could have a secondary goal of costing application owners as much money as possible in cloud service fees.
The point is that although containers are highly scalable, scalability alone probably is not going to be enough to completely mitigate the effects of a denial of service attack. Thankfully, there are some things that you can do to make your containerized applications more resilient to these types of attacks.
Beyond Scalability: Other DDoS Attack Prevention Tactics
The key to successfully mitigating a DDoS attack is to understand that there is no such thing as a standard attack. DDoS attacks can occur at any level of the network stack, and can target any component that the attacker believes to be vulnerable. An attack, for instance, might seek to deplete the available Internet bandwidth, or overwhelm a load balancer.
One way that you can reduce the chances of an infrastructure-targeting DDoS attack’s success is to distribute your containers across multiple clouds. Even if a particular cloud provider is not able to fend off the attack, containers running on other clouds may continue to be accessible.
Another way that containers can be used as a defensive mechanism is to design your application so that the containers act as stateless Web frontends. As such, any DDoS attack that is coming from the Internet will be targeted against the containers, rather than against backend components such as databases or application-related services. In other words, the container can be used as a shield for backend components.
Of course adopting a frontend/backend configuration isn’t sufficient by itself. If a DDoS attack were made against a Web frontend, the container would most likely proxy the malicious requests to the backend, which would eventually become overwhelmed. As previously noted, however, a DDoS attack can occur at any layer of the stack, including layer 7—the application layer. Fortunately, this is the type of attack that containers might be best able to defend against.
Even if a container is designed to act as a Web frontend that proxies requests to a backend server, there is no rule that says that the container has to proxy every request that it receives. Intelligence can be built into the container to look for signs of a potential DDoS attack. For example, if it is determined that a live person would never be able to make more than two or three requests per second, then a session that is generating an unrealistic number of requests can be assumed to be under the control of some automated process. The container could be configured to drop such a session, rather than taking the risk of overwhelming the backend by proxying requests on the session’s behalf. Even if the container itself were to become overwhelmed, the application as a whole should continue to function because of container scalability and the shielding of backend services.
In the end, containers are not a silver bullet solution for mitigating the effects of a DDoS attack. Even so, containerized applications can be structured in such a way as to make the application largely resistant to attack. The keys to achieving resistance to DDoS attacks are distributed scalability and application-level intelligence.
Subscribe to our blog for cloud-native security updates, or get in touch for a demo.
Follow us on Twitter
Keep up to date with the latest news from TwistlockLabs and TwistlockTeam.
Cryptomining Malware Emerges
I have been watching for the spread of malware that, primarily, uses c...
Calling the Twistlock API from PowerShell
The Problem This morning, a colleague was looking for situations where...
What Makes Distributed Security ‘Cloud Native’: Podcast Overview
I caught up with Scott Fulton III on this edition of The New Stack Mak...
Reflections on the 20th Anniversary of Open Source Technology
Exactly twenty years ago in February 1998, the term “open source” ...
Enhanced Syslog Data Streams: 2.3 Deep Dive
In each of our Twistlock releases, we publish some truly remarkable fe...