Domain-Driven Security’s take on Denial-of-Service …945831/FULLTEXT01.pdfstate-of-the art...

IN DEGREE PROJECT COMPUTER SCIENCE AND ENGINEERING,SECOND CYCLE, 30 CREDITS

, STOCKHOLM SWEDEN 2016

Domain-Driven Security’s take on Denial-of-Service (DoS) Attacks

JOHAN ARNÖR

KTH ROYAL INSTITUTE OF TECHNOLOGYSCHOOL OF COMPUTER SCIENCE AND COMMUNICATION

Domain-Driven Security’s take on

Denial-of-Service (DoS) Attacks

JOHAN ARNÖ[email protected]

Master’s Thesis at CSC and Omegapoint ABKTH Supervisor: Olov Engwall

Company Supervisor: Daniel DeogunExaminer: Patric Jensfelt

June 16, 2016

mailto:[email protected]

Abstract

Many companies and organisations today su�er from Denial-of-Service (DoS) attacks, which can have direct and indirecteconomical consequences. This thesis tackles this problemwith a novel approach by utilising domain specific beha-viour and knowledge. The goal is to distinguish maliciousattacks from legitimate usage and to alter overall systembehaviour at the event of a DoS attack. Distributed DoSattacks (DDoS) are examined as well as a category sugges-ted in this thesis, namely Domain DoS attacks.

A simple e-commerce system is developed based on theprinciples of Domain-Driven Design in order to test thegiven approach. Five examples of DoS attacks are presentedand tested towards the system. The results indicate thatutilising domain behaviour is a suitable approach in orderto mitigate DoS attacks, but it requires deep integrationwith the application itself.

Referat

Domändriven säkerhet som skydd mot

Denial-of-Service-attacker

Många företag och organisationer lider idag av Denial-of-Service-attacker (DoS-attacker), som kan få direkta ochindirekta ekonomiska konsekvenser. Denna avhandling sernytänkande på detta problem genom att dra nytta av do-mänspecifikt beteende och kunskap. Målet är att skilja skad-liga attacker från legitimt användande och att ändra syste-mets beteende i händelse av en DoS-attack. DistribueradeDoS-attacker (DDoS) undersöks så väl som en kategori fö-reslagen i denna avhandling, kallad Domän DoS-attacker.

Ett enkelt e-handelssystem utvecklas baserat på prin-ciper från domändriven design i syfte att testa den givnatesen. Fem exempel av DoS-attacker är presenterade ochtestade gentemot systemet. Resultaten indikerar att utnytt-jandet av domänbeteende är ett lämpligt tillvägagångssättför att avvärja DoS-attacker, men att det kräver djup in-tegration med applikationen.

Contents

1 Introduction 1

1.1 Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.1.1 Domain Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.1.2 Domain Behaviour . . . . . . . . . . . . . . . . . . . . . . . . 2

1.2 Problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.3 Aim . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.4 Delimitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.5 Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.6 Collaboration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.7 Societal E�ects and Environmental Concerns . . . . . . . . . . . . . 3

2 Background 5

2.1 DDoS Attacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.1.1 Targets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.1.2 Attackers and Motives . . . . . . . . . . . . . . . . . . . . . . 62.1.3 Types of Attacks . . . . . . . . . . . . . . . . . . . . . . . . . 72.1.4 Mitigation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.2 Domain DoS Attacks . . . . . . . . . . . . . . . . . . . . . . . . . . . 112.3 Domain-Driven Design . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.3.1 Bounded Contexts . . . . . . . . . . . . . . . . . . . . . . . . 122.3.2 Domain Events . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.4 Domain-Driven Security . . . . . . . . . . . . . . . . . . . . . . . . . 13

3 Method 15

3.1 E-Commerce Application . . . . . . . . . . . . . . . . . . . . . . . . 153.2 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

3.2.1 System Design . . . . . . . . . . . . . . . . . . . . . . . . . . 153.2.2 Communication . . . . . . . . . . . . . . . . . . . . . . . . . . 163.2.3 Data Storage . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3.3 Attack Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173.3.1 DDoS Attacks . . . . . . . . . . . . . . . . . . . . . . . . . . 173.3.2 Domain DoS Attacks . . . . . . . . . . . . . . . . . . . . . . . 17

3.4 Mitigation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

3.4.1 Event Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . 183.4.2 Control Mechanisms . . . . . . . . . . . . . . . . . . . . . . . 183.4.3 Mitigating the Attacks . . . . . . . . . . . . . . . . . . . . . . 19

4 Evaluation 21

4.1 Usage Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214.1.1 Legitimate Tra�c . . . . . . . . . . . . . . . . . . . . . . . . 214.1.2 Malicious Tra�c . . . . . . . . . . . . . . . . . . . . . . . . . 224.1.3 Legitimate Data . . . . . . . . . . . . . . . . . . . . . . . . . 22

4.2 Infrastructure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

5 Results 23

5.1 DDoS Attacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235.1.1 Normal Load . . . . . . . . . . . . . . . . . . . . . . . . . . . 245.1.2 Create Account Attack . . . . . . . . . . . . . . . . . . . . . . 245.1.3 Get Item Attack . . . . . . . . . . . . . . . . . . . . . . . . . 275.1.4 Search Attack . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

5.2 Domain DoS Attacks . . . . . . . . . . . . . . . . . . . . . . . . . . . 325.2.1 Duplicate Item Attack . . . . . . . . . . . . . . . . . . . . . . 325.2.2 Shopping Basket Attack . . . . . . . . . . . . . . . . . . . . . 33

5.3 Key Takeaways . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

6 Conclusion 37

6.1 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 376.2 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

Bibliography 41

Appendices 43

A Complete DDoS Results 45

A.1 Normal Load . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45A.2 Create Account Attack . . . . . . . . . . . . . . . . . . . . . . . . . . 47A.3 Get Item Attack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49A.4 Search Attack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

Chapter 1

Introduction

This chapter intends to briefly introduce the reader to the problem and lay outthe overall aim for this thesis project. Delimitations and methodology will also bediscussed.

To keep a system secure, confidentiality, integrity and availability must be up-held. Denial-of-Service (DoS) attacks aim to disrupt the availability of a system,often by consuming all available resources thus making it unable to serve legitimaterequests. A subset of DoS attacks, Distributed Denial-of-Service (DDoS) attacks,aims to achieve just this by flooding the system with a large amount of requests.Even though the concept itself is old, the number of DDoS attacks doubled in 2015compared to 2014 [Ver15b], making the problem more relevant than ever. Banks,online retailers, gambling website and service providers are all commonly targeted[Man11].

Denial-of-Service attacks does not necessarily have to consume infrastructureresources, which is often the case with DDoS attacks. Instead, the business itselfcan be exploited in a number of ways. E.g. an e-commerce site like eBay mightbe attacked by adding a large amount of fake items. If eBay’s customers cannotdistinguish between legitimate and fake items, the Denial-of-Service attack is to beregarded as successful.

1.1 Definitions

1.1.1 Domain Layer

In order to keep a clear separation of concerns in a software application, the LayersArchitecture [Bus+96] is often used. Vernon [Ver13] extends this model to incor-porate the so-called Domain Layer, i.e. the layer where business logic resides. Anillustration can be seen in Figure 1.1.

1

CHAPTER 1. INTRODUCTION

Figure 1.1. Vernon’s view of the Layers Architecture.

1.1.2 Domain Behaviour

In this thesis, domain behaviour is defined as how the business itself is behaving.This could be utilised to answer the following questions;

• What is happening within my business?

• How do I want my business to act?

1.2 Problem

The problem this thesis intends to explore is as follows;

Is it possible to utilise domain behaviour to distinguish maliciousattacks from legitimate usage and to alter overall system behaviour atthe event of a DoS attack?

The problem is twofolded. The first part of the question concerns the classicalDoS problem to identify the request as malicious or legitimate and block it ac-cordingly. The second part intends to investigate if altering system behaviour inthe event of a DoS attack is a suitable approach. The domain behaviour is whatDomain-Driven Security utilise in order to secure software. This thesis intends toexplore if this concept could be expanded to encapsulate DoS attacks as well.

1.3 Aim

The overall aim of this thesis project is to find a complement to existing mitigationtechniques. The result would be useful for small as well as large organisations thatseek to improve their resilience against DoS attacks.

2

1.4. DELIMITATIONS

1.4 Delimitations

DoS is a broad topic and delimitations are therefore needed. So called Layer 3 &4 attacks will be disregarded as they do not act in the application layer (see sec-tion 2.1.3) and the domain behaviour can therefore not be analysed. Furthermore,volumetric attacks which consume all available bandwidth will also be disregarded,since mitigation will be performed in the application itself.

1.5 Methodology

To be able to utilise domain behaviour a simple but adequate web application wasdeveloped based on the principles of Domain-Driven Design (DDD). DDD is a soft-ware development approach created by Eric Evans [Eva03] that heavily emphasisesbusiness-centric development (see section 2.3). The application simulates a publice-commerce site (much like Blocket1) where users can put their items up for sale.

1.6 Collaboration

