an investigation of the impact of the slow http dos and ...1117240/fulltext02.pdf · denial of...

An Investigation of the Impact of the Slow HTTP DOS and DDOS attacks on

the Cloud environment

Seyed Milad Helalat Faculty of computing Blekinge Institute of Technology SE-371 79 Karlskrona Sweden

This thesis is submitted to the Faculty of Computing at Blekinge Institute of Technology in partial fulfillment of the requirements for the degree of Master of Electrical Engineering with emphasis on Telecommunication System. The thesis is equivalent to 20 weeks of full time studies. Contact information: Author: Seyed Milad Helalat E-mail: [email protected] University advisor: Prof. Kurt Tutschku Department of Telecommunication Systems Faculty of computing web site: www.bth.se Blekinge Institute of Technology Phone: +46 455 38 50 00 SE-371 79 Karlskrona Sweden Fax: + 46 455 38 50 57

mailto:[email protected]

I

Abstract Cloud computing has brought many benefits to the IT industry, and could reduce the cost and facilitate the growth of businesses specially the startup companies which don’t have enough financial resources to build their own IT infrastructure. One of the main reason that companies hesitate to use cloud services is the security issues that the cloud computing technology has. This thesis at the beginning has an overview on the cloud computing concept and then reviews the cloud security vulnerabilities according to the cloud security alliance, then it describes the cloud denial of service and will focus on analyzing the Slow HTTP DOS attack and then will analyze the direct and indirect impact of these attacks on virtual machines. We decided to analyze the HTTP slow rate attacks because of the craftiness and covered characteristic also the catastrophic impact of the Slow HTTP attack whether it’s lunched on the cloud component or lunched from the cloud. There are some researches on the different way that a web server or web service can be protected against slow HTTP attacks, but there is a research gap about the impact of the attack on virtual environment or whether this attack has cross VM impact or not. This thesis investigates the impact of Slow HTTP attack on virtualization environment and will analyze the direct and indirect impact of these attack. For analyzing the Slow HTTP attacks, Slow headers, Slow body and Slow read are implemented using Slowhttptest and OWASP Switchblade software, and Wireshark is used to capture the traffic. For analyzing the impact of the attack, attacks are lunched on VirtualBox and the impact of the attack on the victim VM and neighbor VM is measured. Keywords: Slow HTTP DOS, Cloud computing Vulnerabilities, DOS on cloud

II

Acknowledgments I would first like to thank my thesis advisor Prof. Kurt Tutschku for his guidance, encouragement during this semester. I would like to thank Anders Carlsson for his support, and technical guidance that he has given me throughout my thesis. I would like to thank Ms Ievdokymenko of the KNURE for her supports and guidance. I would also like to thank my supervisor Prof. Yevsieieva of the KNURE for her supports and guidance.

III

List of Figures Figure 2.1: DDOS attack architecture ............................................................................................. 9

Figure 2.2: Cloud External DDOS architecture ............................................................................ 11

Figure 2.3: Cloud internal DDOS architecture ............................................................................. 11

Figure 2.4: External-based DDOS on cloud architecture ............................................................. 12

Figure 2.5: Architecture of DRDOS ............................................................................................. 13

Figure 2.6: Amplified DDOS architecture .................................................................................... 14

Figure 2.7: Neighbor DOS attack architecture ............................................................................. 15

Figure 3.1: HTTP request message ............................................................................................... 19

Figure 3.2: Normal HTTP request ................................................................................................ 20

Figure 3.3: A bogus HTTP header ................................................................................................ 20

Figure 3.4: Slow header attack architecture .................................................................................. 21

Figure 3.5: Series of packets that generate one incomplete http header ....................................... 22

Figure 3.6: Slow header attack...................................................................................................... 23

Figure 3.7: Legitimate HTTP POST with true Content-Length ................................................... 24

Figure 3.8: Slow body attack’s header .......................................................................................... 24

Figure 3.9: HTTP slow body attack architecture .......................................................................... 25

Figure 3.10: HTTP slow body stream of incomplete body ........................................................... 25

Figure 3.11: Resembled incomplete HTTP body with hex dump ................................................ 26

Figure 3.12: Window size changes in a legitimate HTTP request and responses ....................... 27

Figure 3.13: One slow read attack’s TCP session......................................................................... 28

Figure 3.14: Ninth HTTP GETs in one HTTP request ................................................................. 29

Figure 3.15: Slow read attack architecture ................................................................................... 29

Figure 3.16: HTTP Slow read attack effect on the web server ..................................................... 30

Figure 4.1: Slow HTTP DOS implementation and measuring environment ............................... 33

Figure 4.2: Slow HTTP DDOS architecture ................................................................................. 34

Figure 5.1: CPU usage of the VM1 in normal condition .............................................................. 35

Figure 5.2: Memory usage of the VM1 in a stable condition ....................................................... 36

Figure 5.3: Network load of the VM1 in the stable condition ...................................................... 36

Figure 5.4: Victim VM average CPU Idle in a stable condition ................................................... 37

Figure 5.5: Victim VM average memory usage in a stable condition .......................................... 38

Figure 5.6: Victim VM average network input in a stable condition ........................................... 38

Figure 5.7: Victim VM average network output in a stable condition ......................................... 39

Figure 5.8: The impact of the Slowloris on the VM1 ................................................................... 40

Figure 5.9: CPU idle comparison during stable and DOS conditions .......................................... 40

Figure 5.10: Memory usage comparison during Stable and DOS conditions............................... 41

Figure 5.11: Data input, comparison during stable and DOS conditions ..................................... 41

Figure 5.12: Data output comparison, during stable and DOS conditions ................................... 42

Figure 5.13: Effect of Slowloris DDOS on the VM1 web server ................................................. 43

Figure 5.14: CPU idle of the VM1 during stable, DOS and DDOS. ............................................ 43

Figure 5.15: memory usage of VM1 during stable, DOS and DDOS .......................................... 44

Figure 5.16: Data received on the VM1 during stable, DOS and DDOS ..................................... 45

Figure 5.17: Data sent on the VM1 during stable, DOS and DDOS ............................................ 45

IV

Figure 5.18: Victim VM average CPU Idle comparison .............................................................. 46

Figure 5.19: Victim VM average memory usage comparison ...................................................... 47

Figure 5.20: Victim VM average network input ........................................................................... 47

Figure 5.21: Victim VM average network output ......................................................................... 48

Figure 5.22: CPU usage of the VM2 in the normal condition ...................................................... 50

Figure 5.23: Memory usage of the VM2 in a stable condition ..................................................... 51

Figure 5.24: Network usage of the VM2 in the stable condition .................................................. 51

Figure 5.25: VM2 ApacheBench test1 while there is no attack ................................................... 52




Figure 5.29: Comparison between the results of 4 benchmarking tests ....................................... 54

Figure 5.30: CPU idle of the VM2 while VM1 is experiencing single Slowloris DOS ............... 55

Figure 5.31: Memory usage of the VM2 during stable and DOS on VM1 .................................. 56

Figure 5.32: Receiving data on VM2 during stable and DOS on VM1 ........................................ 56

Figure 5.33: sending data of VM2 in stable mode and during DOS on VM1 .............................. 57

Figure 5.34: ApacheBench test1 while neighbor is under single Slowloris DOS ........................ 58




Figure 5.38: Comparison in result of 4 ApacheBench tests on VM2 while neighbor VM is under Slowloris DOS .............................................................................................................................. 60

Figure 5.39: CPU idle of the VM2 while VM1 is in stable, DOS and DDOS ............................. 61

Figure 5.40: VM2 memory usage while VM1 is in stable, DOS and DDOS ............................... 61

Figure 5.41: VM2 network input comparison in 3 conditions ...................................................... 62

Figure 5.42: VM2 network output in 3 conditions ....................................................................... 62

Figure 5.43: VM2 average CPU idle comparison in 3 conditions ................................................ 63

Figure 5.44: Neighbor VM average memory usage comparison in 3 conditions ......................... 64

Figure 5.45: Neighbor VM average data received comparison in 3 conditions ........................... 64

Figure 5.46: Neighbor VM average data sent comparison in 3 conditions ................................. 65

Figure 5.47: ApacheBench test 1 on Vm2 while VM1 is under DDOS Slowloris ....................... 65

Figure 5.48: ApacheBench test 2 on Vm2 while VM1 is under DDOS Slowloris ...................... 66

Figure 5.49: ApacheBench test 3 on Vm2 while VM1 is under DDOS Slowloris. ..................... 67

Figure 5.50: ApacheBench test 4 on Vm2 while VM1 is under DDOS Slowloris ....................... 67

Figure 5.51 : ApacheBench measurement results while VM1 is experiencing Slowloris DDOS 68

V

List of Tables Table 3.1: Slowloris attack configuration statics .......................................................................... 23

Table 3.2 : Slow read attack configuration statics ........................................................................ 30

Table 4.1:Machines' specifications. .............................................................................................. 32

Table 4.2: Clouds’ VMs specifications ......................................................................................... 34

Table 5.1: VM1 CPU idle, memory usage, Network load, in stable condition ............................ 37

Table 5.2: Slowhttptest attack configuration ................................................................................ 39

Table 5.3: CPU idle, memory usage, and network load during Slowloris DOS........................... 42

Table 5.4: CPU idle, memory usage and network load on VM1 during Slowloris DDOS .......... 46

Table 5.5: Impact of the attack in Stable mode, during DOS, during DDOS ............................... 48

Table 5.6: Resource usage increase on the victim machine during DOS and DDOS .................. 49

Table 5.7: Average CPU, memory, and network load of VM2 in stable condition ...................... 52

Table 5.8: Result of the ApacheBench on VM2 while there is no attack ..................................... 55

Table 5.9: VM2’s CPU idle, Memory usage and network load while VM1 is under DOS ......... 57

Table 5.10: Average Time per request and transfer rate of ApacheBench on VM2 .................... 60

Table 5.11: CPU idle, memory usage, network load of VM2 while VM1 is under DDOS ......... 63

Table 5.12: ApacheBench tests on VM2 while VM1 is under Slowloris DDOS ......................... 68

Table 5.13: Test’s results comparison on VM2, while VM1 is in stable, under DOS and DDOS conditions ...................................................................................................................................... 69

Table 5.14:VM2 webserver performance comparison in different conditions ............................. 69

Table 5.15: Impact of the attacks on VM2 (neighbor VM) in details........................................... 69

Table 5.16: Average delay increase on neighbor VM .................................................................. 70

Table 5.17: ApacheBench transfer rate reduction on VM2 .......................................................... 70

VI

List of Abbreviations ADOS…………. Application denial of service

BPEL…………. Business Process Execution Language

CIA……………. Confidentiality, integrity and availability

CIDOS………… Cloud internal denial of service

CPU…………… Central Processing unit

CSP…………… Cloud Service provider

DDOS…………. Distributed denial of service

DMZ…………... Demilitarized zone

DNS…………… Domain name service

DTD…………… Document type definition

EDOS…………. Economical denial of service

HIDS…………... Host-based intrusion detection system

HDOS…………. HTTP denial of service

HTTP…………... Hypertext Transfer Protocol

IDS……………. Intrusion detection system

IRC……………. Internet relay chat

LDOS…………. Low-rate denial of service

NIDS…………... Network-based intrusion detection system

OTP…………… One time password

OWASP………... Open Web Application Security Project

QOS…………… Quality of service

RAM…………... Random Access memory

RTBH………… Remotely-Triggered Black Hole

SLA…………… Service level agreement

SOA…………… Service-Oriented Architecture

SRBTH………... Source-based Remotely-Triggered Black Hole

VII

UI……………… User interface

UPRF…………... Unicast Reverse Path Forwarding

VM……………. Virtual machine

VMM…………. Virtual machine monitor

XDOS…………. XML Denial of service

VIII

Contents Abstract ............................................................................................................................................ I

Acknowledgments ...................................................................................................................... II

List of Figures .......................................................................................................................... III

List of Tables ............................................................................................................................. V

List of Abbreviations ................................................................................................................ VI

1 INTRODUCTION AND BACKGROUND ....................................................................... 1

1.1 Cloud computing concept................................................................................................. 2

1.2 Cloud deployment models ................................................................................................ 3

1.3 Benefits of using the cloud computing ............................................................................. 3

1.4 Cloud security vulnerabilities .......................................................................................... 4

1.4.1 Data breaches ............................................................................................................ 4

1.4.2 Insufficient Identity, Credential, and Access Management ...................................... 4

1.4.3 Insecure interfaces and APIs ..................................................................................... 5

1.4.4 System vulnerabilities ............................................................................................... 5

1.4.5 Account hijacking ..................................................................................................... 5

1.4.6 Malicious Insiders ..................................................................................................... 5

1.4.7 Advanced Persistent Threat (APT) ........................................................................... 6

1.4.8 Date Loss .................................................................................................................. 6

1.4.9 Insufficient Due Diligence ........................................................................................ 6

1.4.10 Abuse and nefarious use of cloud services............................................................ 6

1.4.11 Denial of service(DOS) ......................................................................................... 7

1.4.12 Shared technology vulnerabilities ......................................................................... 7

1.5 Aims and objectives ......................................................................................................... 7

1.6 Research questions ........................................................................................................... 7

1.7 Expected contribution ...................................................................................................... 8

1.8 Outline of a report ............................................................................................................ 8

1.9 Related works ................................................................................................................... 8

2 DENIAL OF SERVICE ATTACK .................................................................................... 9

2.1 Distributed denial of service (DDOS) attack ................................................................... 9

2.1.1 Distributed Reflected Denial of Service (DRDOS) ................................................ 12

2.1.2 Amplification distributed denial-of-service attacks ................................................ 13

IX

2.2 Denial of service attacks on cloud.................................................................................. 14

2.2.1 Virtual machine migration attack............................................................................ 14

2.2.2 Cloud-internal denial of service attack (CIDOS).................................................... 14

2.2.3 DOS attack on neighbor .......................................................................................... 15

2.2.4 Mimicking DDOS attack ........................................................................................ 15

2.2.5 Economic denial of service (EDOS) attack ............................................................ 15

2.2.6 Energy-oriented denial of service ........................................................................... 15

2.2.7 Denial of service on SaaS ....................................................................................... 16

2.2.8 Denial of service attacks on web services............................................................... 16

2.2.9 HTTP-based denial of service attacks..................................................................... 17

3 SLOW HTTP DOS ATTACKS ........................................................................................ 18

