Slow rate denial of service attacks on dedicated- versus cloud based server solutions

Transcription

1 Linköping University Department of Computer and Information Science Bachelor thesis, 16 ECTS Information technology 2018 LIU-IDA/LITH-EX-G--18/031--SE Slow rate denial of service attacks on dedicated- versus cloud based server solutions En jämförelse mellan resursbindande denial of service attacker mot dedikerade och molnbaserade serverlösningar Albin Andersson Oscar Andell Supervisor : Simin Nadjm-Tehrani Examiner : Marcus Bendtsen Linköpings universitet SE Linköping ,

2 Upphovsrätt Detta dokument hålls tillgängligt på Internet eller dess framtida ersättare under 25 år från publiceringsdatum under förutsättning att inga extraordinära omständigheter uppstår. Tillgång till dokumentet innebär tillstånd för var och en att läsa, ladda ner, skriva ut enstaka kopior för enskilt bruk och att använda det oförändrat för ickekommersiell forskning och för undervisning. Överföring av upphovsrätten vid en senare tidpunkt kan inte upphäva detta tillstånd. All annan användning av dokumentet kräver upphovsmannens medgivande. För att garantera äktheten, säkerheten och tillgängligheten finns lösningar av teknisk och administrativ art. Upphovsmannens ideella rätt innefattar rätt att bli nämnd som upphovsman i den omfattning som god sed kräver vid användning av dokumentet på ovan beskrivna sätt samt skydd mot att dokumentet ändras eller presenteras i sådan form eller i sådant sammanhang som är kränkande för upphovsmannens litterära eller konstnärliga anseende eller egenart. För ytterligare information om Linköping University Electronic Press se förlagets hemsida Copyright The publishers will keep this document online on the Internet or its possible replacement for a period of 25 years starting from the date of publication barring exceptional circumstances. The online availability of the document implies permanent permission for anyone to read, to download, or to print out single copies for his/hers own use and to use it unchanged for non-commercial research and educational purpose. Subsequent transfers of copyright cannot revoke this permission. All other uses of the document are conditional upon the consent of the copyright owner. The publisher has taken technical and administrative measures to assure authenticity, security and accessibility. According to intellectual property law the author has the right to be mentioned when his/her work is accessed as described above and to be protected against infringement. For additional information about the Linköping University Electronic Press and its procedures for publication and for assurance of document integrity, please refer to its www home page: c Albin Andersson Oscar Andell

3 Students in the 5 year Information Technology program complete a semester-long software development project during their sixth semester (third year). The project is completed in mid-sized groups, and the students implement a mobile application intended to be used in a multi-actor setting, currently a search and rescue scenario. In parallel they study several topics relevant to the technical and ethical considerations in the project. The project culminates by demonstrating a working product and a written report documenting the results of the practical development process including requirements elicitation. During the final stage of the semester, students create small groups and specialise in one topic, resulting in a bachelor thesis. The current report represents the results obtained during this specialisation work. Hence, the thesis should be viewed as part of a larger body of work required to pass the semester, including the conditions and requirements for a bachelor thesis.

4 Abstract Denial of Service (DoS) attacks remain a serious threat to internet stability. A specific kind of low bandwidth DoS attack, called a slow rate attack can with very limited resources potentially cause major interruptions to the availability of the attacked web servers. This thesis examines the impact of slow rate application layer DoS attacks against three different server solutions. The server solutions are a static cloud solution and a load-balancing cloud solution running on Amazon Web Services (AWS) as well as a dedicated server. To identify the impact in terms of responsiveness and service availability a number of experiments were conducted on the web servers using publicly available DoS tools. The response times of the requests were measured. The results show that the dedicated and static cloud based server solutions are severely impacted by the attacks while the AWS load-balancing cloud solution is not impacted nearly as much. We concluded that all solutions were impacted by the attacks and that the readily available DoS tools are sufficient for creating a denial of service state on certain web servers.

5 Acknowledgments We would like to thank our supervisor Simin Nadjm-Tehrani for keeping us on track during the creation of this thesis as well as giving us valuable feedback. We would also like to thank our fellow students for giving us feedback, inspiration and support during this semester. v

6 Contents Abstract Acknowledgments Contents List of Figures List of Listings List of Tables iii v vi viii ix x 1 Introduction Aim Research questions Related work Delimitations Background Slow rate application layer denial of service attacks Server solutions Tools for performing denial of service attacks Performing Denial of Service attacks Experimental environment Experiments Results Slow header attack Slow body attack Discussion Results Method Work in a wider context Conclusion Future Work Bibliography 24 7 Appendix Observer script Full server configurations vi

7 7.3 Experiment Experiment vii

