Tolerating Denial of Service Attacks A System Approach

Transcription

1 Tolerating Denial of Service Attacks A System Approach Ju Wang First Draft, February 2002 First Revision, March 12, 2002 (Finished on March 17, 2002) Revision 1.1, March 22, 2002 Revision 2.0, April, Introduction In recent years, Denial of Service (DoS) attacks have been one of the major security threats to large-scale Internet applications. Since 1998, there have been several large scale DoS attacks in the Internet. Some gigantic sites such as Yahoo!, Amazon and Buy.com were shut down during those attacks [1, 2]. In 2001, the Code Red worm was widely spread in the network as part of a distributed DoS attack on and the web site was forced to move to a different location [3]. These DoS attacks may have serious economic and political impact. They may even threaten critical infrastructures, national security or human lives. All these attacks are very sophisticated and thousands to hundreds of thousands of hosts in the Internet can be used in these massive attacks [4]. There have been no effective ways so far to defend against these massive distributed DoS attacks. Researchers have been looking for solutions to the DoS problem. A lot of work has been done on intrusion detection systems (IDS) [5-8]. IDS can detect compromises and indirectly reduce the magnitude of distributed DoS attacks. But it does not directly address the DoS problem. Other approaches include packet filtering at routers or firewalls [9]. To some extent, it can mitigate the effect of some DoS attacks. But in large-scale distributed DoS attacks, the attack traffic might be indistinguishable with legitimate traffic, so the filtering scheme may not be effective. Some recent research focuses on IP trace-back schemes [10-12]. The idea behind this is to trace back to the origins of the attack traffic during or after a DoS attack, and find out who is responsible. This approach addresses the DoS problem from a different perspective. It does not protect applications during DoS attacks. We are exploring system approaches to tolerate DoS attacks on large-scale publicly accessible applications. We propose a system infrastructure that has two key properties. First, it hides the location of the applications while all Internet users can still access the applications. Second, it provides mechanisms to limit the amount of resource each distinct user can consume without requiring user authentication. The first property protects applications from DoS attacks that require location of the victim. The second property prevents DoS attackers from consuming excessive amount of resource, therefore mitigates the impact of DoS attacks. The proposed system infrastructure as a whole provides a solution to help applications resist DoS attacks. 1

2 The remainder of this document is structured as follows. Section 2 describes the context of the DoS problem addressed. The DoS problem is formulated in section 3, followed by the related work. Next, the proposed approach is discussed in detail, followed by the research plans to evaluate the idea and validate the proposed solution. It is concluded with a summary and a schedule. 2 Background 2.1 Application Context Our study focuses on large-scale open applications. An open application is a publicly accessible service to all users in the Internet. No rigorous authentication of user identity is required to use the application service. All users are supposed to have a fair chance to use the service. Many Internet applications fall into this category. For example, E-Commerce applications, search engines, news, digital libraries and stock information board are all open applications. They are publicly accessible. They do not charge a user for the amount of service he/she uses, therefore, no rigorous user authentication is necessary. There are two types of applications that do not follow the open model: closed applications and semi-open applications. Closed applications are not accessible to all Internet users. They are running on private networks, which are either physically separated from the Internet or logically separated using firewalls. Only users inside those private networks may have access to the applications. Our study does not address this type of applications. Semi-open applications are publicly accessible from the Internet, but require strict user authentication for the purpose of authorization, billing and so on. One example is on-line brokerage applications, which are publicly accessible, and charge users by the amount of service they provide. They bear some vulnerability open applications have. They are usually running on machines with well-known network addresses. Infrastructure level DoS attacks, as defined in the next section, may abuse those machines or the associated network to cause Denial of Service. Even though our study does not focus on semi-open applications, our proposed scheme will provide a solution to this problem. On the other hand, because semi-open applications keep account information, they can easily discourage attackers from sending too many requests, or it may not even be a concern for them. So application level attacks (defined in next section) are easier to solve for semi-open applications. But it is a hard problem for open applications. 2.2 Distributed Environment Context The context of distributed environment is the current Internet. There are several key properties in the current IPv4 dominant Internet, which characterize the key assumptions about the nature of the problem. 2

3 First, the source address of a network packet may be spoofed or incorrect. Current IP network does not guarantee authenticity of source addresses. Therefore, malicious users may construct packets with spoofed source addresses. Furthermore, Network Address Translators (NAT) and Mobile IP legitimately use modified source addresses. Firewalls and NAT boxes are widely used today. Packets coming from different machines inside the same firewall are indistinguishable from outside. Firewalls and NAT boxes will likely continue to exist long after IPv6 is universally deployed. Second, current network infrastructure does not universally support quality of service (QoS), neither at the network level nor at the application level. Attackers may send floods of garbage traffic or application requests to cause significant degradation of service to legitimate users. Last, it is relatively easy to compromise a number of hosts in the Internet in a short period of time. Almost all software has bugs and many of them are remotely exploitable [13]. Systems might also be mis-configured to leave security holes, and user accounts might be compromised. All these vulnerabilities give attackers opportunities to take over hosts running in the Internet. All these properties remain true in IPv6 network, except if IPSec [14] [15] were universally adopted, the network infrastructure can then guarantee authentic source addresses, so the first property is voided. However, for many years IPv4 network will still be predominant, and IPv6 and IPSec will not be universally deployed. Therefore, it is reasonable to model the distributed environment with all these properties. 3 Problem Formulation 3.1 Problem Description Application Service Application Client ] OS Host OS Host Network OS Host Internet OS Host Service side infrastructure Figure 1 Attack Classification As shown in Figure 1, the server side of the application is running on a number of machines connected with network, and users in the Internet run client side software to access the application service via the Internet. The service side infrastructure includes 3