3.1 Slow HTTP headers (Slowloris) .................................................................................... 18

3.2 HTTP Slow Body attack (RUDY) ................................................................................. 23

3.3 HTTP slow read attack ................................................................................................... 26

4 METHODOLOGY ............................................................................................................ 31

4.1 Tools used ...................................................................................................................... 32

4.2 General experiment setup ............................................................................................... 32

5 RESULTS AND ANALYSIS ............................................................................................ 35

5.1 Analysis of the impact of the Slowloris attack on the victim VM ................................. 35

5.1.1 Measurement of the CPU, RAM, and network load of the VM1 in a stable condition ................................................................................................................................. 35

5.1.2 Measurement of the impact of the Slowloris DOS on the victim VM.................... 39

5.1.3 Measurement of the impact of the Slowloris DDOS on the victim VM ................. 42

5.1.4 Analysis of the impact on the victim VM ............................................................... 48

5.2 Analysis of the impact of the Slowloris attacks on the neighbor VM............................ 49

5.2.1 Measurement of the CPU, RAM, network, and Web server performance of the neighbor VM in a stable condition ...................................................................................... 49

5.2.2 Measurement of the CPU, RAM, network, and Web server performance of the VM during Slowloris DOS on the neighbor ............................................................................... 55

5.2.3 Measurement of the CPU, RAM, network load of the VM during SlowLoris DDOS on the neighbor .................................................................................................................... 60

5.2.4 Analysis of the impact on the neighbor VM ........................................................... 68

6 CONCLUSION .................................................................................................................. 71

6.1 Direct impact of the Slow header DOS and DDOS ....................................................... 71

X

6.2 Indirect impact of Slow header DOS and DDOS ........................................................... 71

6.3 Future work .................................................................................................................... 71

REFERENCES ............................................................................................................................. 72

1

1 INTRODUCTION AND BACKGROUND Cloud computing eases up the process of the scaling up businesses, especially in IT without investing a lot of money for infrastructure and training engineers. By using Cloud computing capabilities, we can expand the IT’s functionality with existing environments. Despite of all the benefits of using cloud still many enterprises and individuals are reluctant to run their business on the cloud. In February 2015 Anthem Inc, a leading health insurance company suffered a data breached that compromised information related to 80 million customers, Investigators detected that hackers could smuggle data out of cloud-based file sharing. In 2012 Dropbox which is cloud base storage had a data breach and had 68 million user accounts compromise. As you can see a famous company such as Dropbox and Anthem Inc have had huge data breaches so it reminds us security in cloud computing is not a negligible matter. Security concern is one major issue that reduces the cloud computing growth. Cloud security alliance (CSA) has created industry wide standards of cloud security and it has become industry-standard catalogue of best practice to secure the cloud computing. CSA has released cloud top 12 security threads which are[1]:

1. Data breaches. 2. Weak identity, Credential, and access management. 3. Insecure API. 4. System and application vulnerabilities. 5. Account Hijacking. 6. Malicious insider. 7. Advanced Persistent threats (APTs). 8. Data loss. 9. Insufficient Due Diligence. 10. Abuse and Nefarious Use of Cloud services. 11. Denial of service. 12. Shared technology issues.

As CSA describes most of the attacks that are applicable on the traditional database or IT infrastructure can be applied to the cloud computing environment as well, moreover the cloud’s multitenancy architecture has opened new attack vectors which were absent in the traditional IT infrastructure. Denial of service (DOS) and Distributed Denial of service (DDOS) attacks target is consuming the Victim’s resources in order to make the service unavailable for the legitimate clients. These attacks are relatively easy to implement and have a high negative impact on the targeted system. DDOS attacks can be used for political or Ideologies as well for instance, In 2014 one of the largest DDOS attack in the history of the internet took place the PopVote, an online poll platform managed by The University of Hong Kong was under attack and this site is hosted by CloudFlare, according Matthew Prince CEO of CloudFlare claims that the DDOS was 300Gbps[2]. DDOS attacks in cloud in general could have two purposes, either make the service unavailable or increase the cost of the cloud services consumption for the users.

2

There are three main types of DOS attacks, Volume-based DOS, Protocol-based DOS and Application-based DOS(ADOS) [3][4]. Detecting the volume-based and protocol-based DOS which are lunched on a cloud or a web service or lunched from the cloud to another system is easier because of the type and volume of the traffic and using IPS, IDS, URPF, Firewalls, S/RTBH [5], but detecting Application-based DOS is different because of the type and rate of the traffic that ADOS generates is similar to the normal traffic and it doesn’t need to flood traffic to an application service in order to bring it down, because it targets a vulnerability in the application and exhaust the application resources not underlying hardware. Low intensive HTTP DOS attacks are application layer DOS and they don’t require many resources to use, these attacks are hard to detect by IDS, IPS and firewalls. These attacks have the power to bring down a vulnerable server, less than 5 seconds just by some crafty http requests. This thesis reviews different types of DOS attack on cloud based on the pervious works that has been done in this field and will focus on analyzing slow HTTP DOS attack and analyze the attack specifications, traffic analysis and packet analysis, attack pattern and server down time. This thesis analyzes the direct impact of slow HTTP attack on VMs also analysis the indirect impact of the slow HTTP attack on the neighbor VM. City Network company is also interested in the result of indirect impact of the low intensive attacks on the virtualize environment. 1.1 Cloud computing concept Cloud computing is delivering the computing services and servers, storage, database, networking, software, analytics, etc., over the internet [6]. Usually companies charge their client based on the usage of the cloud which can be based on the time or based on the resources that the clients are using. There are three types of cloud services:

1. Software as a service (SaaS): clients can use provider’s application running on a cloud infrastructure, this application can be network servers, operating system, or individual application. In this model client doesn’t have any control over the underlying cloud infrastructure. Google Docs, office 365, salesforce.com.

2. Platform as a service (PaaS): PaaS gives developers the ability to develop and deploy applications on the development platform which is provided by the cloud service provider (CSP). Developers can access these services over the internet. Developers are responsible to administrate the deployed application and configure the development interface. PaaS typically provides programming language, application framework, databases. Google App engine, Force.com and Red hat OpenShift are examples of the PaaS.

3. Infrastructure as a service(IaaS): IaaS provides processing, storage, networks, Virtual machines(VMs) and other fundamental computing resources on pay-per-use basis. Customers can run any random software they want including operation systems (OS). IaaS client don’t manage the underlying cloud hardware but has control over the other components that cloud provides. The customer can access the IaaS through Internet. Amazon Web Services (AWS), Google Cloud Platform are example of the IaaS.

3

1.2 Cloud deployment models There are four cloud deployment Models, deployment model describes the way that the cloud deployed or is available to the users. We can classify the clouds based on the size, type of services, location, type of users, security, etc., here are four cloud deployment models:

1. private cloud: the cloud infrastructure that is used for a single organization which can have multiple customers. private cloud can be deployed by using opensource tools such as Openstack. Private cloud has smaller size in comparison with other type of cloud deployment, and the organization which owns the cloud maintains it. Private cloud is more secure because single organization deploys and maintains the cloud and generally the cloud users are the organization employees.

2. Public cloud: according to National institute of standard (NIST), the public cloud is the cloud infrastructure that is provisioned for open use by the public. It may be owned, managed, and operated by a business, academic, or government organization. Public clouds can have users from all over the world. Public clouds are highly scalable, affordable, highly available, stringent SLAs, and less secure.

3. Community cloud: in this cloud deployment model, cloud infrastructure is shared between multiple organization with common concerns, it can be deployed or managed by these organizations or deployed and maintained by the third-party organization. It has fewer user than public cloud but more than private cloud. This model is preferable for the organization which can’t afford the private cloud and can’t place reliance on the public cloud.

4. Hybrid cloud: is a cloud that combines two or more cloud infrastructures (Public, private or community) and carry out distinct function within the same organization. The Hybrid cloud goal is to utilize the advantages of the public and private clouds. Hybrid cloud uses the scalability of the public cloud, and uses the more secure environment of the private cloud.

1.3 Benefits of using the cloud computing

Cloud computing is a big change in the traditional way of thinking about information technology in businesses here are 6 common reasons for organizations to move in to the cloud computing[7]:

1. Reducing the price: using the cloud computing reduces the expenses of buying IT infrastructure, also the cost of the IT infrastructure maintenance and the cost of the training the IT staff.

2. Speed: Cloud computing services and resources are provided on demand, if a cloud customer suddenly needs to use a vast amount of computing, networking, and storage these resources can be provisioned in less than a minute, and this feature gives businesses a lot of flexibility and they need to spend less financial resources for capacity planning.

3. Global scalability: cloud uses dynamic scalability architecture model where the system has predefined conditions and when these conditions are triggered the dynamic allocation of the computing, networking or storage will happen. Cloud computing typically uses dynamic horizontal scaling where IT resources dynamically scale out and in to handle workload’s changes.

4

4. Productivity: traditional datacenters needed hardware setup, software patching also IT staff training. Employing cloud computing can eliminate many of these tasks, therefore the IT staff can spend their time on important business targets.

5. Performance: big cloud computing services are running on worldwide network of secure datacenters, which are commonly upgraded to the latest hardware and software. This reduces the network latency and has faster computing speed over traditional datacenters.

6. Reliability: data backup, disaster recovery business continuity is easier and cheaper, because date can be copied in several redundant servers on the cloud provider network.

This Thesis have briefly reviewed the cloud computing concept and services and advantages of using the cloud computing. by considering all the cloud computing’s advantages there are many companies which are hesitating to move their IT work to the cloud system because of downtimes, limited control, platform dependencies, costs and the main concerns are cloud computing security and privacy issues and vulnerabilities to the attacks. Next chapter discusses the cloud computing security issues and vulnerabilities.

1.4 Cloud security vulnerabilities

The conversion of server-based IT services to service-based has many advantages which was mentioned in the last chapter, but these advantages that service-based (cloud computing services) IT services has brought to the industry has amplified the security issues and vulnerabilities as well [1].This thesis reviews cloud security threats and vulnerabilities according to the cloud security alliance’s (CSA) top threats and will study denial of services vulnerability in cloud and web services. Cloud environment is vulnerable to the same traditional threats on the network environments and with utilizing newer technologies such as virtualization, on demand provisioning and remote only access has become vulnerable to new threats and have got new categories of vulnerabilities. 1.4.1 Data breaches If sensitive, preserved, or confidential data is released or accessed by an unauthorized individual or organization a data breach has happened. Human errors, software security practices vulnerability or an organized cyber-attack can cause the data breach[1]. Data breaches can cause companies great financial negative impact for instance in October 2013, Adobe was breached, as the result of the data breach Adobe lost $148 million [8]. CSA suggests multifactor authentication and encryption can help companies to stay secure in the cloud.

1.4.2 Insufficient Identity, Credential, and Access Management Absence of scalable identity access management systems, failure of multifactor authentication, simple passwords and absence of automated rotation of cryptographic keys, passwords and certificates can cause data breaches related to Identity and access management [1]. The conditions that CSA has suggested for securing the identity and access management: 1 Credential and cryptographic keys should not be stored in the source code or public front of

repositories.

5

2 Usage of multifactor authentication system such as smartcards, one-time password (OTP), phone authentication.

3 Periodically Rotating the cryptographic keys including TLS certificates. 4 Decentralizing storage mechanism containing data secrets (passwords, private keys,

customer’s confidential data) and reinforce monitoring and protecting the identity key management system.

1.4.3 Insecure interfaces and APIs Cloud’s costumers use User Interfaces (UIs) or Application program interfaces (APIs) to interact with cloud. In authentication, access control, encryption and activity monitoring these interfaces should be able to protect cloud users. Insecure APIs and UIs can expose cloud users to variety security issues such as data tempering, repudiation, information disclosure and privilege elevation [1]. CSA suggested these methods for mitigating APIs and UIs vulnerabilities: 1 Threat modeling application and system containing data flaws and architecture in development

lifecycle. 2 Security specific code reviews. 3 Rigid penetration testing.

1.4.4 System vulnerabilities Exploitable bugs in programs or operation systems (OSs) that intruders can use to attack a system. These vulnerabilities can exist in components of OS such as Kernel, OS’s libraries and applications which are installed on the OS can put the security of the system at significant risk, more specifically with manifestation of multitenancy in cloud and access to shared memory from different tenant the new attack surface has extruded. A vulnerable system can cause identity spoofing, data tempering, repudiation, information disclosure, denial of service and privilege elevation [1]. For mitigating system vulnerabilities CSA has recommended to have regular vulnerability tests on the system with follow up patch installation and secure design and architecture of the system can reduce the chance of an intruder to take full control of the information system. 1.4.5 Account hijacking Account hijacking in cloud happens when an attacker can obtain the credential and password of cloud customers and gain access to user’s account. Phishing and man in the middle attacks also weak password, software vulnerabilities can cause account hijacking. If user’s account is hijacked, intruder can eavesdrop on user’s activities, manipulate costumer’s data, or use costumers tenant to attack another system. In order to mitigate the risk of account hijacking, CSA suggests that organizations should prevent users from sharing their credentials also they should provide two factor authentications where it’s possible, also all account’s activities must be monitored and be indictable to the account owner [1].

1.4.6 Malicious Insiders A malicious insider is the current or former employee who has or had access to the company’s network or data and abuse his or her access to have a negative impact on confidentiality, integrity, or availability (CIA) of company’s information. Malicious acts don’t have villainy intentions

6

sometimes employee or administrator have human error and the result will be losing of CIA of organization’s information [1]. To mitigate this vulnerability CSP must segregate the duties of employees, limiting the access by applying proper control access, and applying effective logging, monitoring, and auditing of the IT employees’ activities.

1.4.7 Advanced Persistent Threat (APT) These attacks are highly sophisticated and targeting organizations and looking to steal personal identifiable information or intellectual property. The attackers want to stay in the computing infrastructure of the target company as long as they can. APT attack is stealthy and often can adopt to the security measures which are planned to defend against them. Phishing, direct hacking a system, hacking a system by portable devices such as USB or cellphone, accessing to the target network through partner organization. APTs are generally hard to detect and eliminate [1]. For preventing APTs companies need to follow up security standards such as ISO 27001 information security management system (ISMS) and educate employees about social engineering techniques such as phishing, spear phishing and awareness programs.