8 List of Figures 2.1 Legitimate HTTP GET header Wireshark trace of a slow header TCP stream Illegitimate HTTP POST request Topology of the experiment setup Overview of load generation and observation Average response times with a load of 200 concurrent connections while under a slow header attack running variable number of web sockets Response time of requests under a slow header attack using 250 web sockets Response time of requests with a slow header attack using 500 web sockets Average response times with a load of 200 concurrent connections with a slow body attack running variable threads Response time of request with a slow body attack running 30 threads Up-close view of the load-balancing happening in experiment 7 Figure Response times of 1000 request with a load of 10 and 200 with a slow header attack using 250 web sockets Response times of 1000 request with a load of 10 and 200 with a slow header attack using 500 web sockets Response times of 1000 request with a load of 10 and 200 with a slow body attack using 20 threads viii

9 List of Listings 2.1 Implementation of keeping connections alive in slowloris.py Implementation of keeping connections alive in Tor s Hammer Part of the Python script used for saving response times The python script used for creating load and measuring response time ix

10 List of Tables 3.1 Setup Cloud-based server Load-balancer and auto-scaling configuration Setup Dedicated server Parameters of experiment 1: Effectiveness of slow header attack Parameters of experiment 2: Server point of failure when under slow header attack Parameters of experiment 3: Slow header attack over time Parameters of experiment 4: Effects of load on a slow header attack Parameters of experiment 5: Effectiveness of slow body attack Parameters of experiment 6: Server point of failure when under slow body attack Parameters of experiment 7: Slow body attack over time Parameters of experiment 8: Effects of load on a slow body attack Server points of failure while under a slow header attack Average response time of 1000 requests with a slow header attack using 250 web sockets Average response time of 1000 requests with a slow header attack using 500 web sockets Server points of failure while under a slow body attack Average response time of 1000 requests with a slow body attack using 20 threads Full auto scale configuration Full Load balancer configuration x

11 1 Introduction Many aspects of modern life are dependent on near instant access to services and systems via the internet. Online transactions, credit card payments and communication via and social media are a daily and necessary part of the lives of many. Similarly, companies and organizations providing online services are reliant on their systems being accessible for their users. A denial of service attack is an attack that targets the availability of a system. These kinds of attacks occur frequently and have in the past caused high profile services and websites to become unavailable. In October 2016 a cyber attack directed at the DNS provider Dyn resulted in services like Twitter, Spotify and CNN suffering major interruptions during a couple of hours [1]. Efforts and research to defend against these attacks have been ongoing for many years but they still remain a very serious threat to internet stability. Denial of service can be accomplished in a number of ways by exploiting different weaknesses of network protocols and web servers. It is important to understand how these attacks affect the attacked services in order to be able to protect them. One type of denial of service attack is called a slow rate attack. It is called that way due to it requiring very little bandwidth or computational power from the attacker. Slow rate attacks typically target the application layer of the network stack by for example using malformed requests to exhaust the server s available resources. In this thesis we will take a closer look at how slow rate denial of service attacks targeting the application layer affect web applications hosted on virtual machines in the cloud and how they compare to web applications hosted on physical dedicated servers. 1.1 Aim The purpose of this thesis is to investigate and evaluate the impacts of two types types of application layer slow rate denial of service attacks on web applications running on dedicated, physical servers versus web applications running on cloud based servers. After reading this thesis the reader should have an understanding of the threats posed by slow rate denial of service attacks, how they function and how they can affect web services hosted in the cloud and on dedicated servers and also how these differ from each other. 1

12 1.2. Research questions 1.2 Research questions This project aims to answer the following questions: What is the impact of application layer slow rate denial of service attacks against cloud based- and dedicated server solutions? How does the impact on performance on dedicated- and cloud based server solutions compare against each other while affected by an application layer slow rate denial of service attack? These questions will be investigated by running experiments on virtual web servers in the cloud and on a self-hosted dedicated server. The dedicated server is implemented using an Apache HTTP server while the cloud-based server is implemented using an Amazon Web Services (AWS) solution. The experiments will be conducted on as close as possible the same hardware, software and network conditions. To carry out the experiments, two different scripts designed for server testing were used. These and similar tools are easily accessible on the web making it very easy for a potential adversary to execute an attack. These two scripts were specifically chosen for this thesis because of their ease of use and accessibility. 1.3 Related work Slow rate denial of service attacks have been explored thoroughly in other works. Similar to this thesis, Bronte et al. [2] look at slow rate application layer attacks on web applications. The authors of the article run tests by launching slow rate attacks against an Apache web server and propose possible ways of detecting such attacks. Similarly Aqil et al. [3] use combined stealthy application and transport layer attacks against a Unix system hosting an Apache web server. In a similar manner to this thesis they use an observer machine that issues legitimate requests to the server and measure the response times to determine the effects of the attack. What differentiates their implementation from ours is that they don t seem to utilize concurrent requests to simulate legitimate load. Finally they show an approach to detect such stealthy DoS attacks. Muraleedharan and Janet [4] look at various slow rate HTTP denial of service attacks and analyze the abnormal network traffic generated by these attacks. The goal is to be able to use the traffic data as a way to detect incoming attacks. While these works share similarities in implementation with this thesis project they do not cover scenarios in cloud environments. Helat [5] reviews cloud security with a focus on slow rate HTTP attacks. He provides a statistical and visual analysis of the attacks and the impact they have on the virtual cloud servers. 1.4 Delimitations Server configurations, methods and settings to try to mitigate the attack will not be explored. The thesis is also limited to one machine to simulate an attacker. This results in distributed denial of service attacks not being evaluated. 2

