Distributed denial of service attacks from and against the cloud

Cloud Wars

Anycast DNS for Defense

In its defensive actions for Spamhaus, CloudFlare, the provider of the content delivery network (CDN) rescued its customer with a clever trick: With the help of anycast addressing with load balancers and a private CDN using nodes in a total of 23 data centers, they managed to intercept the flood of data in the cloud.

The most common type of addressing on the Internet is unicast , in which a unique IP address belongs to precisely one host. In anycast, however, a single IP address is assigned to multiple hosts, and the router provides the data packets to those hosts with the destination address that is geographically closest. Thus, the data packets always take the shortest route and end up on a number of servers, not just one.

In the case of Spamhaus, CloudFlare spread the victim's IP addresses across 23 different data centers in this way. The shares that reached each data center were filtered by various criteria. The data packets were finally only sent to Spamhaus, after they had passed tests proving that they were legitimate. This allowed CloudFlare to separate the wheat from the chaff and discard the malicious requests.

CloudFlare takes this anycast idea to the extreme and assigns the same IP address to all of its customers. This strategy, which the provider dubbed Global Anycast DNS, makes it impossible for the attackers to focus on one target. Load balancers always forward requests to the nearest data center with spare capacity. Thus, no single element of the cloud infrastructure can collapse from the flood of data (there is no single point of failure).

Global anycast DNS is already available from CloudFlare in the scope of a free basic subscription. Similar services are also offered by other commercial CDN providers, including Akamai, Neustar, OpenDNS, and Prolexic.

SMURF and ACK Reflection Attacks

In a SMURF attack, the attacker sends ICMP packets to third parties with a spoofed source IP that points to the victim. The attackers target a router that is responsible for forwarding ICMP requests to other devices. By addressing the associated broadcast address (xxx.xxx.xxx.255), the perpetrators can reach all devices in the respective network behind the router. Because of the lack of a handshake procedure when connecting, the receiver cannot distinguish legitimate from illegitimate requests, and by properly responding to the ICMP request, they bombard the victim with their IP packets. To prevent such an attack, you just need to suppress ICMP request forwarding on the affected routers.

An ACK reflection attack makes use of the TCP three-way handshake. A TCP client initiates the connection by sending a SYN packet. On receiving this packet at an open port, the server responds with a SYN/ACK packet to accept the connection. It allocates memory, writes to the log, and waits for the final ACK response of the communication partner to acknowledge receipt of the message. In an ACK reflection attack, however, the source IP in the SYN request is spoofed; thus, the server sends a reply to the wrong recipient, that is, the victim.

For a successful defense, the message recipient needs to discard unsolicited incoming handshake packets.

Web Workers and Cross-Origin Requests

In a DDoS attack with Web Workers, the attackers take advantage of a part of the HTML5 specification: cross-origin requests. In the first step, they attract web visitors to a website by planting a link, for example, in an image or a script like a cuckoo's egg. The website then starts a Web Worker, which causes the browser to send cross-origin requests to the victim. These are preferably based on a URL that causes the server hard work.

However, further requests would be prevented if it did not receive a valid answer to the Access-Control-Allow-Origin header. Therefore, the URL must be modified slightly for each instance of access. Thus, just 6,000 unsuspecting users of a browser like Chrome can generate a flood of up to one million requests per second.

Attacks of this type can be prevented just as easily as they are triggered: Because all cross-origin requests include the Origin header, you just need a setting on the firewall to prevent such requests via the header.

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=