The mentioned e-commerce application was developed in cooperation with anotherKTH student, Jonas Stendahl, who also wrote his master thesis at Omegapoint AB.Although we worked towards the same code base, our contributions to this di�eredgreatly. I focused my e�orts on the event based communication and analysis asopposed to Jonas who focused on data handling and application state.

1.7 Societal E�ects and Environmental Concerns

The goal of this thesis is to examine if web applications can be secured from DoSattacks. As many companies and organizations su�er from such attacks (see chapter2), the results of this thesis could potentially help a�ected parties to strengthen theirresilience against DoS attacks.

Environmental concerns however, are not applicable to this thesis and will there-fore not be discussed.

1http://www.blocket.se

3

http://www.blocket.se

Chapter 2

Background

This chapter introduces theories and concepts that are relevant in order to under-stand the problem this thesis intends to examine. This includes current DoS threats,state-of-the art mitigation techniques and an introduction to Domain-Driven Design.

2.1 DDoS Attacks

A Denial-of-Service (DoS) attack is a malicious attempt to disrupt a service andthus denying access to it for its legitimate users. A Distributed Denial-of-Service(DDoS) attack is a subset of the DoS attack, which as the name suggests, is carriedout in a distributed fashion. To achieve this, attackers usually employ what is calleda botnet (see section 2.1.3) to carry out the attack [Man15].

2.1.1 Targets

Gambling and betting sites have for long been targeted by DDoS attacks [Man15]. Atypical example would be a betting site that is attacked during a major sport event,resulting in a direct revenue loss for the business. The attacker would then requesta ransom in order to cease with the attack. Even though such attacks are still com-mon, a new kind of organisations have emerged as common targets. E.g. Akamai’sState of the Internet report shows that 25% o� all attacks were directed towardsSoftware & Technology business providing Software-as-a-Service (SaaS) solutionsand other cloud based services [Aka15]. Furthermore, Verisign reports that finan-cial services and the public sector received 15% and 13% respectively of the totalnumber of DDoS attacks [Ver15a]. However, it must be stressed that the above dataonly reflects the customer base of the specific DDoS mitigation provider.

Governments are also commonly targeted by DDoS attacks. One of the firstlarge scale attacks was aimed towards Estonia in 2007. The event that initiatedthe DDoS attacks was the removal of a Soviet built war memorial, which by manyEstonians were seen as a symbol of oppression [Dav07]. Jaak Aaviksoo, Estonia’sdefence minister at the time explains in Wired Magazine:

5

CHAPTER 2. BACKGROUND

The attacks were aimed at the essential electronic infrastructure ...All major commercial banks, telcos, media outlets, and name servers— the phone books of the Internet — felt the impact, and this a�ectedthe majority of the Estonian population. This was the first time that abotnet threatened the national security of an entire nation.

2.1.2 Attackers and Motives

In a survey conducted by Arbor Networks [Arb16], organisations were asked aboutcommon motives for DDoS attacks against their services. The most common motivewas criminals demonstrating DDoS attack capabilities, closely followed by online-gaming related motives. Extortion attempts, vandalism and business rivalry werealso seen as common reasons.

Online activism - or hacktivism - has recently seen an upswing in media, withgroups such as Anonymous, LulzSec, and Lizard Squad as front figures. Thesegroups make it easy for people with limited technical ability to carry out or par-ticipate in a DDoS attack. E.g. Anonymous encouraged its followers to downloadtheir tool, the Low Orbit Ion Cannon (LOIC), to actively participate in a DDoSattack against Sony. The tool however, did not try to spoof the user’s IP address,resulting in jail time for some participants [Man15].

However, despite these groups strong medial presence, some argue that thereal threat most organisations face is blackmailing carried out by cyber-criminals[Man11]. A particular group of hackers, DD4BC (DDoS for Bitcoin), has had astrong presence in the extortion scene since 2014 [Aka15]. The approach is simple.In the beginning of an attack, the targeted business receives an email demanding aransom of up to 100 bitcoins (roughly $40 000). If the ransom is not paid the attacktra�c is increased to apply further pressure [Arb16]. Many organisations end uppaying the ransom and due to Bitcoin’s nature, tracing the transactions turns outto be very di�cult. However, adequate protection against smaller DDoS attacksusually turns out to be cheaper than paying the ransom [Man15].

Another increasing category of attackers are vandals with no direct monetarygoal. In a recent DDoS attack against the Greater Manchester Police an individualtook full responsibility but presented no demand for ransom. With poor English,possibly intentional, the attacker stated that the attack was just for fun [Mar15].

I do not think for me is a way to show to them as I am not sure itis a way to have fun.

Long has it been suspected that governments themselves carry out large scaleDDoS attacks. During 2015 however, clear evidence was presented that stated thatthe Chinese government was involved in the attack against GitHub and Great-Fire.org - an organisation that help people evade the so-called "Great Firewall" ofChina [Man15]. The attack against GitHub, which mirrors some of GreatFire.org’smaterial, was carried out by injecting JavaScript code in the result from the search

6

2.1. DDOS ATTACKS

engine Baidu via an intermediate server. The infected search result then exploitsunknowing users’ computer to route tra�c to GitHub and GreatFire.org. The at-tack was traced and found to originate from the backbone of China Unicom, thesame organisation which run the Great Firewall [Gra15].

2.1.3 Types of Attacks

DDoS attacks can generally be categorised into Layer 3 & 4 attacks (infrastructurelayer attacks) and Layer 7 attacks (application layer attacks), where the layers referto the OSI model [Bor+14]. An illustration can be seen in Figure 2.1.

Figure 2.1. An overview of the OSI Model and the corresponding DDoS attacks.

Layer 3 & 4 attacks tend to aim to flood the target with requests, thus consum-ing all available bandwidth. Layer 7 attacks on the other hand tend to exploit aspecific, demanding resource in the targeted service and thus consuming all avail-able resources in the server. Since Layer 7 attacks act in the application layer, theyresemble legitimate usage and can therefore be harder to mitigate [Man11]. Anotherunique feature for these attacks is that just a single machine generating tra�c ata low rate can carry out a successful attack [Arb16]. Layer 3 & 4 attacks are how-ever more common than Layer 7 attacks. Recent reports from Arbor Networks andAkamai indicate that Layer 7 attacks represent between 5% and 18% of all DDoSattacks [Arb16; Aka15].

The classical DDoS attack has usually been carried out via botnets, which areuseful for both Layer 3 & 4 attacks and Layer 7 attacks. The attacker infectsthousands of unknowing users’ PCs with malware and thus taking control of them.The PCs are then instructed by the attacker to send large amounts of tra�c to aspecific system at a given moment in order to disrupt the service [Man15].

Today however, many attacks also utilise amplification and reflection techniques.That is, using resources that you do not have explicit control over. E.g. the attacker

7


sends a request, with a spoofed IP address, to a vulnerable service on a legitimateserver. The server then replies with a larger message to the intended target, andnot to the attacker due to the spoofed IP address [Man15]. By exploiting multipleservers, a single attacker can, with limited resources, stage a large scale DDoSattack.

Layer 3 & 4 Attacks

SYN floods and ICMP floods are two common examples of a Layer 3 & 4 attack.The SYN flood attack exploits the so-called three-way TCP handshake. The clientsends a SYN packet to the server, which in turn responds with a SYN/ACK packet.To complete the handshake, an ACK packet is required from the client, but bywithholding this, the attacker is able to occupy resources in the system [Man11].The attack can succeed by either overwhelming the server or consuming all availablebandwidth. The ICMP flood attack acts in an even simpler way. An ICMP Echorequest (ping) is sent to the targeted server, which often replies with its status.With a large enough botnet this attack can easily clog the victim’s bandwidth.

Another common attack utilises the Network Time Protocol (NTP) which viaamplification techniques was responsible for several large scale attacks in 2014[Czy+14]. The attack exploited the NTP monlist command, which when quer-ied, returns a list of last 600 clients of the timeserver. Since UDP is used, the IPaddress can easily be spoofed and the list is therefore returned to the intended tar-get. With a theoretical 206x amplification, this attack can generate large amountsof tra�c even if it originates from a small network [Pri16].

Layer 7 Attacks

A common type of a Layer 7 attack is the HTTP GET flood, where the sheervolume of requests brings down the targeted server. The previously mentioned at-tack against GitHub is a perfect example of such an attack. The injected JavaScriptcode sent multiple page requests to GitHub’s servers and thus overwhelming the sys-tem when run by millions of Baidu users.

Another HTTP GET flood attack utilises a vulnerable pingback feature in Word-Press’s XML-RPC interface. The attacker can send a POST request to the XML-RPC interface on a WordPress site and in turn trigger a GET request from thatsite to a target website [Cid14]. Even if no significant amplification is achieved, theattacker can stay hidden and the attack will be harder to mitigate since it makesuse of legitimate servers.

Layer 7 attacks can also exploit resource heavy operations on the server sidewith carefully crafted HTTP requests [Man11]. These operations can be e.g. searchqueries, file downloads, PDF generations etc. If a specific function within a systemis designed with only a few users in mind, it will not be hard for an attacker tobring down the system.

