Linköpings universitetSE–581 83 Linköping

+46 13 28 10 00 , www.liu.se

Linköping University | Department of Computer and Information ScienceBachelor thesis, 16 ECTS | Information technology

2018 | LIU-IDA/LITH-EX-G--18/031--SE

Slow rate denial of serviceattacks on dedicated- versuscloud based server solutionsEn jämförelse mellan resursbindande denial of service attackermot dedikerade och molnbaserade serverlösningar

Albin AnderssonOscar Andell

Supervisor : Simin Nadjm-TehraniExaminer : Marcus Bendtsen

Upphovsrätt

Detta dokument hålls tillgängligt på Internet – eller dess framtida ersättare – under 25 årfrå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 enstakakopior för enskilt bruk och att använda det oförändrat för ickekommersiell forskning och förundervisning. Överföring av upphovsrätten vid en senare tidpunkt kan inte upphäva dettatillstånd. All annan användning av dokumentet kräver upphovsmannens medgivande. Föratt garantera äktheten, säkerheten och tillgängligheten finns lösningar av teknisk och admin-istrativ art. Upphovsmannens ideella rätt innefattar rätt att bli nämnd som upphovsman iden omfattning som god sed kräver vid användning av dokumentet på ovan beskrivna sättsamt skydd mot att dokumentet ändras eller presenteras i sådan form eller i sådant sam-manhang som är kränkande för upphovsmannens litterära eller konstnärliga anseende elleregenart. För ytterligare information om Linköping University Electronic Press se förlagetshemsida http://www.ep.liu.se/.

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 circum-stances. The online availability of the document implies permanent permission for anyone toread, to download, or to print out single copies for his/hers own use and to use it unchangedfor non-commercial research and educational purpose. Subsequent transfers of copyrightcannot revoke this permission. All other uses of the document are conditional upon the con-sent of the copyright owner. The publisher has taken technical and administrative measuresto assure authenticity, security and accessibility. According to intellectual property law theauthor has the right to be mentioned when his/her work is accessed as described above andto be protected against infringement. For additional information about the Linköping Uni-versity Electronic Press and its procedures for publication and for assurance of documentintegrity, please refer to its www home page: http://www.ep.liu.se/.

c© Albin AnderssonOscar Andell

Students in the 5 year Information Technology program complete a semester-long soft-ware development project during their sixth semester (third year). The project is completedin mid-sized groups, and the students implement a mobile application intended to be usedin a multi-actor setting, currently a search and rescue scenario. In parallel they study severaltopics relevant to the technical and ethical considerations in the project. The project culmi-nates by demonstrating a working product and a written report documenting the results ofthe practical development process including requirements elicitation. During the final stageof the semester, students create small groups and specialise in one topic, resulting in a bache-lor 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 thesemester, including the conditions and requirements for a bachelor thesis.

Abstract

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

Acknowledgments

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

v

Contents

Abstract iii

Acknowledgments v

Contents vi

List of Figures viii

List of Listings ix

List of Tables x

1 Introduction 11.1 Aim . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Research questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.3 Related work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.4 Delimitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2 Background 32.1 Slow rate application layer denial of service attacks . . . . . . . . . . . . . . . . 32.2 Server solutions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.3 Tools for performing denial of service attacks . . . . . . . . . . . . . . . . . . . . 6

3 Performing Denial of Service attacks 73.1 Experimental environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73.2 Experiments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

4 Results 134.1 Slow header attack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134.2 Slow body attack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

5 Discussion 195.1 Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195.2 Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215.3 Work in a wider context . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

6 Conclusion 226.1 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

Bibliography 24

7 Appendix 267.1 Observer script . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267.2 Full server configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

vi

7.3 Experiment 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 287.4 Experiment 8 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

vii

List of Figures

2.1 Legitimate HTTP GET header . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42.2 Wireshark trace of a slow header TCP stream. . . . . . . . . . . . . . . . . . . . . . . 42.3 Illegitimate HTTP POST request . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

3.1 Topology of the experiment setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73.2 Overview of load generation and observation . . . . . . . . . . . . . . . . . . . . . . 9

4.1 Average response times with a load of 200 concurrent connections while under aslow header attack running variable number of web sockets . . . . . . . . . . . . . 13

4.2 Response time of 10000 requests under a slow header attack using 250 web sockets 144.3 Response time of 10000 requests with a slow header attack using 500 web sockets . 154.4 Average response times with a load of 200 concurrent connections with a slow

body attack running variable threads . . . . . . . . . . . . . . . . . . . . . . . . . . . 164.5 Response time of 10000 request with a slow body attack running 30 threads . . . . 17

5.1 Up-close view of the load-balancing happening in experiment 7 Figure 4.5 . . . . . 21

7.1 Response times of 1000 request with a load of 10 and 200 with a slow header attackusing 250 web sockets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

7.2 Response times of 1000 request with a load of 10 and 200 with a slow header attackusing 500 web sockets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

7.3 Response times of 1000 request with a load of 10 and 200 with a slow body attackusing 20 threads . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

viii

List of Listings

2.1 Implementation of keeping connections alive in slowloris.py . . . . . . . . . . . 62.2 Implementation of keeping connections alive in Tor’s Hammer . . . . . . . . . 63.1 Part of the Python script used for saving response times . . . . . . . . . . . . . . 97.1 The python script used for creating load and measuring response time . . . . . 26