13 2 Background The following chapter will cover the theory and background of the thesis which includes the tools used for the experiments. 2.1 Slow rate application layer denial of service attacks Slow rate denial of service attacks are types of attacks that require a very small amount of bandwidth and computing power to achieve the goals of the attack [6]. Because of this, these kinds of attacks can be conducted by a single or few attackers and still have the effectiveness of large, flooding based denial of service attacks. These kind of attacks are generally very hard to detect since they mostly manifest like normal network traffic. Instead of overwhelming the networks or servers with massive amounts of traffic they instead use clever ways of attacking by either consuming huge amounts of resources on the server or by using exploits to crash it. Application layer attacks, also called layer 7 attacks, are denial of service attacks specifically targeting the application layer of the network stack [7]. These kinds of attacks target protocols such as HTTP, HTTPS and DNS and typically target things such as CPU and memory resources by effectively locking these resources with incomplete requests and slow transmission rates. This means a single slow layer 7 attack has the potential to crash an entire web server, regardless of the hardware the server is running on [4]. Slow header attack A slow header denial of service attack [8][6][3], often called a slow loris attack, uses HTTP GET request to fill up a web server s available connections. This attack can be carried out with a limited number of machines that send incomplete requests to the server. The malicious requests are created by not sending the string \r\n\r\n representing a double line break specifying the end of the HTTP-header. Figure 2.1 shows a legitimate HTTP GET request. 3

14 2.1. Slow rate application layer denial of service attacks Figure 2.1: Legitimate HTTP GET header The highlighted extra line break \r\n tells the server that the request header has been completed. By omitting this line break from the HTTP-header the server will continue to keep the connection alive until a double line break is received or an eventual timeout. The attacker will then continue to send illegitimate HTTP-header fields resulting in a trace as shown in Figure 2.2. Figure 2.2: Wireshark trace of a slow header TCP stream. These incomplete requests will fill up the server s connection pool since the server will not break the connection until the request is complete. This results in legitimate connections not being served by the server. Since the attack only sends a small amount of data for every incomplete request, the attacker requires only minimal computational power and bandwidth to execute this kind of attack. Slow body attack A slow body denial of service attack [8][6][5] uses HTTP POST requests to fill up a server s available resources and thus making the server unresponsive to other, legitimate connections. Figure 2.3: Illegitimate HTTP POST request In Figure 2.3 an illegitimate HTTP POST request is shown. Unlike the slow loris attack, the header ended with an empty line. The complete header specifies an abnormally large body content length, bytes in the case of Figure 2.3. An attacker will then send the contents of the body of the POST request at a very slow rate, often single bytes at a time while waiting several minutes between packets. Figure 2.3 shows the body of the request which consist of random characters. Since the content length is defined to be so long this will take a very long time to complete and will use up the server s available connections without using almost any of the attackers computational power and network. This will deny service to any legitimate traffic since the server will be busy handling the incoming illegitimate traffic. By doing this an attacker can keep many connections to the server active for a prolonged amount of time which, if done on a large enough scale, will deny service by the server. 4

15 2.2. Server solutions 2.2 Server solutions There exist multiple solutions for hosting websites or other applications on the web and they all function differently. For this thesis the solutions detailed below are examined. Cloud servers Cloud computing makes a service available to users over the internet that is often shared or distributed between many machines and enables the application to allocate computing power where it is needed [9]. There are many benefits of cloud computing [5]. It allows companies to access computing power and storage on demand without the need to buy and configure additional IT infrastructure. It also allows resources to scale dynamically to meet the demand of workload. Another benefit of employing cloud services is that it reduces the workload of software and hardware maintenance and other IT related work. Despite the benefits, cloud computing is vulnerable to many of the threats faced by traditional infrastructure such as loss of data, hardware failure and insecurities in API:s and interfaces [10]. Amazon Web Services (AWS) is a cloud computing platform which offers a wide variety of services and allows users to create virtual machines to host web servers and various other internet applications. The service which is used for this thesis project is AWS Elastic Beanstalk. Elastic Beanstalk is a service that allows customers to deploy and manage web applications in the AWS cloud. The service allows users to set up their applications in either single instance or load-balancing and auto-scaling environments [11]. Auto-scaling means that application instances are added and removed dynamically to handle increases and decreases of traffic to the application. Traffic to the application instances are distributed by a load-balancer, which acts as an access point to all of the instances. By default the load-balancer listens to HTTP traffic and forwards it to the environment. AWS also monitors the health of the application and routes incoming network traffic to available instances. Dedicated servers A dedicated server is a server running on hardware which isn t shared with other servers as opposed to cloud solutions which typically share the hardware between many virtual machines. Doing this gives the customer full control over the server settings as well as the configurations of the operating system which results in a very flexible environment. It could also increase performance since the environment can be adjusted to the specific workload it is employed to do. Apache The server solutions examined in this thesis are all using an Apache HTTP web server. The Apache HTTP Server Project is an open source HTTP server developed by the Apache Software Foundation. It was released in 1995 and quickly became the leading server solution [12]. According to W3Techs [13], it is currently the most used web server, used in 47.1% of servers surveyed. Apache is a thread-based web server and is known to be vulnerable against slow rate attacks. This is because Apache, by default, dedicates resources to every connection instead of dynamically allocating resources where they are needed [14]. Apache servers have a maximum timeout after which ongoing connections are dropped which for most Apache servers is 300 seconds [7]. This leads to a resource depleting attack such as a typical application layer slow rate denial of service having a big effect since it effectively can bind all resources of the host machine. 5

