Complementary Architectures for Preventing and ... - Semantic Scholar

Complementary Architectures for Preventing and Combating Denial-of-Service Attacks

Felipe Huici email: phone:

Supervisor:

[email protected] +44 (0)20 7679 0401

Prof. Mark Handley

A document submitted in partial fulfillment of the requirements for a PhD 1st Year Report at the University of London Department of Computer Science University College London

November 16, 2005

iv

Abstract Years after their first appearance, Denial-of-Service (DoS) attacks continue to grow and the motivation behind them has become criminal. The research community has brought forward numerous proposals to the problem, but most of them, despite their technical merit, have encountered difficult deployment problems. Commercial solutions and services exist, but they are only affordable to large institutions. As a result, DoS attacks continue largely unabated. This report presents a work plan for a thesis consisting of a deployable architecture aimed at preventing attacks before they reach the victim; a second, complementary architecture seeking to mitigate attacks once they have begun causing damage to the victim; and work on designing and implementing efficient filtering data structures.

vi

Contents

1 Introduction and Motivation

3

2 Deficiencies in Existing Work

5

3 Proposed Contribution

9

3.1

3.2

3.3

Efficient Filtering Data Structures . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

9

3.1.1

Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

10

3.1.2

Testing the Proposal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

10

3.1.3

Expected Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

11

3.1.4

Time Scale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

11

Preventing DoS Attacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

11

3.2.1

Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

12

3.2.2


12

3.2.3


13

3.2.4

Time Scale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

14

Combating DoS Attacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

14

3.3.1

Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

14

3.3.2


15

3.3.3


15

3.3.4

Time Scale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

15

A Time Table

17

B Bibliography from Adjunct Report

19

Bibliography

23

2

Chapter 1

Introduction and Motivation In its early days as the ARPA net, the Internet placed an intrinsic level of trust on its users. Its actual users were, after all, all directly involved in its development. As the Internet expanded to its current size, more and more services and trust were placed on it, including the World Wide Web, Internet telephony, and more recent developments such as the move of cellular networks towards IP and Internet TV. Along with its increased capabilities, however, came a much larger user base, some of which began investigating the network’s vulnerabilities with malicious intentions. One of the attacks that the Internet is vulnerable to is called a Denial-of-Service (DoS) attack. Such an attack has the goal of exhausting a service’s resources (such as network bandwidth, disk space, or CPU time) so that it cannot attend to its legitimate users. A variation on this theme are Distributed Denial-ofService (DDoS) attacks, in which a single victim is attacked by a large number of hosts, typically spread throughout the Internet. The attacking hosts are generally owned by unsuspecting victims who have been infected through a software vulnerability either in the operating system or any of the other packages running on the system; such an infected host is called a zombie or bot. The infection process is accelerated by software programs called worms that can take over thousands of machines in minutes [20], creating large botnets. This infection rate compounded with the fact that many of the bots have broadband connections to the Internet ensure that even a large web site can be taken down with only a bit of expertise and few personal resources. To make matters worse, even those without much expertise can mount an attack: botnets can actually be purchased for a few cents per bot [8]. Their size is also alarming: botnets consisting of hundreds of thousands of bots have been spotted in the wild in today’s Internet, while a recent report stated that Dutch “bot herders” may have controlled as many as 1.5 millions hosts [6]. The motive behind DoS attacks has also been evolving. Originally they were carried out by “script kiddies”, usually teenagers who downloaded attack code and ran it as a curiosity or for bragging rights. Recently, attacks have gained a much more aggressive nature, knocking big companies such as DoubleClick, Yahoo, Google and Microsoft off the Internet for hours at a time [9][10]. One of the most common motives behind DoS attacks is extortion, demanding that the victim pays a certain amount to remain online. More often than not the victim pays because, even though anti-DoS services exist, these tend to be more expensive than paying the attacker and only larger companies can afford them [3]. The

Chapter 1 attackers themselves are no longer amateur criminals: a significant number of the attacks are being carried out by gangs and Mafia-style organizations [14][16], and while there have not yet been reports of terrorist-led DoS attacks, it seems plausible that they will eventually become a reality. Even worse, the true extent and number of DoS attacks is currently under-reported, since most companies are very reluctant to admit that they have been attacked. Clearly then, DoS attacks present a difficult challenge that must be solved or at least significantly mitigated if the Internet is to continue to grow unhindered. While companies such as Cisco, Arbor Networks and Mazu Networks provide anti-DoS hardware and others provide anti-DoS services, the problem continues to intensify. In order to remedy the situation, a more fundamental and architectural change to the Internet is needed.

4

Chapter 2