4 the hosts the application service is running on, the operating system running on those hosts, the network connecting server hosts, and the network links connecting server hosts to other parts of the Internet. Application service depends on these infrastructure components to operate. We classify Denial of Service attacks as two categories: infrastructure level attacks and application level attacks. In an infrastructure level DoS attack, attackers try to jeopardize the availability of the server side infrastructure, so that the application service has less resource to operate on and legitimate users may observe severe degradation of service or denial of service. In an application level DoS attack, attackers try to generate excessive amount of workload on the server side to cause severe degradation or denial of service to legitimate users. Open applications are vulnerable to both infrastructure level and application level DoS attacks. In the Internet, open applications often operate on an infrastructure that is accessible to everyone in the Internet, so that everyone can use the application service. This leaves attackers a clear target for infrastructure level DoS attacks. Open applications normally do not distinguish requests from different users and treat them equally. This gives attackers a good opportunity for application level DoS attacks. Attackers may send floods of application requests to the application service. Processing these requests will consume excessive amount of resource at the server side. So requests from legitimate users may be affected and those users may observe degradation of service or denial of service. Our work focuses on tolerating both infrastructure level and application level DoS attacks for open applications. 3.2 Solution Criteria and Metrics Correctness Criteria: Any system level solution should meet the following correctness criteria: 1. Application correctness must be maintained. 2. The open application property must be maintained. For instance, a scheme that prevents public access to the application service or requires user authentication is not considered as a solution. Effectiveness Metrics: Given a certain number of attackers (number of hosts that participate a DoS attack), and a certain type of DoS attacks (infrastructure level or application level), to evaluate the effectiveness of a given solution in terms of the attackers impact on users ability to use the application, the following metrics are informally defined. 1. Containment a. Spatial containment 4

5 The impact of the attack is contained to a small number of users, with the percentage of affected users as the metric. b. Temporal containment The impact of the attack only lasts for a short period of time, with the length of this period as the metric. 2. Mitigation For any legitimate user, the impact of the attack is mitigated so that the user can access the application service. During DoS attacks, the user may observe slight degradation of service but not denial of service. The degree of degradation can be used as the metric. 3. Avoidance Given a specific scheme attackers may use, we can analyze the probability of DoS attack avoidance. Namely, if a specific solution is used, how likely the application can avoid a DoS attack. This constitutes the avoidance metric. Efficiency Metrics: The following metrics are to measure the runtime cost of using a specific solution. 1. Runtime overhead When there are no attacks, the extra the roundtrip response time for use requests caused by the solution. The lower this overhead is, the more efficient the solution is. 2. Reconfiguration overhead If a solution is based on reconfiguration or adaptation, then this metric applies. It measures the length of the transient period caused by system reconfiguration. An efficient solution should have low reconfiguration overhead. 4 Related Work 4.1 How Distributed DoS Attacks Work Before discussing current approaches, it is necessary to look at how a typical distributed DoS attack (DDoS) works. For DDoS attacks that use zombies, there are two stages in an attack. In the first stage, attackers covertly compromise many hosts in the Internet and install zombie programs on those hosts. In the second stage, attackers somehow trigger the zombies to attack the victim. Both infrastructure level and application level DoS attacks can be performed this way. There are a good number of DDoS tools available in the Internet today, for example, Trinoo, TFN2k and mstream [16-18]. These tools automatically probe network hosts for known vulnerabilities, and then compromise those hosts to install zombies, which form a zombie network. Attackers may later instruct the zombie network to attack specific victims. The recent Internet worm code red is also one of the best-known instances of DDoS attacks. 5

