Domain-Driven Security’s take on
Denial-of-Service (DoS) Attacks
JOHAN ARNÖR
Domain-Driven Security’s take on
Denial-of-Service (DoS) Attacks
JOHAN ARNÖR jarnor@kth.se
Master’s Thesis at CSC and Omegapoint AB KTH Supervisor: Olov Engwall Company Supervisor: Daniel Deogun
Examiner: Patric Jensfelt
Abstract
Many companies and organisations today suffer from Denial-of-Service (DoS) attacks, which can have direct and indirect economical consequences. This thesis tackles this problem with a novel approach by utilising domain specific beha-viour and knowledge. The goal is to distinguish malicious attacks from legitimate usage and to alter overall system behaviour at the event of a DoS attack. Distributed DoS attacks (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 the principles of Domain-Driven Design in order to test the given approach. Five examples of DoS attacks are presented and tested towards the system. The results indicate that utilising domain behaviour is a suitable approach in order to mitigate DoS attacks, but it requires deep integration with the application itself.
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 och indirekta ekonomiska konsekvenser. Denna avhandling ser nytä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. Distribuerade DoS-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 givna tesen. Fem exempel av DoS-attacker är presenterade och testade gentemot systemet. Resultaten indikerar att utnytt-jandet av domänbeteende är ett lämpligt tillvägagångssätt för att avvärja DoS-attacker, men att det kräver djup in-tegration med applikationen.
Contents
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 . . . 31.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.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 A Complete DDoS Results 45 A.1 Normal Load . . . 45
A.2 Create Account Attack . . . 47
A.3 Get Item Attack . . . 49
Chapter 1
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.
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 legitimate requests. 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 2015 compared 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 infrastructure resources, which is often the case with DDoS attacks. Instead, the business itself can be exploited in a number of ways. E.g. an e-commerce site like eBay might be attacked by adding a large amount of fake items. If eBay’s customers cannot distinguish between legitimate and fake items, the Denial-of-Service attack is to be regarded as successful.
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.
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 malicious attacks from legitimate usage and to alter overall system behaviour at the event of a DoS attack?
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.
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.7 Societal Effects and Environmental Concerns
The goal of this thesis is to examine if web applications can be secured from DoS attacks. As many companies and organizations suffer from such attacks (see chapter 2), the results of this thesis could potentially help affected parties to strengthen their resilience against DoS attacks.
Environmental concerns however, are not applicable to this thesis and will there-fore not be discussed.
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 and thus 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 carried out in a distributed fashion. To achieve this, attackers usually employ what is called a 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]. 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:
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 affected the majority of the Estonian population. This was the first time that a botnet 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 about common motives for DDoS attacks against their services. The most common motive was criminals demonstrating DDoS attack capabilities, closely followed by online-gaming related motives. Extortion attempts, vandalism and business rivalry were also seen as common reasons.
Online activism - or hacktivism - has recently seen an upswing in media, with groups such as Anonymous, LulzSec, and Lizard Squad as front figures. These groups 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 download their tool, the Low Orbit Ion Cannon (LOIC), to actively participate in a DDoS attack 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 the real threat most organisations face is blackmailing carried out by cyber-criminals [Man11]. A particular group of hackers, DD4BC (DDoS for Bitcoin), has had a strong 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 a ransom of up to 100 bitcoins (roughly $40 000). If the ransom is not paid the attack traffic is increased to apply further pressure [Arb16]. Many organisations end up paying the ransom and due to Bitcoin’s nature, tracing the transactions turns out to be very difficult. However, adequate protection against smaller DDoS attacks usually turns out to be cheaper than paying the ransom [Man15].
Another increasing category of attackers are vandals with no direct monetary goal. In a recent DDoS attack against the Greater Manchester Police an individual took 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 it is a way to have fun.
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
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].
2.1.3 Types of Attacks
DDoS attacks can generally be categorised into Layer 3 & 4 attacks (infrastructure layer attacks) and Layer 7 attacks (application layer attacks), where the layers refer to 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 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
sends a request, with a spoofed IP address, to a vulnerable service on a legitimate server. The server then replies with a larger message to the intended target, and not to the attacker due to the spoofed IP address [Man15]. By exploiting multiple servers, a single attacker can, with limited resources, stage a large scale DDoS attack.
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 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 atat-tack. 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 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.
2.1. DDOS ATTACKS
Attacks such as Slowloris and R-U-Dead-Yet (RUDY) are examples of slow HTTP attacks. The aim for these attacks is to exhaust the server’s pool of open HTTP connections. Slowloris does this by sending multiple HTTP GET requests, each with an incomplete header [Dam+12]. Since HTTP protocol is designed to wait 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 request instead. 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 send just a byte at a time, making the connection long lasting [Dam+12]. With enough requests, the server’s connection pool will eventually be exhausted. With this low amount of data, it is easy to hide behind proxies and anonymous networks such as TOR to cover your tracks [Man11].
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.
• Download rate - the number of bytes downloaded by a user during a specified time interval.
• Uptime - the time between initialisation and cancellation of communication between a user and the server.
• Downtime - the time between cancellation and initialisation of communication between 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 than
rarely accessed pages.
• Hyperlink fraction click - what fraction of all the links are clicked by a user. Another approach to mitigate malicious traffic is by trying to verify the user itself. Many attackers do not utilise browsers due to their resource heavy nature, but instead thinner clients specifically developed for DDoS attacks. An attempt to block 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 JavaScript engine 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 JavaScript challenges. However, the integration of a lightweight JavaScript engine in the bot client have proven to be feasible [Miu+13].
An effective way to distinguish malicious bots from legitimate usage is a so-called CAPTCHA challenge. In such a challenge, distorted text is displayed to the user as seen in Figure 2.2. If the correct input is supplied, the request is carried out.
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-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
2.2. DOMAIN DOS ATTACKS
be mistaken for a DDoS attack. [Tha+11] proposes that a distinction could be made by analysing the arrival patterns of packages. Predictable patterns, which the authors argue botnets use, include constant attack rate, increasing attack rate and periodical 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 authors leverage 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 traffic volume is slower for flash crowds than for DDoS attacks. In addition to this [BD14] suggests that uptime and targeted resources differ between flash crowds and DDoS attacks. The time a user remains on a site is usually short since it will leave once the news article is read, the ticket purchased etc. Also, during a flash crowd, users tend to access a single resource whereas a DDoS 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 offer taxi-like services via a smartphone app, was during 2014 accused of ordering and cancelling over 5000 rides from Lyft, a competing ride-sharing company [Fin14]. Lyft stated that 177 Uber employees registered accounts with fake names in order to book and cancel the rides. Erica Fink, a writer from CNN explains:
Bogus requests decrease Lyft drivers’ availability, which could send users to Uber instead.
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.
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
it [Ver13]. A crucial part of DDD is to establish a Ubiquitous Language, that is a set of terms that both developers and business experts have decided to agree upon and exclusively use. As [Ver13] puts it;
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 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 large software projects. It achieves this by employing many different concepts, two of which are explained below.
2.3.1 Bounded Contexts
A Bounded Context is a fundamental concept in Domain-Driven Design. One could describe it as DDDs method to fulfil the mantra "high cohesion, loose coupling" at a high level. Many organisations try to develop a consolidated model for the whole domain, but as stated by Eric Evans [Eva03], this is a suboptimal approach.
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.
2.3.2 Domain Events
Domain-Driven Design encourages that communication within and between Bounded Contexts is carried out via so-called Domain Events. As Vaughn Vernon [Ver13] puts it.
Use a Domain Event to capture an occurrence of something that happened in the domain.
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.
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, both consultants at Omegapoint AB, who argued that injection attacks could be seen as modelling problems. Data is usually validated close to the user interface, but DDS proposes that the data should be modelled close to the core and any data that does not conform to that model should be rejected [Wil09].
This thesis tries to expand the concept Domain-Driven Security, by examining how Domain-Driven Design can be utilised to mitigate DoS attacks.
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.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 able
to upload an item for sale which in turn others can purchase. A quantity is specified along with each item to indicate how many copies are available for purchase. At time of purchase, the user puts one or more items in a shopping basket. The items are thereafter reserved for 5 minutes to allow the user to complete the purchase without interference from other customers. Log in functionality is also present and an 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 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].
1http://www.amazon.com/ 2http://www.blocket.se/
Figure 3.1 illustrates an overview of the system architecture, including concepts that will be explained later. The rectangles represent standalone servers (further on 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 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.
3.3. ATTACK SCENARIOS
3.2.3 Data Storage
The storage solution used in both the Customer service and the Marketplace service is 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 is fetched and applied to the object in chronological order. E.g if an item is added and later updated, the Event Store will save two events for this item, an ItemCreated event and an ItemUpdated event. When reading that item, the ItemCreated event will be applied to an empty item, followed by the ItemUpdated event.
With this strategy, history of data is preserved which allows for a more powerful analysis of domain behaviour.
3.3 Attack Scenarios
A number of possible attack scenarios needs to be established in order to design the DoS mitigation. The scenarios are split into two categories; DDoS attacks and Domain DoS attacks. The former aims to exhaust resources in the server in order to bring it offline. The latter on the other hand aims to degrade some functionality in 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 the system, 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 the system with duplicates of existing items. An item is fetched from the application and an identical or similar item is thereafter added to the marketplace. A duplicate item will confuse the legitimate user and hinder it from using the application effectively, thus resulting in a Denial-of-Service.
Shopping Basket Attack
This attack aims to exploit the fact that an item is reserved for five minutes after being added to a user’s shopping basket. By reserving multiple items by one or many accounts, the attacker will deny legitimate users the ability to purchase those items.
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.
3.4.2 Control Mechanisms
Not only should the Event Analyser detect if a DoS attack is ongoing, but it should also coordinate actions to mitigate it. The Event Analyser does not mitigate the attack on its own, but instead instructs the different services how to behave. 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.
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.
3.4.3 Mitigating the Attacks
This section describes the chosen mitigation approach for each attack, based on the techniques mentioned above.
Create Account Attack
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.
Get Item Attack
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.
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.
Duplicate Item Attack
To mitigate this attack, Data Marking is used. The description of each item is compared to all other items in the database. A simple algorithm is used to find similar descriptions; the occurrence of each word is counted and the difference between the each word is summed and thereafter normalized over the total number of words. I.e "this is an example" compared to "this is text" would generate the score ((0 + 0 + 1 + 1) + (0 + 0 + 1))/7 ¥ 0.43. A low score indicates similar texts and in this case, a score lower than 0.15 will result that the item will be marked as a duplicate.
However, in order to not mark the original item as a duplicate the timestamps are checked. Furthermore users which have previously bought items are whitelisted since those users are trusted by the domain.
Shopping Basket Attack
To mitigate this attack, Feature Degradation and User Validation are used. A user is regarded as malicious if it has let the five minute limit expire for 10 items since its last purchase. However, the attacker could also utilise multiple accounts to reserve the items. In this case, the mitigation will be performed item-wise. If an item has been reserved for three times in a row without being purchased, future reservations for that particular item will be discarded. In both cases, the event store (see section 3.2.3) will be of high importance since the full history of reservations are preserved.
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.
4.1 Usage Simulation
All usage simulation for DDoS attacks, both malicious and legitimate, will be carried out through the cloud-based load testing tool Loader.io. A test consists of one or multiple URLs to which HTTP requests are sent with a specified rate. Each request is logged and data such as response time, error rate, bandwidth usage, etc. can be obtained after the test is finished.
4.1.1 Legitimate Traffic
Legitimate usage is simulated by 5 different load tests. This is done to somewhat mimic the versatile behaviour that legitimate traffic usually displays. The 5 tests are 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 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.
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.1.2 Malicious Traffic
Each attack will be simulated by its own load test. The number of clients might differ between tests, but each attack should make usage of the e-commerce application impractical. The attacks will be run for 120 seconds and are started at the same time 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. These were clearly distinct from one another. Thereafter were one item added twice to the database. Once with a new account and once with an account which had already bought an item. The item that was added was very similar to one of the original 50 items.
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.
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.
5.1 DDoS Attacks
For each attack, legitimate traffic as well as attack traffic will be run simultaneously. First without DDoS mitigation and thereafter with DDoS mitigation. In order to eliminate influences from one test to another all servers are restarted between each test 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 for each 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 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.
5.1.1 Normal Load
A baseline of normal usage is important to establish, in order to measure what impact the DDoS attacks have on the application. Table 5.1 shows the aggregated results when all legitimate usage tests are run simultaneously. The legitimate usage generate 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 client sends 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.2 Create Item 5313 35 0 475 93.1 Attack 5392 1930 0 32642 94.4 Create Account 5392 1930 0 32642 94.4 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.
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
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.
Scenario Action T (ms) S E1 E2 E (%) Legitimate Usage 1 638 692 490 0 41.5 Create Account 267 110 490 0 81.7 Create Item 369 582 0 0 0 Attack 265 6005 29995 0 83.3 Create Account 265 6005 29995 0 83.3 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.
5.1. DDOS ATTACKS
Figure 5.4. The average response time for the attack traffic 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, three sub 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 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.
Table 5.4. The result of Get Item Attack 1 with DoS mitigation disabled. Scenario Action T (ms) S E1 E2 E (%) Legitimate Usage 1 10846 62 0 1024 94.3 Create Account 5413 42 0 531 92.7 Create Item 5433 20 0 493 96.1 Attack 1 5433 1529 0 32822 95.5 Get Item 5433 1529 0 32822 95.5 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.
Sub Attack Scenario T (ms) S E1 E2 E (%)
1 - - - - -Legitimate Usage 2 1510 616 537 28 47.8 Legitimate Usage 3 2044 1148 0 22 1.9 Legitimate Usage 4 2024 1159 0 32 2.7 Attack 1 578 6228 29001 771 82.7 2 - - - - -Legitimate Usage 2 926 651 535 0 45.1 Legitimate Usage 3 1025 682 512 0 42.9 Legitimate Usage 4 764 586 0 5 0.8 Attack 2 461 6695 29305 0 81.4 3 - - - - -Legitimate Usage 2 1318 658 527 2 44.6 Legitimate Usage 3 1703 1178 0 2 0.2 Legitimate Usage 4 1679 1182 0 1 0.1 Attack 3 539 7276 28681 43 79.8
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 LeLe-gitimate Usage 2, due to the 2 second delay after the first mitigating action (see 3.4.3). During the third
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.
5.1.4 Search Attack
This attack was from the beginning intended to be very similar to the previous two attacks. However, both Create Account Attack and Get Item Attack seem to put a lot of load on the API Gateway. Table 5.2 indicates that requests towards both the Customer service and the Marketplace service result in high response times even though the attack traffic is only aimed towards the Customer service.
In an attempt to enrich the results, more items were added to the database in order to make the search for items slower. This would shift the load from the API Gateway to the Marketplace service in the event of the proposed Search Attack.
The actual attack consists of 6000 clients distributed over 120 seconds. The amount 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 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.
Scenario T (ms) S E (%)
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.
Scenario Action T (ms) S E1 E2 E (%) Legitimate Usage 1 5222 653 0 521 44.4 Create Account 46 599 0 1 0.2 Create Item 5174 54 0 520 90.6 Legitimate Usage 2 10338 91 0 1009 91.7 Search Item 5173 57 0 518 90.1 Get Item 5166 34 0 419 93.5 Attack 5314 430 0 5309 92.5 Search Item 5314 430 0 5309 92.5
Figure 5.5. The average response time for the attack traffic of Search Attack with
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.
Scenario Action T (ms) S E1 E2 E (%) Legitimate Usage 1 1621 1173 0 27 2.3 Create Account 67 600 0 0 0 Create Item 1552 573 0 27 4.5 Legitimate Usage 2 2190 1141 0 46 3.9 Search Item 572 590 0 10 1.7 Get Item 1616 551 0 36 6.1 Attack 596 5870 0 130 2.2 Search Item 596 5870 0 130 2.2
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.
5.2 Domain DoS Attacks
5.2.1 Duplicate Item Attack
This attack aims to make the application harder to use by creating duplicates of legitimate items. The database is populated as mentioned in section 4.1.3. The duplication 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 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.
Legitimate Items Attack 1 Attack 2 Attack 3 No. 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 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.
5.2. DOMAIN DOS ATTACKS
5.2.2 Shopping Basket Attack
As mentioned aims this attack to make items unavailable for purchase by adding them to the attacker’s shopping basket. The mitigation approach is explained in section 3.4.3 and the attack is carried out with two variations:
• Attack 1 - The attacker utilises one account to continuously put items in its shopping basket, with a rate of 1 item per second.
• Attack 2 - The attacker utilises 10 accounts to continuously put a specific set of 10 items in the shopping basket over and over again. I.e each account adds 1 item to its shopping basket every 10 seconds.
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.
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.
5.3 Key Takeaways
Due to the large amount of results, the most important aspects are summarized in this section.
• 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 Create Account Attack resulted in legitimate traffic being blocked, while making other parts of the application available. I.e a concious decision by the domain.
• 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.
5.3. KEY TAKEAWAYS
• The mitigation of Shopping Basket Attack resulted in efficient blockage of malicious users trying to make items unavailable for purchase. A legitimate user will also be affected by this mitigation, but not in a severe way.
• 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.
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
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 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
6.2. FUTURE WORK
that these methods are used in order to secure applications from DoS attacks with DDS.
6.2 Future Work
As mentioned, event driven communication enables a more consolidated view of what is going on in the domain. This could, and should, be used to perform deeper analysis in order to make the DoS mitigation more accurate. How this is performed will however be left for future studies.
Furthermore, tests which involve real-world data should be carried out. This thesis aimed to show that this type of DoS mitigation is possible and data that resemble real-world data was therefore used. A hypothetical scenario is however not the 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 mitigating actions are accepted by real legitimate users. In this thesis, actions have been taken based on what is assumed legitimate users would prefer. How a new user would react to be denied to create a new account or be given a default search result would certainly be interesting. This is however left for future studies.
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.