Deficiencies in Existing Work While Denial-of-Service attacks have gained considerable notoriety recently, they have existed since the late 1990s. As a result, research in the field has produced numerous and varied schemes aimed at solving or at least mitigating the effects of these attacks, specially those of large, distributed DoS attacks. In previous work, Mark Handley and I produced a report summarizing research solutions in the area, describing each of them and then analyzing how likely they were to deployed in the near future (the report is attached to the end of this document, while a list of its references can be found in Appendix B). The report presented a taxonomy of solutions, discussing the merits and drawbacks of each category. While there are solutions that do not cleanly fall into one of these categories, many do, and so this classification provides a useful organizational aid. Following is a listing of these eight categories (for a more detailed analysis of each of the solutions please refer to the report attached): 1. Architecture Solutions in this category tackle the problem of DoS attacks at the root, changing the network itself so that it will help victims or altogether prevent attacks. While the proposals would have a serious impact on the problem, they generally face significant deployment issues and part of each solution must be a viable deployment story. 2. Anti-Spoofing Mechanisms Even though source IP address spoofing is not directly responsible for DoS attacks, its presence exacerbates the effects of such attacks, specially in terms of tracking down where an attack is originating from. While currently most attacks do not bother spoofing, this is likely to change as traceback mechanisms improve. Ingress filtering could prevent spoofing altogether, but it requires widespread deployment for it to be effective, something that has not yet happened. As a result, alternate research solutions such as Hop-Count Filtering could prove useful (See Appendix B for the reference to this paper). 3. Packet Marking One key aspect of combating a DoS attack once it has started is to be able to identify its sources. This would be trivial using IP except for the fact that it is up to the sender to say where a packet comes from, opening the possibility of spoofing. As a result, several proposals have been made

Chapter 2 that let the network help the victim trace the attack hosts by adding information to packets as they travel from source to destination. Even though several of the solutions in this category are quite sensible, they require a reasonable level of deployment to work: the more complete the traceback path from the victim to the attackers is, the more likely it is that the victim will be able to request that traffic be stopped far from itself, before it has had a chance to aggregate to a significant degree. 4. Traffic Policing and Filtering These approaches seek to install filters at points away from the victim, with the idea of preventing attack traffic from aggregating. In the year 2005, two more papers that roughly fall under this category were published in conferences. In [2] the authors build on previous work, describing a scheme for distributed filtering away from the victim. This proposal has merit, but perhaps its weak point is its incentive for initial deployment: sites hosting victims have a clear financial incentive to protect its clients; the paper claims, however, that sites hosting attackers also have an incentive for deployment, because otherwise the scheme will filter the whole site’s traffic. Whether this policy is reasonable is open to debate. The second paper is different and complementary from the description given so far, aiming to filter traffic at the victim [11]. In general, filtering solutions show promise, but like most anti-DoS proposals the deployment story needs careful thought, in particular the incentives for initial deployment. 5. Service Differentiation and Capabilities Solutions in this category attempt to tackle one of the basic enablers of DoS attacks: senders can send traffic to a destination without the receiver’s consent. The idea is to have senders request permission to send from the destinations and to have check points along the path verify that no unauthorized traffic is flowing towards the destination; a recent paper presents such a scheme [21]. While these solutions show theoretical promise, they face severe deployment challenges: not only do they require check points in the network, but they also require changes to end-hosts, and those that cannot upgrade will receive inferior service. A recent paper [1] demonstrates that even the channel used to request permission to send is vulnerable to attack. 6. Source Routing Source routing is not directly intended as a DoS solution, but the fact that it requires a sender to specify a path to the destination and that the network checks that the path is valid eliminates spoofing. Trace back to an attacking source becomes trivial, since the victim has the full path back to the attacker. Unfortunately, like any scheme that requires significant non-incremental changes to the basic network infrastructure, source routing faces perhaps unsurmountable deployment issues. 7. Overlays The idea behind overlays is to deploy a set of special nodes on top of the underlying network to protect against DoS attacks. The advantage of such approaches is that an overlay network can be deployed without changing the topology of the underlying network. Overlays, however, have their 6

Chapter 2 problems: they require a significant number of nodes to be effective and to be able to sustain an attack on the overlay itself. Further, overlays can have routing inefficiencies, since two adjacent overlay nodes could be geographically far apart. Finally, if the underlying network is unprotected, an attack that overfloods its bandwidth capacity will also render the overlay ineffective. 8. Proof of Work These solutions attempt to diminish the ratio of the amount of work that a server must perform to the amount of work performed by a client. To do so, a server under attack issues computationallyexpensive puzzles that the client must solve before its request is fulfilled. While in theory the premise is reasonable, in practice proof-of-work suffers from several problems. Even if the server does little work compared to the client, an attack with thousands of clients will eventually overload the server. In addition, puzzles tend to ignore the several orders of magnitude in computing power that may exist between a server’s clients. A related solution consists of issuing captchas [19] when the server is overloaded, whereby a client has to usually type a word that is shown in a fuzzy image, a task that is trivial to a human but hard for a computer program. Such an approach could be used as a complement to an overarching DoS solution. Another area of research which is very closely related to DoS attacks is fast filtering. Even if a scheme manages to install the right filters at the right points in the network, if each of these is not able to filter malicious traffic efficiently, legitimate traffic will suffer. More specifically, the look-up mechanism of the data structure used to store the filters must be quick, preferably performing the operation in constant time. Recent papers in this area suggest that this may be accomplished using hashes and a variant on them called Bloom filters [5][18]. Whether it is possible to accomplish significant rates using off-the-shelf memory and hardware is still in the research realm. Commercial DoS solutions exist from companies like Cisco, Arbor and Mazu. However, these do not inter-operate and are meant to provide point or site protection against DoS attacks, not scale to architectural levels. In addition, if an attack is large enough it can still bring down a site protected by this type of hardware. Finally, these boxes are expensive, and a large number of ISPs and server owners cannot afford them. Clearly a cheaper solution based on commodity hardware would be of great help. Regarding research solutions to the DoS problem, it is the architectural and filtering solutions that show the greatest promise in terms of being scalable and effective against large, distributed attacks. However, a common pattern exists among all solutions, namely the difficulty in finding reasonable deployment incentives, particularly in the beginning. Indeed, it seems that the reason a significant number of research approaches failed despite their technical merit has been deployment issues. Consequently, a successful solution has to combine both technical merit and the possibility for incremental deployment. In the next chapter I present architectures that aim to meet these requirements as well as a proposal to investigate efficient data structures for filtering.