ix

List of Tables

3.1 Setup Cloud-based server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83.2 Load-balancer and auto-scaling configuration . . . . . . . . . . . . . . . . . . . . . . 83.3 Setup Dedicated server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83.4 Parameters of experiment 1: Effectiveness of slow header attack . . . . . . . . . . . 103.5 Parameters of experiment 2: Server point of failure when under slow header attack 103.6 Parameters of experiment 3: Slow header attack over time . . . . . . . . . . . . . . 103.7 Parameters of experiment 4: Effects of load on a slow header attack . . . . . . . . . 113.8 Parameters of experiment 5: Effectiveness of slow body attack . . . . . . . . . . . . 113.9 Parameters of experiment 6: Server point of failure when under slow body attack 113.10 Parameters of experiment 7: Slow body attack over time . . . . . . . . . . . . . . . 123.11 Parameters of experiment 8: Effects of load on a slow body attack . . . . . . . . . . 12

4.1 Server points of failure while under a slow header attack . . . . . . . . . . . . . . . 144.2 Average response time of 1000 requests with a slow header attack using 250 web

sockets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154.3 Average response time of 1000 requests with a slow header attack using 500 web

sockets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164.4 Server points of failure while under a slow body attack . . . . . . . . . . . . . . . . 174.5 Average response time of 1000 requests with a slow body attack using 20 threads . 18

7.1 Full auto scale configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277.2 Full Load balancer configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

x

1 Introduction

Many aspects of modern life are dependent on near instant access to services and systemsvia the internet. Online transactions, credit card payments and communication via email andsocial media are a daily and necessary part of the lives of many. Similarly, companies andorganizations providing online services are reliant on their systems being accessible for theirusers.

A denial of service attack is an attack that targets the availability of a system. These kindsof attacks occur frequently and have in the past caused high profile services and websitesto become unavailable. In October 2016 a cyber attack directed at the DNS provider Dynresulted in services like Twitter, Spotify and CNN suffering major interruptions during acouple of hours [1]. Efforts and research to defend against these attacks have been ongoingfor 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 weak-nesses of network protocols and web servers. It is important to understand how these attacksaffect the attacked services in order to be able to protect them. One type of denial of serviceattack is called a slow rate attack. It is called that way due to it requiring very little bandwidthor computational power from the attacker. Slow rate attacks typically target the applicationlayer of the network stack by for example using malformed requests to exhaust the server’savailable resources. In this thesis we will take a closer look at how slow rate denial of serviceattacks targeting the application layer affect web applications hosted on virtual machines inthe 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 ap-plication 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 thisthesis the reader should have an understanding of the threats posed by slow rate denial ofservice attacks, how they function and how they can affect web services hosted in the cloudand on dedicated servers and also how these differ from each other.

1

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 cloudbased- and dedicated server solutions?

• How does the impact on performance on dedicated- and cloud based server solutionscompare against each other while affected by an application layer slow rate denial ofservice attack?

These questions will be investigated by running experiments on virtual web servers in thecloud and on a self-hosted dedicated server. The dedicated server is implemented using anApache HTTP server while the cloud-based server is implemented using an Amazon WebServices (AWS) solution. The experiments will be conducted on as close as possible the samehardware, 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 potentialadversary to execute an attack. These two scripts were specifically chosen for this thesisbecause 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 tothis 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 webserver and propose possible ways of detecting such attacks.

Similarly Aqil et al. [3] use combined stealthy application and transport layer attacksagainst a Unix system hosting an Apache web server. In a similar manner to this thesis theyuse an observer machine that issues legitimate requests to the server and measure the re-sponse times to determine the effects of the attack. What differentiates their implementationfrom 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 andanalyze the abnormal network traffic generated by these attacks. The goal is to be able to usethe traffic data as a way to detect incoming attacks.

While these works share similarities in implementation with this thesis project they donot cover scenarios in cloud environments. Helat [5] reviews cloud security with a focus onslow rate HTTP attacks. He provides a statistical and visual analysis of the attacks and theimpact 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 distributeddenial of service attacks not being evaluated.

2

2 Background

The following chapter will cover the theory and background of the thesis which includes thetools 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 ofbandwidth and computing power to achieve the goals of the attack [6]. Because of this, thesekinds of attacks can be conducted by a single or few attackers and still have the effectivenessof large, flooding based denial of service attacks. These kind of attacks are generally very hardto detect since they mostly manifest like normal network traffic. Instead of overwhelming thenetworks or servers with massive amounts of traffic they instead use clever ways of attackingby 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 specif-ically targeting the application layer of the network stack [7]. These kinds of attacks targetprotocols such as HTTP, HTTPS and DNS and typically target things such as CPU and mem-ory resources by effectively locking these resources with incomplete requests and slow trans-mission rates. This means a single slow layer 7 attack has the potential to crash an entire webserver, 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 HTTPGET request to fill up a web server’s available connections. This attack can be carried outwith a limited number of machines that send incomplete requests to the server. The maliciousrequests are created by not sending the string ”\r\n\r\n” representing a double line breakspecifying the end of the HTTP-header. Figure 2.1 shows a legitimate HTTP GET request.