1.4.8 Date Loss Data stored in the cloud can be lost by cyber-attacks or accidental removal by CSP or physical accidents such as fire, tsunami, earthquake, etc., unless CSP makes redundant off-site backup of data and following by practices in business continuity and disaster management and recovery [1]. In 2014, Code space was hacked and the result was destruction of most of the costumers’ data and consequently company went out of business [1].

1.4.9 Insufficient Due Diligence ISO 37500 describes due diligence [9] as “detailed assessment of one or more business processes or production lines, culture, assets, liabilities, intellectual property, judicial and financial situation in order to make the outsourcing decisions”. Companies before moving to the cloud should create a competent road map and due diligence while assessing the technology and CSPs. Lack of fulfilling due diligence before moving to a cloud companies might expose itself to commercial, technical, legal or compliance issues [1].

1.4.10 Abuse and nefarious use of cloud services Cloud malicious users can use cloud resources to target other cloud clients or organizations even another CSP. Malicious user can lunch denial of service(DOS), spam or phishing attack, or mining bitcoins, automate click fraud or brute-forcing attack [1]. CSPs in order to mitigate this threat should configure firewalls in the way to monitor inbound and outbound DOS attack, CSP should have incident response framework to detect misuse of cloud resources, moreover CSPs must provide a framework for customers to monitor their cloud tenant workload [1].

7

1.4.11 Denial of service(DOS) DOS attacks are used to prevent legitimate users to access the cloud services [1]. DOS attack can be lunched on a cloud service or can be lunched from the cloud and target another organization. This thesis will discuss DOS attacks and Cloud related DOS attack in detail and will analyze the Slow HTTP DOS in chapter 3 attack also the direct and indirect impact of the slow HTTP DOS and DDOS on VMs will be analyzed in chapter 5.

1.4.12 Shared technology vulnerabilities CSPs deliver their services by sharing hardware, platform, or software. CSPs must consider the hardware capabilities that is going to support cloud services because the hardware might not be designed to offer a firm isolation for a multitenant architecture IaaS or re- deployable architecture PaaS or multi-client applications like SaaS. This can cause the shared technology vulnerabilities. A misconfiguration or a vulnerability can compromise among entire CSP’s cloud [1]. To mitigate or prevent shared technology vulnerabilities, CSA suggests CSPs implement multifactor authentication for each host, using host based intrusion detection system (HIDS) and implementing network-based intrusion detection system (NIDS) on the internal network, using segmentation methods in cloud network and patching the shared resources continuously[10][1]. Cross-VM attack, VM escape, VENOM virtual machine escape bug[11] are example of shared technology vulnerabilities.

1.5 Aims and objectives The aim of this thesis is to analyze different types of slow HTTP attacks also measure the impact of these attacks on virtual machines. As it’s known some public CSP provide IaaS and they lease virtual machines to their customers, therefore it’s necessary to investigate how vulnerable is a hypervisor to direct and indirect impact of these attacks. Here are the main objectives of this research work:

• Reviewing DOS and DDOS cloud related attacks (EDOS, ADOS, CIDOS, etc.,). • Analyzing HTTP slow attacks’ specifications such as packet analysis, traffic pattern, attack

effectiveness. • analysis the direct impact of the slow HTTP (Slowloris) attack on a virtual web server and

the pressure that this attack in DOS mode and DDOS mode can cause on a VM’s CPU, RAM and network load.

• Measure the indirect impact of the attack on the neighbor VM’s CPU, RAM, Network load and web server’s performance.

1.6 Research questions 1. What are the DOS attacks that are designed for the cloud systems? 2. What are the specifications and effectiveness of HTTP slow DOS attack? 3. What are the impacts of slow http attacks on CPU usage, memory usage and network load

of the targeted VM? 4. Do slow HTTP DOS and DDOS attacks have a cross VM effect on the neighbor’s web

server, CPU, RAM and network load?

8

1.7 Expected contribution • Review of cloud related DOS. • Implementation and analyzes of specifications of slow HTTP attacks. • Analysis of the direct impact of the slow HTTP DOS and DDOS on a VM. • Analysis of indirect impact of the slow HTTP DOS and DDOS on a neighbor VM’s web

server performance, CPU and RAM usage and network load.

1.8 Outline of a report There have been some research works that has been done similar to this thesis, which will be explained in section 1.9. In chapter 2 we review different types of cloud related DOS and DDOS attacks. In chapter 3 the implementation and specifications of the slow HTTP DOS attacks will be analyzed. Chapter 4 will present Experimental setup for analyzing the impact of slow HTTP DOS and DDOS attacks. Chapter 5 present the result of the experimental work and analysis. Chapter 6 derives the conclusion of the experimental work and thesis scope.

1.9 Related works In [12], the authors gave a general overview about DOS and DDOS that are carried out in the cloud environment and they also overviewed the tools that can be used for to lunch the attack such as LOIC, XOIC and HULK, Moreover they classified different type of defense mechanism against DDOS attacks. In [13] part 1 they have given a comprehensive analysis over the Slow HTTP attacks and in part 2 they have introduced attack detection method by using Markov chains and queuing system. The chapter 3 of this thesis has similar analysis and implementation of slow http attack but the author of this thesis has done deep packet analysis and explained where the attack happens on the hex dump of captured packets. In [14] the authors have reviewed the functionality of the Slow HTTP attacks and then they proposed an anomaly detection system which measures the Hellinger distance among two probability distribution created in training and testing phases. The training phase it creates a normal profile of complete and incomplete HTTP requests, as it’s known that during Slow HTTP attacks the proportion of incomplete HTTP requests increases, then the proposed method compares the result of the measurement to the normal profile and detects the Slow HTTP attack. Most of the research work that has been done on the slow HTTP attacks are considering the attack impact on the web server application also a possible solution or mitigation methods against slow HTTP attacks. Based on our research and empirical study over indirect impact of slow http attack in cloud environment, the research gap that motivated us to investigate the direct and indirect impact of the slow HTTP attack on VMs and between VMs.

9

2 DENIAL OF SERVICE ATTACK Denial of service (DOS) attack is an attack which the attacker or attackers make an effort to make a service or resources out of access for legitimate users. DOS attacks have many different variants, DOS might target the underlining server’s memory or disk space, or they might target the communication and network infrastructure, or the target can be a critical node’s capacity such as domain name server (DNS) or an intrusion prevention system (IPS) or they might attack at layer 7 and aim the vulnerable application.

2.1 Distributed denial of service (DDOS) attack If an intruder wants to lunch a DOS attack, it is an essential to stay undetected for three purposes, firstly the attacker doesn’t want to be caught and face law enforcement issue, secondly the attacker doesn’t want the firewalls or intrusion detection systems (IDSs) block the malicious traffic that intruder is generating, and thirdly to increase the intensity of the attack, to achieve this goal attacker uses many intermediate systems to perform the DOS attack through them. This type of attack is called DDOS[4]. The intermediate systems are: Command and Control System, and Botnets or both of them. Command and control server (C&C server) is a server which receives the order from the attacker and gives the order to botnets. Botnets are compromised system which attacker use them to perform DDOS. Figure 2.1 describes the simplified architecture of DDOS attack [4].

Attacker Command and control server

BOT

BOT

BOT

BOT

Victim

Figure 2.1: DDOS attack architecture

In general we have three categories of botnet-based DDOS [15]:

10

1. Agent handler model: this DDOS attack compromises client, agent, and handlers. Clients are the nodes that the attacker communicate with them directly, agents are the nodes which carry out the attack and generally the agent’s owner doesn’t know that the system is compromised, and handler is a software which installed on the compromised system and the attacker use this software to lunch the attack.

2. Internet relay chat (IRC) model: this model is almost the same as agent handler model, but in this model the client is connected to the agent through IRC communication channel to prevent the tracking DDOS command packets.

3. Web-based model: in this model, number of bots report statics to a website, and other bots are configured and controlled by PHP scripts. This model has some advantages over IRC model, it needs less bandwidth, easy to set up a web site to control the bots, hiding the traffic through port 80/443 is easy, has resistance to botnet hijacking.

Current methods that used to keep the attacker undetected [4]: 1. Spoofing source IP of attack. 2. IP flux, domain flux. 3. Botnets. 4. Using protocol proxies. 5. Using uncompromised system in reflection and amplification attacks. 6. Using many intermediate layers to conduct the attack.

In 2014 News aggregator Feedly, note-taking app Evernote and music streaming service Deezerwhich are cloud-based services came under DDOS attack and went offline[16]. DDOS attacks can be used for political or Ideologies as well for instance, In 2014 one of the largest DDOS attack in the history of the internet took place the PopVote, an online poll platform managed by The University of Hong Kong was under attack and this site is hosted by CloudFlare, according Matthew Prince CEO of CloudFlare claims that the DDOS was 300Gbps[2]. DOS and DDOS can have very sophisticated impact on the Cloud services, web servers and cloud-based web servers. There are various types of denial of service, this thesis focusses on the DOS attacks that target cloud resources and web services and will analyze in detail HTTP slow attacks. There are three main types of DOS attack as volume-based, attack on specific protocol and application-based DOS attack [3], [4]:

1. Volume-based DOS attack: in volume-based DOS attack massive traffic is directed to the victim’s network to block the network’s bandwidth. Amplification distributed denial of service, Reflection-based denial of service and distributed reflective DOS (DRDOS) are subcategory of Volume-based DOS. UDP and ICMP floods are examples of this type of DOS attack.

2. Protocol-based DOS attack: In protocol DOS attack the attacker tries to consume server or intermediate communication equipment such as firewall, load balancer, etc., resources as much as possible. SYN floods, fragmented packet attack, ping of death, Smurf DDOS are examples of volume-based attack.

3. Application-based DOS attack: in ADOS includes low and slow attacks which targets mostly web servers, the purpose of this attack is to crash web server by creating many legitimate requests such as http’s GET/POST request. this type of DOS attack will be discussed in detail in this thesis.

11

DDOS attacks in cloud or from cloud can be internal or external: 1. Cloud External DDOS: attacker should be able to install it’s trojan inside the cloud and if

this trojan is able to infect other tenants in the cloud then the attacker will be able to lunch the DDOS on the external system [4]. Figure 2.2 shows the architecture of Cloud External DDOS attack.

Figure 2.2: Cloud External DDOS architecture

2. Cloud internal DDOS: internal botnets will attack an internal tenant, these attacks are more dangerous than cloud external DDOS and can cause complete breakdown in cloud infrastructure [4]. Figure 2.3 shows the architecture of this attack.

Figure 2.3: Cloud internal DDOS architecture

12

3. External-based DDOS on cloud component: the attacker can lunch DDOS a DDOS attack

from external network or another cloud to one component of a cloud. Figure 2.4 shows the architecture of this attack.

Figure 2.4: External-based DDOS on cloud architecture

2.1.1 Distributed Reflected Denial of Service (DRDOS) DRDOS is one of the dangerous types of DDOS from a single source. The intruder would create a flow packets with return address of the victim, and broadcast or multicast those packets to the innocent hosts in the network which are called reflectors in this scenario. Since the source address of the flow was the victim IP address then all the responses will be sent to the victim and exhaust the victim’s resources. Figure 2.5 shows the architecture of DRDOS attack. This attack uses the legitimate network hosts to flood the victim which can be web server or cloud-based web server the DRDOS feature [17]:

1. The reflector’s address is the source address in the response packets that are sent from the victim.

2. Source address of the packets that are sent by the slaves to the reflector are the victim’s address.

3. When the reflectors send the response packet to the victim they don’t reveal any information about the slave, so the slave identity will be hidden.

4. Each slave sends small number of requests to the reflectors so each reflector creates limited number of response to the victim in this way the victim’s firewall will not detect the flow as a DOS.

13

Attacker

Master

Master

Slave

Slave

Slave

Reflector

Reflector

Reflector

Reflector

Reflector

Reflector

Request

Request

Request

Request

Request

RequestResponses

Victim Server

Responses

Responses

Responses

Responses

Responses

Figure 2.5: Architecture of DRDOS

2.1.2 Amplification distributed denial-of-service attacks Amplification is more sophisticated way of reflective DOS, this attack uses the nature of network protocols such as network time protocol (NTP) or domain name service (DNS) to increase the traffic that is reflected to the victim, because the responses to DNS and NTP queries are larger than the initial request. In this attack the volume of the reflected traffic that is generated by the reflectors is much higher than the request messages issued by the attacker, the result of this is overwhelming the victim’s bandwidth. To lunch amplified attack the reflector (which is the amplifier node too) needs to run a sort of network protocol that, when it receives a query, it response with one or more packets whose size is bigger than the received query. Figure 2.6 shows the architecture of Amplified Distributed DOS.

14

Attacker

Request With spoofed victim IP





Victim Server

Responses

Responses

DNS

DNS

DNS

NTP

NTP

Responses

Responses

Responses

Figure 2.6: Amplified DDOS architecture

2.2 Denial of service attacks on cloud DOS attack in cloud is designed to prevent legitimate users to access the cloud services, or these attacks could be designed to increase the cost of the using cloud computing services (EDOS).

2.2.1 Virtual machine migration attack Live VM migration is one of the main functionality in IaaS. CSPs can improve the QOS and resource use by adjusting VM placement on demand, however live VM migration high resource and CPU consuming, and if the frequency of migration is high in cloud this could reduce the cloud performance. DOS can cause excessive live migration by exploiting dynamic allocation. This type of DOS tries to vary the resource usage of a malicious VM and consequently triggers live migration. A serious aspect of migration attack is while VMs on the same physical machine are completely isolated by virtualization, a malicious VM can have negative impact on availability of co-located VM [18].

2.2.2 Cloud-internal denial of service attack (CIDOS) CIDOS is cloud specific DOS attack. In this attack number of hostile VMs in the same physical host try to attack their host machine. To lunch this attack each adversary VM increases its resources usage to break the physical host ability to avert the load. CIDOS is hard to detect because the hostile VMs behavior is similar to normal VMs. this attack the adversary VMs use covert channel and protocol to coordinate the attack [19].

15

2.2.3 DOS attack on neighbor If a hypervisor is configured not correctly or has vulnerabilities and can’t isolate VMs and allocate resources to each VM. A malicious VM can lunch a DOS attack on its co-locate VMs and reduce the cloud performance [20]. Figure 2.7 shows this attack’s architecture.

Virtual machine manager(Hypervisor)

Attacker VM

VM VMVM

Victim. . .

Flooding (SYN or UDP or ICMP )

Figure 2.7: Neighbor DOS attack architecture