7

Chapter 2

8

Chapter 3

Proposed Contribution Over the years, researchers have proposed many solutions to Denial-of-Service attacks, several of which had considerable technical merit; however, none have seen significant deployment, and DoS attacks continue largely unabated, despite the existence of commercial products and services. The current situation is due to a combination of factors. Many of the research solutions, while theoretically feasible, lack convincing technical and economical incentives for initial or incremental deployment; many, in fact, need a large degree of deployment to be effective against attacks. Commercial solutions, while comparatively easy to deploy, are expensive and therefore restricted to large customers. The challenge is then to design and build architectures that will be effective against DoS attacks and that are economically reasonable: any solution that presents deployment obstacles, either technical or economical, is unlikely to succeed. Rather than designing a single complex architecture to handle DoS attacks, it is possible to break the problem down into a couple of complementary architectures. One logical way to divide the problem is to first design an architecture that will aim to prevent DoS attacks by automatically detecting an attack and taking countermeasures without the involvement of the victim. Since the detection mechanism would have to be somewhat conservative to avoid filtering good traffic, another architecture would then be in charge of fighting an attack that slipped past this first architecture, with the victim directing the defensive response. In addition, it would be ideal if these architectures could be implemented on commodity hardware while still being effective: deployment would then be economically feasible even for small victims, an issue that current commercial offerings do not address. Finally, a crucial element to the performance of both architectures is efficient filtering to separate good from malicious traffic. The rest of the chapter is organized as follows: section 3.1 discusses this issue of filtering; section 3.2 describes the architecture that aims to prevent DoS attacks without the victim’s intervention; and section 3.3 explains the second architecture in charge of combating an attack once it has reached the victim. It is worth noting that this order is not necessarily a reflection of the chronological order in which the thesis will be carried out; please refer to the time table in Appendix A to obtain such information.

3.1

Efficient Filtering Data Structures

A fundamental task of a successful solution against Denial-of-Service attacks is separating the good traffic from the bad by installing the correct filters at the right positions in the network. However, if the

Chapter 3

3.1. EFFICIENT FILTERING DATA STRUCTURES

control point cannot check its installed filters fast enough, it will be forced to drop traffic, regardless of the quality of the filters; clearly then, efficient filtering (specially efficient look-up time) is a crucial element of mitigating DoS attacks. I propose to look at fast filtering data structures that will take advantage of the CPU and memory available in commodity hardware. More specifically, I intend to investigate the following areas: • What should the format of a filter be and at what network layer should it operate? Generally, the more expressive a filter, the less efficient its storage and subsequent look-up will be. A good start would be to look at a simple source and destination filter and a prefix-based filter at the IP level. • The applicability of Bloom filters. Since these are memory-efficient membership hashes that yield no false negatives, it should be possible to keep them in the CPU’s cache and, if so, to quickly determine whether or not a filter exists. • The efficiency of hashes to store the actual filters, including a small study of separate chaining, open addressing and the possibility of perfect hashing. This study should look into protecting the hashes from complexity attacks [4] and whether cryptographic hashes are applicable. • The possibility of exploiting the advantages of multi-port memory. In the case of prefix-matching, for instance, it could be possible to create a separate Bloom filter for each prefix, allowing the search operation on each of them to be carried out in parallel. • The possibility of exploiting multi-core processors. While look-up operations tend to be memorybound, more CPUs mean more CPU caches and, consequently, parallel access to memory. • An analysis of the expected performance of the data structure in the worst and common case. • The possibility of using a load balancer to scale the filter’s performance.

3.1.1

Assumptions

Simplifying assumptions will have to be made with regards to what constitutes attack traffic, how many and which kinds of installed filters would be realistic to have at a filtering point, and how to measure whether a filter is efficient or not.

3.1.2

Testing the Proposal

The proposal will be tested using the Click modular router platform [12] on the Network Research Group’s Heterogeneous Experimental Network (HEN), an easily-configurable network that will consist of a large number of computer nodes. Over the past few months the group has been putting a substantial amount of effort towards HEN to ensure that it will be running with at least 30 or so nodes early next year. HEN allows users to quickly create varied network topologies, allowing for efficient hardwarebased experimentation. This sub-section concludes with a discussion of metrics and scenarios that will be used to test the success of this proposal’s implementation. 10

Chapter 3

3.2. PREVENTING DOS ATTACKS