3

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 beencompleted. By omitting this line break from the HTTP-header the server will continue to keepthe connection alive until a double line break is received or an eventual timeout. The attackerwill then continue to send illegitimate HTTP-header fields resulting in a trace as shown inFigure 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 willnot break the connection until the request is complete. This results in legitimate connectionsnot being served by the server. Since the attack only sends a small amount of data for everyincomplete request, the attacker requires only minimal computational power and bandwidthto 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’savailable 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, theheader ended with an empty line. The complete header specifies an abnormally large bodycontent length, 10000 bytes in the case of Figure 2.3. An attacker will then send the contentsof the body of the POST request at a very slow rate, often single bytes at a time while waitingseveral minutes between packets. Figure 2.3 shows the body of the request which consist ofrandom characters. Since the content length is defined to be so long this will take a very longtime to complete and will use up the server’s available connections without using almost anyof the attackers computational power and network. This will deny service to any legitimatetraffic 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 prolongedamount of time which, if done on a large enough scale, will deny service by the server.

4

2.2. Server solutions

2.2 Server solutions

There exist multiple solutions for hosting websites or other applications on the web and theyall 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 sharedor distributed between many machines and enables the application to allocate computingpower where it is needed [9].

There are many benefits of cloud computing [5]. It allows companies to access computingpower and storage on demand without the need to buy and configure additional IT infras-tructure. 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 andhardware maintenance and other IT related work. Despite the benefits, cloud computingis 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 ofservices and allows users to create virtual machines to host web servers and various other in-ternet 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 inthe AWS cloud. The service allows users to set up their applications in either single instanceor load-balancing and auto-scaling environments [11]. Auto-scaling means that applicationinstances are added and removed dynamically to handle increases and decreases of traffic tothe application. Traffic to the application instances are distributed by a load-balancer, whichacts as an access point to all of the instances. By default the load-balancer listens to HTTPtraffic and forwards it to the environment. AWS also monitors the health of the applicationand 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 asopposed to cloud solutions which typically share the hardware between many virtual ma-chines. Doing this gives the customer full control over the server settings as well as theconfigurations of the operating system which results in a very flexible environment. It couldalso increase performance since the environment can be adjusted to the specific workload itis employed to do.

Apache

The server solutions examined in this thesis are all using an Apache HTTP web server. TheApache HTTP Server Project is an open source HTTP server developed by the Apache Soft-ware 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 serverssurveyed.

Apache is a thread-based web server and is known to be vulnerable against slow rate at-tacks. This is because Apache, by default, dedicates resources to every connection instead ofdynamically allocating resources where they are needed [14]. Apache servers have a maxi-mum timeout after which ongoing connections are dropped which for most Apache serversis 300 seconds [7]. This leads to a resource depleting attack such as a typical application layerslow rate denial of service having a big effect since it effectively can bind all resources of thehost machine.

5

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 GokberkYaltirakli [15]. This simple Python script lets users execute a slow header attack on a serverby specifying a target url address and the number of web sockets to be used in the attack. Thescript will then establish the specified number of connections to the target server and keepthem alive for as long as possible, occupying the server threads. This is accomplished bysending keep-alive headers on all ongoing connections at 15 second intervals (Shown in List-ing 2.1). Broken connections are discarded and recreated keeping the number of connectionsconstant.

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 slowbody HTTP attack. The version used in this thesis [16] works by first sending a completeHTTP POST header and after that sending a random character followed by sleeping for some-where between 0.1 and 3 seconds (as shown in Listing 2.2). The script uses multithreading toallow multiple active illegitimate connections at once and the number of threads used by theattacking 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

3 Performing Denial of Serviceattacks

This chapter explains the testing environment and configurations used for the conductedtests 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 environmentwith settings shown in table 3.1 and a dedicated environment with characteristics shown intable 3.3. The topology of the testing environment is shown in Figure 3.1. The attacker ma-chine will separately execute the attacks on the different server solutions while the observermachine generates legitimate load and observes the effectiveness of the attack by recordingthe response times of the requests.

7

3.1. Experimental environment

Configuration of cloud servers

Table 3.1: Setup Cloud-based server

AWS Virtual enviroment t2.microAWS Environment Type Single instance or load-balanced, auto-scalingOS Ubuntu Server 16.04 LTSWebserver Apache/2.4.2CPU Intel Xeon E5-2676 v3 @ 2.40 GHz running 1 threadRAM 1 GBDisk 8 GB

By using the free tier of Amazon Web Services, a virtual machine running Ubuntu Server16.04 LTS was created. This virtual machine was set up to deploy two separate web applica-tions with the AWS Elastic Beanstalk service.

The first web application was configured to run in a load-balancing and auto-scaling en-vironment. This allows more instances of the application to be added to accommodate anincrease in load. The specific auto-scaling parameters and configuration used for this projectare shown in Table 3.2. The auto-scaling configuration uses the average latency as a metric fordetecting an increase in load. This metric was chosen due to it being similar to the main met-ric used in our experiments, i.e. response time. Measurement period is the time between thepoints at which the server evaluates its current state and health. To be able to quickly respondto a denial of service attack this is set to the minimum value of 60 seconds. The idle timeoutfor the load-balancer is set to the default and recommended value of 60 seconds. This meansthat the load-balancer will close ongoing connections after 1 minute. The full configurationfor 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 theload-balanced server.

