Defeating Cloud-Targeted DDoS Attacks
Defeating Cloud-Targeted DDoS Attacks – As more organizations have moved their web applications to the cloud, many executives had expected that DDoS (Distributed Denial of Service) attacks would no longer be a problem. Since the cloud is inherently more resistant to volumetric DDoS, it seemed that cloud adoption would protect organizations against these types of attacks.
Unfortunately, this is not true. Although the cloud naturally mitigates some forms of DDoS (as will be discussed below), hackers have developed new attacks to compensate. Therefore, these threats must still be protected against, even in a cloud environment. In fact, some new types of DoS (Denial of Service) attacks only work when the targeted site is in the cloud.
As cloud adoption continues to grow, it’s important for executives to understand these new threats. Fortunately, once they are understood, it is not difficult to mitigate them.
Why does the cloud mitigate traditional DDoS?
Traditionally, DDoS attacks have been volumetric. The attacker sends massive volumes of traffic to the targeted site, intending to overwhelm it and make it unavailable to its intended users.
The rise of cloud technologies has made this more difficult for threat actors. When an organization moves to cloud, it enjoys an inherent resistance to volumetric DDoS. There are multiple reasons for this.
First, the major cloud providers make it easy to set up load balancing and autoscaling. As increasing amounts of traffic come in, more resources are deployed automatically, and the traffic is distributed evenly and efficiently across the backend servers. Plus, the cloud provides near-infinite bandwidth. Even massive DDoS assaults can be comfortably handled.
The major cloud providers also include native tools with basic volumetric DDoS mitigation. Although they are not effective against more innovative forms of DDoS, they still can filter out a large percentage of hostile traffic, and as native tools, they are simple to use.
Lastly, cloud architectures make it possible to deploy web security solutions as reverse proxies, running in front of the protected web applications. These solutions block hostile traffic, including DDoS traffic, in the cloud before it reaches the backend site. Unlike on-premise appliances, these solutions prevent DDoS traffic from saturating the incoming Internet pipe. And they too can load balance and autoscale, adjusting resources dynamically to scrub incoming traffic in whatever volumes are necessary, all with minimal latency.
When an organization moves its web assets (its sites, web applications, and APIs) to the cloud, it enjoys many benefits, including the resistance to DDoS described above. How then can DDoS still be a problem?
New attack patterns
It’s true that the threat of simple volumetric DDoS is greatly reduced by the factors described above. But today’s threat actors are highly skilled and motivated, and they have developed new techniques that can still be effective even in a cloud environment.
One of the more interesting of these has been named the “yo-yo attack.”
The name comes from the volume of traffic over time; just like a yo-yo, it goes up and down. Yo-yo attacks seek to turn some of the cloud’s advantages against the victim -specifically, the reactive autoscaling behavior of modern LB (load balancer) systems.
Here’s how it works. The attacker begins by sending the targeted system a massive amount of traffic. The target’s LB responds by autoscaling upwards and bringing more resources online to handle it.
Once this occurs, the attacker pauses the attack for a short time. Now the LB is once again receiving only legitimate http/s requests, at a normal volume. But the LB does not immediately autoscale down again.
Instead, its normal behavior is to wait for a short while, to verify that traffic conditions have really changed, before it scales down the backend resources again.
After the extra resources have been brought offline, the attacker repeats the process. Another wave of traffic is sent, to make the LB autoscale upward again. Once it does, the traffic is turned off, until the LB autoscales downwards. This cycle repeats over and over again.
Unlike a volumetric DDoS, the purpose of a yo-yo attack is not (necessarily) to try to knock the targeted site offline. Instead, its goal is to financially damage the victim. Note that for most of each attack cycle, the targeted system has allocated an excessive amount of resources, compared to the amount that is actually necessary to process incoming traffic. However, cloud providers charge for many of their resources based on their provisioning and deployment, regardless of whether the resources were being fully used. Thus, by being forced to deploy all the extra resources, the victim can accrue significant expenses—enough to have a substantial financial impact on the victim.
Some researchers have noted that DDoS isn’t necessarily the best description for this type of attack. Its ultimate goal is not to damage the site’s availability to its intended users, but instead, merely to inflict financial damage on the site’s owner. Thus, some are calling these attacks EDoS, for Economic Denial of Sustainability.
Regardless of the name, these attacks are becoming more common. They are very attractive to the attacker, because they are much less expensive to wage than a traditional DDoS. Unlike a normal “flat” volumetric assault (with a constant volume of incoming traffic), here the attacker is only sending traffic in short bursts and for a small portion of each cycle. Therefore, the attackers perceive yo-yo attacks as a high-leverage way to accomplish their goals; they can inflict substantial damage on the victims with a small amount of attack resources.
How to mitigate them
The good news is that yo-yo attacks can be defeated. There are several ways to accomplish this.
First, a good web security solution will mask the details of the backend architecture that it is protecting. As a reverse proxy, it processes all communication with outside users, and it can ensure that all responses are scrubbed of unnecessary details—information that an attacker could otherwise use to customize an attack.
Next, the solution can vary its autoscaling behavior. Simple yo-yo attacks assume that cloud applications use the default parameters for their LBs and autoscalers. Therefore, merely using non-default values can interfere with the attack pattern.
For more sophisticated attacks, a different approach is required. Some attackers will monitor the responsiveness of the targeted systems, to determine whether or not the victim’s resources have scaled up yet. To defeat this, a web security solution can “spoof” its condition by selectively changing its responsiveness. It can pretend to be sluggish by delaying its responses to those traffic sources which are suspected to be attackers (while still responding immediately to legitimate users and customers). Again, this will disrupt the attacker’s ability to determine the status of the system, and will make the attack far more costly to wage (because the attacker will continue to send more traffic even after resources have autoscaled upwards). Or, it can confuse the attacker by responding with a mixture of sluggish behavior and immediate responses. And there are other defensive techniques which can work as well.
Yo-yo attacks are one of many threats that are currently evolving, in the perpetual cybersecurity arms race on the web. As a result, just like most other new forms of attack, only the best security solutions are able to consistently mitigate them. And here’s an important point: the native security tools included in the major cloud platforms are functional, but they are limited in scope. They cannot handle the latest threat vectors, including yo-yo attacks.
Therefore, if your organization is using the native cloud tools, you should ensure that you are augmenting them with appropriate third-party solutions. The best security solutions will handle these attacks for you, along with many other threats that are beyond the scope of the tools included with the major cloud platforms.