8

2.1. DDOS ATTACKS

Attacks such as Slowloris and R-U-Dead-Yet (RUDY) are examples of slowHTTP attacks. The aim for these attacks is to exhaust the server’s pool of openHTTP connections. Slowloris does this by sending multiple HTTP GET requests,each with an incomplete header [Dam+12]. Since HTTP protocol is designed towait for incomplete requests to complete, this attack will eventually fill up all avail-able connections. RUDY works in a similar manner, but exploits the POST requestinstead. The header of the request is complete but since it is a POST request,the server waits for the client to complete the body. The attacker can then sendjust a byte at a time, making the connection long lasting [Dam+12]. With enoughrequests, the server’s connection pool will eventually be exhausted. With this lowamount of data, it is easy to hide behind proxies and anonymous networks such asTOR to cover your tracks [Man11].

2.1.4 Mitigation

A number of di�erent techniques exists for mitigating Layer 7 DDoS attacks. Asimple approach is to inspect only the request itself without considering previousbehaviour. The IP can, even though it must be valid, be part of a known botnetnetwork and the request can therefore be blocked. Examination of the HTTPheaders can also give further information. For example, a request can safely bediscarded when the user agent header implies that the request is from the Googlesearch bot, but the IP does not match Google’s network [Cas14].

Demographic profiling is a technique which work under the assumption that theattack tra�c is coming from another geographic location than legitimate requests. Abotnet usually operates from IP addresses originating from the same location, sincea breached network often result in many infected PCs [BD14]. This makes it possibleto filter out the attack tra�c, since the legitimate tra�c is usually distributed moreevenly. Also, when a lot of requests are originating from e.g. Russia to a Swedishwebsite, the suspicious tra�c can be blocked with few false negatives. However, asseen with the Wordpress attack, malicious request can come from legitimate users,making this approach useless.

By analysing multiple requests from a user, a statistical profile can be made.This is what the ConnectionScore scheme from Beitollahi and Deconinck proposes[BD14]. A reference profile is built up by analysing legitimate requests and in theevent of a DDoS attack, the requests are compared with the reference profile and areassigned a score. If the score is below a certain threshold, the request is dismissed.Below are some of the attributes that are evaluated to form the reference profile.

• Request rate - the number of requests from a user during a specified timeinterval.

• Download rate - the number of bytes downloaded by a user during a specifiedtime interval.

9


• Uptime - the time between initialisation and cancellation of communicationbetween a user and the server.

• Downtime - the time between cancellation and initialisation of communicationbetween a user and the server.

• Repetitive pages - the case when a user repeatedly accesses the same page.

• Page popularity - a request for a popular page will lead to a higher score thanrarely accessed pages.

• Hyperlink fraction click - what fraction of all the links are clicked by a user.

Another approach to mitigate malicious tra�c is by trying to verify the useritself. Many attackers do not utilise browsers due to their resource heavy nature,but instead thinner clients specifically developed for DDoS attacks. An attempt toblock such botnets can be to send cookies to the user or run a JavaScript challenge[Miu+13]. Many clients do not have the support to save cookies nor a JavaScriptengine to execute the challenge. According to Imperva, a commercial DDoS mit-igation provider, 74% of all malicious bots support neither cookies nor JavaScript,24.9% support only cookies and 1.1% support both cookies and JavaScript [Imp15].A large portion of malicious bots can therefore be hindered by utilising JavaScriptchallenges. However, the integration of a lightweight JavaScript engine in the botclient have proven to be feasible [Miu+13].

An e�ective way to distinguish malicious bots from legitimate usage is a so-called CAPTCHA challenge. In such a challenge, distorted text is displayed to theuser as seen in Figure 2.2. If the correct input is supplied, the request is carriedout.

Figure 2.2. Example of a CAPTCHA challenge. Source: http://www.captcha.net/

However, many reports show that CAPTCHA challenges are irritating to users,and the usage of such puzzles should be kept to a minimum [BD14]. Therefore,CAPTCHA is often used as a last resort.

One of the more challenging tasks is to distinguish DDoS attacks from so-calledflash crowds. A flash crowd is a sudden rise of legitimate tra�c due to specialevents such as breaking news or ticket release. A flash crowd could therefore easily

10

http://www.captcha.net/

2.2. DOMAIN DOS ATTACKS

be mistaken for a DDoS attack. [Tha+11] proposes that a distinction could bemade by analysing the arrival patterns of packages. Predictable patterns, which theauthors argue botnets use, include constant attack rate, increasing attack rate andperiodical attack rate. These patterns are identified with high accuracy. However,a small change in the bot application could introduce randomised attack patterns,which evade this mitigation technique.

Another approach to solve this problem is suggested by [Li+09]. The authorsleverage three main characteristics. Firstly, the access intent of flash crowds is usu-ally connected to special events whereas DDoS attacks are more random. Secondly,the IP addresses of legitimate users are more disperse than those used by botnets.Thirdly, the transition of tra�c volume is slower for flash crowds than for DDoSattacks. In addition to this [BD14] suggests that uptime and targeted resourcesdi�er between flash crowds and DDoS attacks. The time a user remains on a site isusually short since it will leave once the news article is read, the ticket purchasedetc. Also, during a flash crowd, users tend to access a single resource whereas aDDoS attack might access resources randomly.

2.2 Domain DoS Attacks

Another type of Denial-of-Service attack can be exemplified by recent events sur-rounding the ride-sharing company Uber. Uber, which o�er taxi-like services viaa smartphone app, was during 2014 accused of ordering and cancelling over 5000rides from Lyft, a competing ride-sharing company [Fin14]. Lyft stated that 177Uber employees registered accounts with fake names in order to book and cancelthe rides. Erica Fink, a writer from CNN explains:

Bogus requests decrease Lyft drivers’ availability, which could sendusers to Uber instead.

The false bookings are thus a Denial-of-Service attack since it hinders legitimateusage. However, unlike DDoS attacks which aim to bring down the supportinginfrastructure, these attacks exploit the business, or domain, itself.

As recent as March 2016 Uber was once again involved in a similar case. Thistime however, the company was suing a competitor, Ola, for booking over 400 000false rides over a six month period [Rai16]. The problem with these attacks is theseemingly legitimate nature of the requests. The tra�c towards the servers doesnot increase significantly nor are there any signs that the request itself is malicious.

Due to lack of existing research into the topic, the attacks will further on bereferred to as Domain DoS attacks.

2.3 Domain-Driven Design

Domain-Driven Design (DDD), is a software development approach aimed to dimin-ish the distance between the business itself, or Domain, and the code that supports

11


it [Ver13]. A crucial part of DDD is to establish a Ubiquitous Language, that is aset of terms that both developers and business experts have decided to agree uponand exclusively use. As [Ver13] puts it;

There are zero translations between the domain experts, the softwaredevelopers, and the software. That doesn’t mean maybe some few transla-tions. It means zero translations because your team develops a common,shared language that everyone on the team speaks.

Also the code itself is just not an implementation of a high level model, it is theactual model [Ver13].

The design is the code, and the code is the design.

The major goal DDD tries to address is to reduce the complexity often seen in largesoftware projects. It achieves this by employing many di�erent concepts, two ofwhich are explained below.

2.3.1 Bounded Contexts

A Bounded Context is a fundamental concept in Domain-Driven Design. One coulddescribe it as DDDs method to fulfil the mantra "high cohesion, loose coupling" ata high level. Many organisations try to develop a consolidated model for the wholedomain, but as stated by Eric Evans [Eva03], this is a suboptimal approach.

Total unification of the domain model for a large system will not befeasible or cost-e�ective.

Within an organisation, sub domains exist and Bounded Contexts are DDDs wayto model these [Ver13]. It does so to create explicit boundaries between di�erentparts of the organisation. I.e. a company’s finance department should only commu-nicate with the warehouse department through well-defined channels. Furthermore,it eliminates confusion about ambiguous terms such as a customer. The financedepartment can have its own definition of what a customer is that is di�erent fromother departments’ definition [Ver13].

Since Bounded Contexts introduce clear delimitations in the codebase, the subdomains become less coupled. This makes it possible to scale e.g. a customerdomain di�erently from a finance domain.

2.3.2 Domain Events

Domain-Driven Design encourages that communication within and between BoundedContexts is carried out via so-called Domain Events. As Vaughn Vernon [Ver13]puts it.

Use a Domain Event to capture an occurrence of something thathappened in the domain.

12

2.4. DOMAIN-DRIVEN SECURITY

The captured occurrence must be significant for the domain itself in order to beclassified as a Domain Event. An event which is raised when e.g. a user clicks abutton is not to be regarded as a Domain Event, since it belongs to the infrastruc-ture.

A captured occurrence is thereafter published asynchronously to subscribingcounterparts. E.g. when a product is bought in an e-commerce system, a Pro-ductBoughtEvent can be published. The finance system can then subscribe to suchevents and e.g. deduct the balance of a specific user. Domain Events allow thereforefor loose coupling between Bounded Contexts, as well as it requires little change inexisting code when expanding the application [Ver13].