6 Hundreds of thousands of hosts were infected by the worm and used in a DDoS attack to [3, 4, 19] 4.2 Current Approaches There have been many studies addressing this DoS problem. In general, these approaches can be put into two categories: proactive and reactive approach. They all focus on the source of DoS attacks. Proactive approaches try to protect machines from being compromised and used in DDoS attacks. Intrusion detection systems (IDS) fall into this category. Some IDS [5-7] help to detect compromises in time so that administrators can be notified and take actions to stop compromised machines from being used in DoS attacks. There are some safe runtime systems [8, 20] addressing the problem in a similar way as IDS. The difference is that they focus on making processes fail-safe, so that compromised processes will only crash and will not be controlled by the attacker to participate attacks. When these schemes are widely deployed in the Internet, it will help to reduce the scale of DDoS attacks, because there will not be as many hosts for attackers to use in DDoS attacks. But wide if not universal deployment is required to make this approach effective. However, there are hundreds of millions of hosts running in the Internet. Attackers only need a small fraction of it (thousands for example) to effectively launch a massive attack. That means unless most of the machines running in the Internet are protected, attackers always have a good chance to find enough machines to use in DoS attacks. The administrative and deployment cost make this approach very hard to completely solve the DoS problem. As an example, on July 19, 2001, a week after the first Code Red worm attack, even though many machines installed patches, still more than 359,000 machines were infected with Code-Red version 2 in just fourteen hours [4]. This shows the main restriction of this approach. Reactive approaches take actions after a DoS attack occurs. There are two types of actions: to stop the attack traffic or to find the attackers and punish them. Both of these involve tracing back to the origin of attack traffic. Different schemes in this domain include link testing [21, 22], logging [11] and IP trace-back [10, 12]. Link testing and logging schemes do not scale well and can hardly work in real time. IP traceback schemes [10, 12] are among the most promising ones. Song et al proved that using this scheme, they could trace back to the source of attack traffic in real time. Then it is possible to stop the attack traffic from the source. However, these schemes are not complete solutions yet. First, these schemes can only trace back to the source of the attack traffic, which may not be the attacker. As discussed in the previous section, attackers may use zombies to generate attack traffic. These schemes are not capable of spotting real attackers behind the scene. Second, to stop the attack traffic, prompt cooperation from upstream ISPs is necessary. It is not clear how easy this can be achieved. Effective ways to stop DoS attacks are not addressed in these schemes, especially for distributed DoS attacks where hundreds of 6

7 thousands attackers might be involved. Third, most of these schemes only focus on flooding type of infrastructure level attacks. They are not effective to other types of infrastructure level attacks, which only take a few packets to shutdown a host (for example, ping-of-death [23]). They do not address application level attacks either. In summary, there are many on-going studies in this field. Most of them focus on the source of DoS attacks. Some of them are promising and can help to reduce the severity of attacks. But none of them provide a complete solution, and the DoS problem remains unsolved. In this study, we attack the problem from a different perspective. We focus on the application availability not the source of attacks, and try to mitigate the impact of the DoS attack. We expect our study to be a contributing component of a complete solution to the DoS problem in synergy with other approaches. 5 Proposed Solution 5.1 Overview As shown in Figure 1, DoS attacks may come from two different levels. Accordingly, the solution needs to deal with each level of attacks. Server side infrastructure is the critical resource application services depend on to operate. So an essential part of the solution addresses the issue of how to protect applications against infrastructure level DoS attacks. However, the scheme used in this case may not be effective to application level DoS attacks, where the scenarios are completely different. Instead of directly attacking the server side infrastructure, attackers may send excessive amount of legitimate requests to the application service, which may take huge amount of resource to process on the server side. So the other part of the solution addresses this problem by achieving fair distribution of server side resource among all users. These two parts are discussed respectively in the following sections. 5.2 Tolerate Infrastructure Level DoS Attacks Given the size of the Internet, for infrastructure level DoS attacks on specific applications to be effective, there is a key observation. Attackers need to know where the application is running, so that they can concentrate their attack on that small area. If attackers do not have this information, the probability of successful infrastructure level DoS attacks will be minimized. This leads to the core idea of this solution: making application services location elusive. More specifically, there are three folds of meaning. First of all, location of the application service is a secret, so that attackers do not know where to shoot at. This will minimize the probability of infrastructure level DoS attacks. Second, location of the application service is changing, so that even if attackers somehow gained knowledge of where the application is currently running, that information will expire as soon as the application migrates. Therefore, there is an extra level of security and the attacks cannot persist. This is a form of temporal containment of DoS attacks. Third, this location elusiveness property can be transparently applied to applications, which is part of an ongoing project in UCSD [24], so that application correctness is straightforwardly maintained. Besides that, transparency also implies that this system approach does not 7