2.2.4 Mimicking DDOS attack To prevent the detection of the DOS, the attacker might try to mimic the DOS traffic like a legitimate traffic and in this way the DOS detection mechanism which is working based on network traffic monitoring will not detect the DOS attack [4].

2.2.5 Economic denial of service (EDOS) attack For lunching EDOS on cloud’s client. The attacker will send many forge requests to the cloud service, and consequently increase the workload on the client’s tenant and increase the client’s bill. If the client has an elastic resource to use then as much as the tenant workload increases the CSP releases more resources and as a result the client will have to spent more financial resources in order to pay the bill [21].

2.2.6 Energy-oriented denial of service The targets of this attacks are runtime resources such as computing power, memory buffer, storage and network environment such as network protocols and bandwidth. Energy-oriented attack targets cloud infrastructure and tries to waste energy as much as possible and the consequence of this attack are increasing the energy usage and bill and getting the CSP penalized for exceeding the agreed amount of greenhouse emission. Affecting the cloud servers with EDOS by increasing the workload on the internet connection and storage system of the victim might be able to prevent the legitimate clients to connect to access to the VMs, web-based and computing services [22].

16

2.2.7 Denial of service on SaaS Application DOS (ADOS) attack exploits the flaws in a software and the purpose is to make the application unavailable for the legitimate users. ADOS attack targets bottlenecks also resources restrictions within the victim’s software, therefore the attacker does not need to spend a lot of resources and uses bots and zombies. ADOS are harder to trace back to the intruder because the attacker generally uses HTTP/HTTPS protocols to communicate with the cloud service and he or she can easily use a web proxy to hide the source of the attack [23].

2.2.8 Denial of service attacks on web services Web services are collection of open protocols and standards that are used to exchange data between software and systems. Software and applications that are written in different programming languages and different platforms can communicate to each other by using web services. Web services uses extensible markup language (XML) for tagging and Simple Object Access Protocol (SOAP) for transferring messages and Web Service Definition Language (WSDL) to describe the availability of data [46]. The common DOS attacks that are lunched on web services are:

1. Hash DOS: most of the main web servers such as Apache, Tomcat use the same fast hash algorithm for their dictionary table, this hash function was vulnerable and it was exploited in 2011. This attack was done by sending a single large POST filled by more than one thousand tailored variable that could overload the hashing function of the targeted server [24].

2. XML External entity DOS: XML allows using of DTD (Document Type Definitions). DTD has the feature of defining entities and entities are variables used to define shortcut to string or special character. There are two main type of entities, internal declared entities which are defined within the same document. And external declared entities which are defined in an external document. External entities can be used for the DOS attack by retrieving malicious external content. the XML External entity DOS goal is exhausting the resources of the targeted web service by retrieving malicious external file [25].

3. BPEL Instantiation Flooding: Business Process Execution Language (BPEL) is a language based on XML that allows web services in SOA interconnect and share data[26]. Workflow in BPEL has at least one communication activity that makes a new process instance every time that a message arrives, this process instance starts its execution according to the instruction which is given in the process description. An attacker can send a flood of request to the instantiating activity’s end-point. As a result BPEL engine can get exhausted and the engine’s performance will be decreased or this attack can even make the BPEL engine unavailable [27].

4. BPEL indirect flooding: in this attack type, the attacker uses BPEL engine to attack another system. For example a BPEL process calls a web service for creating account, if an attacker targets the process by flooding instantiating messages, BPEL engine resources will be under pressure but the BPEL engine will reflect the heavy load to the target system, moreover if the target system is not powerful as the BPEL engine then the target system will be overloaded and will not be accessible [28].

5. Web service (WS)-addressing spoofing: WS-addressing is a standard for routing message’s definition and it’s placed inside the exchanged SOAP message in this way routing will be independent of network and transport layer protocols. Using this feature the attacker can

17

send a SOAP messages, containing WS-address information to web service server and this message can provoke the web service server to flood SOAP responses to another endpoint [29].

6. HX-DOS attacks: XML based denial of service or X-DOS attack is generally defined as flooding the server by XML messages and making the server unavailable. HTTP-based denial of service (H-DOS) attack has the same principle such as X-DOS and in this type of attack, the attacker flood a web service by HTTP messages. In HX-DOS attack the attacker flood the cloud’s web by combination of XML and HTTP messages to make the web service unavailable [30].

2.2.9 HTTP-based denial of service attacks HTTP flood is type of attack that targets web servers and web applications. The attacker can flood the server by HTTP GET or POST or by sending HTTP request with malformed elements with malformed fields, and the victim server will process the requests and if there are many requests to the server the attacker can exhaust the web server resources and make it unavailable [31].

2.2.9.1 Malformed HTTP-based DOS

In this attack attacker flood the web server by malformed http messages. For instance Microsoft IIS 5.0 and 5.1 are vulnerable to this attack and if an attacker sends HTTP request with the host header that has many "/"characters it can cause DOS and by consuming CPU resources [32]. This type off attack can cause buffer overflow or DOS.

2.2.9.2 HTTP-GET flood attack

In this attack, the attacker sends a large volume of HTTP-GET requests to the victim web server until the server’s resources such as CPU, memory, disk, bandwidth, etc., exhausted. This flood attack exploits the legitimate HTTP-GET requests to attack web servers or web applications. This attack is hard to detect because the http messages have the same syntax as the normal requests. The attacker can send many HTTP-GET requests with different HTTP formats by using HTTP1.1 features [31].

2.2.9.3 HTTP-POST flood attack

POST request is used with forms, which usually take the input from the user, and since POST request contains many parameters, processing this request is taking more resources than GET requests.

18

3 SLOW HTTP DOS ATTACKS

ADOSs target the vulnerabilities in the application layer protocols such as HTTP, SMTP, POP, etc. ADOS pursue resource exhaustion of the targeted server. Traditional DOS or DDOS attacks target and flood layer 3 or 4, these attacks can be easily detected and prevented by IDS and IPS. Mainly there are 3 main differences between ADOS and DOS [33]:

1. ADOS needs less resources on the intruder side, because it targets a specific vulnerability on the target system and exploit it.

2. ADOS is hard to detect because the attacker establishes a normal TCP or UDP connection to the victim system.

3. Stronger hardware on the victim side doesn’t insure attack failure, because ADOS attack targets the application’s limitation rather than the victim’s computing, networking, or storage resources.

HTTP protocol is designed to keep the connection open till the sending or receiving of data is finished. Slow HTTP DOS attack is a ADOS or ADDOS that take an advantage of the http protocol connection’s mechanism [33]. Three types of slow HTTP DOS attacks are known: Slow HTTP headers, Slow HTTP POST and Slow read attack[34].

3.1 Slow HTTP headers (Slowloris) In a normal HTTP request and response, the client sends a HTTP GET for requesting a resource from server, and server responds by 200 OK and sends the demanded resource to the client. Figure 3.1 describes the structure of HTTP request message.

19

Method VersionURLSP

.

.

SP Cr Lf

Header field name .. Value Cr Lf

Header field name .. Value Cr Lf

Cr Lf

.

.

Entity Body

Method: is the method that used for the request the URL, it can be GET, POST or head.URL: contains the requested URLVersion: defines the HTTP version it can be HTTP/1.0 or HTTP/1.1.Header field name: defines the operating parameter of HTTP message.SP: Space used for continuation of a lineEntity Body: entity is an optional payload in the http messag,it differs from message body when transfer coding is applied. Entity Body is used by Post Method not Get method.

Figure 3.1: HTTP request message

HTTP protocol by its nature needs the GET messages’ headers to be completely received before they are processed. If HTTP GET header is not complete the server presumes that the client is having a slow internet connection, therefore the server keeps the resources busy and waiting for the rest of the HTTP GET header [14]. The attacker will not send the complete HTTP GET header, instead attacker just sends fake HTTP headers slowly in order to evade the connection expiry timer and keep the server busy. Carriage return (CR or /r) and linefeed (LF or /n), According to the RFC2616 [35] “CR LF or \r\n” means end of the line in HTTP header, while “\r\n\r\n” defines the end of the complete header and beginning of the message body. Figure 4.2 shows the usage of \r\n in a legitimate HTTP request.

20

Figure 3.2: Normal HTTP request

The attacker uses this feature of the HTTP header to lunch the Slowloris attack, by sending the “\r\n\” and not sending the complete CRLF will keep the server waiting for the rest of the packet and moreover by creating enough connections to the server and occupying all the connection queues of the server will prevent the legitimate user to connect to the server. Figure 3.3 shows the bogus HTTP header which is sent by Slowhttptest software in order to keep avoid server expiry time out and also keep the server waiting for the rest of the header.

Figure 3.3: A bogus HTTP header

Figure 3.4 shows the architecture of HTTP slow attack, and figure 3.5 shows the series of http headers that are sent every 10 seconds to the server in order to resemble an uncomplete http request, we can detect this trick when we look at the packet information in hex, it shows that the resembled packets doesn’t have a complete “\r\n\r\n”.

21

Attacker

Web Server

SYN

SYN,ACK

ACK

HTTP GET, header 180 bytes and ended by 0a0d not a complete ending


.

.n

incomplete HTTP GET after 10 × n seconds

ACK

ACK


Figure 3.4: Slow header attack architecture

22

Figure 3.5: Series of packets that generate one incomplete http header

Figure 3.6 shows the result of Slow HTTP header attack on apache web server. The yellow line shows the web server availability the blue line shows the closed connections, the gray line shows the connected sessions and orange line shows the pending connections. The Y axis indicates the connections and X axis indicates the time in seconds, the attack has been conducted according the attack architecture in the figure 2.7 on VMware workstation 12.0.1 and network configuration is on NAT mode for this test, the attacking software that is used is Slowhttptest and the Victim web server is Apache/2.2.14 which is running on windows xp SP3. Figure 3.6 shows that the Apache web server goes down by 200 simultaneous HTTP slow header connections after 7 seconds.

23

Figure 3.6: Slow header attack

Table 3.1 gives the details of the configuration of the Slowhttptest for lunching Slowloris. Statics Data

Number of connections 1000 HTTP request type GET

Content-Length header value 4096 Interval between follow up data 10 seconds

Connection per second 200 Timeout for probe connection 3 seconds

Test duration 240 seconds

Table 3.1: Slowloris attack configuration statics

3.2 HTTP Slow Body attack (RUDY) In this attack, the intruder sends a complete HTTP Post header in contrast to HTTP slow header attack, but this header has a fake content-length which is higher than the real content length of the message body, and the attacker sends the message body to the targeted web server in small chunks and slowly in order to keep the victim server waiting and busy to receive the rest of the message body. The attacker creates enough same sessions to the server to occupy all the server available resources and as the result server will be unavailable [36], [14]. Figure 3.7 shows a legitimate HTTP POST with a correct content-length. Figure 3.8 shows the example of Slow HTTP POST header that seem to be legitimate with a content length of 1000000 which is the trick. For implementing this attack OWASP Switchblade[37] is used, this figure shows that the HTTP header that is used for conducting slow body attack seems to be completely legitimate but the follow up packets with relatively small message body and slow rate is what brings the web server down.

0

200

400

600

800

1000

1200

0 9

18

27

36

45

54

63

72

81

90

99

10

8

11

7

12

6

13

5

14

4

15

3

16

2

17

1

18

0

18

9

19

8

20

7

21

6

22

5

23

4

SlowHeader Attack

Closed Pending Connected Service Available

24

Figure 3.7: Legitimate HTTP POST with true Content-Length

Figure 3.8: Slow body attack’s header

Figure 3.9 shows the architecture of the HTTP slow POST attack, and Figure 3.10 shows one of the attack packet’s stream, the first HTTP body length was 27 bytes but the following body packets were 1 byte and they were sent with 100 seconds’ delay. This attack brought down the Apache/2.2.14 in 10 seconds.

25

Attacker

Web Server

SYN

SYN,ACK

ACK

HTTP POST, content-length = 1000, HTTP body 25 bytes

HTTP POST, content-length = 1000, HTTP body 1 byte, after 100 seconds

.

.n

incomplete HTTP POST body after 100 × n seconds

ACK

ACK

HTTP POST, content-length = 1000, HTTP body 1 byte, after 100 seconds

Figure 3.9: HTTP slow body attack architecture

Figure 3.10: HTTP slow body stream of incomplete body

Figure 3.11 depicts the details of the slow http POST header and body, the content-length is 10000 bytes which makes the server waiting for a large amount of data, while the attacker just sends 27 bytes in duration of 300 seconds. The Switchblade can make 300 connections before the server goes down.

26

First body 27 bytesSecond and third body 1 Byte, packet numbers

2111, 2835

Header to body delimiter

Figure 3.11: Resembled incomplete HTTP body with hex dump

3.3 HTTP slow read attack On the pervious slow attacks the attacker sends the HTTP header or the body slowly, in contrary in slow read attack the intruder sends HTTP GET messages to the server in a normal rate but it reads the servers’ responses slowly. TCP window size is the number of bytes that a receiver in a TCP session is willing to receive, the data receiver can use this value to control the flow of data. For implementing this attack when the attacker is initiating the TCP 3-way handshake, in the first SYN packet a small window size will be advertised to the server and requesting a large resource the attacker creates a situation for server to send the data slowly [38], and the attacker makes more than thousand connections to deplete all the web server resources and makes it unavailable. Figure 3.12 shows a legitimate connection between client and server, this figure shows that both client and server advertise their desirable window size and the client start increasing its window size up to 48384 bytes.

27

Figure 3.12: Window size changes in a legitimate HTTP request and responses

Figure 3.13 shows a TCP session of slow read attack, as this figure shows the attacker advertises a relatively small window to the server and after the connection established with the server attacker send a request to the server which contains 9 HTTP GET request Figure 3.14 shows the detail of this HTTP GET which is placed on packet number 9. After sending this request the attacker sets its TCP window size to zero, therefore the web server is unable to send data while it keeps the connection open. As Figure 3.13 shows the attacker could keep this session open till the end of the attack which is 180 seconds.

28

Figure 3.13: One slow read attack’s TCP session