16 2.3. Tools for performing denial of service attacks 2.3 Tools for performing denial of service attacks In this section the tools we used for performing denial of service attacks are described. slowloris.py by Gokberk Yaltirakli Slowloris.py is an open source low bandwidth denial of service tool developed by Gokberk Yaltirakli [15]. This simple Python script lets users execute a slow header attack on a server by specifying a target url address and the number of web sockets to be used in the attack. The script will then establish the specified number of connections to the target server and keep them alive for as long as possible, occupying the server threads. This is accomplished by sending keep-alive headers on all ongoing connections at 15 second intervals (Shown in Listing 2.1). Broken connections are discarded and recreated keeping the number of connections constant. Listing 2.1: Implementation of keeping connections alive in slowloris.py while True: for s in list(list_of_sockets): try: s.send("x-a: {}\r\n".format(random.randint(1,5000)).encode("utf-8")) except socket.error: list_of_sockets.remove(s)... time.sleep(15) Tor s Hammer Tor s Hammer is a low-bandwidth tool written in Python that is used for performing a slow body HTTP attack. The version used in this thesis [16] works by first sending a complete HTTP POST header and after that sending a random character followed by sleeping for somewhere between 0.1 and 3 seconds (as shown in Listing 2.2). The script uses multithreading to allow multiple active illegitimate connections at once and the number of threads used by the attacking machine is specified by the attacker. Listing 2.2: Implementation of keeping connections alive in Tor s Hammer socks.send("post / HTTP/1.1\r\n" "Host: %s\r\n" "User-Agent: %s\r\n" "Connection: keep-alive\r\n" "Keep-Alive: 900\r\n" "Content-Length: 10000\r\n" "Content-Type: application/x-www-form-urlencoded\r\n\r\n" % (host, random.choice(useragents))) for i in range(0, 9999): p = random.choice(string.letters+string.digits) socks.send(p) time.sleep(random.uniform(0.1, 3)) 6

17 3 Performing Denial of Service attacks This chapter explains the testing environment and configurations used for the conducted tests and executions of the experiments. 3.1 Experimental environment Figure 3.1: Topology of the experiment setup The experiments were conducted on two different sets of environments, a cloud environment with settings shown in table 3.1 and a dedicated environment with characteristics shown in table 3.3. The topology of the testing environment is shown in Figure 3.1. The attacker machine will separately execute the attacks on the different server solutions while the observer machine generates legitimate load and observes the effectiveness of the attack by recording the response times of the requests. 7

18 3.1. Experimental environment Configuration of cloud servers Table 3.1: Setup Cloud-based server AWS Virtual enviroment AWS Environment Type OS Webserver CPU RAM Disk t2.micro Single instance or load-balanced, auto-scaling Ubuntu Server LTS Apache/2.4.2 Intel Xeon E GHz running 1 thread 1 GB 8 GB By using the free tier of Amazon Web Services, a virtual machine running Ubuntu Server LTS was created. This virtual machine was set up to deploy two separate web applications with the AWS Elastic Beanstalk service. The first web application was configured to run in a load-balancing and auto-scaling environment. This allows more instances of the application to be added to accommodate an increase in load. The specific auto-scaling parameters and configuration used for this project are shown in Table 3.2. The auto-scaling configuration uses the average latency as a metric for detecting an increase in load. This metric was chosen due to it being similar to the main metric used in our experiments, i.e. response time. Measurement period is the time between the points at which the server evaluates its current state and health. To be able to quickly respond to a denial of service attack this is set to the minimum value of 60 seconds. The idle timeout for the load-balancer is set to the default and recommended value of 60 seconds. This means that the load-balancer will close ongoing connections after 1 minute. The full configuration for the load-balanced and auto-scaling server can be seen in Table 7.1 and 7.2 in the appendix. From now on we will refer to the load-balanced and auto-scaling server as simply the load-balanced server. Table 3.2: Load-balancer and auto-scaling configuration Scale based on Add instance when Remove instance when Measurement period Idle timeout Average latency > 5 seconds < 1 second 60 seconds 60 seconds The second application was configured to run in a single instance environment which means it does not have a load-balancer and does not allow more instances to be dynamically added. Due to the limitations of the AWS free tier, the virtual machine is running on hardware located in the US. Dedicated server configuration Table 3.3: Setup Dedicated server OS Webserver CPU RAM Disk Ubuntu Server LTS Apache/2.4.2 Intel Core 2.50 GHz 4 GB 8 GB 8