By analysing these Domain Events, one can get a comprehensive view of whatis happening in the domain.

2.4 Domain-Driven Security

Domain-Driven Security (DDS) aims to secure software by using concepts and prin-ciples from Domain-Driven Design, since DDD itself does not deal with such issues.The term was coined in 2009 by Dan Bergh Johnsson and John Wilander, bothconsultants at Omegapoint AB, who argued that injection attacks could be seen asmodelling problems. Data is usually validated close to the user interface, but DDSproposes that the data should be modelled close to the core and any data that doesnot conform to that model should be rejected [Wil09].

This thesis tries to expand the concept Domain-Driven Security, by examininghow Domain-Driven Design can be utilised to mitigate DoS attacks.

13

Chapter 3

Method

This chapter describes the application used for evaluation as well as numerous pos-sible attack scenarios. Furthermore, di�erent mitigation techniques are proposed forDDoS attacks and Domain DoS attacks.

3.1 E-Commerce Application

The application used for evaluating this thesis simulates an e-commerce business.It can be described as a mix between Amazon1 and Blocket2. Individuals are ableto upload an item for sale which in turn others can purchase. A quantity is specifiedalong with each item to indicate how many copies are available for purchase. Attime of purchase, the user puts one or more items in a shopping basket. The itemsare thereafter reserved for 5 minutes to allow the user to complete the purchasewithout interference from other customers. Log in functionality is also present andan account will be required when selling and purchasing items.

3.2 Implementation

3.2.1 System Design

As previously mentioned, the system design will be heavily influenced by Domain-Driven Design. With the description of the system above, two Bounded Contextscan clearly be identified. One where the customer account resides and one where theitems themselves reside, which are named Customer and Marketplace respectively.

In order to be able to scale the Bounded Contexts di�erently, each contextis modelled as its own application and is running on its own server. This pat-tern, where a single application is split up into smaller applications, is called Mi-croservices Architecture, and is a good fit for applications developed with Domain-Driven Design [New15].

1http://www.amazon.com/

2http://www.blocket.se/

15

http://www.amazon.com/

http://www.blocket.se/

CHAPTER 3. METHOD

Figure 3.1 illustrates an overview of the system architecture, including conceptsthat will be explained later. The rectangles represent standalone servers (furtheron referred to as services), and the arrows the communication between them.

Figure 3.1. An overview of the system architecture for the e-commerce application.

3.2.2 Communication

Since the communication is one of the key components when understanding domainbehaviour, it must be carefully designed. Instead of traditional request/responsecommunication, event based communication is employed [New15]. Each service isresponsible for creating and publishing events, as well as listening and acting onevents from other services. All events are passed to a channel on the MessageService, which forwards the events to subscribed services for the specified channel.

E.g. a user creates an account via the Frontend Application. The API Gatewayreceives the request which turns it into an AccountCreationRequested event. It isthereafter sent to the Message Service on the channel Account. The Message Serviceforwards it to the Customer service, since the Customer service subscribes on thechannel Account. The Customer service creates and stores the account and publishesan AccountCreated event, which propagates back to the API Gateway. The userwhich initiated the creation is thereafter notified in the Frontend Application.

This way of communicating enables a detailed analysis of domain behaviour,since all events are passed through the Message Service. This might become abottleneck, but since the Message Service does not contain any state, it should notbe di�cult to scale.

16

3.3. ATTACK SCENARIOS

3.2.3 Data Storage

The storage solution used in both the Customer service and the Marketplace serviceis a so-called Event Store [Ver13]. Instead of constantly modifying a database record,each event which modify the data is saved. When reading an object, each event isfetched and applied to the object in chronological order. E.g if an item is added andlater updated, the Event Store will save two events for this item, an ItemCreatedevent and an ItemUpdated event. When reading that item, the ItemCreated eventwill be applied to an empty item, followed by the ItemUpdated event.

With this strategy, history of data is preserved which allows for a more powerfulanalysis of domain behaviour.

3.3 Attack Scenarios

A number of possible attack scenarios needs to be established in order to designthe DoS mitigation. The scenarios are split into two categories; DDoS attacks andDomain DoS attacks. The former aims to exhaust resources in the server in orderto bring it o�ine. The latter on the other hand aims to degrade some functionalityin the application, while keeping the application as a whole online.

3.3.1 DDoS Attacks

Create Account Attack

A large number of accounts are made in order to overwhelm the system.

Get Item Attack

A large number of reads of a specific item are made in order to overwhelm thesystem, much like a typical HTTP GET attack.

Search Attack

A large number of searches are made in order to overwhelm the system.

3.3.2 Domain DoS Attacks

Duplicate Item Attack

This attack aims to disrupt the practical use of the application by flooding thesystem with duplicates of existing items. An item is fetched from the application andan identical or similar item is thereafter added to the marketplace. A duplicate itemwill confuse the legitimate user and hinder it from using the application e�ectively,thus resulting in a Denial-of-Service.

17

CHAPTER 3. METHOD

Shopping Basket Attack

This attack aims to exploit the fact that an item is reserved for five minutes afterbeing added to a user’s shopping basket. By reserving multiple items by one ormany accounts, the attacker will deny legitimate users the ability to purchase thoseitems.

3.4 Mitigation

3.4.1 Event Analysis

One of the first problems a system is facing during a DoS attack is to actually realisethat an attack is ongoing. This task is delegated to the Event Analyser which canbe seen in Figure 3.1. The Event Analyser subscribes to all channels and is also ableto control actions in the API Gateway, the Customer service and the Marketplaceservice.

When it comes to DDoS attacks, a simple threshold would probably su�ce todetermine if an attack is taking place. E.g. if the Event Analyser registers 500AccountCreationRequested events per second, compared to a normal load of 20,mitigating actions should be taken.

A di�erent kind of anomaly detection is required when dealing with Domain DoSattacks, since these attacks can be carried out with low intensity. E.g. to detectduplicate items, one must check if the specific item is similar to all other items inthe database. This could be done either in real-time or later in batches.

3.4.2 Control Mechanisms

Not only should the Event Analyser detect if a DoS attack is ongoing, but it shouldalso coordinate actions to mitigate it. The Event Analyser does not mitigate theattack on its own, but instead instructs the di�erent services how to behave.

User Validation

When abnormal load exists on the site, user validation could be activated withdomain behaviour in mind. A first attempt could be that only logged in userswould be able to access, otherwise public, parts of the site. If the problem persists,users with none or few purchases could also be blocked.

Rate Limiting

Rate limiting could also be introduced when the system is experiencing abnormalload. E.g. a limit of 10 searches per second could be set for each account, sincea human would probably not go over this limit. The attacker would then need toutilise multiple accounts to attack the site, but with user validation in place, theimpact should not be severe.

18

3.4. MITIGATION

Feature Degradation

Feature degradation could be put into place if high load persists after the abovemechanisms are activated or if they are not applicable. E.g. when a user tries toregister an account, the domain has no knowledge of the user itself. A reasonableaction would then be to turn o� the ability to register new accounts, if that featureis under attack.

Another degradation of a feature would be to modify the result of a search queryduring high load. E.g. if an item is considerably more popular than other items, adefault response containing that particular item would be a reasonable approach toreduce to load on the system.

Data Marking

Data marking is a suitable approach when direct actions cannot be taken due tothe need of deeper analysis. In the case of a Domain DoS attack certain items oraccounts might be marked as malicious, if deviations in the data are noticed. Theaccount could be marked as blocked along with the items associated with it. Ifthis action results in an inaccurate decision, the user will have to contact customerservice to undo the blockage.

3.4.3 Mitigating the Attacks

This section describes the chosen mitigation approach for each attack, based on thetechniques mentioned above.

Create Account Attack

In this attack, only Feature Degradation is used to mitigate the attack. The reasonfor this is because the domain does not know anything about the user, since anaccount is not yet registered. The functionality to create an account is turned o�for 20 seconds if 1000 account creation requests are received during 10 seconds.

Get Item Attack

For this attack, User Validation is used together with Rate Limiting. Feature De-gradation is not utilised since turning o� the ability to read items would render theapplication useless. If 1000 requests are received during 10 seconds, only loggedin users will be let through and a user must wait 500 ms between requests. If theload still persists after two seconds, the application will constrain itself further byonly allowing accounts which are more than one month old and have spent at least10 credits. As with the previous attack, the mitigating actions are active for 20seconds.

19

CHAPTER 3. METHOD

Search Attack

To mitigate this attack, Feature Degradation is used. If 300 search requests arereceived during 10 seconds, a default search response will be given back instead.The default response will be the most sold item during the past 30 days. As withthe previous attacks, the mitigating action is active for 20 seconds.

User Validation and Rate Limiting could also be used to mitigate this attack,but since both techniques are already tested in Get Item Attack, they provide littlenew value.

Duplicate Item Attack

