Distributed denial of service attacks from and against the cloud

Cloud Wars

Scalability: A Double-Edged Sword

IT security experts have been focusing their efforts on two phases of a DDoS confrontation: preventive measures and subsequent improvements. So far, people have been able to sit out the DDoS attack, but that is no longer possible with DDoS in the cloud. If you still implement this two-phase defense model, you could be out of luck. DDoS attacks in the cloud typically last between several days to several weeks and alternately use multiple vectors. IT staff have no choice but actively to counter the DDoS attack.

DDoS from Cloud to Cloud

Hosting CDNs in the cloud is gaining in popularity. However, a scalable cloud architecture provides no protection against DDoS attacks; on the contrary, the attacker can use the victim's own infrastructure to take down IP-based defense mechanisms on the target server. A CDN can absorb attacks with high data volume and considerably complicate the exploitation of the available resources.

Unfortunately, the cloud offers IT professionals a false sense of security. The CDN forwards requests for dynamically generated data to the origin server. By slightly modifying requests for non-existing data, the attacker can cause the CDN to kick off a DDoS attack against its own data center. The offenders can also work around the CDN with cache directives in the HTTP header (e.g., with cache-control: no-cache or Pragma: no-cache).

If malicious requests are routed by the CDN to the origin server, they also undermine existing security systems because they now identify themselves with a trusted IP address of your own CDN. The result is a DoS attack by your own CDN on your own data center. In this case, illegitimate requests cannot be identified by IP address or blocked on the basis of volume of data. Load distribution of incoming attacks across different nodes of the CDN ensures that they are multiplexed with legitimate data streams and thus unrecognizable; they then bombard the target systems in a highly concentrated attack.

The only way to distinguish legitimate from illegitimate requests in an attack from your own CDN is to inspect the HTTP headers. Only the X-Forwarded-For header (XFF) sheds some light on the origin of the request and then allows selective blocking of the attack on the basis of the IP address.

Buy ADMIN Magazine

Get it on Google Play

US / Canada

Get it on Google Play

UK / Australia

Related content

comments powered by Disqus
Subscribe to our ADMIN Newsletters
Subscribe to our Linux Newsletters
Find Linux and Open Source Jobs

Support Our Work

ADMIN content is made possible with support from readers like you. Please consider contributing when you've found an article to be beneficial.

Learn More”>


		<div class=