19 3.2. Experiments The Linux machine acting as a dedicated server (Table 3.3) hosts the web application on a Apache/2.4.2 web server configured with the default configurations. This means that among other things, the maximum number of clients is set to the default value of 256. This server was hosted on the same local network as the attacking and observation machines. This means that the dedicated solution will have a naturally shorter round trip time to the server compared to the cloud solutions because of the physical distance between them. 3.2 Experiments To measure the effectiveness of the denial of service the response time of the applications was used as a metric. The response time was measured by issuing multiple HTTP GET requests to the server and recording the time between sending the request and the response from the server on the same machine, the observer one. The variations in configurations and settings of the tools and load generators will be detailed under each specific experiment. All of the server solutions were set up to serve a Python 3.6 application which outputs static HTML content. Load generation and observation Figure 3.2: Overview of load generation and observation To simulate legitimate web traffic and measure response times to the servers we created the Python script shown in Appendix 7.1. The script uses multiple concurrent threads to send HTTP GET request to a chosen website URL. The program will measure the amount of time between sending the request and an HTTP 200 OK response from the server, as shown in Listing 3.1. Other responses such as 500 Internal Server Error are discarded and counted as failed requests. For each request the timestamp and response time are saved to file to allow further analysis of the data. Listing 3.1: Part of the Python script used for saving response times response = requests.get(url) if response.status_code == 200: arr.append([response.elapsed.total_seconds(), time_stamp]) In this script we define two different parameters, which can be specified by the user. The first is the total number of measurement requests. This specifies the total number of HTTP requests sent by the script. The second parameter is load. Load specifies how many concurrent threads will be used to send the measurements requests, i.e how many requests are sent 9

20 3.2. Experiments concurrently. Figure 3.2 shows the relation between the measurement requests and load. The measurement requests are placed in a queue until a thread is available and is then sent to the server. During the experiments, this script will be run on the observer machine as seen in Figure 3.1. Henceforth in this thesis we will call this script the observer script. Slow header attack The slow header attack experiments were executed with the slowloris.py script described in section 2.3. The attacking script was left running on the attacking machine for each intensity of the attack until all measurements were complete. Tables 3.4, 3.5, 3.6 and 3.7 show the different slow header test configurations. The number of attacking web sockets for each experiments is called attacking web sockets. Table 3.4: Parameters of experiment 1: Effectiveness of slow header attack Attack type Slow header Load 200 Measurement requests 500 Attacking web sockets , increments of 100 The goal of experiment 1 (Table 3.4) was to examine how the different servers reacted to the number of illegitimate connections generated by the slow header attack. In the experiment, the load script was configured to test response time of the servers 500 times with a load of 200 concurrent connections. For each server, the number of web sockets used by the attacking machine was incremented by 100. The attacks have the potential to cause very long response times and the time to perform the experiments could potentially become very long. Because of this we chose to use 500 measurement requests in most experiments. Table 3.5: Parameters of experiment 2: Server point of failure when under slow header attack Attack type Slow header Load 200 Measurement requests 500 Attacking web sockets Incremented until failure In experiment 2 (Table 3.5), the goal was to find if there is a point of failure where the servers becomes completely unavailable. This is done by incrementing the number of illegitimate connections and measuring the number of failed requests. For this test completely unavailable is defined to be the point where 100% of the requests fail. Table 3.6: Parameters of experiment 3: Slow header attack over time Attack type Slow header Load 200 Measurement requests Attacking web sockets 250, 500 In experiment 3 (Table 3.6) we measure the effectiveness of the attack over a longer period of time to determine if the effects on the servers remain constant or change during the duration of the attack. This is done by increasing the number of measurements in the observer script and presenting them in the order they were sent. This means that we can observe how the server response times change over time. The test was carried out under a slow header attack using 250 and 500 web sockets. 10