To mitigate this attack, Data Marking is used. The description of each item iscompared to all other items in the database. A simple algorithm is used to findsimilar descriptions; the occurrence of each word is counted and the di�erencebetween the each word is summed and thereafter normalized over the total numberof words. I.e "this is an example" compared to "this is text" would generate thescore ((0 + 0 + 1 + 1) + (0 + 0 + 1))/7 ¥ 0.43. A low score indicates similar textsand in this case, a score lower than 0.15 will result that the item will be marked asa duplicate.

However, in order to not mark the original item as a duplicate the timestampsare checked. Furthermore users which have previously bought items are whitelistedsince those users are trusted by the domain.

Shopping Basket Attack

To mitigate this attack, Feature Degradation and User Validation are used. A useris regarded as malicious if it has let the five minute limit expire for 10 items since itslast purchase. However, the attacker could also utilise multiple accounts to reservethe items. In this case, the mitigation will be performed item-wise. If an item hasbeen reserved for three times in a row without being purchased, future reservationsfor that particular item will be discarded. In both cases, the event store (see section3.2.3) will be of high importance since the full history of reservations are preserved.

20

Chapter 4

Evaluation

This chapter gives the reader a detailed overview of how the evaluation of this thesisis performed. Required third party infrastructure is explained and the simulationstrategy for malicious tra�c and legitimate tra�c is presented.

4.1 Usage Simulation

All usage simulation for DDoS attacks, both malicious and legitimate, will be carriedout through the cloud-based load testing tool Loader.io. A test consists of one ormultiple URLs to which HTTP requests are sent with a specified rate. Each requestis logged and data such as response time, error rate, bandwidth usage, etc. can beobtained after the test is finished.

4.1.1 Legitimate Tra�c

Legitimate usage is simulated by 5 di�erent load tests. This is done to somewhatmimic the versatile behaviour that legitimate tra�c usually displays. The 5 testsare described as follows:

Legitimate Usage 1 simulates new users which first creates an account and there-after puts up an item for sale.

Legitimate Usage 2 simulates anonymous users, i.e. users which are not loggedin, who search for items and view details of an item.

Legitimate Usage 3 simulates the same case as Legitimate Usage 2, but with theexception that the users are logged in with newly created accounts.

Legitimate Usage 4 simulates the same case as Legitimate Usage 2, but with theexception that the users are logged in with older accounts and have spent moneyon the site.

21

http://loader.io

CHAPTER 4. EVALUATION

Legitimate Usage 5 simulates existing users which update contact information, addcredit to their respective account and thereafter purchase an item.

Each test is set to have 600 clients active during a total of 120 seconds, whichLoader.io aims to distribute evenly. Each client performs all actions in a test once.I.e if a test has two actions, e.g. create an account and add an item for sale, a totalof 1200 requests will be made.

4.1.2 Malicious Tra�c

Each attack will be simulated by its own load test. The number of clients might di�erbetween tests, but each attack should make usage of the e-commerce applicationimpractical. The attacks will be run for 120 seconds and are started at the sametime as the legitimate usage tests.

4.1.3 Legitimate Data

For Duplicate Item Attack the database needs to be populated with legitimate items.First 50 items were extracted from Blocket.se and added to the database. Thesewere clearly distinct from one another. Thereafter were one item added twice to thedatabase. Once with a new account and once with an account which had alreadybought an item. The item that was added was very similar to one of the original50 items.

4.2 Infrastructure

Since Loader.io is a cloud-based service, the application must be publicly availableon the internet. To achieve this, the cloud-based hosting service Pivotal CloudFoundry was used. Each microservice is deployed as an independent virtual serverwith its own IP address, RAM, storage etc.

22

https://www.blocket.se/

https://run.pivotal.io/

https://run.pivotal.io/

Chapter 5

Results

In this chapter results of the di�erent DoS attacks will be presented along with itscorresponding mitigation approach, as described in chapter 3.

5.1 DDoS Attacks

For each attack, legitimate tra�c as well as attack tra�c will be run simultaneously.First without DDoS mitigation and thereafter with DDoS mitigation. In order toeliminate influences from one test to another all servers are restarted between eachtest run and populated with default data. Several runs were made for each attack,with little variation between them. To keep the results concise, only one run foreach attack is presented. Variables mentioned in the tables are defined as follows:

• T - The average response time.

• S - The number of successful requests.

• E1 - The number of HTTP 403 Forbidden errors. A 403 error indicates thatthe request has actively been blocked by server in an attempt to mitigate anattack.

• E2 - The number of HTTP 504 Gateway timeout errors. In this case a 504error is returned when the server took more than 5 seconds to process therequest.

• E - The portion of all requests that resulted in an error from the server, i.ethe error rate.

For every attack, all tests for legitimate usage are run, but only sig-

nificant results are presented in this chapter. For full result tables, see

appendix A.

23

CHAPTER 5. RESULTS

5.1.1 Normal Load

A baseline of normal usage is important to establish, in order to measure whatimpact the DDoS attacks have on the application. Table 5.1 shows the aggregatedresults when all legitimate usage tests are run simultaneously. The legitimate usagegenerate low response times and error rates.

Table 5.1. Legitimate usage which should be considered as "normal load".

Scenario T (ms) S E (%)Legitimate Usage 1-5 52 6600 0

5.1.2 Create Account Attack

This attack aims to overwhelm the system by creating a large amount of accounts.The attack consists of 36000 clients distributed over 120 seconds where each clientsends one request.

Mitigation Disabled

Table 5.2 shows the result of the Create Account Attack with DoS mitigation dis-abled. All scenarios display high response times and high error rates due to timeouts.

Table 5.2. The result of Create Account Attack with DoS mitigation disabled.

Scenario Action T (ms) S E1 E2 E (%)Legitimate Usage 1 10471 80 0 1005 92.6

Create Account 5168 45 0 530 92.2Create Item 5313 35 0 475 93.1

Attack 5392 1930 0 32642 94.4Create Account 5392 1930 0 32642 94.4

The change of response time of the above scenarios are shown in figures 5.1 and5.2. For both scenarios the response time increases sharply until the requests hitthe 5 second timeout. The response time for Legitimate Usage 1 is twice as largeas the Attack scenario due to Legitimate Usage 1 contains two actions, whereas theAttack scenario only contains one action.

24

5.1. DDOS ATTACKS

Figure 5.1. The average response time for Legitimate Usage 1 of Create Account

Attack with DoS mitigation disabled. Similar results were observed for Legitimate

Usage 2-5.

Figure 5.2. The average response time for the attack tra�c of Create Account Attack

with DoS mitigation disabled.

25

CHAPTER 5. RESULTS

Mitigation Enabled

Table 5.3 shows the result of Create Account Attack with DoS mitigation enabled.The mitigation approach is described in section 3.4.3.

Table 5.3. The result of Create Account Attack with DoS mitigation enabled.


Create Account 267 110 490 0 81.7Create Item 369 582 0 0 0


As seen in table 5.3, malicious tra�c is blocked as well as legitimate tra�c. Thisis a sensible choice for the business, since it lowers the response time and error ratefor legitimate usage such as creating items.

The change of response time of the above scenarios are shown in figures 5.3 and5.4. The peaks represent the moments when the account creation feature is enabledand all attack tra�c is processed. In the valleys the account creation requests areblocked in the API Gateway which greatly reduces the load on the application andthus the response time of the legitimate tra�c.

Figure 5.3. The average response time for Legitimate Usage 1 of Create Account

Attack with DoS mitigation enabled. Similar results were observed for Legitimate

Usage 2-5.

26

5.1. DDOS ATTACKS

Figure 5.4. The average response time for the attack tra�c of Create Account Attack

with DoS mitigation enabled.

5.1.3 Get Item Attack

This attack aims to overwhelm the servers by fetching a large amount of items.Since a user may or may not have an account when performing this action, threesub attacks are identified.

• Get Item Attack 1 - Each request is made anonymously.

• Get Item Attack 2 - Each request is made by a unique user. This is plausiblesince the attacker can create a large amount of accounts before staging theattack.

• Get Item Attack 3 - All requests are made with a single account, which hasbeen registered a long time ago and has a long history of purchases. Tocompromise one such account is plausible, but having thousands of them ismore unlikely.

All attacks are carried out with the same load as the Create Account Attack, i.e.36000 clients distributed over 120 seconds.

Mitigation Disabled

Since each attack is performed with the same load, only one of the three attacksneed to be performed in order to show a weakness in the application. Table 5.4shows the result of Get Item Attack 1 with DoS mitigation disabled. All scenariosdisplay high response times and high error rates due to timeouts. The change ofresponse time during this attack, with mitigation disabled, is similar to the patternsof Create Account Attack, as shown in figures 5.1 and 5.2.

27

CHAPTER 5. RESULTS

Table 5.4. The result of Get Item Attack 1 with DoS mitigation disabled.



Attack 1 5433 1529 0 32822 95.5Get Item 5433 1529 0 32822 95.5

Mitigation Enabled

Table 5.5 shows the aggregated results of all variations of Get Item Attack with DoSmitigation enabled. The mitigation approach for all three attacks is described insection 3.4.3.