8 require application specific information, therefore not only can future applications get benefit from it, but existing applications also have full potential to take advantage of it. Given this scheme, now applications can covertly run somewhere in the gigantic Internet and attackers cannot easily find where they are. But there remains an important question: how to maintain the open property? Namely, how to allow everyone in the Internet to access the application without disclosing the location of it? Distributed Location Elusive Application Proxy Proxy Proxy Proxy Proxies as shield against infrastructure level attacks Figure 2 DoS tolerant proxy network Our approach employs a proxy network on trusted hosts in the Internet. These proxies know how to access the application service. s in the Internet use the proxies to access the application. There are two issues worth mentioning. First, proxies are highly redundant and distributed in the Internet; so that the proxy-network can tolerate DoS attacks and guarantee availability. Since the major task for proxies is to forward requests and they do not need to carry much state, it is not difficult to build a high performance DoS-tolerant proxy-network. Second, we need to prevent attackers from persistently tracking the location of the application. In this scheme, intrusion detectors are used on each proxy so that attackers cannot compromise proxies without being detected. Results from intrusion detection systems, especially the anomaly detection systems can be used here [7, 20, 25, 26]. For example, David Wagner has shown that it is possible to build high precision intrusion detectors to make programs fail-safe, especially for simple programs, on which static analysis is feasible [8]. With fail-safe proxies, and assuming that proxies are running on trusted machines, it is impossible for attackers to keep track of the location of the application from remote. The issue about internal attacks where attackers may infiltrate some proxies without being noticed is discussed later. In summary, location elusiveness property makes it hard for attackers to get the location of the application, so that the probability of successful infrastructure level DoS attacks is minimized. The proxy-network works as a shield to protect the application 8

9 service against infrastructure level DoS attacks (Figure 2). It maintains the open property of the applications. The problem is solved at the system level and separates the problem from applications, so that the solution can benefit a large domain of applications. 5.3 Tolerate Application Level DoS Attacks In the previous section, a scheme to tolerate infrastructure level DoS attacks has been discussed. That scheme does not apply to application level DoS attacks, because here attackers do not need to know the location of the application and they can access the application service the same way as legitimate users do. This section addresses the issue about application level DoS attacks. Tolerance of application level DoS attacks is defined as the ability to continue delivering service to legitimate users and all discussions will be in this context. Our study focuses on mitigating the impact of attacks given a specific number of attackers. The impact of an attack depends on two main factors: number of participating attackers and damage caused by each attacker. Both of these factors need to be minimized to achieve DoS tolerance. Several studies [6-8, 20] address the problem of protecting hosts from being used in distributed DoS attacks. Our system can use those schemes to reduce the number of attackers. The focus of our work is to mitigate the impact of each attacker. One straightforward way to mitigate DoS impact is to evenly allocate application service resource among all active users. Logically, there is a scheduler for each application to schedule users requests fairly, so that attackers cannot send excessive amount of requests to starve other users. This can be done either in a distributed way or a centralized way. The tradeoffs in performance and scalability will be addressed in the implementation stage of this study. The scheduling schemes have been studied in Quality-of-Service (QoS) networks [27-29]. Therefore this study focuses on building a system infrastructure to use these scheduling schemes, not on the scheduling schemes themselves. Consumer Consumer Requests Requests Scheduler Service Provider Consumer Requests Figure 3 System Model 9

10 Before discussing the problem, let us model the system as follows. Consider the system as a provider consumer model as shown in Figure 3, where the application is the service provider, application users are consumers and their requests are associated with some amount of workload at the service provider side. The scheduler is responsible of scheduling those requests to ensure fair distribution of service among those consumers. Two problems need to be solved for the scheduler to work: measurement of workload involved in each request and association between workload and consumer. Accurate measurement of workload is a challenging problem, but in the context of DoS tolerance on open applications, we can greatly simplify the problem. Many commercial server platforms [30, 31] indicate that for many open applications there is not much variation in workload for different requests to the same service. Therefore, the number of requests can be a reasonable approximation of workload. Furthermore, the communication paradigm of most open applications follows request-response model. The delay between the request and the response directly corresponds to the workload on the service side. It gives a more accurate approximation of the workload. For the purpose of DoS tolerance, these approximation schemes give sufficient information to limit the amount of workload attackers may cause. The second problem is more challenging. For open applications, user identity is not guaranteed to be authentic. Therefore, it is hard to use individual users as the consumers in the model in Figure 3. Instead, we follow the principle that host is the fairness unit (consumer in the model). Specifically, we use the network addresses to identify hosts. There are several issues need to be solved. 1. Attackers may forge the source address of the requests. 2. Firewalls and Network Address Translators (NAT) are widely used. Hosts inside a same firewall are indistinguishable from outside, so when the scheduler receives a hundred requests from a same source address, it is impossible to tell whether they are from a hundred distinct hosts inside a firewall or from one host. We call this problem the NAT problem. 3. Attackers may configure one host to have multiple addresses. The first issue turns out not to be a big concern. Currently, most applications are based on connection-oriented protocols, such as TCP or HTTP. A request cannot successfully go through if its source address is forged [32, 33]. The other two problems are more difficult, and obviously naïve approaches do not work. The remainder of this section proposes a scheme that solves these two problems. This scheme has two parts. 1. Network topology guided scheduling, the key idea of this scheme, is to use network topology information to approximate number of hosts behind a firewall, so that we can schedule them as an aggregation and partially overcome the NAT problem. This can also solve the third problem, because even if attackers can configure one host to have multiple addresses, they will still be grouped into one 10