This HTTP slow read attack was lunch in the manner of cross VM attack similar the architecture which was depicted on the Figure 2.7. The attacker VM is a Kali linux 64/bit, 1 CPU and 1 GB RAM. The Victim server is running on XP SP3 1 CPU and 1 GB RAM. The host machine is windows 10 64/bit, Intel core I7, 8GB RAM. The VMM is used for lunching this attack is VMware workstation pro 12. Figure 3.15 shows the slow read attack architecture. As this figure shows the attacker starts the attacks by advertising relatively small window size and then requests for large amount of data and then reduces the window size to zero. Figure 3.16 shows the statics of the HTTP slow read attack that was lunched for this experimental work, as it’s describes the test duration is 180 seconds and Apache/2.2.14 web server goes down after 24 seconds. The yellow line shows the web server availability the blue line shows the closed connections, the gray line shows the connected sessions and orange line shows the pending connections, the Y axis indicates the connections and X axis indicates the time in seconds. Slowhttptest application is used to lunch this attack, and Wireshark is used to monitor the network traffic and capture the attacks’ packets. Table 3.2 shows the attack configuration statics.

29

Figure 3.14: Ninth HTTP GETs in one HTTP request

AttackerWeb Server

SYN, window = 1152

SYN,ACK, window = 64240

ACK, window =1152

HTTP GET, Requesting data more than initial window size

ACK, Window = 0

HTTP 200, HTTP body, but I need to send more data to complete the response

ACK, TCP zero window probing, TCP segment 1 byte

ACK, Window = 0

ACK

This pattern repeats as long as the attack is

running Figure 3.15: Slow read attack architecture

30

Figure 3.16: HTTP Slow read attack effect on the web server

Table 3.2 shows the configuration’s statics of the Slow read attack on Slowhttptest.

Statics Data

Number of connections 4090

Receive window range 28 - 505

Pipeline factor 10 Read rate from received buffer 1 byte/ second

Connection per second 25

Timeout for probe connection 5 seconds Target test duration 180 seconds

Web server unavailability 165 seconds

Table 3.2 : Slow read attack configuration statics

In all the three types of slow HTTP attacks experimental work the host machine’s firewall wall was working and it hasn’t detected any abnormal traffic behavior in the network.

0

1000

2000

3000

4000

5000

0 7

14

21

28

35

42

49

56

63

70

77

84

91

98

10

5

11

2

11

9

12

6

13

3

14

0

14

7

15

4

16

1

16

8

17

5

Slow Read Attack


31

4 METHODOLOGY

The literature review on the DOS cloud related attacks has been done and implementation and analysis of slow HTTP attacks is done in the previous chapters. Like we mentioned earlier, the aims and objectives of these research work after empirical studies of related works, we decided to implement Slow header (Slowloris) attack in two different modes: single attacker DOS and multiple attackers DDOS. As it is discussed before the slow HTTP DOS is hard to detect, therefore we decided to lunch the DDOS from the public cloud, and as it was expected the public clouds firewalls havn’t detected the attack, even though 17 VMs from two different public clouds simultaneously were attacking a single IP web server. The purpose of lunching DDOS and measuring the impact is to have the analysis of the impact comparable to the real attack scenario. For having an accurate and persistent results we decided to separate the victim server attacking server, measurement server and command and control (coordinator) machine. The VMs’ CPU, RAM, network load and web server performances were measured before the attack and they are used as an index to compare the result of the measurement during the attacks. The VMs’ CPU, RAM, network load and web server performances were measured during the attack, and it’s obvious that the victim web server is unable to response to measuring test while it is under attack, but during the attack the neighbor VM’s web server performance is measured. In this experimental work only the neighbor VM’s web server is measured. For measuring VMs’ CPU, RAM and Network load we used Dstat, by using this tool at first, we measured CPU, RAM and network load in the stable condition, then we repeated this measurement test while the attacks were lunched in DOS and DDOS modes. Dstat has an option to generate a .CSV file of the measurement results, we used this option to take the logs and generate the graphs and extract the measurement statics. The result of Slow HTTP DOS and DDOS will be compared accordingly to give clear statics of the impact of the attacks. Each test has been run more than 20 times, because we wanted to make sure that the results are not accidental or influenced by interferences. For the whole experimental works ApacheBench [39] was setup to send 50000 connection requests and 50 concurrent connection. This thesis shows the result of four tests in each condition (stable, during DOS and during DDOS), to give more clearer view of the experimental work. The measurement of the direct impacts and indirect impacts of the Slowloris attacks were taken at the moment that webserver went down, and the measurement continued till the end of the attack. The ApacheBench and Dstat were not used simultaneously, because ApacheBench tests will send many HTTP requests to the webserver and this can influence the result of the network measurement, thus these tools are used in separated tests, which means we haven’t measured the CPU, RAM and network load at the same time that we were measuring the web server performance.

32

4.1 Tools used • Slowhttptest is a great tool for lunching Slow HTTP DOS and DDOS attacks, it provides

important statics such as server availability, pending requests closed connections and also it provides html graphical representation of the attack [40].

• DSTAT is a real simple and thorough tool to monitor system resources in a real time, it gives the monitoring results in columns which are easy to read [41].

• ApacheBench(ab) is a single-threaded command line software which is widely used to measure the performance of HTTP web server.

• MobaXtreme is a perfect tool for remote administrating servers and it has a multiple execution option which was amazing feature during Software installation and lunching DDOS without using BOT[42].

4.2 General experiment setup As it’s discussed for measuring the impact of the slow HTTP attack two modes are used, single mode or DOS and multiple mode or DDOS. Figure 4.1 depicts the architecture of the single mode attack and figure 4.2 shows the architecture of slow HTTP DDOS. Details of the servers that are used for this experimental work are on the Table 4.1. Machine CPU RAM OS Measurement machine

Intel (R) Pentium, 4 CPU 2.80 GHZ 4 GB Ubuntu 14.04.3 LTS

Attacking machine

Intel(R) Core(TM) 2, dual CPU E7400, 2.80 GHZ

8 GB Ubuntu 14.04.3 LTS

Coordinator machine

Intel(R) Core(TM), i7-2630QM, 2 GHZ

8 GB Windows 10 pro

VM server Intel Xeon Quad Core -8 cores 2.4 GHZ

8 GB Ubuntu 14.04.3 LTS

VM 1 Intel(R) Xeon(R), X3430, 2.4 GHZ 514MB Debian GNU/Linux 7.1 (wheezy)



Table 4.1:Machines' specifications.

33

Switch

Attacking Server

Measurement server

Router

VM Server

VM 1

VM2

VM3

coordinator machine

Measuring the impact

Slow HTTP

Figure 4.1: Slow HTTP DOS implementation and measuring environment

In this experimental work, the attacks are lunched against Apache/2.2, this experimental work investigates the cross VM effect of the slow HTTP attack on the neighbor virtual web server. The VMs’ interfaces are bridge to eth0 to give public access to the VMs and reduce the interference of NAT mechanism in the hypervisor. For investigating the effect of Slowloris DDOS attack, Microsoft azure public cloud and Google public cloud platform are used to lunch the attack on the VMs inside the DMZ. Figure 4.2 shows the architecture of the Slow HTTP DDOS that is used in this experiment.

34

Switch

Attacking Server Measurement server

Router

VM Server

VM 1

VM2

VM3

Command and Control machine

Microsoft Azure with 9 VMs

Google cloud with 8 VMs

Slow HTTP

Slow HTTP

Slow HTTP

Measuring the impact

Figure 4.2: Slow HTTP DDOS architecture

Table 4.2 gives the specifications of the cloud VMs that are used to carry the DDOS. Public cloud OS CPU RAM Microsoft Azure cloud

9×Debian GNU/Linux 8.7 (jessie)

Intel(R) Xeon(R) CPU E5-2673 v3 2.40GHz

3.529 GB

Ubuntu 17.04 Intel(R) Xeon(R) CPU, E5-2660 2.20GHz

3.529 GB

Google Cloud platform

8×Debian GNU/Linux 8.7 (jessie)

Intel(R), Xeon(R) CPU 2.30GHz

0.6GB

Table 4.2: Clouds’ VMs specifications

In this experimental work Slowhttptest software is used for lunching the attack because of the simplicity also the attack statics that application provides.

35

5 RESULTS AND ANALYSIS

This chapter shows the result of measuring the CPU, memory, network load, and web server performances. The goal is to find out how much Slowloris attack which is not resource costly for the attacker can put stress on the victim VM and consequently on the neighbor VM.

5.1 Analysis of the impact of the Slowloris attack on the victim VM In this section, we measure and analyze the impact of the Slowloris DOS and DDOS on the victim VM. The measurement tests are taken while there is no attack means the VM1 is stable and the measurement are repeated while VM1 is under DOS and DDOS attack.

5.1.1 Measurement of the CPU, RAM, and network load of the VM1 in a stable condition

For measuring the impact of the Slowloris DOS and DDOS in the first step, the CPU, memory, and network load of the victim measured. These results will be used as an index for stable condition of VM1 during the entire tests. Figure 5.1 shows the CPU usage of the VM1 in a stable condition. The gray line indicates the CPU idle state. The blue line indicates the user processes, the orange line indicates the system processes and the yellow line indicates the waiting processes. The Y axis indicates the idle percentage, and the X axis indicates the time duration of the test in seconds. Figure 5.2 shows the memory usage of the VM1 in a stable condition. The gray line indicates the cashed memory, the orange line indicates the buffered memory, the yellow line indicates free memory, and the blue line which is partially covered by the orange line indicates the memory usage. The Y axis shows the amount of memory in byte and X axis shows the test duration in seconds.

Figure 5.1: CPU usage of the VM1 in normal condition

0

20

40

60

80

100

120

1 9

17

25

33

41

49

57

65

73

81

89

97

10

5

11

3

12

1

12

9

13

7

14

5

15

3

16

1

16

9

17

7

18

5

19

3

20

1usr stable sys stable idle stable wai stable

36

Figure 5.2: Memory usage of the VM1 in a stable condition

Figure 5.3 shows the network load of the VM1 in the stable condition. The blue line indicates the data receive and the orange line indicates the data sent. The X axis indicates the bytes and the Y axis indicates the test duration in seconds.

Figure 5.3: Network load of the VM1 in the stable condition

Table 5.1 gives the average, CPU idle percentage, memory usage, and network load of the VM1 in a stable condition.

0

50000000

100000000

150000000

200000000

250000000

300000000

350000000

1 9

17

25

33

41

49

57

65

73

81

89

97

10

5

11

3

12

1

12

9

13

7

14

5

15

3

16

1

16

9

17

7

18

5

19

3

20

1

used stable buff stable cach stable free stable

0

200

400

600

800

1000

1200

1400

1600

1 9

17

25

33

41

49

57

65

73

81

89

97

10

5

11

3

12

1

12

9

13

7

14

5

15

3

16

1

16

9

17

7

18

5

19

3

20

1

recv stable send stable

37

condition Average

CPU idle %

CPU Idle Standard deviation %

Memory usage average (byte)

Memory usage Standard deviation (byte)

Received data Average (byte)

Received data Standard deviation (byte)

Sent data Average (byte)

Sent data Standard deviation (byte)

Stable condition

99.36 0.89 48431104 52844.91 169.75 181.49 521.89 176.78

Table 5.1: VM1 CPU idle, memory usage, Network load, in stable condition

Figure 5.4 shows the average CPU idle of the victim VM in stable condition, this graph also contains the standard deviation of the CPU Idle, the standard deviation is indicated by yellow line. The Y axis indicates the CPU idle percentage.

Figure 5.4: Victim VM average CPU Idle in a stable condition

Figure 5.5 shows the average memory usage of the victim VM in stable condition, this graph also contains the standard deviation of the memory usage, the standard deviation is indicated by yellow line. The Y axis indicates the memory usage in bytes.

97.5

98

98.5

99

99.5

100

100.5

Average CPU idle %

Average CPU Idle (+/- S.D.)

38

Figure 5.5: Victim VM average memory usage in a stable condition

Figure 5.6 shows the average network input of the victim VM in stable condition, this graph also contains the standard deviation of the network input, the standard deviation is indicated by yellow line. The Y axis indicates the received data in bytes.

Figure 5.6: Victim VM average network input in a stable condition

Figure 5.7 shows the average network output of the victim VM in stable condition, this graph also contains the standard deviation of the network output, the standard deviation is indicated by yellow line. The Y axis indicates the sent data in bytes. The web server performance on the VM1 is not measured because the VM1 is the victim VM and when it goes under attack it can’t response to the HTTP requests, therefore there is no reason to measure the performance of the web server on VM1.

48320000

48340000

48360000

48380000

48400000

48420000

48440000

48460000

48480000

48500000


Average memory usage(+/- S.D.)

0

50

100

150

200

250

300

350

400

Received data

Average data recieved (+/- S.D.)

39

Figure 5.7: Victim VM average network output in a stable condition

5.1.2 Measurement of the impact of the Slowloris DOS on the victim VM In this section the CPU idle, memory usage and network load of the VM1 is measured while the attacking server is lunching Slowloris against it. Table 5.2 gives the detail of the Slowhttptest configuration. The configuration of the Slowhttptest will remain constant for the entire experiment.

Test parameters Test type SLOW HEADERS Number of connections 4000 Verb GET Content-Length header value 4096 Interval between follow up data 10 seconds Connections per seconds 25 Timeout for probe connection 3

Table 5.2: Slowhttptest attack configuration

Figure 5.8 shows the impact of the Slowloris DOS on the VM1’s web server. The web server goes down in 14 seconds and then it becomes available after 220 seconds. The yellow line indicates the service availability and the blue line indicates the closed connection. The orange line indicates the pending connections and the gray line indicates the connected sessions to the web server.

0

100

200

300

400

500

600

700

800

Sent data

Average data sent(+/- S.D.)

40

Figure 5.8: The impact of the Slowloris on the VM1

The Dstat used on the victim machine to record the CPU idle, memory usage and network load during the Slowloris attack. Figure 5.9 shows the CPU idle of the VM1 while it’s under Slowloris DOS, And stable condition. Blue line indicates the CPU idle in stable condition and orange line indicates the CPU usage during Slowloris DOS. The Y axis indicates the CPU idle and the X axis indicates the duration of the test in seconds.

Figure 5.9: CPU idle comparison during stable and DOS conditions

Figure 5.10 shows the memory usage of the VM1 during Slowloris attack. And normal condition. Blue line indicates the memory usage in stable condition and orange line indicates the memory

0

500

1000

1500

2000

2500

3000

3500

4000

4500

0 8

16

24

32

40

48

56

64

72

80

88

96

10

4

11

2

12

0

12

8

13

6

14

4

15

2

16

0

16

8

17

6

18

4

19

2

20

0

20

8

21

6

22

4

23

2

24

0

Slowloris DOS


0

20

40

60

80

100

120

1 9

17

25

33

41

49

57

65

73