Table 5.5. The result of all variations of Get Item Attack with DoS mitigationenabled.

Sub Attack Scenario T (ms) S E1 E2 E (%)1 - - - - -

Legitimate Usage 2 1510 616 537 28 47.8Legitimate Usage 3 2044 1148 0 22 1.9Legitimate Usage 4 2024 1159 0 32 2.7Attack 1 578 6228 29001 771 82.7

2 - - - - -Legitimate Usage 2 926 651 535 0 45.1Legitimate Usage 3 1025 682 512 0 42.9Legitimate Usage 4 764 586 0 5 0.8Attack 2 461 6695 29305 0 81.4

3 - - - - -Legitimate Usage 2 1318 658 527 2 44.6Legitimate Usage 3 1703 1178 0 2 0.2Legitimate Usage 4 1679 1182 0 1 0.1Attack 3 539 7276 28681 43 79.8

As seen in table 5.5, the attack tra�c is consistently blocked for all sub attacks.However, di�erent legitimate tra�c is a�ected for each attack variation. For thefirst attack, anonymous usage (Legitimate Usage 1 ) is blocked in contrast to authen-ticated tra�c (Legitimate Usage 2 & 3 ). This is however changed for the secondattack, since the attacker make requests with actual users. The error rate for Le-gitimate Usage 3 is slightly lower than the error rate for Legitimate Usage 2, dueto the 2 second delay after the first mitigating action (see 3.4.3). During the third

28

5.1. DDOS ATTACKS

attack, the attacker uses an important user, which is blocked by the rate limiting.Authenticated, less important users are not a�ected, since the rate limiting is putinto place at the same time anonymous users are blocked (as in the first attack).

The change of response time during this attack, with mitigation disabled, issimilar to the patterns of Create Account Attack, as shown in figures 5.3 and 5.4.

5.1.4 Search Attack

This attack was from the beginning intended to be very similar to the previous twoattacks. However, both Create Account Attack and Get Item Attack seem to put alot of load on the API Gateway. Table 5.2 indicates that requests towards both theCustomer service and the Marketplace service result in high response times eventhough the attack tra�c is only aimed towards the Customer service.

In an attempt to enrich the results, more items were added to the database inorder to make the search for items slower. This would shift the load from the APIGateway to the Marketplace service in the event of the proposed Search Attack.

The actual attack consists of 6000 clients distributed over 120 seconds. Theamount of requests are therefore only 1

6 compared to the previous attacks.

Normal Load

With more items in the database, the scenarios for legitimate usage needed to bererun in order to create a new base case. The results can be seen in table 5.6. Thelegitimate usage generate relatively low response times and error rates. Comparedto table 5.1, the response times are much higher which is due to the resource heavysearch feature.

Table 5.6. Legitimate usage which should be considered as "normal load" when thesearch feature is more resource heavy.

Scenario T (ms) S E (%)Legitimate Usage 1-5 299 6579 0.1

29

CHAPTER 5. RESULTS

Mitigation Disabled

Table 5.7 shows the result of Search Attack with DoS mitigation disabled. Similarlyto the previous attacks, the response time for the attack tra�c sharply increasesuntil the timeout is reached. However, requests towards the Customer service, e.gthe Create Account action, display error rates and response time not far from thebase case. The change of response time for this action can be seen in figure 5.5.

Table 5.7. The result of Search Attack with DoS mitigation disabled.



Legitimate Usage 2 10338 91 0 1009 91.7Search Item 5173 57 0 518 90.1Get Item 5166 34 0 419 93.5

Attack 5314 430 0 5309 92.5Search Item 5314 430 0 5309 92.5

Figure 5.5. The average response time for the attack tra�c of Search Attack withDoS mitigation disabled.

30

5.1. DDOS ATTACKS

Mitigation Enabled

Table 5.8 shows the result of Search Attack with DoS mitigation enabled. Themitigation approach for this attack is described in section 3.4.3.

Table 5.8. The result of Search Attack with DoS mitigation enabled.


Create Account 67 600 0 0 0Create Item 1552 573 0 27 4.5



As seen in table 5.8, the error rates are far lower than for previous attacks. Thisis because of the default search response, which is still a valid response. All searchrequests however, do get the same response, meaning that legitimate usage is stilla�ected. The response time pattern is similar to the other mitigation techniquesand can be seen in figures 5.3 and 5.4.

31

CHAPTER 5. RESULTS

5.2 Domain DoS Attacks

5.2.1 Duplicate Item Attack

This attack aims to make the application harder to use by creating duplicates oflegitimate items. The database is populated as mentioned in section 4.1.3. Theduplication is carried out with three variations:

• Attack 1 - The attacker creates an identical duplicate of the legitimate item.

• Attack 2 - The attacker adds an arbitrary word to the end of the descriptionof the duplicated item.

• Attack 3 - The attacker duplicates the item but replaces the description witha fixed default text.

The number of identified duplicates with DoS mitigation enabled can be seen intable 5.9. The mitigation approach is explained in section 3.4.3.

Table 5.9. The number of identified duplicates for each category of items.

Legitimate Items Attack 1 Attack 2 Attack 3No. of identified duplicates 1/52 52/52 51/52 51/52

One of the legitimate items were classified as a duplicate due to its close resemb-lance to an existing item. However, as mentioned in 4.1.3, the same item was addedto an account with purchase history, which was not marked as a duplicate item.

For the first attack, all items were successfully marked as a duplicate.For the second attack, a malicious duplicate was missed. When an extra word

was added, the similarity score moved pass the threshold since the description ofthe legitimate item was very short.

For the third attack, all but one malicious items were marked as duplicates. Thefirst item with the default description did not match any existing items. However,all following items matched the first malicious items and were therefore marked asduplicates.

32

5.2. DOMAIN DOS ATTACKS

5.2.2 Shopping Basket Attack

As mentioned aims this attack to make items unavailable for purchase by addingthem to the attacker’s shopping basket. The mitigation approach is explained insection 3.4.3 and the attack is carried out with two variations:

• Attack 1 - The attacker utilises one account to continuously put items in itsshopping basket, with a rate of 1 item per second.

• Attack 2 - The attacker utilises 10 accounts to continuously put a specific setof 10 items in the shopping basket over and over again. I.e each account adds1 item to its shopping basket every 10 seconds.

The database is populated with 50 items and for the purpose of this test thereservation time is lowered from 5 minutes to 10 seconds. For both attacks, thenumber of available items for purchase is measured each second.

Figure 5.6. The number of available items over time during Attack 1 of Shopping

Basket Attack with DoS mitigation enabled.

Figure 5.6 shows the result of Attack 1. From 0-10 seconds the number ofavailable items declines. From 10-20 seconds, one reservation expire per second butsince the attacker still is able to reserve items, the number of available items staysconstant. After 20 seconds, the system notices that the user has more than 10expired reservations in a row without a purchase, and blocks further reservationsmade by that user.

33

CHAPTER 5. RESULTS

Figure 5.7. The number of available items over time during Attack 2 of Shopping

Basket Attack with DoS mitigation enabled.

Figure 5.7 shows the result of Attack 2. From 0-10 seconds, the 10 items arereserved for their first time. At 10-30 seconds, the same 10 items are continuouslyreserved. After 30 seconds, the system notices that three reservations has beenmade without a purchase, and turns o� further reservations.

5.3 Key Takeaways

Due to the large amount of results, the most important aspects are summarized inthis section.

• All DoS attacks, both DDoS attacks and Domain DoS attacks, had largeimpact on the usability of the system when mitigation was disabled.

• The mitigation of Create Account Attack resulted in legitimate tra�c beingblocked, while making other parts of the application available. I.e a conciousdecision by the domain.

• The mitigation of Get Item Attack had di�erent impact on legitimate usagedepending on how the attack was performed. A more elaborated attack res-ulted in more legitimate usage being blocked.

• The design of Search Attack was changed to increase the load on the market-place service compared to other services. This resulted in interesting resultswhere the DDoS attack could disrupt the marketplace service without a�ect-ing the customer service. The mitigation lowered the error rate and responsetime in exchange for a default search response.

• The mitigation of Duplicate Item Attack blocked almost all duplicated items,but classified a legitimate item as malicious as well.

34

5.3. KEY TAKEAWAYS

• The mitigation of Shopping Basket Attack resulted in e�cient blockage ofmalicious users trying to make items unavailable for purchase. A legitimateuser will also be a�ected by this mitigation, but not in a severe way.

• For all attacks, the mitigation techniques a�ects not only malicious usage, butlegitimate usage as well. However, it does so in a less harmful way than itwould have with no mitigation.

35

Chapter 6

Conclusion

This final chapter will analyse the results and conclusions regarding the outcomeof the thesis as a whole will be drawn. Ethical and economical concerns as well asareas of promising future work will also be discussed.

6.1 Discussion

The goal of this thesis was to examine if domain behaviour could be used to mitigateDoS attacks, in contrast to existing solutions which rely on technical parameters.Even though simplified scenarios have been created, the results clearly indicate thata domain-driven approach is feasible to mitigate both DDoS attacks and DomainDoS attacks. Across all three DDoS attacks, the legitimate tra�c experienced animprovement in both response time and error rate. The mitigation of the twoDomain DoS attacks also resulted in improved experience for legitimate users.