11 aggregation, whose fairness depends on the network topology that attackers cannot easily change. Therefore impact of attackers can be contained locally. 2. Hierarchical schedulers together with the previous scheme can completely solve the NAT problem. Network topology guided scheduling We can shrink a firewall into one node, which carries a weight corresponding to the size of the firewall. The network address of this node is the address of the NAT box, which is visible from outside the firewall. Then each network address is associated with a weight value, and the aggregation of hosts inside one firewall is used as one entity in the scheduling scheme. The problem now is how to determine the weight value. 6 hops AS 1 Link to other AS 2 hops Corporation Firewall AS 2 AS 3 Router Home PC Application Figure 4 Network Topology Guided Scheduling We can use the route information to achieve this. From the Internet topology [34, 35], we know that the Internet is composed of an interconnected mesh of ASes. Border Gateway Protocol (BGP) [36] is used among ASes to route packets from one AS to another. There is a router network connecting all the hosts inside each AS. This router network has a hierarchical structure. Routers at the edge of the AS are at the top level of the hierarchy. All traffic flows into the AS go through these routers, and disperse via routers at lower level hierarchies into the end hosts. In general, as the level of hierarchy goes down, router s capacity becomes less and the number of hosts each router in charge of becomes smaller as well. Therefore, the distance between a low level router and the edge routers infers the capacity of that router. Using this property, we can approximate the size of the user community behind a firewall by looking at the route distance. Larger firewalls tend to be closer to routers at higher levels. Hosts not in firewalls are much farther away and attached to routers at the lowest level (leaf routers). Figure 4 shows an example. To identify an AS, information inside BGP tables can be used as in [37]. There are many implementation choices to discover routes inside an AS. The most 11

12 straightforward scheme is to use traceroute. We can also leverage the infrastructure proposed in the IP trace back schemes [10, 12]. The pros can cons will be discussed in the implementation stage. The scheme works as follows. Network addresses are grouped into clusters based on the discovered network topology. As described above, the scheduler allocates fair share to the clusters based on the distance from the cluster to the edge of the AS. Inside each host cluster, all distinguishable network addresses are treated equally. This scheme is consistent with the fact that users normally pay more money to get higher link capacity, so they may also get more fairness. It has several advantages. First at all, this scheme partially overcomes the NAT problem without any change in the network infrastructure. Furthermore, it also solves the third problem previously discussed. Attackers may configure one host to have many network addresses. But all these addresses will be routed from the same leaf router. In our scheme, network addresses are grouped into clusters based on route/topology discovery and each cluster has certain amount of fairness. Therefore, all these forged addresses will collide inside one cluster. The impact of attackers can be contained locally. Hierarchical Schedulers The scheme described above cannot protect hosts inside firewalls. Analytical study (Appendix I) shows that, an attacker inside a firewall may cause Denial of Service to users in the same firewall by sending floods of application requests. To address this problem, a hierarchical scheduling scheme is proposed. In addition to the scheme discussed in the previous section, each firewall may also have a fair scheduler inside to protect users against attackers in that firewall. There are a few reasons why we only use a simple centralized scheduler inside the firewall. First of all, normally a firewall is always a centralized administrative domain. It is significantly easier to enforce security policies than in the open Internet environment. It is also fairly easy to locate which host is conducting an infrastructure level attack. Therefore infrastructure level DoS attacks inside firewalls are less likely to be a threat. On the other hand, the NAT box is already the vulnerable point. Adding a centralized scheduler will not make the system less secure. For these reasons, schedulers inside firewalls can be simple fair schedulers, and do not need to tolerate infrastructure level DoS attacks. This will be further discussed at the implementation stage. To summarize the scheme of tolerating application level DoS attacks, we exploit the network topology and routing information, especially the route inside ASes, to overcome the NAT problem. Hosts inside a firewall are scheduled as one entity and guaranteed fairness as an aggregation. Our scheme also spatially contains attackers impact by grouping network addresses into clusters. Simple fair schedulers are used inside firewalls to protect users inside firewalls. Analytical study (Appendix II) shows that this scheme can effectively mitigate the impact of application level DoS attacks. 12

13 5.4 Summary Shield against infrastructure level attacks Distributed Location Elusive Application Network topology guided hierarchical schedulers defeat application level attacks Proxy Scheduler Proxy Scheduler Proxy Scheduler Proxy Scheduler Firewall NAT Box Schedule Figure 5 the Proposed Solution Location elusiveness plus DoS-tolerant proxy network minimizes the possibility of infrastructure level attacks. There are two key ideas. First, attackers cannot launch an infrastructure level attack if they do not know the location of their target. Location elusiveness property of the application defeats the attackers in that way. Second, the application is still accessible to users (any user in the Internet) through a DoS-tolerant proxy network, and the open model is still guaranteed. The combination of the two provides a system level protection for arbitrary applications against infrastructure level DoS attacks. Existing applications can easily leverage this innovation. Network topology guided scheduling scheme provides a solution to contain and mitigate the impact of attackers. In the open Internet, there are firewalls and hosts may also forge their network addresses. So the information we can collect may always be incomplete and sometimes even erroneous. One of the major innovations here is to use network topology information to guide schedulers overcoming incomplete information found in the Internet and contain the impact of attackers closely to their local regions. Hierarchical scheduling scheme also ensures that everyone, including users inside firewalls, in the Internet has a fair chance of accessing the application service, despite of the fact that applications may not have information about user identity. This provides a system approach to mitigate the impact of application level DoS attacks without requiring any application specific information. 13

