IJCNC 08

A SURVEY ON CDN VULNERABILITY TO DOS ATTACKS

Maurizio D’Arienzo and Serena Gracco

Dipartimento di Scienze Politiche Universit`a della Campania ”L.Vanvitelli” – Italy

ABSTRACT

Content Delivery Networks (CDN), or ”content distribution networks” have been introduced to improve performance, scalability, and security of data distributed through the web. To reduce the response time of a web page when certain content is requested, the CDN redirects requests from users’ browsers to geographically distributed surrogate nodes, thus having a positive impact on the response time and network load.

As a side effect, the surrogate servers manage possible attacks, especially denial of service attacks, by distributing the considerable amount of traffic generated by malicious activities among different data centers. Some CDNs provide additional services to normalize traffic and filter intrusion attacks, thus further mitigating the effects of possible unpleasant scenarios.

Despite the presence of these native protective mechanisms, a malicious user can undermine the stability of a CDN by generating a disproportionate amount of traffic within a CDN thanks to endless cycles of requests circulating between nodes of the same network or between several distinct networks. We refer in particular to Forwarding Loops Attacks, a collection of techniques that can alter the regular forwarding process inside CDNs. In this paper, we analyze the vulnerability of some commercial CDNs to this type of attacks and then propose some possible useful defensive strategies.

1. INTRODUCTION

The content delivery network is a quite young technology. Some of the first experiments with this approach were carried out in the mid-1990s by the NEXUS International Broad- casting Association, an IT business incubator based in Milan, using it for the streaming distribution of audio-video documents, as well as web services and ftp archives for NEXUS members. The first commercial version of the Content Delivery Network was launched in 1995 by NEXUS itself and its technological and financial potential was immediately un- derstood.

In the following years, the system was also exported to the United States and other Western countries for local usage, but it was in the global Internet that it found more inter- esting applications and greater margins for development. In 1998 a former Massachusetts Institute of Technology student founded Akamai, a leading global provider of CDN ser- vices. Akamai, which provides its performance to giants such as Adobe, Audi, Apple, IBM, Nintendo, IKEA, Reuters, and many others, make a mirror copy of the content of the client company’s servers and saves several copies on different servers in its network. Although the URL remains the same, the user is automatically redirected to one of the Akamai servers, selected according to the type of file requested and the geographical location of the user. All this happens in a transparent manner, that is, without the user noticing it and, above all, without the quality of the services they want to use being affected.

The effective expansion of CDNs across the Internet, where a rising number of websites are being put behind CDNs, has been attributed to CDN providers’ promotion of its capacity to defend against DoS attacks. It is generally accepted that CDN suppliers offer good DoS protection for the CDN-powered websites since the CDN absorbs distributed assault traffic with its enormous bandwidth capacity [1] [2]. However, CDNs are exposed to a particular type of attack where endless cycles of requests traveling between nodes of the same network or across multiple different networks can jeopardize the stability of a CDN

by creating an excessive quantity of traffic within it. Such attacks, namely Forwarding Loop Attacks [3], handle a single request repeatedly or endlessly, consuming unnecessary resources and increasing the risk of DoS attacks. In this paper we survey the effects of four type of attacks, the self loop attack, the intra-CDN loop attack, the inter-CDN loop attack, and the dam flooding, a highly damaging type of loop attack. Novel type of attacks, aiming either at starving the bandwidth or the connections of the origin server [4], as well as other type of DoS attacks are recently arising as a possible threat for CDNs [5] [6] [7], and are out of the scope of this survey

2.ARCHITECTURE AND OPERATION OF A CDN

Content Delivery Network means a network of computers and servers, connected to each other via the Internet and used to distribute large files and data, such as movies, and live TV. CDN is a network within the network: dozens of servers (sometimes even hundreds or thousands) spread over five continents, hosting the same content (usually movies and other large multimedia files), making it available to computers all over the world. The aim is to optimize the content delivery process to the various nodes of the Network that request it, ensuring that any peaks in requests do not have a negative effect on server performance[8][9].

Figure 1.Load distribution between Edge Servers in a CDN

Especially when dealing with media files, such as live streaming of TV events or movies,centralized systems based on a single distribution server can suffer significant performance degradation.This inevitably has negative effects on the audio and video quality of the distributed content: thanks to CDN it is possible to overcome this problem by diverting traffic to other servers, a perfect copy of the original, while maintaining the performance of the Network and the quality of the distributed content[10].

The four parts that generally make up a CDN are:
– Content Delivery: source web server plus CDN’s set of Edge Servers;
– Request Routing: routes content requests to Edge Servers;
– Distribution: replicates content from Origin to Edge Server, and manages content con- sistency
(expiration, on-demand/periodic update, update propagation);
– Accounting: produces logs, statistics, and analysis for the site administrator.
The heart of a CDN, and also the part a webmaster has to deal with, is the Request Routing. In particular,
this part is of fundamental importance because it also establishes how the content is replicated, and
therefore also sent to users. The main Request Routing devices (including Edge Server), are nothing more
than authoritative Name Servers, with functions to control and monitor network traffic. By definition, a
name server is absolute for a host if it always has a DNS record that translates the hostname of the host to the IP address of that host. When an absolute name server receives a request from a root name sever, it gives a DNS response that contains the requested correlation. The root server then sends the correlation to the local name server, which in turn runs it to the requesting host. Many name servers act as both local and absolute name servers [11]. So, the Request Routing handles what content to replicate, then how to send it to users[12].

3.VULNERABILITY OF A CDN

In this section, we present the key mechanisms that can be used to undermine a CDN by using
four different types of attacks that exploit the flexibility of CDNs in terms of configuration of
forwarding requests, and can compromise the stability of the entire system [13][14][15].

3.1. Collecting IP Addresses of Edge Servers
The identification of the edge servers of a CDN is based on the resolution of the hostnames from URLs served by the CDN using for example public platforms like PlanetLab or DipZoom, which allows to process a large amount of data in a short time [16]. To this purpose, if we consider the Coral CDN, a free peer-to-peer content distribution network running on PlanetLab, we can draw up a list of URLs served by it; then we randomly select a URL and resolve its hostname in its IP address from each of the DipZoom measurement points located all over the world. You can repeat this process for several hours to discover all 263 unique IP addresses of Coral’s servers. A similar but much slower procedure exploits the nslookup command to find the IP address of an edge server of the CDN assigned to our device as shown in the following figure. Once the IP address of the edge server is retrieved, we describe the next step