Professional Documents
Culture Documents
FULLTEXT01
FULLTEXT01
JOHAN ARNÖR
JOHAN ARNÖR
jarnor@kth.se
1 Introduction 1
1.1 Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.1.1 Domain Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.1.2 Domain Behaviour . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2 Problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.3 Aim . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.4 Delimitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.5 Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.6 Collaboration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.7 Societal Effects and Environmental Concerns . . . . . . . . . . . . . 3
2 Background 5
2.1 DDoS Attacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1.1 Targets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1.2 Attackers and Motives . . . . . . . . . . . . . . . . . . . . . . 6
2.1.3 Types of Attacks . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.1.4 Mitigation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.2 Domain DoS Attacks . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.3 Domain-Driven Design . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.3.1 Bounded Contexts . . . . . . . . . . . . . . . . . . . . . . . . 12
2.3.2 Domain Events . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.4 Domain-Driven Security . . . . . . . . . . . . . . . . . . . . . . . . . 13
3 Method 15
3.1 E-Commerce Application . . . . . . . . . . . . . . . . . . . . . . . . 15
3.2 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.2.1 System Design . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.2.2 Communication . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.2.3 Data Storage . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.3 Attack Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.3.1 DDoS Attacks . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.3.2 Domain DoS Attacks . . . . . . . . . . . . . . . . . . . . . . . 17
3.4 Mitigation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.4.1 Event Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.4.2 Control Mechanisms . . . . . . . . . . . . . . . . . . . . . . . 18
3.4.3 Mitigating the Attacks . . . . . . . . . . . . . . . . . . . . . . 19
4 Evaluation 21
4.1 Usage Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.1.1 Legitimate Traffic . . . . . . . . . . . . . . . . . . . . . . . . 21
4.1.2 Malicious Traffic . . . . . . . . . . . . . . . . . . . . . . . . . 22
4.1.3 Legitimate Data . . . . . . . . . . . . . . . . . . . . . . . . . 22
4.2 Infrastructure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
5 Results 23
5.1 DDoS Attacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
5.1.1 Normal Load . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
5.1.2 Create Account Attack . . . . . . . . . . . . . . . . . . . . . . 24
5.1.3 Get Item Attack . . . . . . . . . . . . . . . . . . . . . . . . . 27
5.1.4 Search Attack . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
5.2 Domain DoS Attacks . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
5.2.1 Duplicate Item Attack . . . . . . . . . . . . . . . . . . . . . . 32
5.2.2 Shopping Basket Attack . . . . . . . . . . . . . . . . . . . . . 33
5.3 Key Takeaways . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
6 Conclusion 37
6.1 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
6.2 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
Bibliography 41
Appendices 43
Introduction
This chapter intends to briefly introduce the reader to the problem and lay out
the overall aim for this thesis project. Delimitations and methodology will also be
discussed.
1.1 Definitions
1.1.1 Domain Layer
In order to keep a clear separation of concerns in a software application, the Layers
Architecture [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. An
illustration can be seen in Figure 1.1.
1
CHAPTER 1. INTRODUCTION
1.2 Problem
The problem this thesis intends to explore is as follows;
The problem is twofolded. The first part of the question concerns the classical
DoS problem to identify the request as malicious or legitimate and block it ac-
cordingly. The second part intends to investigate if altering system behaviour in
the event of a DoS attack is a suitable approach. The domain behaviour is what
Domain-Driven Security utilise in order to secure software. This thesis intends to
explore 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 mitigation
techniques. The result would be useful for small as well as large organisations that
seek 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 was
developed based on the principles of Domain-Driven Design (DDD). DDD is a soft-
ware development approach created by Eric Evans [Eva03] that heavily emphasises
business-centric development (see section 2.3). The application simulates a public
e-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 another
KTH student, Jonas Stendahl, who also wrote his master thesis at Omegapoint AB.
Although we worked towards the same code base, our contributions to this differed
greatly. I focused my efforts on the event based communication and analysis as
opposed to Jonas who focused on data handling and application state.
1
http://www.blocket.se
3
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.1 Targets
Gambling and betting sites have for long been targeted by DDoS attacks [Man15]. A
typical 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 request
a 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’s
State of the Internet report shows that 25% off all attacks were directed towards
Software & Technology business providing Software-as-a-Service (SaaS) solutions
and other cloud based services [Aka15]. Furthermore, Verisign reports that finan-
cial services and the public sector received 15% and 13% respectively of the total
number of DDoS attacks [Ver15a]. However, it must be stressed that the above data
only reflects the customer base of the specific DDoS mitigation provider.
Governments are also commonly targeted by DDoS attacks. One of the first
large scale attacks was aimed towards Estonia in 2007. The event that initiated
the DDoS attacks was the removal of a Soviet built war memorial, which by many
Estonians were seen as a symbol of oppression [Dav07]. Jaak Aaviksoo, Estonia’s
defence minister at the time explains in Wired Magazine:
5
CHAPTER 2. BACKGROUND
Long has it been suspected that governments themselves carry out large scale
DDoS attacks. During 2015 however, clear evidence was presented that stated that
the Chinese government was involved in the attack against GitHub and Great-
Fire.org - an organisation that help people evade the so-called "Great Firewall" of
China [Man15]. The attack against GitHub, which mirrors some of GreatFire.org’s
material, 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 exploits
unknowing users’ computer to route traffic to GitHub and GreatFire.org. The at-
tack was traced and found to originate from the backbone of China Unicom, the
same organisation which run the Great Firewall [Gra15].
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 a
specific, 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, they
resemble legitimate usage and can therefore be harder to mitigate [Man11]. Another
unique feature for these attacks is that just a single machine generating traffic at
a 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 and
Akamai indicate that Layer 7 attacks represent between 5% and 18% of all DDoS
attacks [Arb16; Aka15].
The classical DDoS attack has usually been carried out via botnets, which are
useful for both Layer 3 & 4 attacks and Layer 7 attacks. The attacker infects
thousands 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 traffic to a
specific 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
CHAPTER 2. BACKGROUND
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 client
sends 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 by
withholding this, the attacker is able to occupy resources in the system [Man11].
The attack can succeed by either overwhelming the server or consuming all available
bandwidth. The ICMP flood attack acts in an even simpler way. An ICMP Echo
request (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 via
amplification 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 IP
address 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 amounts
of traffic 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 sheer
volume of requests brings down the targeted server. The previously mentioned at-
tack against GitHub is a perfect example of such an attack. The injected JavaScript
code 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 that
site to a target website [Cid14]. Even if no significant amplification is achieved, the
attacker can stay hidden and the attack will be harder to mitigate since it makes
use of legitimate servers.
Layer 7 attacks can also exploit resource heavy operations on the server side
with carefully crafted HTTP requests [Man11]. These operations can be e.g. search
queries, file downloads, PDF generations etc. If a specific function within a system
is designed with only a few users in mind, it will not be hard for an attacker to
bring down the system.
8
2.1. DDOS ATTACKS
2.1.4 Mitigation
A number of different techniques exists for mitigating Layer 7 DDoS attacks. A
simple approach is to inspect only the request itself without considering previous
behaviour. The IP can, even though it must be valid, be part of a known botnet
network and the request can therefore be blocked. Examination of the HTTP
headers can also give further information. For example, a request can safely be
discarded when the user agent header implies that the request is from the Google
search bot, but the IP does not match Google’s network [Cas14].
Demographic profiling is a technique which work under the assumption that the
attack traffic is coming from another geographic location than legitimate requests. A
botnet usually operates from IP addresses originating from the same location, since
a breached network often result in many infected PCs [BD14]. This makes it possible
to filter out the attack traffic, since the legitimate traffic is usually distributed more
evenly. Also, when a lot of requests are originating from e.g. Russia to a Swedish
website, the suspicious traffic can be blocked with few false negatives. However, as
seen 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 the
event of a DDoS attack, the requests are compared with the reference profile and are
assigned 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 time
interval.
9
CHAPTER 2. BACKGROUND
• 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 than
rarely accessed pages.
• Hyperlink fraction click - what fraction of all the links are clicked by a user.
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-called
flash crowds. A flash crowd is a sudden rise of legitimate traffic due to special
events such as breaking news or ticket release. A flash crowd could therefore easily
10
2.2. DOMAIN DOS ATTACKS
The false bookings are thus a Denial-of-Service attack since it hinders legitimate
usage. However, unlike DDoS attacks which aim to bring down the supporting
infrastructure, these attacks exploit the business, or domain, itself.
As recent as March 2016 Uber was once again involved in a similar case. This
time however, the company was suing a competitor, Ola, for booking over 400 000
false rides over a six month period [Rai16]. The problem with these attacks is the
seemingly legitimate nature of the requests. The traffic towards the servers does
not 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 be
referred to as Domain DoS attacks.
11
CHAPTER 2. BACKGROUND
There are zero translations between the domain experts, the software
developers, 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 the
actual model [Ver13].
The major goal DDD tries to address is to reduce the complexity often seen in large
software projects. It achieves this by employing many different concepts, two of
which are explained below.
Total unification of the domain model for a large system will not be
feasible or cost-effective.
Within an organisation, sub domains exist and Bounded Contexts are DDDs way
to model these [Ver13]. It does so to create explicit boundaries between different
parts 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 finance
department can have its own definition of what a customer is that is different from
other departments’ definition [Ver13].
Since Bounded Contexts introduce clear delimitations in the codebase, the sub
domains become less coupled. This makes it possible to scale e.g. a customer
domain differently from a finance domain.
12
2.4. DOMAIN-DRIVEN SECURITY
The captured occurrence must be significant for the domain itself in order to be
classified as a Domain Event. An event which is raised when e.g. a user clicks a
button is not to be regarded as a Domain Event, since it belongs to the infrastruc-
ture.
A captured occurrence is thereafter published asynchronously to subscribing
counterparts. 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 such
events and e.g. deduct the balance of a specific user. Domain Events allow therefore
for loose coupling between Bounded Contexts, as well as it requires little change in
existing code when expanding the application [Ver13].
By analysing these Domain Events, one can get a comprehensive view of what
is happening in the domain.
13
Chapter 3
Method
This chapter describes the application used for evaluation as well as numerous pos-
sible attack scenarios. Furthermore, different mitigation techniques are proposed for
DDoS attacks and Domain DoS attacks.
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 Contexts
can clearly be identified. One where the customer account resides and one where the
items themselves reside, which are named Customer and Marketplace respectively.
In order to be able to scale the Bounded Contexts differently, each context
is 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].
1
http://www.amazon.com/
2
http://www.blocket.se/
15
CHAPTER 3. METHOD
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 domain
behaviour, it must be carefully designed. Instead of traditional request/response
communication, event based communication is employed [New15]. Each service is
responsible for creating and publishing events, as well as listening and acting on
events from other services. All events are passed to a channel on the Message
Service, which forwards the events to subscribed services for the specified channel.
E.g. a user creates an account via the Frontend Application. The API Gateway
receives the request which turns it into an AccountCreationRequested event. It is
thereafter sent to the Message Service on the channel Account. The Message Service
forwards it to the Customer service, since the Customer service subscribes on the
channel Account. The Customer service creates and stores the account and publishes
an AccountCreated event, which propagates back to the API Gateway. The user
which 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 a
bottleneck, but since the Message Service does not contain any state, it should not
be difficult to scale.
16
3.3. ATTACK SCENARIOS
Search Attack
A large number of searches are made in order to overwhelm the system.
17
CHAPTER 3. METHOD
3.4 Mitigation
3.4.1 Event Analysis
One of the first problems a system is facing during a DoS attack is to actually realise
that an attack is ongoing. This task is delegated to the Event Analyser which can
be seen in Figure 3.1. The Event Analyser subscribes to all channels and is also able
to control actions in the API Gateway, the Customer service and the Marketplace
service.
When it comes to DDoS attacks, a simple threshold would probably suffice to
determine if an attack is taking place. E.g. if the Event Analyser registers 500
AccountCreationRequested events per second, compared to a normal load of 20,
mitigating actions should be taken.
A different kind of anomaly detection is required when dealing with Domain DoS
attacks, since these attacks can be carried out with low intensity. E.g. to detect
duplicate items, one must check if the specific item is similar to all other items in
the database. This could be done either in real-time or later in batches.
User Validation
When abnormal load exists on the site, user validation could be activated with
domain behaviour in mind. A first attempt could be that only logged in users
would 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 abnormal
load. E.g. a limit of 10 searches per second could be set for each account, since
a human would probably not go over this limit. The attacker would then need to
utilise multiple accounts to attack the site, but with user validation in place, the
impact should not be severe.
18
3.4. MITIGATION
Feature Degradation
Feature degradation could be put into place if high load persists after the above
mechanisms are activated or if they are not applicable. E.g. when a user tries to
register an account, the domain has no knowledge of the user itself. A reasonable
action would then be to turn off the ability to register new accounts, if that feature
is under attack.
Another degradation of a feature would be to modify the result of a search query
during high load. E.g. if an item is considerably more popular than other items, a
default response containing that particular item would be a reasonable approach to
reduce to load on the system.
Data Marking
Data marking is a suitable approach when direct actions cannot be taken due to
the need of deeper analysis. In the case of a Domain DoS attack certain items or
accounts might be marked as malicious, if deviations in the data are noticed. The
account could be marked as blocked along with the items associated with it. If
this action results in an inaccurate decision, the user will have to contact customer
service to undo the blockage.
In this attack, only Feature Degradation is used to mitigate the attack. The reason
for this is because the domain does not know anything about the user, since an
account is not yet registered. The functionality to create an account is turned off
for 20 seconds if 1000 account creation requests are received during 10 seconds.
For this attack, User Validation is used together with Rate Limiting. Feature De-
gradation is not utilised since turning off the ability to read items would render the
application useless. If 1000 requests are received during 10 seconds, only logged
in users will be let through and a user must wait 500 ms between requests. If the
load still persists after two seconds, the application will constrain itself further by
only allowing accounts which are more than one month old and have spent at least
10 credits. As with the previous attack, the mitigating actions are active for 20
seconds.
19
CHAPTER 3. METHOD
Search Attack
To mitigate this attack, Feature Degradation is used. If 300 search requests are
received 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 with
the 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 little
new value.
20
Chapter 4
Evaluation
This chapter gives the reader a detailed overview of how the evaluation of this thesis
is performed. Required third party infrastructure is explained and the simulation
strategy for malicious traffic and legitimate traffic is presented.
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 logged
in, who search for items and view details of an item.
Legitimate Usage 3 simulates the same case as Legitimate Usage 2, but with the
exception that the users are logged in with newly created accounts.
Legitimate Usage 4 simulates the same case as Legitimate Usage 2, but with the
exception that the users are logged in with older accounts and have spent money
on the site.
21
CHAPTER 4. EVALUATION
Legitimate Usage 5 simulates existing users which update contact information, add
credit to their respective account and thereafter purchase an item.
Each test is set to have 600 clients active during a total of 120 seconds, which
Loader.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 total
of 1200 requests will be made.
4.2 Infrastructure
Since Loader.io is a cloud-based service, the application must be publicly available
on the internet. To achieve this, the cloud-based hosting service Pivotal Cloud
Foundry was used. Each microservice is deployed as an independent virtual server
with its own IP address, RAM, storage etc.
22
Chapter 5
Results
In this chapter results of the different DoS attacks will be presented along with its
corresponding mitigation approach, as described in chapter 3.
• E1 - The number of HTTP 403 Forbidden errors. A 403 error indicates that
the request has actively been blocked by server in an attempt to mitigate an
attack.
• E2 - The number of HTTP 504 Gateway timeout errors. In this case a 504
error is returned when the server took more than 5 seconds to process the
request.
• E - The portion of all requests that resulted in an error from the server, i.e
the 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
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.
The change of response time of the above scenarios are shown in figures 5.1 and
5.2. For both scenarios the response time increases sharply until the requests hit
the 5 second timeout. The response time for Legitimate Usage 1 is twice as large
as the Attack scenario due to Legitimate Usage 1 contains two actions, whereas the
Attack 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 traffic 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.
As seen in table 5.3, malicious traffic is blocked as well as legitimate traffic. This
is a sensible choice for the business, since it lowers the response time and error rate
for legitimate usage such as creating items.
The change of response time of the above scenarios are shown in figures 5.3 and
5.4. The peaks represent the moments when the account creation feature is enabled
and all attack traffic is processed. In the valleys the account creation requests are
blocked in the API Gateway which greatly reduces the load on the application and
thus the response time of the legitimate traffic.
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 traffic of Create Account Attack
with DoS mitigation enabled.
• Get Item Attack 2 - Each request is made by a unique user. This is plausible
since the attacker can create a large amount of accounts before staging the
attack.
• Get Item Attack 3 - All requests are made with a single account, which has
been registered a long time ago and has a long history of purchases. To
compromise one such account is plausible, but having thousands of them is
more 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 attacks
need to be performed in order to show a weakness in the application. Table 5.4
shows the result of Get Item Attack 1 with DoS mitigation disabled. All scenarios
display high response times and high error rates due to timeouts. The change of
response time during this attack, with mitigation disabled, is similar to the patterns
of 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.
Mitigation Enabled
Table 5.5 shows the aggregated results of all variations of Get Item Attack with DoS
mitigation enabled. The mitigation approach for all three attacks is described in
section 3.4.3.
Table 5.5. The result of all variations of Get Item Attack with DoS mitigation
enabled.
As seen in table 5.5, the attack traffic is consistently blocked for all sub attacks.
However, different legitimate traffic is affected for each attack variation. For the
first attack, anonymous usage (Legitimate Usage 1 ) is blocked in contrast to authen-
ticated traffic (Legitimate Usage 2 & 3 ). This is however changed for the second
attack, 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, due
to 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 affected, since the rate limiting is put
into 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, is
similar to the patterns of Create Account Attack, as shown in figures 5.3 and 5.4.
Normal Load
With more items in the database, the scenarios for legitimate usage needed to be
rerun in order to create a new base case. The results can be seen in table 5.6. The
legitimate usage generate relatively low response times and error rates. Compared
to table 5.1, the response times are much higher which is due to the resource heavy
search feature.
Table 5.6. Legitimate usage which should be considered as "normal load" when the
search feature is more resource heavy.
29
CHAPTER 5. RESULTS
Mitigation Disabled
Table 5.7 shows the result of Search Attack with DoS mitigation disabled. Similarly
to the previous attacks, the response time for the attack traffic sharply increases
until the timeout is reached. However, requests towards the Customer service, e.g
the Create Account action, display error rates and response time not far from the
base 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.
Figure 5.5. The average response time for the attack traffic of Search Attack with
DoS mitigation disabled.
30
5.1. DDOS ATTACKS
Mitigation Enabled
Table 5.8 shows the result of Search Attack with DoS mitigation enabled. The
mitigation approach for this attack is described in section 3.4.3.
Table 5.8. The result of Search Attack with DoS mitigation enabled.
As seen in table 5.8, the error rates are far lower than for previous attacks. This
is because of the default search response, which is still a valid response. All search
requests however, do get the same response, meaning that legitimate usage is still
affected. The response time pattern is similar to the other mitigation techniques
and can be seen in figures 5.3 and 5.4.
31
CHAPTER 5. RESULTS
• Attack 2 - The attacker adds an arbitrary word to the end of the description
of the duplicated item.
• Attack 3 - The attacker duplicates the item but replaces the description with
a fixed default text.
The number of identified duplicates with DoS mitigation enabled can be seen in
table 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.
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 added
to 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 of
the legitimate item was very short.
For the third attack, all but one malicious items were marked as duplicates. The
first item with the default description did not match any existing items. However,
all following items matched the first malicious items and were therefore marked as
duplicates.
32
5.2. DOMAIN DOS ATTACKS
• Attack 1 - The attacker utilises one account to continuously put items in its
shopping basket, with a rate of 1 item per second.
The database is populated with 50 items and for the purpose of this test the
reservation time is lowered from 5 minutes to 10 seconds. For both attacks, the
number 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 of
available items declines. From 10-20 seconds, one reservation expire per second but
since the attacker still is able to reserve items, the number of available items stays
constant. After 20 seconds, the system notices that the user has more than 10
expired reservations in a row without a purchase, and blocks further reservations
made 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 are
reserved for their first time. At 10-30 seconds, the same 10 items are continuously
reserved. After 30 seconds, the system notices that three reservations has been
made without a purchase, and turns off further reservations.
• All DoS attacks, both DDoS attacks and Domain DoS attacks, had large
impact on the usability of the system when mitigation was disabled.
• The mitigation of Get Item Attack had different impact on legitimate usage
depending 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 results
where the DDoS attack could disrupt the marketplace service without affect-
ing the customer service. The mitigation lowered the error rate and response
time 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
• For all attacks, the mitigation techniques affects not only malicious usage, but
legitimate usage as well. However, it does so in a less harmful way than it
would have with no mitigation.
35
Chapter 6
Conclusion
This final chapter will analyse the results and conclusions regarding the outcome
of the thesis as a whole will be drawn. Ethical and economical concerns as well as
areas 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 mitigate
DoS attacks, in contrast to existing solutions which rely on technical parameters.
Even though simplified scenarios have been created, the results clearly indicate that
a domain-driven approach is feasible to mitigate both DDoS attacks and Domain
DoS attacks. Across all three DDoS attacks, the legitimate traffic experienced an
improvement in both response time and error rate. The mitigation of the two
Domain DoS attacks also resulted in improved experience for legitimate users.
To distinguish malicious attacks from legitimate usage, the application utilised
domain-specific knowledge about the users. For Get Item Attack parameters such as
how long the user had existed and how much it had spent were examined. Also, the
reservation history were considered for Shopping Basket Attack. Even if this resulted
in legitimate users being blocked, as seen in e.g. table 5.5, it was a deliberate decision
in 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 Attack
are two simple scenarios where feature degradation was used, but they still show
the potential strength of this behaviour. The Shopping Basket Attack also showed
how feature degradation could be used mitigate a DoS attack, by rejecting further
reservations.
Duplicate Item Attack gave a simple example of how a Domain DoS attack could
be performed and mitigated. Current technical solutions would find it impossible
to mitigate this attack and Shopping Basket Attack, due to its close resemblance
to 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 example
of how such attacks can be mitigated.
Domain-Driven Design and its concepts such as event based communication
and clearly defined bounded contexts were initially heavily emphasised. However,
in retrospect, these concepts were not as important as originally thought when
mitigating DDoS attacks. The event based communication was mainly utilised to
count the number of requests of a specific type. This could have been done in other
ways. Furthermore, bounded contexts were emphasised for scaling purposes, which
this thesis did not cover. However, event based communication makes it easy to
get a good comprehension of what is happening in the domain, which will certainly
be helpful to perform more advanced analysis. Bounded contexts should also not
be disregarded for future work, since scaling is an important tool when mitigating
DDoS attacks. However, it must be stressed that the philosophy of Domain-Driven
Design, i.e. to diminish the distance between the business itself and the code that
supports it, influenced the project heavily.
For Shopping Basket Attack however, the event driven communication and the
event store were crucial. It is a reasonable assumption that the reservation feature
would be implemented with no history in mind in a standard web application. With
an event store however, the full history of an item is preserved, which allowed for
powerful mitigation.
When analysing user data, one must be concerned with the ethical aspects that
follows. Sensitive information must be handled with care and stored properly. Care
should also be taken when deciding what users to allow and to disallow in case of
a DoS attack. Patterns of discrimination might arise if a particular group of users
are always the first ones to be denied usage to the system when mitigating actions
are taken.
This thesis proposes an approach which is heavily integrated in the application
itself. This makes it suitable for new custom built software, especially if DDD is
already 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 off-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 approach
would certainly implicate a large investment from the business, but could on the
other hand solve problems that a technical approach can not solve. The opposite is
also true and the recommendation is to employ both approaches to ensure thorough
DoS 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 DoS
attacks. 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 with
DDS.
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 on
2016-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 Measurement
Conference. 2014, pp. 435–448. isbn: 9781450332132. url: http://dl.
acm.org.focus.lib.kth.se/citation.cfm?doid=2663716.2663717.
41
BIBLIOGRAPHY
[Dam+12] Evan Damon et al. ‘Hands-on denial of service lab exercises using
SlowLoris 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
BIBLIOGRAPHY
[Rai16] Saritha Rai. Uber Sues Ola Claiming Fake Bookings as India Fight
Escalates. 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 traffic from
flash crowd through packet arrival patterns’. In: 2011 IEEE Confer-
ence on Computer Communications Workshops, INFOCOM WKSHPS
2011 (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
Appendix A
Table A.1. Legitimate usage which should be considered as "normal load" for Create
Account Attack and Get Item Attack.
45
APPENDIX A. COMPLETE DDOS RESULTS
Table A.2. Legitimate usage which should be considered as "normal load" Search
Attack.
46
A.2. CREATE ACCOUNT ATTACK
Table A.3. The result of Create Account Attack with DoS mitigation disabled.
47
APPENDIX A. COMPLETE DDOS RESULTS
Table A.4. The result of Create Account Attack with DoS mitigation enabled.
48
A.3. GET ITEM ATTACK
Table A.5. The result of Get Item Attack 1 with DoS mitigation disabled.
49
APPENDIX A. COMPLETE DDOS RESULTS
Table A.6. The result of Get Item Attack 1 with DoS mitigation enabled.
50
A.3. GET ITEM ATTACK
Table A.7. The result of Get Item Attack 2 with DoS mitigation enabled.
51
APPENDIX A. COMPLETE DDOS RESULTS
Table A.8. The result of Get Item Attack 3 with DoS mitigation enabled.
52
A.4. SEARCH ATTACK
Table A.9. The result of Search Attack with DoS mitigation disabled.
53
APPENDIX A. COMPLETE DDOS RESULTS
Table A.10. The result of Search Attack with DoS mitigation enabled.
54
www.kth.se