14 The two schemes combined as a system solution to tolerate DoS attacks from both the infrastructure level and the application level (Figure 5). 6 Research Plan 6.1 Research plan overview Stage 1: Problem analysis and formalization At this stage, we study the DoS incidents in the Internet and properties of the victim applications. Then we formalize the DoS problem into an abstract model, so that we can rigorously define: - What the DoS problem is - Assumptions about applications and the distributed environment - Solution criteria for the DoS problem - Metrics to evaluate the effectiveness of a solution Stage 2: Design of a high-level solution At this stage, we propose a system approach to the DoS problem, which is based on the abstract model formalized in the first stage. Theoretical analysis of the feasibility and effectiveness of the proposed scheme is also conducted. Stage 3: Implementation of the proposed solution We implement a system infrastructure, which captures all the key ideas in the proposed solution, so that experiments can be conducted to evaluate the effectiveness of the proposed solution. Stage 4: Validation and evaluation of the proposed solution Analytical and empirical studies are conducted to verify that the proposed solution meet all the solution criteria given in stage 1, and also evaluate the effectiveness of the proposed solution based on the metrics given in stage 1. These studies are conducted based on the proposed high-level design and the proof-of-concept implementation built in stage 3. We have already completed the first two stages. The rest of the section focuses on stage 4. First, we give a checklist of the key elements in the proposed solution to be validated and evaluated. Then we describe the analytical and empirical studies to validate or evaluate these key elements. The expected result of each experiment is also described. At the end of this section, a schedule is given, which covers the high-level implementation plan and also the current progress. 6.2 Key elements to be studied 1. Effectiveness of the location elusiveness scheme to tolerate infrastructure level DoS attacks. a) DoS attack avoidance. b) Temporal containment of attack impact. c) Measure of DoS resistance for the proxy network. Bullet a) measures the probability that a direct infrastructure level attack on the application can be avoided. With bullet b), if there is a direct infrastructure level attack against the application, its impact can be contained. The proxy network is the public access point for the application, and its availability directly affects the 14

15 availability of the application. Bullet c) ensures that the proxy network itself can effectively resist DoS attacks. These three metrics characterize the ability of our scheme to tolerate infrastructure level attacks. 2. Effectiveness of the network topology guided scheduling scheme to tolerate application level DoS attacks. a) Spatial containment of attack impact. b) Mitigation of attack impact. These two metrics characterize the effectiveness of our scheme to tolerate application level attacks by containing and mitigating attack impact. 3. Efficiency of the network topology guided scheduling scheme. The metric runtime overhead is used here. 4. Efficiency of the location elusiveness scheme. The metric reconfiguration overhead is used here. 6.3 Analytical study Analytical study covers 1.a), 2.a) and 2.b) listed in section 6.2. Analytical study of 1.a) (Avoidance) How this study should be conducted depends on the implementation of the location-changing scheme and the secret sharing scheme used in the proxy network. In general, the following cases are interesting to study. First, attackers cannot compromise the proxy network, so that attackers may only guess the location of the application. Second, attackers may compromise a small number of proxies, so they may have some limited information about where the application could be. We will analyze the probability of DoS avoidance in these cases to evaluate the effectiveness of our scheme. Analytical study of 2.a) and 2.b) (Spatial containment and mitigation) In the theoretical analysis of the proposed scheduling scheme, we establish a formal model of the system, where there are firewalls and hosts inside and outside firewalls. We also assume that the fair schedule principle can be used at each scheduler. We study the fairness measure of the proposed scheme under two configurations. First, there are no schedulers inside firewalls. We study the impact of attackers on hosts inside and outside the firewalls. Second, there is a simple fair scheduler inside the studied firewall, and we study the impact of attackers on hosts inside and outside that firewall. The impact of attackers to a user is measured by the ratio of the amount of service that user gets and the ideal fair share of service that user should get. This part of the study has already been completed. The result is summarized here. Full analysis is attached in the appendix, and will appear in the final dissertation. I. A fair scheduling scheme can effectively mitigate the impact of attackers on hosts outside firewalls. There is a lower bound of a fair share service guarantee that attackers cannot compromise. 15