Table 3.2: Load-balancer and auto-scaling configuration

Scale based on Average latencyAdd instance when > 5 secondsRemove instance when < 1 secondMeasurement period 60 secondsIdle timeout 60 seconds

The second application was configured to run in a single instance environment whichmeans it does not have a load-balancer and does not allow more instances to be dynamicallyadded. Due to the limitations of the AWS free tier, the virtual machine is running on hardwarelocated in the US.

Dedicated server configuration

Table 3.3: Setup Dedicated server

OS Ubuntu Server 16.04 LTSWebserver Apache/2.4.2CPU Intel Core i5-2450M @ 2.50 GHzRAM 4 GBDisk 8 GB

8

3.2. Experiments

The Linux machine acting as a dedicated server (Table 3.3) hosts the web application on aApache/2.4.2 web server configured with the default configurations. This means that amongother things, the maximum number of clients is set to the default value of 256. This server washosted on the same local network as the attacking and observation machines. This means thatthe dedicated solution will have a naturally shorter round trip time to the server comparedto 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 wasused as a metric. The response time was measured by issuing multiple HTTP GET requeststo the server and recording the time between sending the request and the response from theserver on the same machine, the observer one. The variations in configurations and settingsof the tools and load generators will be detailed under each specific experiment. All of theserver solutions were set up to serve a Python 3.6 application which outputs static HTMLcontent.

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 thePython script shown in Appendix 7.1. The script uses multiple concurrent threads to sendHTTP GET request to a chosen website URL. The program will measure the amount of timebetween sending the request and an ”HTTP 200 OK” response from the server, as shown inListing 3.1. Other responses such as ”500 Internal Server Error” are discarded and counted asfailed requests. For each request the timestamp and response time are saved to file to allowfurther 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. Thefirst is the total number of measurement requests. This specifies the total number of HTTPrequests sent by the script. The second parameter is load. Load specifies how many concurrentthreads will be used to send the measurements requests, i.e how many requests are sent

9

3.2. Experiments

concurrently. Figure 3.2 shows the relation between the measurement requests and load. Themeasurement requests are placed in a queue until a thread is available and is then sent to theserver.

During the experiments, this script will be run on the observer machine as seen in Figure3.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 insection 2.3. The attacking script was left running on the attacking machine for each inten-sity of the attack until all measurements were complete. Tables 3.4, 3.5, 3.6 and 3.7 showthe different slow header test configurations. The number of attacking web sockets for eachexperiments is called attacking web sockets.

Table 3.4: Parameters of experiment 1: Effectiveness of slow header attack

Attack type Slow headerLoad 200Measurement requests 500Attacking web sockets 0-1000, increments of 100

The goal of experiment 1 (Table 3.4) was to examine how the different servers reacted tothe number of illegitimate connections generated by the slow header attack. In the exper-iment, the load script was configured to test response time of the servers 500 times with aload of 200 concurrent connections. For each server, the number of web sockets used by theattacking machine was incremented by 100. The attacks have the potential to cause very longresponse 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 headerLoad 200Measurement requests 500Attacking web sockets Incremented until failure

In experiment 2 (Table 3.5), the goal was to find if there is a point of failure where theservers becomes completely unavailable. This is done by incrementing the number of ille-gitimate connections and measuring the number of failed requests. For this test ”completelyunavailable” 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 headerLoad 200Measurement requests 10000Attacking web sockets 250, 500

In experiment 3 (Table 3.6) we measure the effectiveness of the attack over a longer periodof time to determine if the effects on the servers remain constant or change during the du-ration of the attack. This is done by increasing the number of measurements in the observerscript and presenting them in the order they were sent. This means that we can observe howthe server response times change over time. The test was carried out under a slow headerattack using 250 and 500 web sockets.

10

3.2. Experiments

Table 3.7: Parameters of experiment 4: Effects of load on a slow header attack

Attack type Slow headerLoad 10 & 200Measurement requests 1000Attacking web sockets 250, 500

To explore if and how the slow header attack is affected by competing legitimate traf-fic, the slow header attacks are executed on servers with different levels of load. In thisexperiment the observer script has two configurations. The first configuration runs the mea-surements using only 10 concurrent connections while the second uses 200. Since we onlyevaluate two intensities of the slow header attack in this experiment it will be quicker topreform. Because of this the number of measurement requests is set to 1000 to potentiallyobserve 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 3.11.The attacks were launched using the tool Tor’s Hammer as described in section 2.3. Similarto the slow header attack the script was left running for each intensity of the attack until allmeasurements were complete. The number of threads used by the attacking machine is calledattacking threads.

Table 3.8: Parameters of experiment 5: Effectiveness of slow body attack

Attack type Slow bodyLoad 200Measurement requests 500Attacking threads 5 - 400

Similar to experiment 1, experiment 5 examines how the server reacts to different inten-sities of the same attack. This is to get an overview of how effective the slow body attacksare against the servers. In this experiment the observer script was executed 20 seconds afterthe attack tool was started as recommended by the creator of the tool. The number of threadsused in the attack was incremented by 5 until we reached 40 active threads. The numberwas then incremented by 10 to 50 active threads and later 60 active threads. The next set oftests started at 100 threads and was incremented by 50 until we reached the final test of 400attacking treads.