21 3.2. Experiments Table 3.7: Parameters of experiment 4: Effects of load on a slow header attack Attack type Slow header Load 10 & 200 Measurement requests 1000 Attacking web sockets 250, 500 To explore if and how the slow header attack is affected by competing legitimate traffic, the slow header attacks are executed on servers with different levels of load. In this experiment the observer script has two configurations. The first configuration runs the measurements using only 10 concurrent connections while the second uses 200. Since we only evaluate two intensities of the slow header attack in this experiment it will be quicker to preform. Because of this the number of measurement requests is set to 1000 to potentially observe more long term effects. Slow body attack The configurations of the slow body experiments are shown in tables 3.8, 3.9, 3.10 and The attacks were launched using the tool Tor s Hammer as described in section 2.3. Similar to the slow header attack the script was left running for each intensity of the attack until all measurements were complete. The number of threads used by the attacking machine is called attacking threads. Table 3.8: Parameters of experiment 5: Effectiveness of slow body attack Attack type Slow body Load 200 Measurement requests 500 Attacking threads Similar to experiment 1, experiment 5 examines how the server reacts to different intensities of the same attack. This is to get an overview of how effective the slow body attacks are against the servers. In this experiment the observer script was executed 20 seconds after the attack tool was started as recommended by the creator of the tool. The number of threads used in the attack was incremented by 5 until we reached 40 active threads. The number was then incremented by 10 to 50 active threads and later 60 active threads. The next set of tests started at 100 threads and was incremented by 50 until we reached the final test of 400 attacking treads. Table 3.9: Parameters of experiment 6: Server point of failure when under slow body attack Attack type Slow body Load 200 Measurement requests 500 Attacking threads Incremented until failure Similar to experiment 2, experiment 6 examines if there exists a point where the servers become completely inaccessible while under attack from a slow body denial of service attack. The measurements where made approximately 1 minute after the attack was started to ensure that the attack has taken full effect. 11

22 3.2. Experiments Table 3.10: Parameters of experiment 7: Slow body attack over time Attack type Slow body Load 200 Measurement requests Attacking threads 30 Experiment 7 seeks to examine how the slow body attack affects the servers over a longer period of time. Like experiment 3 this is done by increasing the number of requests made by the observer script and presenting them in chronological order. Table 3.11: Parameters of experiment 8: Effects of load on a slow body attack Attack type Slow body Load 10 & 200 Measurement requests 1000 Attacking threads 20 Similar to experiment 4 this experiment aims to explore how the attack is affected by competing, legitimate traffic. As in experiment 4 the load of the first test of the experiment is 10 concurrent connections followed by another test with a load of 200 concurrent connections. This test also uses 1000 measurement requests for the same reason as experiment 4. 12

23 4 Results In this chapter the results of the experiments detailed in chapter 3 will be accounted for. 4.1 Slow header attack Experiment 1: Effectiveness of slow header attack In Section 3.1 we introduced our three server solutions examined in this thesis, the dedicated-, the static cloud- and the load-balanced cloud server. The first experiment which is presented in Figure 4.1 looks at the average response times and the number of failed requests to the servers under different intensities of the slow header attack. A logarithmic scale was used for Figure 4.1 since the results varied too much in size to be easily represented in a linear scale. Figure 4.1: Average response times with a load of 200 concurrent connections while under a slow header attack running variable number of web sockets 13

24 4.1. Slow header attack As can be seen in Figure 4.1 there are some big differences between the different server solutions. The dedicated server was not noticeably affected at all until between 200 and 300 sockets where it stopped responding all together. However the cloud solutions behaved differently. The static cloud solution steadily increased in response time while the load-balanced cloud solution remained roughly the same across all tests. An anomaly can be observed in the static cloud server. When the number of attacking web sockets reached 600 about 1/5 of the measurement requests failed, while in the next test with 700 web sockets, no requests failed. We are unsure about why exactly this occurred but we observed that the static cloud server became very unstable past 500 attacking web sockets. Experiment 2: Point of failure for server under slow header attack Table 4.1: Server points of failure while under a slow header attack Server Point of failure Static cloud server 1500 Load-balanced cloud server None Dedicated server 256 The results of experiments 2 is shown in Table 4.1. The dedicated server became completely unavailable after 256 web sockets were used in the attack. An observation is that this is the same as the default number of max clients as mentioned in section 3.1, which is most likely the reason for this behaviour. For the static cloud servers the point of failure is not as clear. We found no clear cutoff point where the server was completely unavailable for all request but after 1500 sockets a vast majority of the requests failed or had an response time of more than 20 seconds. The load-balancing cloud server isn t noticeably affected by the header attack and has no point of failure. Experiment 3: Slow header attack over time Figure 4.2: Response time of requests under a slow header attack using 250 web sockets 14