16 II. When there are no schedulers inside firewalls, attackers may potentially cause DoS to other hosts inside the same firewall. But attackers impact is contained inside the same firewall, and hosts outside that firewall still have the previous service guarantee. III. When there are schedulers inside firewalls, there are also lower bounds of service guarantee for all hosts inside and outside firewalls. These results prove that the proposed scheduling scheme can successfully mitigate and contain the impact attackers. 6.4 Empirical study Simulation environment The simulation testbed to conduct the empirical experiments has the following components. A testbed is built on a cluster-based network simulator with representative topology. The topology represents a simplified version of the Internet, which has firewalls of different sizes, and has a hierarchical structure with high-capacity links at the core and lower capacity links at the edges. There is a demo application running inside the testbed, and the proposed proxy network also runs on the testbed. There are simulators of users and attackers running inside the testbed to simulate legitimate user requests, infrastructure level DoS attacks and application level DoS attacks Experiments The empirical study covers 1.b), 1.c), 2.a), 2.b), 3 and 4 listed in section 6.2. Effect of location elusiveness scheme (temporal containment) Simulate infrastructure level DoS attacks on fixed locations and study the user request delay distribution changes with time. Parameters: The disclosed locations of applications under attack (high volume of attack traffic to those locations), current location of the application, and the migration decision scheme employed. Variables of interest: Distribution of user request delay over time. We expect to see the temporal containment of the attack impact given by the location elusiveness scheme. Strength of DoS-tolerant proxy network Simulate infrastructure level DoS attacks on a number of proxies and study the user request delay distribution. Parameters: The number of attackers, volume of attack traffic each attacker generates, the number of proxies in the network. Variables of interest: request delay and user request loss rate. We expect to see that the proxy network can successfully resist DoS attacks and maintain availability to users during DoS attacks. Effect of topology guided scheduling scheme (spatial containment) Simulate application level DoS attacks from various locations (inside and outside firewalls) and study the geographic distribution of user request delay. 16

17 Parameters: The geographic distribution of attackers and the geographic distribution of active users. Variables of interest: Distribution of user request delay, user request loss rate. We expect to see that the proxy network can successfully contain DoS attacks locally. Effect of hierarchical scheduling scheme (mitigation) Simulate application level DoS attacks with different intensity and study how user request delay changes with attack intensity. Parameters: Intensity of the attack. Variables of interest: request delay, user request loss rate and the ratio of the amount of service provided to legitimate users to the amount of service taken by attackers. We expect to see attackers impact is bounded, so that attackers can only have limited impact on legitimate users. Runtime Overhead Simulate user accesses to the application and measure the roundtrip delay with and without the proxy network. Parameters: Location of proxies and location of the user. Variables of interest: The difference in user request delay between the two configurations. Reconfiguration Overhead Migrate the application from one location to another, and measure the length of the transient period, during which users may not be able to access the application. Parameters: Layout of the proxy network and size of the proxy network. Variables of interest: The length of the transient period. 6.5 Expected Impact The proposed scheme has two folds of impact. It can tolerate both types of DoS attacks discussed in the context of this study. It can also help to locate origin of application level DoS attacks, which may deter attackers. This scheme is provided as a tier between applications and users. It is transparent to all users so that all users can get benefit from it. It has been proved possible to provide location elusiveness property transparently to the applications at the system level [24]. Therefore new applications can get full benefit from this solution. Application designers only need to focus on the application logic itself. The DoS problem is solved at the system level. Many existing applications have stateless front-end [38] and easy to make location elusive. These applications can also get full benefit from this solution with some small changes. For some existing applications those are difficult to achieve location changing, they can use the location-hiding scheme and get partial benefit from the proposed solution. 17

18 6.6 Implementation plan and schedule Stage Work Item Timeline Status Problem Problem analysis and formulation Done formulation High level design Design of location elusiveness plus proxy network scheme to tolerate infrastructure level DoS attacks Done Design of network topology guided scheduling Done framework to tolerate application level DoS attacks Implementation DoS tolerant proxy network design 3 months X Secret sharing scheme for proxies ½ month X Topology discovery scheme 1 month X Distributed scheduling scheme 2½ months X Validation and Analytical study 1 month X evaluation Simulation environment setup 1 months X Empirical study 2 months X Writing Collect data and prepare publications 8 months X Total 19 months X 7 Summary The core ideas of the proposed scheme can be summarized as follows. With location hiding scheme, the possibility of direct infrastructure level DoS attacks on the application is minimized. The proxy network maintains the open property of applications and also works as a shield to protect applications against infrastructure level DoS attacks. With location changing, the system can also tolerate proxy compromises by temporal containment of attacks. Network topology guided hierarchical scheduling scheme overcomes the NAT problem and mitigates attackers impact. It also has spatial containment on application level DoS attacks. This is an effective way to tolerate DoS attacks and it can also help to locate origin of attacks. Contributions This study demonstrates a system level approach to effectively minimize the possibility and contain impact of infrastructure level DoS attacks. This study also demonstrates a system level scheme to mitigate and contain impact of application level DoS attacks. It proves that all these schemes can be incrementally deployed in the existing distributed environment and transparent to applications. Caveats and Limitations Correlation among applications This scheme puts a number of applications into a same shield, namely the proxy network. This inevitably creates correlation among those applications. First, flaws in the 18