• Metrics: The clear metric to measure the performance of a network filter such as this is simple throughput, either in terms of packets or bits per second for minimum-sized packets. The key will be to determine the maximum throughput beyond which the filter becomes saturated and begins dropping packets arbitrarily; ideally this would equal the rate at which the underlying platform, Click, can process packets. If Bloom filters are used, care will have to be taken so that the data structure does not become over-saturated and begins yielding an unacceptable percentage of false positives. • Scenarios: The first and simplest topology will consist of a sending host, a filtering host and a counting host on the other side of the filter. The first experiment will focus on establishing the maximum rate beyond which Click will drop packets even without the filter being active. With this in place, the next experiment will be to send only legitimate traffic (that which should not be filtered) and measure the filter’s throughput, followed by a similar experiment in which only malicious traffic is sent. In both these experiments it would be worth varying the traffic rate, the number of installed filters as well as the IP header fields that the hashing is based on to establish a general idea of the filter’s performance. In terms of the types of filters, the idea is to begin with simple filters such as matching source and/or destination IP addresses, and then moving on to more complicated schemes such as prefix matching. Beyond the basic topology discussed so far, a more complex one will be used with more sending hosts, mixing legitimate and malicious traffic and measuring the filter’s performance as the ratio of one to the other changes, while varying once again the number of installed filters. More involved topologies could then be used to investigate the issue of scalability by adding a load balancer and several filtering hosts behind it.

3.1.3

Expected Results

Ideally, the implemented filter should be able to process packets as fast as the Click platform can receive them and forward them; in other words, the filtering elements should not have a significant impact in the maximum forwarding rate of the router, even for minimum-sized packets (I recently conducted an informal study on Click’s forwarding performance to establish what this baseline is; the study is attached to the end of this report).

3.1.4

Time Scale

This proposal should take approximately 4 months to analyze, design, implement and test.

3.2

Preventing DoS Attacks

Many of the research solutions for DoS attacks are reactive, waiting for an attack to strike the victim before taking countermeasures. This section describes a complementary architecture to such approaches that seeks to mitigate an attack before it arrives at the victim. The basic idea is to set up a number of control points forming a ring of protection around the victim. These control points monitor traffic going to the victim and share this information with each other, thus detecting even distributed attacks (note that while this section uses the term “victim” in the singular, a ring would be able to protect several hosts at 11

Chapter 3


once). From this general description arise several issues that would need investigation: • Attack Detection: One approach is to baseline “normal” traffic, compare the current traffic to this baseline, and have the control points communicate anomalies to determine if an attack is taking place. Another possibility is to have the server export its capabilities to the ring, perhaps in terms of throughput or connection per second, with the ring then taking care of mitigating traffic if it exceeds these capabilities. Another option would be to monitor whether traffic is largely symmetrical: in the case of TCP, the ring could ensure that the number of ACKs roughly equals the number of packets being sent by the server (this idea was suggested in [13]). • Countermeasures: Once the ring determines that an attack is taking place, it can take several actions: rate-limit connections or throughput; re-direct traffic to perform some sort of scrubbing including spoof-detection or perhaps even redirect traffic to a honeypot for closer monitoring of the attack and for post-mortem analysis; force clients to perform connections hand-shakes at the ring before allowing traffic through to the server; effect application-specific measures such as issuing captchas to distinguish a bot from a human user (in which case it would be useful to survey Internet traffic to determine which kinds should receive the most protection); notify the victim, allowing it to take local measures such as, in the case of a web server, serving text-only pages; contact upstream rings if they exist; or allow the victim itself to specify the countermeasures ahead of time and mitigate the attack according to these. • Scalability and Deployment: Initial deployment could start at the edges, with an ISP installing a ring and selling protection to its direct customers. Expanding this to a multi-ISP scenario would raise the difficult issue of inter-ISP collaboration, though an ISP could pay its upstream ISPs for the added protection, selling this as a premium service to its customers (the larger and farther away from the victim a ring is, the higher the cost of protection to the victim will be). From a technical point of view, larger rings raise issues of scalability that will need to be addressed, including the type, frequency, and amount of information that the various control points in a ring exchange with each other.

3.2.1

Assumptions

One basic assumption is that the larger the ring, the better the protection against distributed attacks. While this seems certainly the case for small rings, careful thought will be needed to ensure that the protocol used for communication between members of the ring is efficient and responsive enough for larger rings. Analysis should also be carried out to see how the protocol reacts when increasing the number of hosts to protect as well as the degree to which an attack is distributed. In addition, it is also unclear what a realistic scenario would be, how big a ring should be compared to the number of attack hosts or how many victims it should be able to protect.

3.2.2


HEN will once again provide an ideal test environment, not only because of its number of nodes and flexibility, but also because it is a private and isolated network, preventing test Denial-of-Service traffic 12

Chapter 3


from escaping into the Internet. Following is a discussion of performance metrics and possible test scenarios and topologies.

• Metrics: Since details of DoS attacks are hardly ever made publicly available, there is no widely accepted method for measuring the effectiveness of a DoS solution. Even so, a few possibilities seem reasonable. Since the architecture is trying to protect the victim, this provides a logical point from which to measure the proposal’s performance. Perhaps the most obvious metric is to compare the raw throughput at the server before and after the ring has determined that an attack is occurring, and also determining what percentage of the server’s traffic that reaches the ring actually reaches the victim. Since the type and amount of traffic generated will be controlled, the next metric will consist of measuring what percentage of the legitimate and malicious traffic hitting the ring actually reaches the server. Another important metric will be to measure how quickly the ring reacts to changes in the incoming traffic; in other words, measuring how long the ring takes to meet a server’s exported capabilities once the traffic has changed. A related metric will be to measure the time between an attack appearing and the ring installing filters to mitigate it. While this discussion defines units, it is still unclear what values should be obtained to consider the architecture effective. In terms of traffic, the extremes are clear: filtering only a small percentage of malicious traffic is unacceptable, while filtering all of it is perhaps unattainable, leaving a large grey area in between; response time presents similar issues. Setting a basic working architecture and measuring its performance should begin to give an idea of where a compromise between these extremes might lie.