To distinguish malicious attacks from legitimate usage, the application utiliseddomain-specific knowledge about the users. For Get Item Attack parameters such ashow long the user had existed and how much it had spent were examined. Also, thereservation history were considered for Shopping Basket Attack. Even if this resultedin legitimate users being blocked, as seen in e.g. table 5.5, it was a deliberate decisionin order to mitigate the attack.

Domain behaviour was also utilised when deciding what features should be de-graded and how this would be carried out. Create Account Attack and Search Attackare two simple scenarios where feature degradation was used, but they still showthe potential strength of this behaviour. The Shopping Basket Attack also showedhow feature degradation could be used mitigate a DoS attack, by rejecting furtherreservations.

Duplicate Item Attack gave a simple example of how a Domain DoS attack couldbe performed and mitigated. Current technical solutions would find it impossibleto mitigate this attack and Shopping Basket Attack, due to its close resemblanceto legitimate usage. However, by utilising domain knowledge, the malicious items

37

CHAPTER 6. CONCLUSION

could be identified. Again, this scenario is simplified, but it still serves as an exampleof how such attacks can be mitigated.

Domain-Driven Design and its concepts such as event based communicationand clearly defined bounded contexts were initially heavily emphasised. However,in retrospect, these concepts were not as important as originally thought whenmitigating DDoS attacks. The event based communication was mainly utilised tocount the number of requests of a specific type. This could have been done in otherways. Furthermore, bounded contexts were emphasised for scaling purposes, whichthis thesis did not cover. However, event based communication makes it easy toget a good comprehension of what is happening in the domain, which will certainlybe helpful to perform more advanced analysis. Bounded contexts should also notbe disregarded for future work, since scaling is an important tool when mitigatingDDoS attacks. However, it must be stressed that the philosophy of Domain-DrivenDesign, i.e. to diminish the distance between the business itself and the code thatsupports it, influenced the project heavily.

For Shopping Basket Attack however, the event driven communication and theevent store were crucial. It is a reasonable assumption that the reservation featurewould be implemented with no history in mind in a standard web application. Withan event store however, the full history of an item is preserved, which allowed forpowerful mitigation.

When analysing user data, one must be concerned with the ethical aspects thatfollows. Sensitive information must be handled with care and stored properly. Careshould also be taken when deciding what users to allow and to disallow in case ofa DoS attack. Patterns of discrimination might arise if a particular group of usersare always the first ones to be denied usage to the system when mitigating actionsare taken.

This thesis proposes an approach which is heavily integrated in the applicationitself. This makes it suitable for new custom built software, especially if DDD isalready employed. For legacy systems however, large changes are probably needed.The mitigation approach will also be hard to generalize over multiple businesses.It could possibly be integrated in some kind of Commercial o�-the-shelf (COTS)product, but it can be challenging for a business to incorporate such a product.

As stated above requires this mitigation approach large changes to the applic-ation itself. Many current commercial mitigation solutions sits outside the applic-ation, which makes them easier to incorporate. A more domain-driven approachwould certainly implicate a large investment from the business, but could on theother hand solve problems that a technical approach can not solve. The opposite isalso true and the recommendation is to employ both approaches to ensure thoroughDoS mitigation.

The goal of this thesis was to expand the concept Domain-Driven Security (DDS)by examining if patterns from Domain-Driven Design could be used to mitigate DoSattacks. As discussed above, event based communication and a domain-driven philo-sophy were crucial to successfully mitigate DoS attacks. It is thereby recommended

38

6.2. FUTURE WORK

that these methods are used in order to secure applications from DoS attacks withDDS.

6.2 Future Work

As mentioned, event driven communication enables a more consolidated view ofwhat is going on in the domain. This could, and should, be used to perform deeperanalysis in order to make the DoS mitigation more accurate. How this is performedwill however be left for future studies.

Furthermore, tests which involve real-world data should be carried out. Thisthesis aimed to show that this type of DoS mitigation is possible and data thatresemble real-world data was therefore used. A hypothetical scenario is however notthe same as a real-world scenario and this should be examined by future studies.

An interesting field of study would also be to investigate how these mitigatingactions are accepted by real legitimate users. In this thesis, actions have been takenbased on what is assumed legitimate users would prefer. How a new user wouldreact to be denied to create a new account or be given a default search result wouldcertainly be interesting. This is however left for future studies.

39

Bibliography

[Aka15] Akamai. State of the Internet. Tech. rep. 2015, pp. 1–61. url: https:

//www.stateoftheinternet.com/downloads/pdfs/2015- cloud-

security-report-q3.pdf.[Arb16] Arbor Networks. Worldwide Infrastructure Security Report. Tech. rep.

2016. url: http://www.arbornetworks.com/images/documents/

WISR2016%7B%5C_%7DEN%7B%5C_%7DWeb.pdf.[BD14] Hakem Beitollahi and Geert Deconinck. ‘ConnectionScore: A statistical

technique to resist application-layer DDoS attacks’. In: Journal of Am-bient Intelligence and Humanized Computing 5.3 (2014), pp. 425–442.issn: 18685145. url: http://link.springer.com.focus.lib.kth.

se/article/10.1007/s12652-013-0196-5.[Bor+14] Gaurav Bora et al. ‘OSI Reference Model Networking : An Overview’.

In: International Journal of Computer Trends and Technology 7.4 (2014),pp. 214–218. url: http://www.ijcttjournal.org/archives/200-

ijctt-v7p151.[Bus+96] Frank Buschmann et al. Pattern-Oriented Software Architecture, Volume

1, A System of Patterns. Wiley, 1996. isbn: 978-0-471-95869-7.[Cas14] Orion Cassetto. Banishing Bad Bots with Incapsula. 2014. url: https:

//www.incapsula.com/blog/banishing-bad-bots.html (visited on2016-03-03).

[Cid14] Daniel Cid. More Than 162,000 WordPress Sites Used for Distrib-uted Denial of Service Attack. 2014. url: https://blog.sucuri.

net/2014/03/more- than- 162000- wordpress- sites- used- for-

distributed-denial-of-service-attack.html (visited on 2016-02-10).[Czy+14] Jakub Czyz et al. ‘Taming the 800 Pound Gorilla: The Rise and Decline

of NTP DDoS Attacks’. In: 2014 Conference on Internet MeasurementConference. 2014, pp. 435–448. isbn: 9781450332132. url: http://dl.

acm.org.focus.lib.kth.se/citation.cfm?doid=2663716.2663717.

41

https://www.stateoftheinternet.com/downloads/pdfs/2015-cloud-security-report-q3.pdf



http://www.arbornetworks.com/images/documents/WISR2016%7B%5C_%7DEN%7B%5C_%7DWeb.pdf

http://www.arbornetworks.com/images/documents/WISR2016%7B%5C_%7DEN%7B%5C_%7DWeb.pdf

http://link.springer.com.focus.lib.kth.se/article/10.1007/s12652-013-0196-5

http://link.springer.com.focus.lib.kth.se/article/10.1007/s12652-013-0196-5

http://www.ijcttjournal.org/archives/200-ijctt-v7p151

http://www.ijcttjournal.org/archives/200-ijctt-v7p151

https://www.incapsula.com/blog/banishing-bad-bots.html

https://www.incapsula.com/blog/banishing-bad-bots.html

https://blog.sucuri.net/2014/03/more-than-162000-wordpress-sites-used-for-distributed-denial-of-service-attack.html



http://dl.acm.org.focus.lib.kth.se/citation.cfm?doid=2663716.2663717

http://dl.acm.org.focus.lib.kth.se/citation.cfm?doid=2663716.2663717

BIBLIOGRAPHY

[Dam+12] Evan Damon et al. ‘Hands-on denial of service lab exercises usingSlowLoris and RUDY’. In: Proceedings of the 2012 Information Secur-ity Curriculum Development Conference on - InfoSecCD ’12 (2012),pp. 21–29. url: http://dl.acm.org/citation.cfm?id=2390317.

2390321.[Dav07] Joshua Davis. Hackers Take Down the Most Wired Country in Europe.

2007. url: http://www.wired.com/2007/08/ff-estonia/?currentPage=

all (visited on 2016-02-04).[Eva03] Eric Evans. Domain-Driven Design: Tackling Complexity in the Heart

of Software. Prentice Hall, 2003. isbn: 978-0321125217.[Fin14] Erica Fink. Uber’s dirty tricks quantified: Rival counts 5,560 canceled

rides. 2014. url: http://money.cnn.com/2014/08/11/technology/

uber-fake-ride-requests-lyft/index.html (visited on 2016-03-30).[Gra15] Robert Graham. Pin-pointing China’s attack against GitHub. 2015.

url: http://blog.erratasec.com/2015/04/pin-pointing-chinas-

attack-against.html (visited on 2016-02-05).[Imp15] Imperva. Global DDoS Threat Landscape, Q2 2015. Tech. rep. 2015.