25 4.1. Slow header attack Figure 4.2 shows the effects of the slow header denial of service attack over HTTP-GET requests in a scatter plot. The right column shows the baseline test for the different server solutions. Each request is presented as a dot and the request are ordered in the order they were sent to the server. For the static cloud and dedicated server, the figure shows significant effects on the response times of requests, however the effects are sporadic. In the case of the load-balancing cloud server, no clear effects of the denial of service attack can be seen. Figure 4.3: Response time of requests with a slow header attack using 500 web sockets With 500 web sockets used in the attack the dedicated server is unavailable and no requests were served. Because of that Figure 4.3 only shows the results of the cloud solutions. During the attack, the static cloud server experienced three major spikes in response time, with some request taking over 60 seconds to complete. The load-balanced server also experienced a spike in response time, with maximum response times of around 5 seconds. Both Figure 4.2 and Figure 4.3 shows a large spread in response times, indicating that the slow header attack is not able to constantly maintain a denial of service state on the targeted severs. Experiment 4: Effects of load on a slow header attack Table 4.2: Average response time of 1000 requests with a slow header attack using 250 web sockets Server 10 Load 200 Load Static Cloud 0.31s 4.92s Load-balanced Cloud 0.29s 0.51s Dedicated 0.16s 2.96s Table 4.2 shows that when the intensity of the attack is lower (250 sockets), the response time is negatively effected by a larger load. The case with a load of 10 concurrent connections does not seem to be noticeably affected by the attack while the case with a load of 200 concurrent connections has significant increases in response time. 15

26 4.2. Slow body attack Table 4.3: Average response time of 1000 requests with a slow header attack using 500 web sockets Server 10 Load 200 Load Static Cloud 27.68s 13.68s Load-balanced Cloud 0.34s 0.45s Dedicated Unavailable Unavailable In the test with a higher attack intensity (500 sockets) the opposite is observed. Figure 4.3 indicate that a larger load has a shorter average response time than the case with a load of 10. While this is noteworthy, the complete scatter plots shown in appendix 7.1 and 7.2 do not indicate any outliers that might unproportionally affect the results. One possible explanation for this behavior is that with 250 sockets the attack occupy some but not all of the server s available connections. That means that with high load the legitimate connections have to compete with each other for the few available resources, while with low load the few available connections will be sufficient to serve the legitimate connections. Then when the number of web sockets used is increased to 500, all of the servers available connections are occupied. Legitimate traffic has to compete with illegitimate to reach the server. This makes the attack less effective when the server is under higher load. 4.2 Slow body attack Experiment 5: Effectiveness of slow body attack Figure 4.4: Average response times with a load of 200 concurrent connections with a slow body attack running variable threads A logarithmic scale was used for experiment 5 in Figure 4.4. As can be seen in Figure 4.4 the response times of the dedicated server stayed fairly constant until the point of failure between 250 and 300 threads used, when the server became unresponsive and failed all requests. The static and load-balancing cloud servers both followed roughly the same pattern of steadily increasing in response times and the number 16

27 4.2. Slow body attack of failed requests as the number of threads used in the attack increased. In the case of 400 threads all the requests sent from the observer to the load-balanced server failed. The static cloud server barely remained responsive with response times of up to 2 minutes and 4 out of 5 requests failing. Experiment 6: Point of failure for server under slow body attack Table 4.4: Server points of failure while under a slow body attack Server Point of failure Static cloud server 400 Load-balanced cloud server None Dedicated server 256 The dedicated server became unavailable when the attack used 256 threads. This is unsurprising for the same reasons explained in the results of experiment 2, that the default maximum clients in Apache is set to 256. The points of failure of the cloud servers is harder to define. At around 400 threads the static cloud server became unresponsive but this number varied a bit between experiments. The load-balanced cloud server became unresponsive for a short while but later returned to normal levels. This meant that the load-balancing cloud solution had no clear point of failure. Experiment 7: Slow body attack over time Figure 4.5: Response time of request with a slow body attack running 30 threads Results of experiment 7 is shown in Figure 4.5. The dedicated server remained consistent with experiment 5 (Figure 4.4) and no noticeable effects of the attack is shown. The first requests sent to the load-balancing cloud server experienced response times of around 50 seconds. After the first batch of requests the attack has little to no noticeable effect on the server. The static cloud server however was massively impacted by the attack and had delays in the 17

28 4.2. Slow body attack response time of up to two minutes while failing approximately 40% of all requests as can be seen in the gaps in the plot. This experiment seemed to create a more consistent denial of service state on the static cloud solution compared to the slow header attack shown in experiment 3 (Figures 4.2 and 4.3). The slow body and slow header attacks both manage to create response times of around a minute but the major difference is that in the case of the slow header attack this only occurs in spikes while it happens quite consistently in the case of the slow body attack. Experiment 8: Effects of load on a slow body attack Table 4.5: Average response time of 1000 requests with a slow body attack using 20 threads Server 10 Load 200 Load Static Cloud 4.21s 23.50s Load-balanced Cloud 0.54s 7.82s Dedicated 0.17s 3.10s The results of experiment 8 can be seen in Table 4.5. While under a load of 10 concurrent connections only the static cloud server was impacted in a major way while the other solutions remained fairly healthy. Every server solution tested was impacted when using a load of 200 concurrent connections and experienced a major increase in response times. The loadbalancing cloud server however was only impacted for a short duration of the test before returning to normal levels. This experiment indicate that the slow body attack is also affected by legitimate load, similar to the slow header attack. A full scatter plot of this experiment can be found in Figure 7.3 in the Appendix. 18