• Scenarios: The proposal outlined in this section is rather open-ended. Consequently, the best approach will be to build the most basic components of the architecture and then implement some of the other solutions mentioned earlier incrementally if time permits. The first topology will consist of a ring of three hosts (a minimum number to test communication among ring members), a victim, and a few sending hosts, perhaps six, so that each ring member will have a malicious sending host and a legitimate one. With this setup, it should be possible to implement and test a simple ring protocol to communicate basic, per-destination throughput information and then ratelimit traffic when these statistics surpass a certain threshold. Constructing this basic architecture could give insight into other solutions to the problem and will provide the pillars on which more involved defenses can be built. Other topologies might consist of adding victims to the same ring, expanding the ring and increasing the number of sending hosts.

3.2.3

Expected Results

The basic implementation should be able to detect an attack and reduce the amount of traffic arriving at the victim or victims, though it will act as a simple rate-limiter, not distinguishing between malicious or legitimate traffic. 13

Chapter 3

3.2.4

3.3. COMBATING DOS ATTACKS

Time Scale

The basic architecture should take approximately 3 months to analyze, design, implement and test. Additional components will be added if time permits.

3.3

Combating DoS Attacks

Since a number of DoS attacks are bound to slip through the defense provided by the architecture described in the previous section, a second architecture is needed to curtail an attack once it has arrived at the victim. The proposed solution, fully described in [7], consists of setting up special control points called encapsulators that receive traffic going to a protected server, and encapsulate it in an IP-in-IP tunnel towards a second control point near the server called a decapsulator. In this way, the victim, through its decapsulator, knows exactly which encapsulators malicious traffic is coming from, and can request that it is stopped far from itself. All traffic flowing to the victim is forced through encapsulators by controlling the routing protocol, BGP. The proposal is then to implement this architecture, using Click as the platform for the encapsulators and decapsulators. This will involve the following components: • The encapsulator, which needs to be able to perform ip-in-ip encapsulation at fast speeds, ideally in the order of several hundred Mbps. • The decapsulator, which has similar requirements to the encapsulator • The filtering mechanism, which may or may not reside on the same host as the encapsulator. This may include a rate-limiter of some sort. • The control protocol, through which a victim under attack can specify which filters to apply. The protocol should be designed so that it will not provide another avenue for Denial-of-Service. • The BGP daemons in charge of distributing the correct route information. This proposal will use existing ones. • An Intrusion Detection System at or near the victim to determine when an attack is actually taking place. Again, an existing IDS such as Bro [15] or Snort [17] will be used. • An optional load balancer to be placed before the encapsulators. If the performance of one encapsulator is not sufficient to protect that particular control point, it should be possible to install additional units and place a load balancer in front of them to scale performance.

3.3.1

Assumptions

Assumptions will have to be made about the number of encapsulators, decapsulators, servers, attackers and legitimate clients that represent a realistic scenario. This work also depends on the availability of several higher-end computer hosts, but HEN should be able to provide these. In the paper that describes this architecture it was assumed that a Click router could forward minimum-sized packets at a rate of several hundred Mbps; these figures were confirmed through an informal study I conducted in the last couple of months (the study is included as an attachment to this report). Finally, this architecture assumes 14

Chapter 3


that an attack is not spoofing and could, as a result, be complemented by an anti-spoofing solution such as ingress filtering.

3.3.2


HEN will be the main testbed for this architecture, since it provides a large number of nodes that can be easily configured into varied topologies; simulation could be used as a fallback. If the work advances rapidly enough, there is the possibility of deployment at ISPs who have ties with the Networks Group. • Metrics: The metrics for this approach are not too dissimilar to those discussed for the preventive architecture in the previous section, except that instead of measuring the amount of traffic hitting the ring, this time it is the traffic seen at the encapsulators that will be considered; metrics at the victim will be the same. • Scenarios: The first and most basic topology will consist of one sending host, one encapsulator, one decapsulator and one protected server. The first step will be to send only legitimate traffic to make sure that all the different parts of the system such as the tunneling, the control protocol and the filtering mechanism are working properly; this setup will also yield basic performance figures. The next step will entail sending only malicious traffic, mostly to test the filter’s performance in this setup (note that the traffic will be malicious only because the server will be set up to label all traffic from the sending host as such). Following this experiment, another sending host will be added, creating a mixture of legitimate and malicious traffic flowing towards the victim; this will test the ability of the victim to send a control message to separate bad traffic from good traffic and the encapsulator’s ability to perform the actual filtering. It is worth noting that the filtering mechanism itself could reside on a separate host in front of the encapsulator, since it is an independent function from the actual tunneling. A further addition to this setup will be to place a load balancer in front of the encapsulator and split the latter into two hosts, testing the possibility of scaling the encapsulator’s performance. Once satisfied with the performance of the most basic deployment of the architecture, a more complex topology consisting of three encapsulators and several sending hosts will be used to provide a somewhat more realistic scenario. In terms of these sending hosts, factors to vary will be the amount of traffic, the ratio of malicious to legitimate traffic, and how distributed an attack is. Additional topologies will involve adding victims and decapsulators to derive a general idea of what the ratio of one to the other should be.