Table 3.9: Parameters of experiment 6: Server point of failure when under slow body attack

Attack type Slow bodyLoad 200Measurement requests 500Attacking threads Incremented until failure

Similar to experiment 2, experiment 6 examines if there exists a point where the serversbecome 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 ensurethat the attack has taken full effect.

11

3.2. Experiments

Table 3.10: Parameters of experiment 7: Slow body attack over time

Attack type Slow bodyLoad 200Measurement requests 10000Attacking threads 30

Experiment 7 seeks to examine how the slow body attack affects the servers over a longerperiod of time. Like experiment 3 this is done by increasing the number of requests made bythe 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 bodyLoad 10 & 200Measurement requests 1000Attacking threads 20

Similar to experiment 4 this experiment aims to explore how the attack is affected bycompeting, legitimate traffic. As in experiment 4 the load of the first test of the experiment is10 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

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 presentedin Figure 4.1 looks at the average response times and the number of failed requests to theservers under different intensities of the slow header attack. A logarithmic scale was used forFigure 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 aslow header attack running variable number of web sockets

13

4.1. Slow header attack

As can be seen in Figure 4.1 there are some big differences between the different serversolutions. The dedicated server was not noticeably affected at all until between 200 and 300sockets where it stopped responding all together.

However the cloud solutions behaved differently. The static cloud solution steadily in-creased in response time while the load-balanced cloud solution remained roughly the sameacross all tests.

An anomaly can be observed in the static cloud server. When the number of attackingweb sockets reached 600 about 1/5 of the measurement requests failed, while in the next testwith 700 web sockets, no requests failed. We are unsure about why exactly this occurred butwe 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 failureStatic cloud server „1500

Load-balanced cloud server NoneDedicated server 256

The results of experiments 2 is shown in Table 4.1. The dedicated server became completelyunavailable after 256 web sockets were used in the attack. An observation is that this is thesame as the default number of max clients as mentioned in section 3.1, which is most likelythe reason for this behaviour. For the static cloud servers the point of failure is not as clear. Wefound no clear cutoff point where the server was completely unavailable for all request butafter 1500 sockets a vast majority of the requests failed or had an response time of more than20 seconds. The load-balancing cloud server isn’t noticeably affected by the header attackand has no point of failure.

Experiment 3: Slow header attack over time

Figure 4.2: Response time of 10000 requests under a slow header attack using 250 web sockets

14

4.1. Slow header attack

Figure 4.2 shows the effects of the slow header denial of service attack over 10000 HTTP-GETrequests in a scatter plot. The right column shows the baseline test for the different serversolutions. Each request is presented as a dot and the request are ordered in the order theywere sent to the server. For the static cloud and dedicated server, the figure shows significanteffects on the response times of requests, however the effects are sporadic. In the case of theload-balancing cloud server, no clear effects of the denial of service attack can be seen.

Figure 4.3: Response time of 10000 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 re-quests 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 experi-enced 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 theslow header attack is not able to constantly maintain a denial of service state on the targetedsevers.

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 websockets

Server 10 Load 200 LoadStatic Cloud 0.31s 4.92sLoad-balanced Cloud 0.29s 0.51sDedicated 0.16s 2.96s

Table 4.2 shows that when the intensity of the attack is lower (250 sockets), the response timeis negatively effected by a larger load. The case with a load of 10 concurrent connections doesnot seem to be noticeably affected by the attack while the case with a load of 200 concurrentconnections has significant increases in response time.

15

4.2. Slow body attack

Table 4.3: Average response time of 1000 requests with a slow header attack using 500 websockets

Server 10 Load 200 LoadStatic Cloud 27.68s 13.68sLoad-balanced Cloud 0.34s 0.45sDedicated Unavailable Unavailable

In the test with a higher attack intensity (500 sockets) the opposite is observed. Figure 4.3indicate that a larger load has a shorter average response time than the case with a load of10. While this is noteworthy, the complete scatter plots shown in appendix 7.1 and 7.2 do notindicate any outliers that might unproportionally affect the results. One possible explanationfor this behavior is that with 250 sockets the attack occupy some but not all of the server’savailable connections. That means that with high load the legitimate connections have tocompete with each other for the few available resources, while with low load the few availableconnections will be sufficient to serve the legitimate connections. Then when the number ofweb 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 attackless 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 slowbody 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 con-

stant until the point of failure between 250 and 300 threads used, when the server becameunresponsive and failed all requests. The static and load-balancing cloud servers both fol-lowed roughly the same pattern of steadily increasing in response times and the number

16

4.2. Slow body attack

of failed requests as the number of threads used in the attack increased. In the case of 400threads all the requests sent from the observer to the load-balanced server failed. The staticcloud server barely remained responsive with response times of up to 2 minutes and 4 out of5 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 failureStatic cloud server „400

Load-balanced cloud server NoneDedicated server 256

The dedicated server became unavailable when the attack used 256 threads. This is unsurpris-ing for the same reasons explained in the results of experiment 2, that the default maximumclients 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 varieda bit between experiments. The load-balanced cloud server became unresponsive for a shortwhile but later returned to normal levels. This meant that the load-balancing cloud solutionhad no clear point of failure.