29 5 Discussion In this chapter we will discuss, examine and evaluate our results and methodology. We will also be looking at our work in a wider context. 5.1 Results The experiments clearly show that all of the different tested server solutions show vulnerabilities to slow rate application layer denial of service attacks. There are however differences in how the servers are affected. The experiments show that the slow header and slow body attacks have different properties and affect the servers differently. In this section we will discuss the attacks and the different servers separately. Denial of service attack impacts Using the slow header attack, the attacking machine can create a state of denial of service on both the dedicated and static cloud server, causing large delays in response times or even making the requests to the server fail to retrieve the page content. The experiments also show that the slow header attack does not noticeably affect the load-balanced cloud server. The slow header attack is also shown to be affected by legitimate server load, but this impact seem to depend on the intensity of the attack, as shown in experiment 4 Tables 4.2 and 4.3. The slow body attack is shown to be able to cause a state of denial of service to all server solutions presented in this thesis, with varying effectiveness. The attacking machine could make both the static cloud server and the dedicated server unavailable for an indefinite amount of time. While not being able take it down completely, the slow body attack could also cause interruptions to the load-balanced cloud server. Experiment 8 presented in Table 3.11 shows that the amount of load also has an impact on the effectiveness of the slow body attack. The experiment seems to indicate that a server under heavy load is affected more severely. Dedicated server An observation about the dedicated server is that it does not show the same gradual degradation of performance as the other server solutions. It is however very vulnerable to both slow 19

30 5.1. Results header and body attacks since it becomes completely unavailable for an indefinite amount of time when the number of illegitimate connections exceeds the maximum, shown in Tables 4.1 and 4.4. An explanation for this result is that the attacks manages to use up the Apache servers client slots which defaults to 256. When there were still connection slots available the server was accommodating all the requests but as soon as all slots filled up the service was completely denied. Static cloud server The static cloud server showed a gradual decrease in performance as the intensity of the tests increased. Figure 4.1 and Figure 4.4 from experiments 1 and 5 illustrate this point quite well. The static server did however resist a crash when subjected to these loads, it slowed down significantly but stayed online even after the dedicated server had long since become unavailable. There could be many reasons for this behaviour. One explanation might be the proximity of the attack. The cloud servers are located in the US while the attacks are launched from Sweden. This makes things like packet loss more likely to occur and the attack is not able to occupy server resources as effectively. It could also be an effect of the cloud architecture. Load-balanced cloud server The slow header experiments (Section 4.1) seem to show that the slow loris attack has no or very little impact on the server. Response times do not increase when increasing the intensity of the attack and no point of failure was found. On the other hand the slow body experiments (Section 4.2) show that the server is severely effected by this type of attack. We speculate that the reason the effectiveness of the different attacks vary so widely is because of the loadbalancer in front of the server. The load-balancer forwards HTTP request to the correct server instance but this does not seem to occur in the case of a slow header attack. This could be because the slow header attack never completes the HTTP-header and as such is never interpreted as an HTTP request and will not be forwarded to the server. This explanation raises another question. Why is not the load-balancer itself affected by the slow header denial of service? One possible answer is that the load-balancer might be running on a different web server solution than Apache and is not as vulnerable to these kinds of slow rate application layer attacks. When the load-balancing server is subjected to the slow body attack it initially seems to be affected in a similar manner to the static cloud server. The results of experiment 5 (Figure 4.4) show long response times and that a large number of requests fail. The reason why this attack is effective while the header attack is not might be because of the slow body attacks actually completing the HTTP-header. This might cause the load-balancer to forward the malicious traffic to the targeted server. When looking at the attack over a longer period of time in experiment 7 (Figure 4.5), we observe that the initial requests sent from the observer have very long response times of around 50 seconds. After roughly 50 seconds the response times drop significantly. This could possibly be the result of the of the auto-scaling feature. The auto-scaling is triggered by the average latency and creates new instances to accommodate the load. Another possible explanation is that the load-balancer closes the illegitimate connections after they exceed the timeout period. No matter the explanation the attack is effectively mitigated. While the attack was mitigated this does not necessarily mean that the load-balanced solution has any kind of protection against these kinds of attacks. It could simply be a symptom of this solution having more resources than the other solutions. The load-balancer can scale the web application to accommodate for the illegitimate connections. This results in a higher cost since you pay for the resources you use which is why you typically don t let it scale indefinitely. This means that an attack using more illegitimate connections should be able to cause a state of denial of service similar to the static cloud solution. 20