3.3.3

Expected Results

It is always to difficult to judge how effective a defense against DoS attacks actually is. However, it is expected that the system will be responsive enough to the victim’s requests, so that if an attack is still causing significant damage after an initial request, the victim will be able to send additional ones in order to finally control the attack.

3.3.4

Time Scale

This proposal should take approximately 5 months to analyze, design, implement and test on HEN. 15

Chapter

16


Appendix A

Time Table The following table gives a tentative work schedule for the rest of the thesis. Note that since the various parts of the thesis are inter-related, it is not necessarily the case that they will be implemented in perfect serial order as the table suggests. Since it is difficult to estimate how long it will take to implement these proposals on real hardware, the period between February 2007 and September 2007 will be used to finish the basic proposals if these are running behind or to implement extensions to the prevention architecture or new ideas if the project is running ahead of schedule.

Dates

Description

January 2006 - May 2006

Efficient Filtering Data Structures Design and implementation. HEN setup and testing. Documentation of results.

May 2006 - November 2006

Combating DoS Attacks Architecture Design, implementation and testing. Documentation of results.

November 2006 - January 2006

Transfer report write-up and viva.

January 2006 - June 2007

Preventing DoS Attacks Architecture Basic architecture. Design, implementation and testing. Documentation of results.

June 2007 - September 2007

Extensions Additional components to prevention architecture Other ideas

September 2007 - December 2007

Thesis write-up.

January 2008

Thesis submission.

February 2008 (approximately)

Thesis viva.

Table A.1: Work Schedule

Appendix A

18

Appendix B

Bibliography from Adjunct Report

[1] M. Abadi. Moderately hard, memory-bound functions. In Proceedings of the 10th Annual Network and Distributed System Security Symposium, February 2003. [2] D. Adkins, K. Lakshminarayanan, A. Perrig, and I. Stoica. Brief announcement: towards a secure indirection infrastructure. In PODC ’04: Proceedings of the twenty-third annual ACM symposium on Principles of distributed computing, pages 383-383. ACM Press, 2004. [3] D. Adkins, K. Lakshminarayanan, A. Perrig, and I. Stoica. Taming IP packet flooding attacks. SIGCOMM Comput. Commun. Rev., 34(1):45-50, 2004. [4] D. Adkins, S. Shenker, I. Stoica, S. Surana, and S. Zhuang. Internet Indirection Infrastructure. In Proceedings of the ACM SIGCOMM 2002 Conference, August 2002. [5] M. Adler. Tradeothiry-fourth annual ACM symposium on Theory of computing, pages 407-418. ACM Press, 2002. [6] D. Andersen. Mayday: Distributed ltering for internet services. In Proceedings of the 4th USENIX Sysmposium on Internet Technologies and Systems, March 2003. [7] T. Anderson, T. Roscoe, and D. Wetherall. Preventing internet denial-of-service with capabilities. SIGCOMM Comput. Commun. Rev., 34(1):39-44, 2004. [8] K. Argyraki and D. Cheriton. Loose source routing as a mechanism for trac policies. In FDNA ’04: Proceedings of the ACM SIGCOMM workshop on Future directions in network architecture, pages 57-64. ACM Press, 2004. [9] K. Argyraki and D. Cheriton. Protecting public-access sites against DDoS attacks, May 2004. [10] T. Aura, J. Leiwo, and P. Nikander. Towards network denial of service resistant protocols. In Proceedings of the IFIP TC11 Fifteenth Annual Working Conference on Information Security for Global Information Infrastructures, pages 301-310. Kluwer, B.V., 2000. [11] H. Balakrishnan, F. Dabek, F. Kaashoek, D. Karger, D. Liben-Nowell, R. Morris, and I. Stoica. Chord: a scalable peer-to-peer lookup protocol for internet applications. IEEE/ACM Trans. Netw., 11(1):17-32, 2003. [12] S. Bellovin, S. Floyd, J. Ioannidis, R. Mahajan, V. Paxson, and S. Shenker. Controlling high bandwidth aggregates in the network. SIGCOMM Comput. Commun. Rev., 32(3):62-73, 2002.