81

89

97

10

5

11

3

12

1

12

9

13

7

14

5

15

3

16

1

16

9

17

7

18

5

19

3

20

1

idle stable idle during Slowloris

41

usage during Slowloris DOS. The Y axis indicates bytes and the X axis indicates test duration in seconds.

Figure 5.10: Memory usage comparison during Stable and DOS conditions

Figure 5.11 shows the network input of the VM1 while it’s under single Slowloris attack. And compares the result with stable condition. Blue line indicates the network input in stable condition and orange line indicates the network input during Slowloris DOS. The Y axis indicates bytes and the X axis indicates test duration in seconds.

Figure 5.11: Data input, comparison during stable and DOS conditions

Figure 5.12 shows the network output of the VM1 during Slowloris attack and stable condition. Blue line indicates the network output in stable condition and orange line indicates the network

0

10000000

20000000

30000000

40000000

50000000

60000000

70000000

1 9

17

25

33

41

49

57

65

73

81

89

97

10

5

11

3

12

1

12

9

13

7

14

5

15

3

16

1

16

9

17

7

18

5

19

3

20

1

used stable used during slowloris

0

10000

20000

30000

40000

50000

60000

70000

80000

90000

100000

1 8

15

22

29

36

43

50

57

64

71

78

85

92

99

10

6

11

3

12

0

12

7

13

4

14

1

14

8

15

5

16

2

16

9

17

6

18

3

19

0

19

7

20

4

recv stable recv during slowloris

42

output during Slowloris DOS. The Y axis indicates bytes and the X axis indicates test duration in second.

Figure 5.12: Data output comparison, during stable and DOS conditions

Table 5.3 shows the CPU idle, memory usage, received data and sent data during the Slowloris DOS on the VM1.

condition Average CPU Idle%

CPU Idle standard deviation%


Memory usage standard deviation (byte)


Received data standard deviation (byte)


Sent data standard deviation (byte)

During Slowloris DOS

96.65 3.81 60268781.71

366183.38

23744.23 17751.33 10403.26 13199.04

Table 5.3: CPU idle, memory usage, and network load during Slowloris DOS

5.1.3 Measurement of the impact of the Slowloris DDOS on the victim VM Figure 5.13 shows the effect of Slowloris DDOS on the VM1 web server. The web server goes down in 6 seconds and it is unavailable for the entire attack. The yellow line indicates the web server availability and the blue line indicates the closed connections. The orange line indicates the pending connections and the gray line indicates the connected sessions to the web server.

0

5000

10000

15000

20000

25000

30000

35000

40000

450001 8

15

22

29

36

43

50

57

64

71

78

85

92

99

10

6

11

3

12

0

12

7

13

4

14

1

14

8

15

5

16

2

16

9

17

6

18

3

19

0

19

7

20

4

send stable send during slow loris

43

Figure 5.13: Effect of Slowloris DDOS on the VM1 web server

For measuring the impact of Slowloris DDOS the attack was lunched according Figure 4.2 attack architecture. Dstat used on the VM1 to measure the impact of the attack on CPU usage, memory usage and network load measured. Figure 5.14 shows the CPU idle of the VM1 while it’s experiencing DDOS Slowloris attack, this figure also presents the previous CPU measurements on the VM1. The orange line indicates the CPU idle of the VM1 while there is no attack. The gray line indicates the CPU idle of the VM1 while there is Slowloris DOS and the blue line indicates the CPU usage of the VM1 during Slowloris DDOS. The Y axis indicates the CPU idle and X axis indicates the test duration in seconds.

Figure 5.14: CPU idle of the VM1 during stable, DOS and DDOS.

0

500

1000

1500

2000

2500

3000

3500

4000

45000 8

16

24

32

40

48

56

64

72

80

88

96

10

4

11

2

12

0

12

8

13

6

14

4

15

2

16

0

16

8

17

6

18

4

19

2

20

0

20

8

21

6

22

4

23

2

24

0

Slowloris DDOS


0

20

40

60

80

100

120

1 9

17

25

33

41

49

57

65

73

81

89

97

10

5

11

3

12

1

12

9

13

7

14

5

15

3

16

1

16

9

17

7

18

5

19

3

20

1

cpu idle comparison in 3 conditions

idle during Ddos Loris idle stable idle during Slowloris

44

Figure 5.15 shows the memory usage of the VM1 during Slowloris DDOS attack. this figure also presents the previous memory measurements on the VM1 while it is in stable also during DOS. The blue line indicates the memory usage in the stable condition, the gray line indicates the memory usage during DOS, and orange line indicates the memory usage during DDOS. The Y axis indicates the memory usage in byte and X axis indicates the test duration in seconds. Figure 5.16 shows the data received by VM1 during Slowloris DDOS attack, this figure also presents the receiving data by VM1 while it is in stable condition also during DOS. The orange line indicates the network input during stable condition, gray line indicates the network input during DOS and blue line indicates the network input during DDOS. The Y axis indicates the byte received and the X axis indicates the test duration in seconds. Figure 5.17 shows the data sent from VM1 during Slowloris DDOS attack, this figure also presents the data sent from VM1 while it was stable, also during DOS. The orange line indicates the network output during stable condition, gray line indicates the network output during DOS and blue line indicates the network output during DDOS. The Y axis indicates the byte sent and the X axis indicates the test duration in seconds.

Figure 5.15: memory usage of VM1 during stable, DOS and DDOS

0

10000000

20000000

30000000

40000000

50000000

60000000

70000000

1 8

15

22

29

36

43

50

57

64

71

78

85

92

99

10

6

11

3

12

0

12

7

13

4

14

1

14

8

15

5

16

2

16

9

17

6

18

3

19

0

19

7

20

4

Memory used comparison in 3 conditions

used stable used during Ddos Loris used during slowloris

45

Figure 5.16: Data received on the VM1 during stable, DOS and DDOS

Figure 5.17: Data sent on the VM1 during stable, DOS and DDOS

Table 5.4 shows the result of CPU idle, memory usage and network load on VM1 while VM1 is under Slowloris DDOS.

0

200000

400000

600000

800000

1000000

1200000

1400000

1600000

1800000

2000000

1 71

31

92

53

13

74

34

95

56

16

77

37

98

59

19

71

03

10

91

15

12

11

27

13

31

39

14

51

51

15

71

63

16

91

75

18

11

87

19

31

99

Data recieve comparison in 3 conditions

recv during Ddos Loris recv stable recv during slowloris

0

20000

40000

60000

80000

100000

120000

140000

1 8

15

22

29

36

43

50

57

64

71

78

85

92

99

10

6

11

3

12

0

12

7

13

4

14

1

14

8

15

5

16

2

16

9

17

6

18

3

19

0

19

7

20

4

Data send comparison in 3 conditions

send during Ddos Loris send stable send during slow loris

46

condition Average CPU idle %








During DDOS Slowloris Attack

60.5716 37.63 64235067 112419 426789.50 285269.3 18544.03 18971.76

Table 5.4: CPU idle, memory usage and network load on VM1 during Slowloris DDOS

Figure 5.18 shows the comparison in average CPU Idle of the VM1 while it is in a stable condition and experiencing Slowloris DOS and DDOS, this graph also contains the standard deviation of the CPU Idle in these different conditions, the standard deviation is indicated by yellow line. The Y axis indicates the CPU idle percentage.

Figure 5.18: Victim VM average CPU Idle comparison

Figure 5.19 shows the comparison in average memory usage of the VM1 while it is in a stable condition and experiencing Slowloris DOS and DDOS, this graph also contains the standard deviation of the memory usage in these three different conditions, the standard deviation is indicated by yellow line. The Y axis indicates the memory usage in bytes.

0

20

40

60

80

100

120

Stable condition During Slowloris DOS During DDOS Slowloris Attack


47

Figure 5.19: Victim VM average memory usage comparison

Figure 5.20 shows the comparison in average network input of the VM1 while it is in a stable condition and experiencing Slowloris DOS and DDOS, this graph also contains the standard deviation of the network input in these three different conditions, the standard deviation is indicated by yellow line. The Y axis indicates the data received in bytes.

Figure 5.20: Victim VM average network input

Figure 5.21 shows the comparison in average network output of the VM1 while it is in a stable condition and experiencing Slowloris DOS and DDOS, this graph also contains the standard deviation of the network output in these different conditions, the standard deviation is indicated by yellow line. The Y axis indicates the data sent in bytes.

0

10000000

20000000

30000000

40000000

50000000

60000000

70000000

Stable condition During Slowloris DOS During DDOS SlowlorisAttack

Average memory usage (+/- S.D.)

0

100000

200000

300000

400000

500000

600000

700000

800000



48

Figure 5.21: Victim VM average network output

5.1.4 Analysis of the impact on the victim VM In this section, we compare the results of the measurements that has been taken from the VM1 and drag out the exact impact of the DOS and DDOS on the CPU and memory usage and network load. Table 5.5 shows the impact of the attack in stable mode, under Slowloris DOS and DDOS.

condition Average CPU idle %








Stable condition

99.36 0.89 48431104 52844.91 169.75 181.49 521.89 176.78


96.65 3.81 60268781.71 366183.38 23744.23 17751.33 10403.26 13199.04


60.5716 37.63 64235067 112419 426789.50 285269.3 18544.03 18971.76

Table 5.5: Impact of the attack in Stable mode, during DOS, during DDOS

Table 5.6 shows the amount increase in resource usage on the victim machine while it was experiencing Slowloris DOS and DDOS.

0

5000

10000

15000

20000

25000

30000

35000

40000


Average data sent (+/- S.D.)

49

condition Average CPU

usage increase Average Memory usage increase

Average Received data Increase (byte)

Average sent data increase (byte)

During Slowloris DOS attack

2.71% 24.44% 23574.48 10233.51

During Slowloris DDOS attack

38.78% 32.63% 426619.75 18374.28

Table 5.6: Resource usage increase on the victim machine during DOS and DDOS

Table 5.6 shows how effective is the Slowloris attack in increasing the resource usage on the targeted machine. We see that Slowloris single attack against the VM could increase the CPU usage by 2.71% and memory usage by 24.44%, even though the attack intensity was low, and 25 connections per second was used to target the server, we can see that the average network input load increased by 139.87 times and average network output increased by 19.93 times during DOS. These statics shows the high impact of Slowloris DOS on the memory usage and network load. Slowloris DDOS attack, which was performed by 17 VMs on the public clouds and one attacking server inside our DMZ, could increase the CPU usage of the victim by 38.78%, which we can conclude each VM on the cloud could increase the CPU usage of the server approximately 2%. Memory usage increased by 38.78% which is a lot but it hasn’t increased in the same way that CPU usage increased. Ingress traffic increased by 2514.22 times, and egress traffic increased by 35.53 times. Our analysis shows the high impact of the Slowloris DOS and DDOS, while they are low rated and assimilate the legitimate traffic which makes it hard to detect, these attacks can bring down a web server which is susceptible to these attacks easily and fast.

5.2 Analysis of the impact of the Slowloris attacks on the neighbor VM In this section, we measure the indirect impact of the Slowloris DOS and DDOS on the VM2. The measurement tests are taken while there is no attack on the VM1(the victim VM) and then they are repeated while the neighbor VM1 is experiencing DOS and DDOS. For investigating the possible cross VM impact of the Slowloris the CPU, memory and network load measured by Dstat, the web server performance of the VM2 also measured by ApacheBench. We have performed the measurement tests in three conditions on VM2, the stable condition which is when there is no attack on the VM1 and we use the result of this measurement as an indicator for the entire tests, secondly, we measured the VM2 while there is a Slowloris DOS on VM1 and finally we did the same measurements while VM1 was experiencing DDOS.

5.2.1 Measurement of the CPU, RAM, network, and Web server performance of the neighbor VM in a stable condition

In this section we measure CPU, memory usage and network load of VM2 by Dstat and also the web performance of the VM2 is measured by ApacheBench these results will be used as an index of stability.

50

Figure 5.22 shows the CPU usage of the VM2 in a stable condition. The gray line indicates the CPU idle state. The blue line indicates the user processes, the orange line indicates the system processes and the yellow line indicates the waiting processes. The Y axis indicates the idle percentage, and the X axis indicates the time duration of the test in seconds. Figure 5.23 shows the memory usage of the VM2 in a stable condition. The gray line indicates the cashed memory, the orange line indicates the buffered memory, the yellow line indicates free memory, and the blue line which is partially covered by the orange line indicates the memory usage, to make a clear graph of memory usage we have made a second graph that just shows the memory usage and that is fused to the bottom of the graph. The Y axis shows the amount of memory in byte and X axis shows the test duration in seconds.

Figure 5.22: CPU usage of the VM2 in the normal condition

Figure 5.24 shows the network load of the VM2 in a stable condition. The blue line indicates the data receive and the orange line indicates the data sent. The X axis indicates the bytes and the Y axis indicates the test duration in seconds.

0

20

40

60

80

100

120

1

10

19

28

37

46

55

64

73

82

91

10

0

10

9

11

8

12

7

13

6

14

5

15

4

16

3

17

2

18

1

19

0

19

9

20

8

21

7

22

6

23

5

24

4

usr stable sys stable idl stable wai stable

51

Figure 5.23: Memory usage of the VM2 in a stable condition

Figure 5.24: Network usage of the VM2 in the stable condition

Table 5.7 shows the average CPU idle, memory usage and network load while VM2 in a stable condition.

0

500

1000

1500

2000

2500

3000

1

10

19

28

37

46

55

64

73

82

91

10

0

10

9

11

8

12

7

13

6

14

5

15

4

16

3

17

2

18

1

19

0

19

9

20

8

21

7

22

6

23

5

24

4

recv stable send stable

52

condition Average CPU Idle %







Sent data Standard deviation

Stable condition

98.47 1.1071 46488961.02 83209.47 190.692 217.685 492.168 209.016

Table 5.7: Average CPU, memory, and network load of VM2 in stable condition

Figure 5.25, 5.26, 5.27 and 5.28 shows the result of ApacheBench tests on the VM2 while there is no attack and the hypervisor is in stable condition. The Y axis in these figures indicates the response time in millisecond and the X axis indicates the time, the granularity of our time data is 5 seconds on the X axis. The Linux time stamp is used to make the X axis of the graphs.

Figure 5.25: VM2 ApacheBench test1 while there is no attack

53



54


Figure 5.29 shows the comparison result of the ApacheBench tests on VM2 during 4 tests while there is no attack. The X axis indicates the time and the Y axis indicates the webserver response time in millisecond.