19 proxy network may become a common security hole for all those applications. Second, DoS attacks on one application may affect other applications as well. Third, the proxy network will become a bigger target for attackers. Less effective if applications have exploitable flaws First, if the application has exploitable implementation flaws, for example, bufferoverflow bugs, attackers may be able to compromise the application directly. The proposed scheme does not address this issue. Second, if the application has design flaws, for example, it allows a small number of requests consume huge amount of resource at the server side, the proposed solution will be less effective in mitigating application level DoS attacks. References 1. Williams, M., EBay, Amazon, Buy.com hit by attacks Fonseca, B., Yahoo outage raises Web concerns CERT, "Code Red" Worm Exploiting Buffer Overflow In IIS Indexing Service DLL CAIDA Analysis of Code-Red Axelsson, S., Intrusion Detection Systems: A Survey and Taxonomy. 2000, Chalmers University of Technology: Goteborg, Sweden. 6. Kumar, S. and E.H. Spafford. A Pattern Matching Model For Misuse Intrusion Detection. in Proceedings of the 17th National Computer Security Conference Vigna, G. and R.A. Kemmerer, NetSTAT: a network-based intrusion detection system. Journal of Computer Security, (1): p Wagner, D. and D. Dean. Intrusion detection via static analysis. in 2001 IEEE Symposium on Security and Privacy Oakland, CA, United States: Proceedings of the IEEE Computer Society Symposium on Research in Security and Privacy Ferguson, P. and D. Senie, Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing. The Internet Society, Savage, S., et al., Practical network support for IP traceback. Computer Communication Review, (4): p Snoeren, A.C., et al. Hash-based IP traceback. in ACM SIGCOMM Applications, Technologies, Architectures, and Protocols for Computers 19

20 Communications San Diego, CA, United States: Computer Communication Review. v 31 n Song, D.X. and A. Perrig. Advanced and authenticated marking schemes for IP traceback. in 20th Annual Joint Conference of the IEEE Computer and Communications Societies Anchorage, AK, United States: Proceedings - IEEE INFOCOM. v One, A., Smashing The Stack For Fun And Profit. 1997, BugTraq, r00t, and Underground.Org. 14. Kent, S. and R. Atkinson, Security Architecture for the Internet Protocol. 1998, IETF.org. 15. IP Version 6 Working Group (ipv6), IETF.org. 16. Dittrich, D., The DoS Project's "trinoo" distributed denial of service attack tool. 1999, University of Washington. 17. Dittrich, D., The "Tribe Flood Network" distributed denial of service attack tool. 1999, University of Washington. 18. Dittrich, D., et al., The "mstream" distributed denial of service attack tool CERT, "Code Red II:" Another Worm Exploiting Buffer Overflow In IIS Indexing Service DLL Cowan, C., et al. Automatic Detection and Prevention of Buffer-Overflow Attacks. in the 7th USENIX Security Symposium San Antonio, TX. 21. Stone, R. An IP Overlay Network for Tracking DoS Floods. in the 2000 USENIX Security Symposium Denver, CO. 22. Burch, H. and B. Cheswick. Tracing Anonymous Packets to Their Approximate Source. in LISA XIV New Orleans, LA: usenix.org. 23. Kenney, M., Ping of Death. 1996, insecure.org. 24. CSAG, Agile Objects: Component-based Inherent Survivability. 25. Kim, G.H. and E.H. Spafford, Experiences with Tripwire: Using Integrity Checkers for Intrusion Detection. 1995, Purdue University. 26. Porras, P.A. and P.G. Neumann. EMERALD: Event Monitoring Enabling Responses to Anomalous Live Disturbances. in 1997 National Information Systems Security Conference

21 27. Parekh, A.K. and R.G. Gallager, Generalized processor sharing approach to flow control in integrated services networks: The single-node case. Ieee/Acm Transactions on Networking, (3): p Parekh, A.K. and R.G. Gallager, Generalized processor sharing approach to flow control in integrated services networks: The multiple node case. Ieee/Acm Transactions on Networking, (2): p Shreedhar, M. and G. Varghese, Efficient fair queuing using deficit round-robin. Ieee/Acm Transactions on Networking, (3): p Websphere Edge Services Architecture, IBM. 31. Network Load Balancing Technical Overview -- Microsoft Application Center, Microsoft Corporation. 32. Unpredictable TCP Sequence Numbers in SP4 (Q192292). 1998, Microsoft.com. 33. Bhansali, B.B., Man-In-the-Middle Attack - A Brief. 2001, SANS Institute. 34. Broido, A. and k. claffy. Internet topology: connectivity of IP graphs. in SPIE International symposium on Convergence of IT and Communication Huffaker, B., et al. Topology discovery by active probing. in Symposium on Applications and the Internet (SAINT) Lougheed, K. and Y. Rekhter, RFC 1106: Border Gateway Protocol (BGP) Krishnamurthy, B. and J. Wang, On network-aware clustering of Web clients. Computer Communication Review, (4): p Network Infrastructure Design, Microsoft Corporation. 21