Appendix B [13] S. Bellovin, M. Leech, and T. Taylor. The ICMP traceback message, October 2001. [14] S. Belloving and J. Ioannidis. Implementing pushback: Router-based defense against DDoS attacks. In Proceedings of the Network and Distributed System Security Symposium, 1775 Wiehle Ave., Suite 102, Reston, VA 20190, February 2002. The Internet Society. [15] C. Boyd, Michael Frentz, R. Krishnan, D. Mankins, and J. Zao. Mitigating distributed denialofservice attacks with dynamic resource pricing. In Proceedings of the 17th Annual Computer Security Applications Conference, December 2001. [16] H. Burch and B. Cheswick. Tracing anonymous packets to their approximate source. In Proceedings of the 14th Systems Administration Conference, December 2000. [17] Z. Chen and M. Lee. An IP traceback technique against denial-of-service attack. In Proceedings of the 19th Annual Computer Security Applications Conference, December 2003. [18] K. Clay and S. McCreary. Sampled measurements from june 1999 at the AMES interexchange point, January 2000. [19] D. Cook, A. Keromytis, V. Misra, W. Morein, and D. Rubenstein. Websos: Protecting web servers from DDoS attacks. In Proceedings of the 11th IEEE International Conference on Networks, September 2003. [20] Inc. Cs3. Mananet: Infrastructure-level ddos defense. [21] D. Dean, M Franklin, and A. Stubbleeld. An algebraic approach to IP traceback. ACM Trans. Inf. Syst. Secur., 5(2):119-137, 2002. [22] S. Deering and R. Hinden. Internet protocol, version 6 (IPv6) specication. RFC 2460, December 1998. [23] S. Deering and J. Mogul. Path MTU discovery. RFC 1191, IETF, November 1990. [24] S. Dietrich, D. Dittrich, J. Mirkovic, and P. Reiher. Internet Denial of Service: Attack and Defense Mechanisms. Prentice Hall PTR, January 2005. [25] E. Felten, A. Halderman, A. Juels, and B. Waters. New client puzzle outsourcing techniques for DoS resistance. In CCS ’04: Proceedings of the 11th ACM conference on Computer and communications security, pages 246-256. ACM Press, 2004. [26] W. Feng, W. Feng, and A. Luu. The design and implementation of network puzzles. In Proceedings of the 24th INFOCOMM Conference, March 2005. [27] P. Ferguson and D. Senie. Network ingress ltering: Defeating denial of service attacks which employ IP source address spoong. RFC 2267, IETF, January 1998. [28] A. Garg and N. Reddy. Mitigation of DoS attacks through QoS regulation. In Proceedings of the 10th IEEE International Workshop on Quality of Service, pages 45-53, May 2002. [29] T. Gil and M. Poletto. MULTOPS: A data-structure for bandwidth attack detection. In Proceedings of the 10th USENIX Security Symposium, pages 23-38, 2001. [30] V. Gligor. Guaranteeing access in spite of service-flooding attacks. In Proceedings of the Security Protocols Workshop, 2003. [31] M. Goodrich. Ecient packet marking for large-scale IP traceback. In Proceedings of the 9th ACM 20

Appendix B conference on Computer and communications security, pages 117-126. ACM Press, 2002. [32] R. Govindan, A. Hussain, R. Lindell, J. Mehringer, and C. Papadopoulos. COSSACK: Coordinated suppression of simultaneous attacks. In Proceedings of IEEE DISCEX Conference, April 2003. [33] M. Handley and A. Greenhalgh. Steps towards a DoS-resistant internet architecture. In FDNA ’04: Proceedings of the ACM SIGCOMM workshop on Future directions in network architecture, pages 49-56. ACM Press, 2004. [34] IAB, M. Handley (editor). Internet denial of service considerations. draft-iab-dos-01.txt, internet draft, work-in-progress, IETF, January 2004. [35] C. Jin, H. Wang, and K. Shin. Hop-count ltering: an esecurity, pages 30-41. ACM Press, 2003. [36] P. Jokela, R. Moskowitz, and P. Nikander. Host identity protocol. draft-moskowitz-hip-09.txt, work-in-progress, IETF, February 2004. [37] J. Jung, B. Krishnamurthy, and M. Rabinovich. Flash crowds and denial of service attacks: characterization and implications for CDNs and web sites. In Proceedings of the eleventh international conference on World Wide Web, pages 293-304. ACM Press, 2002. [38] A. Keromytis, V. Misra, and D. Rubenstein. SOS: Secure Overlay Services. In Proceedings of ACM SIGCOMM, August 2002. [39] H. Lee and K. Park. On the eectiveness of probabilistic packet marking for IP traceback under denial of service attack. In Proceedings from INFOCOMM 2001, pages 338-347, April 2001. [40] H. Lee, V. Thing, and J. Zhou. Enahnced ICMP traceback with cumulative path. In Proceedings of the 61st IEEE Vehicular Technology Conference, May 2005. [41] W. Lee and J. Xu. Sustaining availability of web services under distributed denial of service attacks. IEEE Transactions on Computers, 52(3):195-208, 2003. [42] K. Levitt and S. Templeton. Detecting spoofed packets, 2003. [43] J. Mirkovic, G. Prier, and P. Reiher. Attacking DDoS at the source. In Proceedings of the IEEE ICNP Conference, November 2002. [44] J. Mirkovic, M. Robinson, and P. Reiher. Alliance formation for DDoS defense. In Proceedings of the 2003 workshop on New security paradigms, pages 11-18. ACM Press, 2003. [45] D. Moore and G. Voelker. Inferring internet denial-of-service activity. In Proceedings of the USENIX Security Conference, June 2001. [46] K Park and H Lee. On the eattack prevention in Power-Law internets. In Proceedings of ACM SIGCOMM, pages 15-26, 2001. [47] A. Perrig and D. Song. Advanced and authenticated marking schemes for IP traceback. In Proceedings of IEEE Infocomm 2001, April 2001. [48] M. Reiter and X. Wang. Defending against denial-of-service attacks with puzzle auctions. In SP ’03: Proceedings of the 2003 IEEE Symposium on Security and Privacy, page 78. IEEE Computer Society, 2003. [49] S. Savage, D. Wetherall, A. Karlin, and T. Anderson. Practical network support for IP traceback. SIGCOMM Comput. Commun. Rev., 30(4):295-306, 2000. 21