Figure 5.29: Comparison between the results of 4 benchmarking tests

55

Table 5.8 shows the average Time per request and transfer rate of the ApacheBench on the VM2. VM2 Test 1 Test 2 Test 3 Test 4 Average Average Time per request [ms]

3.070 3.038 3.092 3.101 3.07525

Transfer rate [Kbytes/sec]

144.09 145.64 143.06 142.67 143.865

Table 5.8: Result of the ApacheBench on VM2 while there is no attack

5.2.2 Measurement of the CPU, RAM, network, and Web server performance of the VM during Slowloris DOS on the neighbor

The Slowloris DOS is lunched from the attacking machine against VM1, and by using Dstat the impact of the attack on VM2 is recorded. ApacheBench is used to measure VM2’s web server performance while the VM1 is experiencing Slowloris DOS attack. Figure 5.30 shows the CPU idle of the VM2 while the VM1 is under Slowloris DOS, it also contains the record of the CPU idle of VM2 in the stable condition. The blue line indicates the CPU idle during Slowloris DOS on the neighbor, and the orange line indicates the CPU idle in stable condition. Y axis indicates the CPU idle percentage and X axis indicates the test duration in second.

Figure 5.30: CPU idle of the VM2 while VM1 is experiencing single Slowloris DOS

Figure 5.31 shows the memory usage of the VM2 while the VM1 is under Slowloris DOS, it also contains the record of the memory usage in the stable condition. The orange line indicates the memory usage in stable condition and the blue line indicates the memory usage during Slowloris DOS. Y axis indicates the memory used in byte and X axis indicates the test duration in seconds. Figure 5.32 shows the differences in network input on VM2 before and during the time that VM1 is experiencing single Slowloris DOS attack. The orange line indicates the network input in stable condition, and the blue line indicates the network input during Slowloris DOS on VM1. Y axis indicates data received in byte and X axis indicates the test duration in seconds.

75

80

85

90

95

100

105

1 9

17

25

33

41

49

57

65

73

81

89

97

10

5

11

3

12

1

12

9

13

7

14

5

15

3

16

1

16

9

17

7

18

5

19

3

20

1

20

9

21

7

22

5

idle singl att idl stable

56

Figure 5.33 shows the differences in network output on VM2 in stable condition and during the time that VM1 is experiencing single Slowloris attack. The orange line indicates the network output in stable condition, and the blue line indicates the network output during Slowloris DOS on the neighbor. The Y axis indicates the Network output in byte, and X axis indicates the test duration in second.

Figure 5.31: Memory usage of the VM2 during stable and DOS on VM1

Figure 5.32: Receiving data on VM2 during stable and DOS on VM1

46000000

46100000

46200000

46300000

46400000

46500000

46600000

46700000

46800000

46900000

1 9

17

25

33

41

49

57

65

73

81

89

97

10

5

11

3

12

1

12

9

13

7

14

5

15

3

16

1

16

9

17

7

18

5

19

3

20

1

20

9

21

7

22

5

used during single att used stable

0

500

1000

1500

2000

2500

3000

1 8

15

22

29

36

43

50

57

64

71

78

85

92

99

10

6

11

3

12

0

12

7

13

4

14

1

14

8

15

5

16

2

16

9

17

6

18

3

19

0

19

7

20

4

21

1

21

8

22

5

recv during single att recv stable

57

Figure 5.33: sending data of VM2 in stable mode and during DOS on VM1

Table 5.9 shows the differences on CPU idle, Memory usage and network load of VM2 while VM1 is under Slowloris DOS attack.

Condition CPU Idle average%




Received data Average(byte)

Data received Standard deviation (byte)

Sent data Average(byte)

Data sent Standard deviation (byte)

During single Attack

98.35 1.2584 46401071.79 55862.89 213.577 257.873 520.453 189.537

Table 5.9: VM2’s CPU idle, Memory usage and network load while VM1 is under DOS

Figure 5.34, 5.35, 5.36 and 5.37 shows the result of ApacheBench on the VM2 while VM1 is under single Slowloris DOS attack. The Y axis in these figures indicates the response time in millisecond and the X axis indicates the time, the granularity of our time data is 5 seconds on the X axis. The Linux time stamp is used to make the X axis of the graphs.

0

500

1000

1500

2000

2500

3000

1 8

15

22

29

36

43

50

57

64

71

78

85

92

99

10

6

11

3

12

0

12

7

13

4

14

1

14

8

15

5

16

2

16

9

17

6

18

3

19

0

19

7

20

4

21

1

21

8

22

5

send during single att send stable

58

Figure 5.34: ApacheBench test1 while neighbor is under single Slowloris DOS


59



Figure 5.38 shows the comparison between the Apache performance during 4 tests while the neighbor was experiencing single Slowloris attack. Similar to previous ApacheBench tests the Y axis shows the server response time and the X axis shows the Linux time stamp, therefore the graph is chronological.

60

Figure 5.38: Comparison in result of 4 ApacheBench tests on VM2 while neighbor VM is under

Slowloris DOS Table 5.10 shows the average Time per request and transfer rate of the ApacheBench on the VM2 while the neighbor is under single Slowloris attack.

VM2 Test 1 Test 2 Test 3 Test 4 Average result in 4 tests

Average Time per request [ms]

3.151 3.097 3.224 3.087 3.13975


140.38 142.85 137.22 143.29 140.935

Table 5.10: Average Time per request and transfer rate of ApacheBench on VM2

5.2.3 Measurement of the CPU, RAM, network load of the VM during SlowLoris DDOS on the neighbor

For measuring the impact of the DDOS on the neighbor VM like previous tests Dstat is used to measure the CPU idle, memory usage and network load, and ApacheBench is used to measure web server performance while the neighbor VM is under Slowloris DDOS. The architecture of the Slowloris DDOS is depicted on Figure 4.2. Figure 5.39 shows the CPU idle of VM2 while VM1 is under Slowloris DDOS and this Figure also contains the CPU idle during Stable condition, and DOS. The gray line indicates the CPU idle state in stable condition, the orange line indicates the CPU idle during DOS on VM1, the blue line indicates the CPU idle state during DDOS on VM1. The Y axis indicates the CPU idle percentage and X axis indicates the test duration in second.

61

Figure 5.39: CPU idle of the VM2 while VM1 is in stable, DOS and DDOS

Figure 5.40 shows the memory usage of VM2 while VM1 is under Slowloris DDOS and this Figure also contains the record of memory usage during Stable condition, and DOS on VM1. The gray line indicates the memory usage in stable condition, the orange line indicates memory usage during DOS on VM1, the blue line indicates the memory usage during DDOS on VM1. The Y axis indicates the memory usage in bytes and the X axis indicates the test duration in seconds.

Figure 5.40: VM2 memory usage while VM1 is in stable, DOS and DDOS

Figure 5.41 shows the received data of VM2 while VM1 is under Slowloris DDOS and this Figure also contains the received data record during Stable condition, and DOS on VM1. The gray line indicates network input in stable condition, the orange line indicates network input during DOS

75

80

85

90

95

100

1051 8

15

22

29

36

43

50

57

64

71

78

85

92

99

10

6

11

3

12

0

12

7

13

4

14

1

14

8

15

5

16

2

16

9

17

6

18

3

19

0

19

7

20

4

21

1

21

8

CPU idle comparison in 3 conditions

idle DDOS idle singl att idl stable

45800000

46000000

46200000

46400000

46600000

46800000

47000000

1 9

17

25

33

41

49

57

65

73

81

89

97

10

5

11

3

12

1

12

9

13

7

14

5

15

3

16

1

16

9

17

7

18

5

19

3

20

1

20

9

21

7

memory usage comparison in 3 conditions

used DDOS used during single att used stable

62

on VM1 and the blue line indicates the network input during DDOS on VM1. The Y axis indicates data received in bytes and the X axis indicates the test duration in seconds. Figure 5.42 shows the Network output of VM2 while VM1 is under Slowloris DDOS and this Figure also contains the sent data during Stable condition, and DOS. The gray line indicates date sent during stable condition, the orange line indicates the data sent during DOS on VM1, the blue line indicates data sent during DDOS on the neighbor. The Y axis indicates the data sent in byte and the X axis indicates the test duration in seconds.

Figure 5.41: VM2 network input comparison in 3 conditions

Figure 5.42: VM2 network output in 3 conditions

0

500

1000

1500

2000

2500

3000

1 7

13

19

25

31

37

43

49

55

61

67

73

79

85

91

97

10

3

10

9

11

5

12

1

12

7

13

3

13

9

14

5

15

1

15

7

16

3

16

9

17

5

18

1

18

7

19

3

19

9

20

5

21

1

21

7

recieve data compariosn in 3 conditions

recv DDOS recv during single att recv stable

0

500

1000

1500

2000

2500

3000

1 7

13

19

25

31

37

43

49

55

61

67

73

79

85

91

97

10

3

10

9

11

5

12

1

12

7

13

3

13

9

14

5

15

1

15

7

16

3

16

9

17

5

18

1

18

7

19

3

19

9

20

5

21

1

21

7

send data comparison in 3 conditions

send DDOS send during single att send stable

63

Table 5.11 shows the average CPU idle, memory usage, network load on VM2 while VM1 is experiencing DDOS Slowloris. condition CPU Idle

average%






Sent data Average(byte)



98.42 0.8725 46371095.27

88801.73 294.613 216.479 521.636 240.403

Table 5.11: CPU idle, memory usage, network load of VM2 while VM1 is under DDOS

Figure 5.43 shows the average CPU idle of VM2 in stable condition also during Slowloris DOS and DDOS on VM1, this graph also contains the standard deviation of the CPU Idle in these different conditions, the standard deviation is indicated by yellow line. The Y axis indicates the CPU idle percentage.

Figure 5.43: VM2 average CPU idle comparison in 3 conditions

Figure 5.44 shows the average memory usage of VM2 in stable condition also during Slowloris DOS and DDOS on VM1, this graph also contains the standard deviation of the memory usage in these different conditions, the standard deviation is indicated by yellow line. The Y axis indicates the memory usage in bytes.

95.5

96

96.5

97

97.5

98

98.5

99

99.5

100



64

Figure 5.44: Neighbor VM average memory usage comparison in 3 conditions

Figure 5.45 shows the average network input of VM2 in stable condition also during Slowloris DOS and DDOS on VM1, this graph also contains the standard deviation of the network input in these three different conditions, the standard deviation is indicated by yellow line. The Y axis indicates the data received in bytes.

Figure 5.45: Neighbor VM average data received comparison in 3 conditions

Figure 5.46 shows the average network output of VM2 in stable condition also during Slowloris DOS and DDOS on VM1, this graph also contains the standard deviation of the network input in these three different conditions, the standard deviation is indicated by yellow line. The Y axis indicates the data sent in bytes.

46100000

46150000

46200000

46250000

46300000

46350000

46400000

46450000

46500000

46550000

46600000


Average memory usage (+/- S.D.)

0

100

200

300

400

500

600



65

Figure 5.46: Neighbor VM average data sent comparison in 3 conditions

Figure 5.47, 5.48, 5.49 and 5.50 shows the result of ApacheBench on the VM2 while VM1 is under DDOS Slowloris attack. The Y axis in these figures indicates the response time and the X axis indicates the time, the granularity of our time data is 5 seconds on the X axis. The Linux time stamp is used to make the X axis of the graphs.

Figure 5.47: ApacheBench test 1 on Vm2 while VM1 is under DDOS Slowloris

0

100

200

300

400

500

600

700

800

900


Average data sent (+/- S.D.)

66



67

Figure 5.50: ApacheBench test 4 on Vm2 while VM1 is under DDOS Slowloris Figure 5.51 shows the result of comparison between the 4 ApacheBench tests on VM2 while VM1 is experiencing Slowloris DDOS. Similar to pervious graphs the X axis shows the Linux time stamp and the Y axis shows the webserver response time.

68

Figure 5.51 : ApacheBench measurement results while VM1 is experiencing Slowloris DDOS

Table 5.12 shows the result of the ApacheBench tests on VM2 while VM1 is under Slowloris DDOS. VM2 Test 1 Test 2 Test 3 Test 4 Average result in 4 tests Average Time per request [ms]

3.358 3.382 3.454 3.465 3.41475


131.74 130.82 128.06 127.67 129.5725

Table 5.12: ApacheBench tests on VM2 while VM1 is under Slowloris DDOS

5.2.4 Analysis of the impact on the neighbor VM In this section, we compare the results of the measurements that has been taken from the VM2 while VM1 is experiencing Slowloris DOS and DDOS and stable condition, and we find the impact of the Slowloris DOS and DDOS on the neighbor VM’s CPU, RAM, network load and web server. Table 5.13 compares the result of the measurements which were taken from VM2 while it is stable and while the neighbor VM is under Slowloris DOS and DDOS, CPU usage, memory usage and network load details are included in this table.

69

conditions Average

CPU Idle %







Sent data Standard deviation

Stable condition

98.47 1.1071 46488961.02 83209.47 190.692 217.685 492.168 209.016


98.35 1.2584 46401071.79 55862.89 213.577 257.873 520.453 189.537


98.42 0.8725 46371095.27 88801.73 294.613 216.479 521.636 240.403

Table 5.13: Test’s results comparison on VM2, while VM1 is in stable, under DOS and DDOS conditions

Table 5.14 shows the differences in performances of web server on VM2 while VM1 is experiencing Slowloris DOS and DDOS. VM2 Average result during

Slowloris DDOS Average result during Slowloris DOS

Average result during stable condition

Average Time per request [ms] 3.41475 3.13975 3.07525 Transfer rate [Kbytes/sec] 129.5725 140.935 143.865

Table 5.14:VM2 webserver performance comparison in different conditions

Table 5.15 shows the impact of the attacks on VM2 (neighbor VM) in details. conditions Average CPU

usage increase (percentage)

Average Memory usage decrease (byte)

Received data Average increase

Sent data Average increase

byte percentage byte percentage


0.12% 87889 22.885 12% 28.285 5.75 %


0.05% 117865 103.921 54% 29.468 5.99%

Table 5.15: Impact of the attacks on VM2 (neighbor VM) in details

Table 5.15 shows some deviation on the CPU usage during the attacks on the neighbor but this

70