Experiment 7: Slow body attack over time

Figure 4.5: Response time of 10000 request with a slow body attack running 30 threads

Results of experiment 7 is shown in Figure 4.5. The dedicated server remained consistent withexperiment 5 (Figure 4.4) and no noticeable effects of the attack is shown. The first requestssent 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. Thestatic cloud server however was massively impacted by the attack and had delays in the

17

4.2. Slow body attack

response time of up to two minutes while failing approximately 40% of all requests as can beseen in the gaps in the plot.

This experiment seemed to create a more consistent denial of service state on the staticcloud solution compared to the slow header attack shown in experiment 3 (Figures 4.2 and4.3). The slow body and slow header attacks both manage to create response times of arounda minute but the major difference is that in the case of the slow header attack this only occursin 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 LoadStatic Cloud 4.21s 23.50sLoad-balanced Cloud 0.54s 7.82sDedicated 0.17s 3.10s

The results of experiment 8 can be seen in Table 4.5. While under a load of 10 concurrentconnections only the static cloud server was impacted in a major way while the other solu-tions remained fairly healthy. Every server solution tested was impacted when using a loadof 200 concurrent connections and experienced a major increase in response times. The load-balancing cloud server however was only impacted for a short duration of the test beforereturning to normal levels. This experiment indicate that the slow body attack is also affectedby 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

5 Discussion

In this chapter we will discuss, examine and evaluate our results and methodology. We willalso 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 vulnera-bilities to slow rate application layer denial of service attacks. There are however differencesin how the servers are affected. The experiments show that the slow header and slow bodyattacks have different properties and affect the servers differently. In this section we willdiscuss 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 serviceon both the dedicated and static cloud server, causing large delays in response times or evenmaking the requests to the server fail to retrieve the page content. The experiments alsoshow 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 impactseem 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 serversolutions presented in this thesis, with varying effectiveness. The attacking machine couldmake both the static cloud server and the dedicated server unavailable for an indefiniteamount of time. While not being able take it down completely, the slow body attack couldalso cause interruptions to the load-balanced cloud server. Experiment 8 presented in Table3.11 shows that the amount of load also has an impact on the effectiveness of the slow bodyattack. The experiment seems to indicate that a server under heavy load is affected moreseverely.

Dedicated server

An observation about the dedicated server is that it does not show the same gradual degrada-tion of performance as the other server solutions. It is however very vulnerable to both slow

19

5.1. Results

header and body attacks since it becomes completely unavailable for an indefinite amountof time when the number of illegitimate connections exceeds the maximum, shown in Tables4.1 and 4.4. An explanation for this result is that the attacks manages to use up the Apacheservers client slots which defaults to 256. When there were still connection slots available theserver was accommodating all the requests but as soon as all slots filled up the service wascompletely denied.

Static cloud server

The static cloud server showed a gradual decrease in performance as the intensity of thetests increased. Figure 4.1 and Figure 4.4 from experiments 1 and 5 illustrate this point quitewell. The static server did however resist a crash when subjected to these loads, it sloweddown significantly but stayed online even after the dedicated server had long since becomeunavailable. There could be many reasons for this behaviour. One explanation might be theproximity of the attack. The cloud servers are located in the US while the attacks are launchedfrom Sweden. This makes things like packet loss more likely to occur and the attack is not ableto 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 orvery little impact on the server. Response times do not increase when increasing the intensityof 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 thatthe reason the effectiveness of the different attacks vary so widely is because of the load-balancer in front of the server. The load-balancer forwards HTTP request to the correct serverinstance but this does not seem to occur in the case of a slow header attack. This couldbe because the slow header attack never completes the HTTP-header and as such is neverinterpreted as an HTTP request and will not be forwarded to the server. This explanationraises another question. Why is not the load-balancer itself affected by the slow header denialof service? One possible answer is that the load-balancer might be running on a different webserver solution than Apache and is not as vulnerable to these kinds of slow rate applicationlayer attacks.

When the load-balancing server is subjected to the slow body attack it initially seems to beaffected 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 attackis effective while the header attack is not might be because of the slow body attacks actuallycompleting the HTTP-header. This might cause the load-balancer to forward the malicioustraffic 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 timesof around 50 seconds. After roughly 50 seconds the response times drop significantly. Thiscould possibly be the result of the of the auto-scaling feature. The auto-scaling is triggeredby the average latency and creates new instances to accommodate the load. Another possibleexplanation is that the load-balancer closes the illegitimate connections after they exceed thetimeout period. No matter the explanation the attack is effectively mitigated.

While the attack was mitigated this does not necessarily mean that the load-balanced so-lution has any kind of protection against these kinds of attacks. It could simply be a symptomof this solution having more resources than the other solutions. The load-balancer can scalethe web application to accommodate for the illegitimate connections. This results in a highercost since you pay for the resources you use which is why you typically don’t let it scale in-definitely. This means that an attack using more illegitimate connections should be able tocause a state of denial of service similar to the static cloud solution.

20

5.2. Method

5.2 Method