Appendix B [50] A. Snoeren, C. Partridge, A. Sanchez, Jones C., F. Tchakountio, S. Kent, and T. Strayer. Hash-based IP traceback. In Proceedings of the 2001 ACM SIGCOMM Conference, 2001. [51] I. Stoica and H. Zhang. Providing guaranteed services without per ow management. In SIGCOMM ’99: Proceedings of the conference on Applications, technologies, architectures, and protocols for computer communication, pages 81-94. ACM Press, 1999. [52] R. Stone. CenterTrack: An IP overlay network for trackind DoS oods. In Proceedings of the 9th USENIX Security Symposium, August 2000. [53] M. Sung and J. Xu. IP traceback-based intelligent packet ltering: A novel technique for defending against internet DDoS attacks. In ICNP ’02: Proceedings of the 10th IEEE International Conference on Network Protocols, pages 302-311. IEEE Computer Society, 2002. [54] A. Yaar, A. Perrig, and D. Song. Pi: A path identication mechanism to defend against DDoS attacks. In SP ’03: Proceedings of the 2003 IEEE Symposium on Security and Privacy, page 93. IEEE Computer Society, 2003. [55] A. Yaar, A. Perrig, and D. Song. SIFF: A stateless internet ow lter to mitigate DDoS flooding attacks. In Proceedings of the IEEE Security and Privacy Symposium, May 2004. [56] X. Yang. NIRA: a new internet routing architecture. In FDNA ’03: Proceedings of the ACM SIGCOMM workshop on Future directions in network architecture, pages 301-312. ACM Press, 2003. [57] D. Yau, J. Lui, and F. Liang. Defending against distributed denial-of-service attacks with max-min fair server-centric router throttles. In Proceedings of the IEEE IWQoS Conference, May 2002.

22

Bibliography [1] K. Argyraki and D. Cheriton. Network Capabilities: The Good, the Bad and the Ugly. In HotNets: Proceedings from the Fourth Workshop on Hot Topics in Networks, 2005. 6 [2] K. Argyraki and D. R. Cheriton. Active Internet Traffic Filtering: Real-Time Response to Denialof-Service Attacks. In USENIX 2005: Proceedings from the Annual Technical Conference, 2005. 6 [3] S. Berinato. How a Bookmaker and a Whiz Kid Took On an Extortionist - and Won. 2005. 3 [4] S. Crosby and D. Wallach. In USENIX: Proceedings from the USENIX Annual Technical Conference, 2003. 10 [5] S. Dharmapurikar, P. Krishnamurthy, and D. Taylor. Longest prefix matching using Bloom filters. In SIGCOMM 2003: Proceedings of the ACM SIGCOMM, 2003. 7 [6] J. Evers. ”Bot herders” may have controlled 1.5 million PCs. 2005. 3 [7] A. Greenhalgh, F. Huici, and M. Handley. Using Routing and Tunelling to Combat DoS Attacks. In SRUTI: Proceedings from the 1st Workshop on Steps to Reducing Unwanted Traffic on the Internet, 2005. 14 [8] M. Handley. Internet Architecture WG: DoS-resistant Internet Subgroup Report, January 2005. 3 [9] M. Hicks. DDoS Attack Knocks Out DoubleClick Ads. 2004. 3 [10] J. Hu. Attack Down Yahoo, Google and Microsoft. 2004. 3 [11] S. Kandula, D. Katabi, M. Jacob, and A. Berger. Botz-4-Sale: Surviving Organized DDoS Attacks That Mimic Flash Crowds. In NSDI 2005: Proceedings from the 2nd Symposium on Networked Systems Design and Implementation, 2005. 6 [12] E. Kohler, R. Morris, B. Chen, J. Jannotti, and M. F. Kaashoek. The Click Modular Router. ACM Trans. Comput. Syst., 18(3):263–297, 2000. 10 [13] C. Kreibich, A. Warfield, J. Crowcroft, S. Hand, and I. Pratt. Using Packet Symmetry to Curtail Malicious Traffic. In HotNets: Proceedings from the Fourth Workshop on Hot Topics in Networks, 2005. 12

BIBLIOGRAPHY [14] J. Leyden. East European gangs in online protection racket. 2003. 4 [15] V. Paxson. Bro: A System for Detecting Network Intruders in Real-Time. In USENIX: Proceedings of the 7th USENIX Security Symposium, 1998. 14 [16] K. Poulsen. FBI busts alleged DDoS Mafia. 2004. 4 [17] snort.org. Snort - the de facto standard for intrusion detection and prevention. 14 [18] H. Song, S. Dharmapurikar, J. Turner, and J. Lockwoord. Fast Hash Table Lookup Using Extended Bloom Filter: An Aid to Network Processing. In SIGCOMM 2005: Proceedings of the ACM SIGCOMM, 2005. 7 [19] L. von Ahn, M. Blum, and J. Langford. Telling humans and computers apart automatically. Commun. ACM, 47(2):56–60, 2004. 7 [20] M. Williams. Study: Slammer was fastest spreading worm yet. 2003. 3 [21] X. Yang, D. Wetherall, and T. Anderson. A DoS-limiting network architecture. SIGCOMM Comput. Commun. Rev., 35(4):241–252, 2005. 6

24