amount of deviation is not enough to conclude the indirect impact. We can see interesting fact that the average memory usage during DOS and DDOS has reduced by 87.8 KB and 117KB.8 KB respectively. These statics shows that Slowloris attack on one VM could decrease the memory usage of the neighbor VM. Another considerable fact that we can conclude from the table is, increase in the network load input of VM2 by 12% and 54% during DOS and DDOS respectively, and VM2’s network output load during the DOS and DDOS on VM1 has increased by 5.75% and 5.99% respectively. These statics shows that attacking one VM could indirectly increase the network load of the neighbor VM. Table 5.16 shows the average delay that Slowloris DOS and DDOS could cause on the neighbor’s web server.

VM2 Average delay increase during Slowloris DDOS

Average delay increase during Slowloris DOS

Average result during

stable condition millisecond percentage millisecond percentage

Average Time per request

0.3395 11% 0.0645 2.09% 3.07525 [ms]

Table 5.16: Average delay increase on neighbor VM Table 5.17 shows the average reduction of transfer rate on ApacheBench while the neighbor is experiencing Slowloris DOS and DDOS.

VM2 Average transfer rate decrease during Slowloris

DDOS

Average transfer rate decrease during Slowloris DOS

Kbyte/sec percentage Kbyte/sec percentage

Transfer rate 14.2925 9.93% 2.93 2.04%

Table 5.17: ApacheBench transfer rate reduction on VM2

The result of table 5.16 shows that average time per request on VM2’s web server during DOS and DDOS increased by 2.09% and 11% respectively. The result on table 5.17 shows that transfer rate of ApacheBench on VM2 during DOS and DDOS on VM1 decreased by 2.04% and 9.93% respectively. As ApacheBench is ran on stand-alone server, the Slowloris DOS and DDOS couldn’t influence the NIC on the measurement server, therefore the reduction of the transfer rate of ApacheBench is influenced by VM2’s performance.

71

6 CONCLUSION This thesis has provided statistical and visual analysis of the Slow HTTP DOS attacks, also this thesis has provided a visual and statistical analysis of the impact of the Slow header (Slowloris) attacks in DOS and DDOS architecture on VMs, and we analyzed the direct impact of the attacks on the victim VM and indirect impact of the attack on the neighbor VM.

6.1 Direct impact of the Slow header DOS and DDOS The result of the CPU usage, memory usage and network load measurement on the victim VM that was experiencing the Slowloris DOS and DDOS shows that the HTTP Slow header attacks have influence on the targeted web server resource usage. If this attack is lunched by a single machine, it increased the memory usage of the victim machine by 24.44% and CPU usage by 2.71%. When the attack is lunched in DDOS mode CPU usage increased 38.78%, which is comparable to effect of the flooding DOS, and memory usage increased by 32.63%. While Slowloris attack have a high negative impact on the webserver resource usage if the attacker use DDOS method. This attack is subtly and hard to detect by firewalls. As our experiment shows that we had a successful simultaneous Slowloris DDOS attack by seventeen virtual machines from Google cloud platform and Microsoft azure, even without using VPN connection to hide the malicious traffic the attack was successful and went undetected. This experiment shows that these cloud platforms don’t have a mechanism to prevent these attacks to be lunched from their IaaS.

6.2 Indirect impact of Slow header DOS and DDOS The results of the CPU usage of the neighbor VM showed the Slowloris DOS and DDOS don’t have significant impact on the CPU usage of the neighbor VM but the memory usage has decreased by 87.8 KB (0.19%) and 117KB.8 KB (0.25%) during the Slowloris DOS and DDOS respectively. During the Slowloris DOS and DDOS the network input increased by 12% and 54% respectively, and network output load increased by 5.75% and 5.99%. Considering the result of the network load measurement we can conclude that the Slowloris DOS and DDOS can increase the network load of the neighbor VM indirectly. According to our ApacheBench results, the average time per request of the VM2’s web server during DOS and DDOS increased by 0.06 ms (2.09%) and 0.33 ms (11%) while the ApacheBench transfer rate decreased by 2.93 KB/sec (2.04%) and 14.29 KB/sec (9.93%) during Slowloris DOS and DDOS respectively. Considering the statics that measuring tests provides we can conclude that Slowloris DOS and DDOS on one VM in VirtualBox has negative impacts on the neighbor VM web server performance.

6.3 Future work We ran the HTTP Slow header attacks against a VM on a Virtual Box which is a hypervisor type 2, so there is the native OS between the hypervisor and hardware. Considering testing the impact of the Slow HTTP attacks on a hypervisor type1 such as Microsoft Hyper-V, KVM or VMware ESXi which are directly installed on top of the hardware, could be considered as a future work.

72

REFERENCES [1] cloud security Alliance, “Cloud Computing Top Threats in 2016 The Treacherous 12,”

Cloud Secur. alliance, no. February, pp. 1–35, 2016. [2] JON RUSSELL, “Hong Kong Group Battles Huge DDoS Attack - The Next Web,” 2014.

[Online]. Available: https://thenextweb.com/asia/2014/06/20/cloudflare-hong-kong-democracy-movement-battling-one-largest-ddos-attacks-history/#.tnw_NIdwMQei. [Accessed: 26-Apr-2017].

[3] B. B. Gupta and O. P. Badve, “Taxonomy of DoS and DDoS attacks and desirable defense mechanism in a Cloud computing environment,” Neural Comput. Appl., pp. 1–28, 2016.

[4] M. Masdari and M. Jalali, “A survey and taxonomy of DoS attacks in cloud computing,” Security and Communication Networks, vol. 9, no. 16. pp. 3724–3751, 2016.

[5] Arbor Networks, “Worldwide Infrastructure Security Report,” vol. IX, pp. 1–83, 2014. [6] S. Subashini and V. Kavitha, “A survey on security issues in service delivery models of

cloud computing,” J. Netw. Comput. App., vol. 34, no. 1, pp. 1–11, 2011. [7] Microsoft, “What is cloud computing?,” micfosoft. [Online]. Available:

https://azure.microsoft.com/en-us/overview/what-is-cloud-computing/. [Accessed: 26-Apr-2017].

[8] “The Impact of a Data Breach Can Be Minimized Through Encryption,” 2014. [Online]. Available: https://securityintelligence.com/the-impact-of-a-data-breach-can-be-minimized-through-encryption/. [Accessed: 30-Mar-2017].

[9] Iso.org, “Guidance on outsourcing,” 2014. [Online]. Available: https://www.iso.org/obp/ui/#iso:std:56269. [Accessed: 01-Apr-2017].

[10] C. Modi, D. Patel, B. Borisaniya, H. Patel, A. Patel, and M. Rajarajan, “A survey of intrusion detection techniques in Cloud,” J. Netw. Comput. Appl., vol. 36, no. 1, pp. 42–57, 2013.

[11] P. Ducklin, “The VENOM “virtual machine escape,” 2015. [Online]. Available: https://nakedsecurity.sophos.com/2015/05/14/the-venom-virtual-machine-escape-bug-what-you-need-to-know/. [Accessed: 01-Apr-2017].

[12] B. B. Gupta and O. P. Badve, “Taxonomy of DoS and DDoS attacks and desirable defense mechanism in a Cloud computing environment,” Neural Computing and Applications. pp. 1–28, 2016.

[13] A. L. CARLSSON, A. E. DURAVKIN, “ANALYSIS OF REALIZATION AND METHOD OF DETECTING LOW-INTENSITY HTTP-ATTACKS . PART 2 . METHOD OF DETECTING SLOW HTTP ATTACKS,” http://pt.journal.kh.ua/, vol. 1, pp. 96–100, 2014.

[14] N. Tripathi, N. Hubballi, and Y. Singh, “How Secure are Web Servers? An Empirical Study of Slow HTTP DoS Attacks and Detection,” 2016 11th Int. Conf. Availability, Reliab. Secur., pp. 454–463, 2016.

[15] E. Alomari, S. Manickam, B. B. Gupta, S. Karuppayah, and R. Alfaris, “Botnet-based Distributed Denial of Service (DDoS) Attacks on Web Servers: Classification and Art,” Int. J. Comput. Appl., vol. 49, no. 7, pp. 24–32, 2012.

[16] David Gilbert, “Feedly Knocked Offline by DDoS Attack Following Evernote and Deezer

73

Attacks,” 2014. [Online]. Available: http://www.ibtimes.co.uk/feedly-knocked-offline-by-ddos-attack-following-evernote-deezer-attacks-1452237. [Accessed: 26-Apr-2017].

[17] P. Revathi, “Flow and rank correlation based detection against Distributed Reflection Denial of Service attack,” 2014 Int. Conf. Recent Trends Inf. Technol., pp. 1–6, 2014.

[18] J. Yeh, H. Hsiao, and A. Pang, “Migrant Attack: A Multi-resource DoS Attack on Cloud Virtual Machine Migration Schemes,” Inf. Secur. (AsiaJCIS), 2016.

[19] S. Alarifi and S. D. Wolthusen, “Mitigation of cloud-internal denial of service attacks,” Proc. - IEEE 8th Int. Symp. Serv. Oriented Syst. Eng. SOSE 2014, pp. 478–483, 2014.

[20] F. Abazari, “Exploring the Effects of Virtual Machine Placement on the Transmission of Infections in Cloud,” pp. 278–282, 2014.

[21] K. Anusha, N. Tulasiram, and S. B. S. Mary, “Detection of economic denial of sustainability using time spent on a web page in cloud,” 2013 IEEE Int. Conf. Cloud Comput. Emerg. Mark. CCEM 2013, 2013.

[22] F. Palmieri, S. Ricciardi, U. Fiore, M. Ficco, and A. Castiglione, “Energy-oriented denial of service attacks: an emerging menace for large cloud infrastructures,” J. Supercomput., vol. 71, no. 5, pp. 1620–1641, 2015.

[23] T. Siva, E. S. P. Krishna, S. Vidyanikethan, and C. Dist, “Controlling various network based ADoS Attacks in cloud computing environment : By Using Port Hopping Technique,” vol. 4, no. May, pp. 2099–2104, 2013.

[24] David Holmes, “Mitigating DDoS Attacks with F5 Technology,” 2013. [Online]. Available: https://f5.com/resources/white-papers/mitigating-ddos-attacks-with-f5-technology. [Accessed: 26-Apr-2017].

[25] Ws-attacks.org, “XML External Entity DOS - WS-Attacks,” Ws-attacks.org, 2015. [Online]. Available: http://www.ws-attacks.org/XML_External_Entity_DOS. [Accessed: 26-Apr-2017].

[26] “What is BPEL (Business Process Execution Language)? - Definition from WhatIs.com.” [Online]. Available: http://searchmicroservices.techtarget.com/definition/BPEL-Business-Process-Execution-Language. [Accessed: 26-Apr-2017].

[27] WS-Attacks, “BPEL Instantiation Flooding - WS-Attacks,” 2015. [Online]. Available: http://www.ws-attacks.org/BPEL_Instantiation_Flooding. [Accessed: 26-Apr-2017].

[28] Ws-attacks.org, “BPEL Indirect Flooding - WS-Attacks,” 2015. [Online]. Available: http://www.ws-attacks.org/BPEL_Indirect_Flooding. [Accessed: 26-Apr-2017].

[29] C. Mainka, J. Somorovsky, and J. Schwenk, “Penetration Testing Tool for Web Services Security,” 2012 IEEE Eighth World Congr. Serv., pp. 163–170, 2012.

[30] A. Chonka and J. Abawajy, “Detecting and mitigating HX-DoS attacks against cloud web services,” Proc. 2012 15th Int. Conf. Network-Based Inf. Syst. NBIS 2012, no. Xml, pp. 429–434, 2012.

[31] T. R. Sree and S. M. S. Bhanu, “HADM: detection of HTTP GET flooding attacks by using Analytical hierarchical process and Dempster-Shafer theory with MapReduce,” Secur. Commun. Networks, vol. 9, no. 17, pp. 4341–4357, Nov. 2016.

[32] “Microsoft IIS Malformed HTTP HOST Header Field Denial Of Service Vulnerability - Threat Encyclopedia - Trend Micro USA,” 2011. [Online]. Available: https://www.trendmicro.com/vinfo/us/threat-encyclopedia/vulnerability/515/microsoft-iis-malformed-http-host-header-field-denial-of-service-vulnerability. [Accessed: 26-Apr-

74

2017]. [33] S. Shafieian, M. Zulkernine, and A. Haque, “CloudZombie: Launching and detecting slow-

read distributed denial of service attacks from the Cloud,” Proc. - 15th IEEE Int. Conf. Comput. Inf. Technol. CIT 2015, 14th IEEE Int. Conf. Ubiquitous Comput. Commun. IUCC 2015, 13th IEEE Int. Conf. Dependable, Auton. Se, pp. 1733–1740, 2015.

[34] T. Hirakawa, K. Ogura, B. B. Bista, and T. Takata, “Slow HTTP DoS A Defense Method against Distributed Slow HTTP DoS Attack,” 2016.

[35] F. R, I. UC, and W3C/MIT, “Hypertext Transfer Protocol -- HTTP/1.1,” 1999. [Online]. Available: https://www.ietf.org/rfc/rfc2616.txt. [Accessed: 26-Apr-2017].

[36] David Senecal, “Slow DoS on the Rise - The Akamai Blog,” 2013. [Online]. Available: https://blogs.akamai.com/2013/09/slow-dos-on-the-rise.html. [Accessed: 26-Apr-2017].

[37] “OWASP HTTP Post Tool - OWASP.” [Online]. Available: https://www.owasp.org/index.php/OWASP_HTTP_Post_Tool. [Accessed: 17-May-2017].

[38] Sergey Shekyan, “Are you ready for slow reading? – Network Security Blog | Qualys, Inc.,” 2012. [Online]. Available: https://blog.qualys.com/securitylabs/2012/01/05/slow-read. [Accessed: 26-Apr-2017].

[39] “ab - Apache HTTP server benchmarking tool,” Apache. . [40] Sergey Shekyan, “slowhttptest,” 2016. [Online]. Available:

https://github.com/shekyan/slowhttptest/wiki. [Accessed: 14-May-2017]. [41] “DAG: Dstat: Versatile resource statistics tool.” [Online]. Available:

http://dag.wiee.rs/home-made/dstat/. [Accessed: 14-May-2017]. [42] “MobaXterm free Xserver and tabbed SSH client for Windows.” [Online]. Available:

http://mobaxterm.mobatek.net/. [Accessed: 14-May-2017].

an investigation of the impact of the slow http dos and ...1117240/fulltext02.pdf · denial of...

Documents