The choice to use response time as the main evaluation metric gives a general understandingof how the servers are impacted. It does have some potential problems however. It doesnot take into account failed requests when the server is completely unresponsive. Duringthe majority of the tests, this had no or very little effect on the results since the parametersused in the tests where chosen to slow down but not completely crash the servers. In thecase of experiment 1 and 4 where it did have an impact we showed the number of failedrequest for each server. Another problem with response time in terms of the load-balancingand auto-scaling server is that it does not take into account the time for the server to mitigatethe attack. During the tests this server initially experiences very long response times followedby a return to the baseline, as seen in Figure 5.1. This can potentially skew the average andgive a misleading view of the results.

Figure 5.1: Up-close view of the load-balancing happening in experiment 7 Figure 4.5

The application running on the web servers was a simple Python application serving staticcontent. The results might have been different and more realistic if the application was morecomplex with database queries and calculations. This might have been a more realistic sim-ulation of backend systems. To produce fair results, we configured the server solutions toserve the same content through an Apache HTTP server. However, late in the testing processwe discovered that there is a difference between the dedicated server and the cloud servers.The difference lies in how Apache connects incoming network traffic to the Python applica-tion. The cloud servers use a web server gateway interface which specifies how the web severcommunicates with the web application. This communication between the application andweb server could potentially be a bottleneck which has not been examined. This differencein implementation might be an explanation for why the cloud servers were affected moreseverely by the slow body attack and showed a more gradual degradation when subjected todifferent intensities of attack.

5.3 Work in a wider context

As discussed in chapter 1, today’s society is very reliant on the stability and availability ofonline services. This means that an effective denial of service attack can potentially havedevastating consequences. We believe that to be able to prevent and defend against theseattacks one must know how they function and how they can affect online infrastructure. Inthis thesis we only take a preliminary look at this wide and deep problem. We hope that byshowcasing the vulnerabilities of the web servers and the effects of the slow rate attacks wehighlight the importance and need for protected and secure server solutions.

21

6 Conclusion

The aim of this thesis was to investigate and evaluate the impact of application layer slowrate denial of service attacks on web applications hosted on dedicated- versus cloud basedserver solutions. The questions we chose to investigate as a way to fulfill the aim of the thesisare how the servers are impacted by these types of attacks as well as how the different serversolutions differ from each other when under an attack of this kind. We have investigated thisby conducting tests and experiments on these server solutions under attacks using varyingsettings and intensity.

The performance of all investigated server solutions were largely impacted by at least oneof the attempted attacks. The server solution that performed best was the load-balancing andauto-scaling cloud server. It was completely immune to the slow header attack and managedto mitigate the slow body attack to the extent of not becoming completely unresponsive. Itdid however experience major slowdowns in response time during the first minute of theattack before the load-balancer kicked in.

The dedicated server solution and the static cloud based solution differed quite a bit inbehaviour. The static cloud based solution gradually slowed down and became more un-stable as the attacks intensified until eventually becoming unresponsive while the dedicatedsolution showed low impact until it reached a point of failure and became completely unre-sponsive.

The two denial of service tools used by the attacking machine were chosen over other op-tions for their accessibility and easy of use. Despite not requiring any advanced knowledgeof the technology, these two scripts were shown to have the potential to cause major inter-ruptions to internet applications. This effectively showcases the potential threat slow rateapplication layer attacks may pose towards unprotected web servers.

6.1 Future Work

Since this thesis solely investigates how different server solutions are impacted by slow rateapplication layer denial of service attacks a natural progression would be to investigate howto stop and/or mitigate these kinds of attacks on the different server solutions. One could forexample examine how different settings to the load-balancer and auto-scaling features of thecloud server impacts the effectiveness of the attack. Tweaking the configuration files of theApache web server might also yield some interesting results. Following this one could also

22

6.1. Future Work

attempt to alter the attacks to circumvent the above measures to get a further understandingabout how the different server settings impact the attacks.

Another possible option is to attempt to distribute the attacks across many machines, thatis to run the attack from a large number of devices, and see if the impact is different comparedto the non-distributed versions. One might be able to investigate what measures are availablefor stopping and mitigating these kinds of distributed denial of service attacks.

One could also expand the scope of the report to investigating for example high rate denialof service attacks or slow rate attacks not targeting specifically the application layer.

23

Bibliography

[1] C. Johnston S. Thielman. “Major cyber attack disrupts internet service across Europeand US”. In: The Guardian (Oct. 21, 2016). URL: https://www.theguardian.com/technology/2016/oct/21/ddos-attack-dyn-internet-denial-service(visited on 03/21/2018).

[2] Robert Bronte, Hossain Shahriar, and Hisham M. Haddad. “Mitigating Distributed De-nial of Service Attacks at the Application Layer”. In: Proceedings of the Symposium onApplied Computing. SAC ’17. Marrakech, Morocco: ACM, 2017, pp. 693–696. ISBN: 978-1-4503-4486-9. DOI: 10.1145/3019612.3019919.

[3] A. Aqil, A. O. F. Atya, T. Jaeger, S. V. Krishnamurthy, K. Levitt, P. D. McDaniel, J. Rowe,and A. Swami. “Detection of stealthy TCP-based DoS attacks”. In: MILCOM 2015 -2015 IEEE Military Communications Conference. Oct. 2015, pp. 348–353. DOI: 10.1109/MILCOM.2015.7357467.

[4] N Muraleedharan and B Janet. “Behaviour analysis of HTTP based slow denial of ser-vice attack”. In: Wireless Communications, Signal Processing and Networking (WiSPNET),2017 International Conference on. IEEE. 2017, pp. 1851–1856.