url: http://lp.incapsula.com/ddos-report-2015.html.[Li+09] Ke Li et al. ‘Distinguishing DDoS attacks from flash crowds using prob-

ability metrics’. In: NSS 2009 - Network and System Security (2009),pp. 9–17. url: http://ieeexplore.ieee.org.focus.lib.kth.se/

xpl/articleDetails.jsp?arnumber=5319006.[Man11] Steve Mansfield-Devine. ‘DDoS: Threats and mitigation’. In: Network

Security 2011.12 (2011), pp. 5–12. issn: 13534858. url: http://dx.

doi.org/10.1016/S1353-4858(11)70128-3.[Man15] Steve Mansfield-Devine. ‘The growth and evolution of DDoS’. In: Net-

work Security 2015.10 (2015), pp. 13–20. issn: 13534858. url: http://

www.sciencedirect.com/science/article/pii/S1353485815300921.[Mar15] Alexander J Martin. Greater Manchester plod site targeted by nuisance

DDoS attack. 2015. url: http://www.theregister.co.uk/2015/

09/03/greater%7B%5C_%7Dmanchester%7B%5C_%7Dpolice%7B%5C_

%7Dddos/ (visited on 2016-02-04).[Miu+13] Tony Miu et al. ‘Universal DDoS Mitigation Bypass’. In: Black Hat

USA 2013 (2013). url: https://media.blackhat.com/us-13/US-

13-Lee-Universal-DDoS-Mitigation-Bypass-WP.pdf.[New15] Sam Newman. Building Microservices. O’Reilly, 2015.[Pri16] Matthew Prince. Technical Details Behind a 400Gbps NTP Amplific-

ation DDoS Attack. 2016. url: https : / / blog . cloudflare . com /

technical - details - behind - a - 400gbps - ntp - amplification -

ddos-attack/ (visited on 2016-02-10).

42

http://dl.acm.org/citation.cfm?id=2390317.2390321

http://dl.acm.org/citation.cfm?id=2390317.2390321

http://www.wired.com/2007/08/ff-estonia/?currentPage=all

http://www.wired.com/2007/08/ff-estonia/?currentPage=all

http://money.cnn.com/2014/08/11/technology/uber-fake-ride-requests-lyft/index.html

http://money.cnn.com/2014/08/11/technology/uber-fake-ride-requests-lyft/index.html

http://blog.erratasec.com/2015/04/pin-pointing-chinas-attack-against.html

http://blog.erratasec.com/2015/04/pin-pointing-chinas-attack-against.html

http://lp.incapsula.com/ddos-report-2015.html

http://ieeexplore.ieee.org.focus.lib.kth.se/xpl/articleDetails.jsp?arnumber=5319006


http://dx.doi.org/10.1016/S1353-4858(11)70128-3

http://dx.doi.org/10.1016/S1353-4858(11)70128-3

http://www.sciencedirect.com/science/article/pii/S1353485815300921

http://www.sciencedirect.com/science/article/pii/S1353485815300921

http://www.theregister.co.uk/2015/09/03/greater%7B%5C_%7Dmanchester%7B%5C_%7Dpolice%7B%5C_%7Dddos/



https://media.blackhat.com/us-13/US-13-Lee-Universal-DDoS-Mitigation-Bypass-WP.pdf

https://media.blackhat.com/us-13/US-13-Lee-Universal-DDoS-Mitigation-Bypass-WP.pdf

https://blog.cloudflare.com/technical-details-behind-a-400gbps-ntp-amplification-ddos-attack/



BIBLIOGRAPHY

[Rai16] Saritha Rai. Uber Sues Ola Claiming Fake Bookings as India FightEscalates. 2016. url: http://www.bloomberg.com/news/articles/

2016-03-23/uber-sues-ola-claiming-fake-bookings-as-india-

fight-escalates (visited on 2016-03-31).[Tha+11] Theerasak Thapngam et al. ‘Discriminating DDoS attack tra�c from

flash crowd through packet arrival patterns’. In: 2011 IEEE Confer-ence on Computer Communications Workshops, INFOCOM WKSHPS2011 (2011), pp. 952–957. issn: 10636692. url: http://ieeexplore.

ieee.org.focus.lib.kth.se/xpl/articleDetails.jsp?arnumber=

5928950.[Ver13] Vaughn Vernon. Implementing Domain-Driven Design. Addison Wes-

ley, 2013.[Ver15a] Verisign. Verisign Distributed Denial of Service Trends Report. Tech.

rep. 2015, pp. 1–8. url: https : / / www . verisign . com / assets /

report-ddos-trends-Q32015.pdf.[Ver15b] Verizon. 2015 Data Breach Investigations Report. Tech. rep. 2015, pp. 1–

70. url: http://www.verizonenterprise.com/DBIR/2015/.[Wil09] John Wilander. Domändriven säkerhet / Domain-Driven Security. 2009.

url: http://owaspsweden.blogspot.se/2009/09/domandriven-

sakerhet-domain-driven.html (visited on 2015-01-29).

43

http://www.bloomberg.com/news/articles/2016-03-23/uber-sues-ola-claiming-fake-bookings-as-india-fight-escalates






https://www.verisign.com/assets/report-ddos-trends-Q32015.pdf

https://www.verisign.com/assets/report-ddos-trends-Q32015.pdf

http://www.verizonenterprise.com/DBIR/2015/

http://owaspsweden.blogspot.se/2009/09/domandriven-sakerhet-domain-driven.html

http://owaspsweden.blogspot.se/2009/09/domandriven-sakerhet-domain-driven.html

Appendix A

Complete DDoS Results

A.1 Normal Load

Table A.1. Legitimate usage which should be considered as "normal load" for Create

Account Attack and Get Item Attack.

Scenario Action T (ms) S E1 E2 E (%)Legitimate Usage 1 34 1200 0 0 0

Create Account 16 600 0 0 0Create Item 16 600 0 0 0

Legitimate Usage 2 43 1200 0 0 0Search Item 21 600 0 0 0Get Item 21 600 0 0 0



Legitimate Usage 5 98 1800 0 0 0Change Account 29 600 0 0 0Add Credits 19 600 0 0 0Buy Item 48 600 0 0 0

45

APPENDIX A. COMPLETE DDOS RESULTS

Table A.2. Legitimate usage which should be considered as "normal load" Search

Attack.



Legitimate Usage 2 278 1196 0 4 0.3Search Item 170 600 0 0 0Get Item 108 596 0 4 0.7



Legitimate Usage 5 358 1786 0 1 0.1Change Account 50 600 0 0 0Add Credits 34 600 0 0 0Buy Item 272 586 0 1 0.2

46

A.2. CREATE ACCOUNT ATTACK

A.2 Create Account Attack

Table A.3. The result of Create Account Attack with DoS mitigation disabled.



Legitimate Usage 2 10161 132 0 966 88Search Item 4977 80 0 495 86.1Get Item 5202 52 0 471 90.1



Legitimate Usage 5 15370 141 0 1370 90.7Change Account 5150 68 0 507 88.2Add Credits 5153 38 0 478 92.6Buy Item 5162 35 0 385 91.7


47


Table A.4. The result of Create Account Attack with DoS mitigation enabled.


Create Account 267 110 490 0 81.7Create Item 369 582 0 0 0




Legitimate Usage 5 1032 1762 0 0 0Change Account 463 600 0 0 0Add Credits 305 587 0 0 0Buy Item 261 575 0 0 0


48

A.3. GET ITEM ATTACK

A.3 Get Item Attack

Table A.5. The result of Get Item Attack 1 with DoS mitigation disabled.







Attack 1 5433 1529 0 32822 95.5Get Item 5433 1529 0 32822 95.5

49


Table A.6. The result of Get Item Attack 1 with DoS mitigation enabled.







Attack 1 578 6228 29001 771 82.7Get Item 578 6228 29001 771 82.7

50

A.3. GET ITEM ATTACK








Attack 2 461 6695 29305 0 81.4Get Item 461 6695 29305 0 81.4

51






Legitimate Usage 3 1703 1178 0 2 0.2Search Item 1063 598 0 2 0.3Get Item 639 580 0 0 0



Attack 3 539 7276 28681 43 79.8Get Item 539 7276 28681 43 79.8

52

A.4. SEARCH ATTACK

A.4 Search Attack

Table A.9. The result of Search Attack with DoS mitigation disabled.








53


Table A.10. The result of Search Attack with DoS mitigation enabled.




Legitimate Usage 3 2251 1147 0 48 4Search Item 607 587 0 13 2.2Get Item 1643 560 0 35 5.9


Legitimate Usage 5 1758 1761 0 31 1.7Change Account 98 598 0 2 0.3Add Credits 61 600 0 0 0Buy Item 1597 563 0 29 5.8


54

www.kth.se

Domain-Driven Security’s take on Denial-of-Service …945831/FULLTEXT01.pdfstate-of-the art...

Documents

Transcript of Domain-Driven Security’s take on Denial-of-Service …945831/FULLTEXT01.pdfstate-of-the art...