[5] Seyed Milad Helalat. “An Investigation of the Impact of the Slow HTTP DOS andDDOS attacks on the Cloud environment”. MA thesis. Blekinge Institute of Technol-ogy, 2017, p. 74.

[6] Nikhil Tripathi and Neminath Hubballi. “Slow rate denial of service attacks againstHTTP/2 and detection”. In: Computers & Security 72 (2018), pp. 255–272. ISSN: 0167-4048. DOI: https://doi.org/10.1016/j.cose.2017.09.009.

[7] V. Durcekova, L. Schwartz, and N. Shahmehri. “Sophisticated Denial of Service attacksaimed at application layer”. In: 2012 ELEKTRO. May 2012, pp. 55–60. DOI: 10.1109/ELEKTRO.2012.6225571.

[8] Enrico Cambiaso, Gianluca Papaleo, and Maurizio Aiello. “Taxonomy of slow DoS at-tacks to web applications”. In: International Conference on Security in Computer Networksand Distributed Systems. Springer. 2012, pp. 195–204.

[9] Dan C Marinescu. Cloud computing: theory and practice. Morgan Kaufmann, 2017.

[10] Mark D. Ryan. “Cloud Computing Privacy Concerns on Our Doorstep”. In: Commun.ACM 54.1 (Jan. 2011), pp. 36–38. ISSN: 0001-0782. DOI: 10.1145/1866739.1866751.

24

Bibliography

[11] Amazon Web Services. AWS Elastic Beanstalk Developer Guide. https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/using-features-managing-env-types.html?icmpid=docs_elasticbeanstalk_console. 2018. (Visitedon 04/20/2018).

[12] R. T. Fielding and G. Kaiser. “The Apache HTTP Server Project”. In: IEEE Internet Com-puting 1.4 (July 1997), pp. 88–90. ISSN: 1089-7801. DOI: 10.1109/4236.612229.

[13] W3Techs. Usage of web servers broken down by ranking. https : / / w3techs . com /technologies/cross/web_server/ranking. 2017. (Visited on 04/27/2018).

[14] Apache Software Foundation. Apache HTTP Server Version 2.4 Documentation. https://httpd.apache.org/docs/2.4/. 2018. (Visited on 04/27/2018).

[15] Gokberk Yaltirakli. About Slowloris. https : / / gkbrk . com / 2016 / 09 / about -slowloris/. 2016. (Visited on 03/21/2018).

[16] dotfighter. Tor’s Hammer. https://github.com/dotfighter/torshammer. 2012.(Visited on 03/21/2018).

25

7 Appendix

7.1 Observer script

Listing 7.1: The python script used for creating load and measuring response time

import requestsfrom threading import Threadimport queueimport numpyimport timefrom multiprocessing import Poolarr = []concurrent = 10numberOfTests = 1000failed = 0

def doWork():while True:

url = q.get()ts = time.time()try:

response = requests.get(url)print(response.elapsed, response.status_code)if response.status_code == 200:

arr.append([response.elapsed.total_seconds(), ts])else:

arr.append([0, ts])except Exception as ex:

print(ex)arr.append([0, ts])

q.task_done()

q = queue.Queue(concurrent * 2)for i in range(concurrent):

t = Thread(target=doWork)

26

7.2. Full server configurations

t.daemon = Truet.start()

try:for i in range(0,numberOfTests):

q.put("http://example.com/")q.join()

counter = 0avg = 0stdarray = []open(’data.txt’, ’w’).close()for val in arr:

if val[0] !=0:avg = avg + val[0]

with open(’data.txt’, ’a’) as data_file:data_file.write(str(val[1])+’: ’+str(val[0])+’\n’)

counter = counter+1stdarray.append(val[0])

avg = avg / len(arr)print("Average response time:")print(avg)print("STD:")print(numpy.std(stdarray, ddof=1))for val in arr:

if val[0] == 0:failed = failed+1

print("Failed requests")print(failed)print((failed*100)/numberOfTests, "%")

except KeyboardInterrupt:sys.exit(1)

7.2 Full server configurations

Table 7.1: Full auto scale configuration

Minimum instance count 1Maximum instance count 4Availability Zones AnyScaling cooldown 1 secondTrigger measurement LatancyTrigger statistic AverageMeasurement period 1 minuteBreach duration 1 minuteUpper threshold 5 secondsUpper breach scale increment 1Lower threshold 1Lower breach scale increment -1

27

7.3. Experiment 4

Table 7.2: Full Load balancer configuration

Listener port 80Protocol HTTPSecure listener port OFFConnection Draining 20 secondsHealth check interval 10 secondsHealth check timeout 5 secondsHealthy check count threshold 3Unhealthy check count threshold 5Idle timeout 60 seconds

7.3 Experiment 4

Figure 7.1: Response times of 1000 request with a load of 10 and 200 with a slow headerattack using 250 web sockets

28

7.4. Experiment 8

Figure 7.2: Response times of 1000 request with a load of 10 and 200 with a slow headerattack using 500 web sockets

7.4 Experiment 8

Figure 7.3: Response times of 1000 request with a load of 10 and 200 with a slow body attackusing 20 threads

29