Preliminary Study of Fission Defenses againstLow-Volume DoS Attacks on Proxied

Multiserver Systems∗

Yuquan Shan, George Kesidis Daniel Fleck, Angelos StavrouEECS, PSU, Univ. Park, PA CS Dept, GMU, Fairfax, VA{gik2,yxs182}@psu.edu {dfleck,astavrou}@gmu.edu

CSE Dept, PSU, Technical Report No. CSE-17-001Feb. 22, 2017, revised Aug. 1, 2017

Abstract

Multiserver applications deployed in the public cloud infrastructurecontinue to be plagued by significant threat of Distributed Denial of Ser-vice (DDoS) attacks by large scale botnets, including very notable attackinstances just this past Fall. We describe defenses to address differentaspects of this problem including: a proactive moving target approach tocombat the reconnaissance phase where the botnet ascertains the identi-ties (IP addresses) of the proxy (indirection) servers, and reactive client-to-server “shuffling” and “fission” quarantine approaches to deal with highor low volume DDoS attacks respectively targeting the proxy or replicaapplication servers. In this paper, we overview our preliminary imple-mentation of these defenses and describe the results of a model basedevaluation of their performance.

1 Introduction

Consider a generic multiserver virtual system of clients, indirection/proxy servers,and replica worker/application servers (replicas), where the servers are con-trolled either by a central coordination server or in a distributed fashion by theproxies themselves [7, 8, 20, 21], see Figure 1. The clients reach the proxies viathe public commodity Internet. The proxies and replicas could be implementedin Virtual Machines (VMs) or lightweight containers (instances) on physicalservers of one or more datacenters of the public cloud. The proxies in turnassign clients to replicas to fulfill their requests. The clients never know theIP addresses of the replicas, only those of the proxies which they determine

∗Research supported by DARPA XD3 grant, gifts of Amazon AWS and Google GCEcredits, and a Cisco Systems URP gift.

1

by DNS, where the coordination server manages the DNS records of the prox-ies. That is, the proxies segment the sessions between clients and replicas. Forexample, load-balanced content distribution networks or session establishmentsystems can be mounted on such systems.

Figure 1: Overview of system architecture

Generally, the threat of Distributed Denial of Service (DDoS) attacks (e.g., [16,13, 2]) continue to be a concern because the fundamental lack of economic in-centives to secure attack-participating bots1 and/or deploy egress filtering intheir access network. Indeed, two very significant botnet based DDoS attackswere witnessed just this past Fall [5, 11].

We then focus on reactive fission defense to combat low-volume attacks tar-geting replicas. In Section 3, we describe our developing experimental set-up onAWS and preliminary fission experiments. In Section 4, we give some prelimi-nary performance results largely based on numerical computations of a binomialmodel for fission. The paper concludes with a summary in Section 5.

1e.g., well known techniques of specification-based behavioral anomaly detection and pre-vention for IoT devices, e.g., [1, 4]

2

2 Summary overview of considered threats andproposed cloud-based defenses

DDoS defense is closely related to load-balancing operations. Among availableservers, load balancing may distribute the “heavy hitter” clients (including as-signing a dedicated server) as well as evenly distribute more numerous clientswith light workloads. If heavy hitters are violating some terms of use or SLA,they may be individually deemed abnormal and throttled or consolidated (quar-antined). An individual client’s workload may naturally vary over time and afew heavy hitter clients at a given point in time may be considered normal andmay not result in significant performance degradation of the servers under loadbalancing.

When there are simultaneously significantly more sustained heavy hitters orsignificantly more light-workload clients than normal, so that the performanceof a sufficiently large number of servers is significantly degraded (overloadedservers), then a DDoS attack or flash crowd may be occurring. In this case, itis desirable that deemed heavy hitters be terminated, throttled or consolidatedin quarantine (effectively underserved), i.e., heavy hitter clients would then beconsidered attackers. Note that load-balancing operations alone may addressmany weaker DDoS attacks - such “missed detections” are not as importantbecause the resulting performance degradation of the servers is not significant.Clients deemed attackers may be challenged, e.g., Javascript puzzles, that likelycannot be solved by bots running on IoT devices deployed with limited protocolsuites - in this way, a DDoS attack and a flash crowd can be discriminated.

In the following, we will describe mechanisms that can be used:

• proactively as a load balancer before a DDoS attack is detected to dealwith the problem overloaded servers by distributing heavy-hitter clientsamong all available servers (possibly by identifying heavy-hitter clients inthe first place); or

• reactively after a DDoS attack is detected, e.g., to quarantine deemedattacking clients.

In some cases, the same techniques (e.g., shuffling client-to-server assignments)can be used both proactively and reactively.

2.1 General assumptions of attack and defense on servers

To reduce costs, multiple client end-users are assigned to each server and indi-vidual clients are not “containerized” within each server (Virtual Machine). Akey assumption in the following is that an overloaded (attacked) server cannotdetermine which of its assigned client(s) are responsible. This said, it can bereliably determined whether a server itself is overloaded, cf., Section 2.6.

In some defense frameworks, new clients are never added to servers (eitherproxies or replicas) deemed overloaded. “Liberated” nominal (benign) clientsmay be consolidated into fewer servers to reduce the number of virtual machines

3

or containers (instances) used by the overall system, particularly when the threatmodel is such that a single attacker can detectably affect a server (as assumedfor application server replicas). However, as discussed below, individual proxyservers subjected to flooding attacks may be able to tolerate more than oneattacker (A > 1) - so consolidating proxy servers deemed not under attack mayresult in servers that are subsequently detected under attack.

Some attacking clients are simple bots that cannot cope with reassignmentto a new server. For such bots, continual shuffling of clients to servers may bea sufficient defense. We focus herein on other malware that is more resilientand can continue its attack even after it is transferred to another server (orafter the server modifies its IP address), and on nominal clients that can alsobe redirected to new servers.

2.2 Proactive moving-target defense against botnet recon-naissance phase

The botmaster needs to gather the current IP addresses of as many proxiesas possible before launching its DDoS attack. Suppose the coordination serverattempts to protect against botnet reconnaissance by periodically changing (viaDNS) proxy IP addresses. Proxies may change their IP addresses individually(even at random) or collectively at the same time. In the latter case, all proxiesknown by the botnet become stale at once. Clients with active sessions duringa proxy’s IP address change may be interrupted and the proxy may or may notassist clients in re-establishing their interrupted sessions. Some bots may not beable to re-establish sessions and need to launch new ones, while nominal clientsshould be able reestablish sessions with only minor delay.

In the Appendix, we describe a simple model of this moving-target defense.Each proxied multiserver system is a tenant of a datacenter. Suppose that,

as a service, the datacenter makes available a large pool of external IPv4 IPaddresses for proactive moving-target defense. Tenants wishing to engage inmoving-target defense would dynamically share the entire pool. This wouldbe more effective and less costly than the individual tenants managing theirown sets of addresses that would need to be much larger in number than theirproxies, or periodically asking the datacenter for fresh addresses. Naturally,under IPv6, a vast number of addresses would be available so that each tenantcould cost-effectively mount such moving-target defense on their own.

2.3 Fission of application replicas servers against low-volumeattacks targeting them

Low-volume threats are such that just one attacker can take down a replicaapplication server. The idea of a m-ary fission defense is that m− 1 containersare spun-up for each container housing a server deemed overloaded (and thistypically on the same physical server). The clients assigned to the overloadedserver are equally divided among the m resulting containers, and overload (and

4

DDoS attack) detection is repeated. Note that the fissioned containers may ormay not be on the same server.

Even if they remain on the same server, each fissioned containers is basi-cally a group of processes within the virtual machine running the server, andnamespaces and cgroups can be used to isolate different containers from eachother. For example, consider a server with four clients including a BlackNurseclient [10] which consumes CPU resources. By fissioning into two containershosting two clients each, the container hosting two nominal clients will haveCPU resources that are protected from the one hosting the attacker, i.e., twoclients were “liberated” by fissioning. If the attacker is instead a Slowloris [19]client consuming memory for half-open HTTP connections, this same benefit ofbinary fissioning would result.

Containers housing only nominal clients (i.e., containers deemed not over-loaded) may be consolidated to reduce the number of containers in play. Fissionand overload-detection are repeated until the attacking clients are sufficientlyquarantined (spinning up new containers can be performed in parallel with de-tection).

Recall that the botnet is limited in that clients are not aware of the identitiesof the application replica servers. So, they are not aware whether plural botsshare a replica.

2.4 Existing defenses against high-volume attacks target-ing proxies

Classical high-volume attacks include TCP SYN floods and reflector attacks.Load balancing and traffic filtering techniques have been deployed to deal withattacks attempting to exhaust network bandwidth. These techniques can beat a third-party system, like Akamai’s Prolexic Proxy, located elsewhere in theInternet, or by the public-cloud providers themselves.

Scaling the system volume with load balancing In GCE, the frontend in-frastructure can automatically scale to absorb certain types of attacks (e.g., SYNfloods), and if the user has provisioned a sufficient number of instances, the au-toscaler can ramp up the backend servers to accommodate the traffic spikes ofthe attack [?]. In AWS, Amazon CloudWatch alarms are used to initiate theautoscaling of the size of a user’s Amazon EC2 fleet in response to user-definedevents [?].

Detecting and filtering excess traffic There is a non-user-configurableDDoS protection layer in an Azure user’s virtual network. If a proxy serverwith an Internet-facing IP address was overloaded by a DDoS attack, the DDoSprotection layer would attempt to detect the sources of attack2 and scrub theoffending traffic [?]. In GCE, anti-spoofing protection is provided for a user’s

2e.g., by a challenge-response mechanism designed to defeat a bot, or by SYN cookies(randomized initial TCP sequence numbers).

5

virtual network by default [?]. In AWS, Elastic Load Balancing (ELB) acceptsonly well-formed TCP connections to protect users from SYN floods or UDPreflection attacks; Amazon CloudFront can automatically terminate connectionsfrom “slow reading/writing” attackers (e.g., Slowloris) [?]. Users can also definefirewall rules for their virtual network to block the source IP addresses that areengaging in the attack or restrict the access to some ports [?, ?, ?].

Changing proxy addresses Note that the moving-target defense of Section2.2 would protect newly spun-up proxies in response to a DDoS attack, andcontinue to protect the original proxies post-attack as well.

2.5 Summary of additional proposed defenses against high-volume attacks based on shuffling client-to-server as-signments

Suppose all clients using proxies that are overloaded could be periodically reas-signed to (shuffled among) the attacked proxies at random. By chance, some for-merly overloaded proxies are assigned only nominal clients and those clients havethus been effectively “liberated.” As with the fission defense, overload/attackdetection and shuffling among overloaded/attacked servers is repeated untilattacking/heavy-hitter clients are sufficiently quarantined.

Shuffling client-to-server assignments can also be used on replica applicationservers to protect against low-volume DDoS attacks targeting them. Shufflingcan be used in concert with a client reputation system based on the history ofclient involvement with overloaded servers. Here, all client-to-server assignmentsare shuffled, even those of servers not deemed overloaded. Clients who are re-peatedly assigned to servers thereafter deemed overloaded have decreasing repu-tation relative to those that are often assigned to servers deemed not overloaded.After several shuffles, clients with sufficiently low reputation can be deemed at-tackers (respectively, heavy-hitters) and quarantined (distributed/load-balancedamong the active servers, respectively). If all servers are initially under attackthen:

1. sequentially sequester/queue a fraction of all clients to an idle server untilnot all servers under attack;

2. employ shuffling/detection with reputation to quarantine some of the re-maining clients;

3. introduce some of the sequestered clients into service; and repeat 1-3.

Note that attack detection may not be perfect so an operator may not want toidentify as heavy-hitters/attackers just the clients with the lowest reputations.

Finally, shuffling client-to-server assignments can occur proactively, i.e., be-fore a DDoS attack is detected according to sufficiently large number of serversdeemed overloaded. Again, shuffling can be used as part of a load-balancing

6

mechanism to distribute, rather than quarantine, deemed heavy-hitter (low rep-utation) clients. By continually distributing clients that are causing servers toslow down, one is increasing the work-factor of a potential attacker. And again,once a DDoS attack is detected, the policy of distributing heavy-hitter clientscan be switched to quarantine.

2.6 Overhead associated with defense

Again, a key assumption is that a server is overloaded cannot determine whichof its assigned client(s) are responsible. This said, it can be reliably determinedwhether a server is overloaded either through the use of:

• probing “canary” clients that can determine when response times of theirmock workloads have grown too high,

• heartbeat signals between proxy/replica servers and coordination server,

• host-based (HIDS) security checks by the OS of a VM managing a num-ber of containers3 in which proxies or replicas operate. This could bepart of general server and client diagnostic performance checks that arecontinually run by many public-cloud providers (e.g., AWS CloudWatch).

Response to volumetric attacks may require employing different physical ma-chines if the downlink (ingress) network I/O is partitioned among its VMs/containers,recall Section 2.4.

Note that if fission is used for high-volume attacks targeting proxies, morespecifically targeting (external) network I/O, then the new containers may needto reside on separate physical machines for subsequent attack detection. In thiscase, fission defense would be much more complex and costly. Fission defensesfor application servers might only involve spinning up containers or dynamically“containerizing” clients within their existing virtual machines and not migratingthem to application servers on other physical machines.

Of course, the overhead of defense also includes the IT resources required forthe defense itself (e.g., network I/O for stateful clients, disk I/O) and serviceoutages experienced especially by stateful nominal clients. Note that, generally,clients have little state in proxies so shuffling clients among proxies would requirerelatively little overhead compared to migrating stateful clients among replicaapplication servers [3, 6] residing on different physical machines. For example,a SIP server could have little state (once established, the media between clientsis exchanged directly without the SIP server’s involvement); however, some SIPservers monitor their active sessions, e.g., for billing purposes. For another ex-ample, clients of one streaming-media server could easily be migrated to anotherthat is mounted on a physical machine that has access to a (possibly different)disk storing the same media being streamed; in this case, server migration mayinclude suitably priming the cache of the new server.

3or by the hypervisor of a physical server managing a number of VMs, i.e., Security-as-a-Service

7

3 Developing experimental set-up

There is substantial prior work on DDoS attack experimentation [14, 18, 12, 17,15] spanning simulation, emulation, benchmarks and metrics. We are develop-ing our defense system prototype on the Amazon AWS platform. The systemuses a combination of Linux Virtual Machines (VMs) and Docker containers toimplement and test the defense approach.

3.1 Defense Experimental Setup

The defense consists of a layer of indirection proxies which are used to facilitateshuffling of clients and also serve to hide the application replica layer. The indi-rection proxies are each launched from an indirection manager VM. A single VMwill run an indirection manager and many indirection server Docker containers.The application replica layer is similar. A single VM will run a replica managerprocess which then launches multiple replica Docker containers within the VM.Each replica container executes a small management process and the protectedservice (e.g., a web server).

To scale the system, any number of VMs can be launched and in turn addreplica containers and indirection proxy containers into the defense.

The overall defense is controlled by another VM running a coordinationserver. This server is used to assign clients to both replica and indirectioncontainers. Additionally, state information about each container and VM comesto the coordination server which can bring new servers online and remove othersas needed.

To facilitate testing in the prototype, a DNS server is also used which allowsthe coordination server to register DNS names for each of the defense servers.The initial contact from the client comes to a forwarding server which redirectsthe client to the initial proxy location based on input from the coordinationserver. To fully simulate a typical n-tier architecture we have also added a back-end MySQL database VM accessible by the web tier on the replica containers.The full architecture is shown in Figure 2 below.

3.2 Test Experimental Setup

To facilitate testing we have also built test infrastructure using a similar designas the defense. The test infrastructure has a test controller VM which con-figures and launches various attacks and load benchmarks against the defensesystem. The test controller communicates with any number of Bot ManagerVMs. Each BotManager VM instantiates multiple Docker containers within theVM to launch attacks from multiple IPs and simulate many users accessing thesystem. The test architecture can create both nominal clients and attackersrunning various types of volumetric attacks (targeting proxies) and applicationlevel attacks (targeting replica application servers).

8

Figure 2: Physical architecture of the defense and test setup on AWS.

3.3 Experimental Capabilities

Using the described setup the team, has implemented multiple types of proactiveand reactive defenses:

• Random shuffling of client assignments among attacked servers (followedby attack detection) to create “clean” servers to label nominal clients.

• Random shuffling of client assignments among all servers (followed byattack detection) as a basis for a client reputation system.

• Fission of attacked servers (followed by attack detection).

• Random modification of proxy identity (IP address) to proactively defeatattacker’s reconnaissance phase [9].

Shuffling and fission can also be used proactively for purposes of load balancingto deal with overloaded servers.

In addition, the system is designed to support both stateful and statelessclients. Stateless clients are able to be redirected to other servers without trans-ferring state, e.g., HTTP(S) traffic. Stateful clients must transfer state to thenew target server, e.g., multimedia streaming or VoIP session establishment.Members of our implementation team are working on VMTorrent, an efficientstateful client reassignment platform (leveraging prior work such as [3, 6]), andporting our experimental framework to other public clouds, e.g., GCE, Azure.

9

3.4 Preliminary fission emulation experiments with churn

Attack/fission-defense emulations on AWS in static cases, and where fissionoccurs on a shorter time-scale than the lifetimes of clients, are consistent withthe binomial model described above. We now present results for a small-scaleattack/fission-defense experiment with client churn, i.e., where fission occurs ata time-scale that is on the order of client lifetimes. A representative experimentinvolved 10 replica web servers on which binary fission could be performed (ifnecessary) every 2 minutes. The assignment of a single attacker disables itsserver so that a benign client (nominal user) would get responses to its streamof http requests with error codes, otherwise code 200 or 300 (redirect) - in thisway, the service availability of each benign client is monitored during its lifetime.Containers free of attack were periodically merged to reduce the total number ofcontainers in play. Benign clients (resp., attackers) arrived every 90 (resp., 180)seconds in batches of independent size having mean 25 and standard deviation 5(resp., mean 5 and standard deviation 1). The mean lifetimes of benign clients(resp., attackers) were 60 (resp., 180) seconds with standard deviation being15% of the mean. Note that by Little’s formula, the mean number of benignclients (resp., attackers) in the system in steady state is 60 ·25/90 = 16.7 (resp.,180 · 5/180 = 5). Again, the initial number of service replicas was 10 andnot-attacked replicas are periodically merged.

Our emulation experiments ran for 16 hours and the average service avail-ability A experienced by the benign clients over their lifetimes is depicted inFigure 3: that is, x% of benign clients experience server availability A(x)% ofthe time over their lifetimes. From the figure, we see that about 44% of the be-nign clients experience no service degradation at all (100% availability), whilethe rest experience service degradation by varying degrees depending, of course,on whether they are assigned to an attacked server (that is, simultaneously as-signed with an attacking client), and also depending on the client lifetimes andfrequency of fissioning (again, every 2 minutes for this figure). Following intu-ition, reduced server availability results when the fission frequency is reduced toonce every 8 minutes, see Figure 4 where only about 32% of the benign clientsexperience no service degradation.

4 Fission: numerical performance evaluations

In the following, let

• M be the number of servers

• U = Eu be the mean number of nominal users

• K = Eκ be the mean number of attacker users

Assume an equal number of users v are assigned to each server. Let p bethe probability that a client is an attacker. The following analysis is based on

10

Figure 3: Percent service availability experienced by percentage of benign clientsover their lifetimes, with fissioning once every 2 minutes

the binomial distribution:

a(i) =

(v

i

)pi(1− p)v−i for i ∈ {0, 1, 2, ..., v},

where v =U +K

Mand p =

K

U +K.

So, a(i) is the probability that a server has i attackers clients. Note that K =Eκ = Mvp and U = Eu = Mv(1 − p). Also note that the standard deviationsσ(κ) =

√Mvp(1− p) = σ(u) so that

σ(κ)

Eκ=

√U

K(U +K)and

σ(u)

Eu=

√K

U(U +K).

So, u ≈ U and κ ≈ K with high probability when U is large and on the orderof K, i.e., K ∼ U � 1.

In the following, we will evaluate performance primarily in terms of thenumber of nominal (not attacking) clients entirely unaffected by or liberatedfrom the attack. Overhead includes number of additional containers/VMs usedand delays experienced by clients owing to the defense itself. If the number ofattackers per server is not limited, a kind of Stirling distribution of the secondkind can be used [9] instead of the binomial model sketched in the following.

11

Figure 4: Percent service availability experienced by percentage of benign clientsover their lifetimes, with fissioning once every 8 minutes

4.1 Binomial model for fission

The following model is based on the binomial distribution assuming an equalnumber of users are assigned to each server. If the number of attackers perserver is unlimited, a kind of Stirling distribution of the second kind can beused instead [9]. Define the following binomial distribution

a(·) = binom(v, p) where v =U +K

M, p =

K

U +K

i.e., a(i) =

(v

i

)pi(1− p)v−i for i ∈ {0, 1, 2, ..., v},

Recall a = binom(v, p) where v = (U +K)/M, p = K/(U +K) and let

φ(l|k; v) =

(k

l

)(v − kv/2− l

)/(v

v/2

),

where(bc

)= 0 if c < 0 or c > b.

The mean number of nominal users not attacked because their servers ini-tially had no attacking users is

Ma(0)v = M(1− p)vv

12

The mean number of nominal users liberated by n binary fission steps is

M

v∑k0=1

a(k0)Λn(k0; v)

where each binary tree rooted at a replica server initially attacked by k0 usersis accounted by Λn(k0; v).

After one binary fission step, the number of liberated nominal users is

Λ1(k0; v) =

k0∑k1=0

φ(k1|k0; v)(1{k1 = 0}v

2

+ 1{k1 = k0}v

2

)(1)

and the following recursion holds for n ≥ 2:

Λn(k0; v) =

k0∑k1=0

φ(k1|k0; v)(

Λn−1(k1;v

2)

+ Λn−1(k0 − k1;v

2)), (2)

where

Λn(k;x) =

{0 if x = kx if k = 0

This framework is easily to m-ary fissions for m > 2.To count the mean number of containers used after n fission steps (number

of leaves in the tree, a measure of overhead), replace terms v/2i with 1 in (1):

Λ1(k0; v) =

k0∑k1=0

φ(k1|k0; v) (1{k1 = 0}+ 1{k1 = k0})

= φ(0|k0; v) + φ(k0|k0; v),

and use the same recursion (2). i.e., Λn(k;x) = 1 if k = 0.Figures 5 and 6 depict typical numerical performance results using the bino-

mial model which, again, agree with simulations. Regarding these figures recallthat prior to the first fission (i.e., after zero fission steps), the mean fraction ofaffected nominal clients is 1−M(1− p)vv/U .

5 Summary

In summary, we presented an overview of proactive and reactive techniques todefend a generic proxied multiserver application in the public cloud againstDDoS attacks by botnets, including a proactive moving-target technique that

13

Figure 5: Mean fraction of affected nominal clients after one binary fission stagefor U = 50000, M = 500, 1000, 5000, and 0 ≤ K ≤ 5000

periodically changes IP addresses of proxy servers to combat the botnet’s re-connaissance phase, and a reactive shuffling approach to combat volumetricattacks targeting the proxies. We described a “fission” based approach to com-bat low-volume attacks targeting the replica application servers. A preliminaryemulation study and a numerical study based on a binomial model of the attackcharacterized the performance of the fission defense.

Attack-reactive fission and shuffling frameworks reassign clients to servers tocombat low volume attacks targeting application servers and high-volume floodstargeting proxy servers.

Preliminary numerical results of the performance of the defenses were pre-sented.

References[1] Berthier, R., and Sanders, W. Specification-based intrusion detection for advanced

metering infrastructures. In Proc. Pacific Rim Int’l Symp. on Dependable Computing(PRDC) (Dec. 2011).

[2] Carl, G., Brooks, R., Rai, S., and Kesidis, G. DoS/DDoS attack detection techniques.IEEE Internet Computing (Jan./Feb. 2006).

14

Figure 6: Mean number of unaffected and liberated nominal clients after multi-ple binary fission stages

[3] Clark, C., Fraser, K., Hand, S., Hansen, J. G., Jul, E., Limpach, C., Pratt,I., and Warfield, A. Live migration of virtual machines. In Proceedings of the 2ndconference on Symposium on Networked Systems Design & Implementation-Volume 2(2005), USENIX Association, pp. 273–286.

[4] Copos, B., Levitt, K., Bishop, M., and Rowe, J. Is Anybody Home? InferringActivity From Smart Home Network Traffic. In IEEE Security and Privacy Workshops(May 2016).

[5] Hilton, S. Dyn Analysis Summary of Friday October 21 Attack.http://dyn.com/blog/dyn-analysis-summary-of-friday-october-21-attack/, Oct. 26,2016.

[6] Hines, M. R., and Gopalan, K. Post-copy based live virtual machine migration us-ing adaptive pre-paging and dynamic self-ballooning. In Proceedings of the 2009 ACMSIGPLAN/SIGOPS international conference on Virtual execution environments (2009),ACM, pp. 51–60.

[7] Jia, Q., Sun, K., and Stavrou, A. MOTAG: Moving Target Defense Against InternetDenial of Service Attacks. In Proc. ICCCN (2013).

[8] Jia, Q., Wang, H., Fleck, D., Li, F., Stavrou, A., and Powell, W. Catch Me if YouCan: A Cloud-Enabled DDoS Defense. In Proc. IEEE/IFIP DSN (2014).

[9] Kesidis, G., Shan, Y., Stavrou, A., Fleck, D., and Konstantopoulos, T. A movingtarget and shuffle-decimation quarantine strategy to combat persistent DDoS attackson a distributed, indirection server system in the cloud. CSE Dept, PSU, Technical

15

Report CSE-16-012 (Oct 31, 2016, http://www.cse.psu.edu/research/publications/tech-reports/2016/CSE-16-012.pdf).

[10] Khandelwal, S. Even A Single Computer Can Take Down Big Servers Using Black-Nurse Attack. http://thehackernews.com/2016/11/dos-attack-server-firewall.html, Nov.13, 2016.

[11] Krebs, B. The Democratization of Censorship. http://krebsonsecurity.com/tag/ddos/,Sept. 16, 2016.

[12] Mirkovic, J., Arikan, E., Wei, S., Fahmy, S., Thomas, R., and Reiher, P. Bench-marks for DDoS Defense Evaluation. In Proceedings of MILCOM (October 2006).

[13] Mirkovic, J., Dietrich, S., Dittrich, D., and Reiher, P. Internet Denial of Service:Attack and Defense Mechanisms. Prentice Hall, 2005.

[14] Mirkovic, J., Hussain, A., Fahmy, S., Reiher, P., and Thomas, R. Accurately mea-suring denial of service in simulation and testbed experiments. IEEE Trans. Dependable& Secure Computing 6, 2 (Apr/June 2009), 81–95.

[15] Mirkovic, J., Hussain, A., Wilson, B., Fahmy, S., Reiher, P., Thomas, R., Yao,W., and Schwab, S. Towards User-Centric Metrics for Denial-Of-Service Measurement.In Proceedings of the Workshop on Experimental Computer Science (June 2007).

[16] Mirkovic, J., and Reiher, P. A taxonomy of DDoS attack and DDoS defense mecha-nisms. SIGCOMM Computer Communications Review (2004).

[17] Mirkovic, J., Reiher, P., Fahmy, S., Thomas, R., Hussain, A., Schwab, S., and Ko,C. Measuring denial of service. In Proceedings of the second workshop on quality ofprotection (QoP), in conjunction with ACM CCS (2006).

[18] Mirkovic, J., Wei, S., Hussain, A., Wilson, B., Thomas, R., Schwab, S., Fahmy, S.,Chertov, R., and Reiher, P. DDoS benchmarks and experimenter’s workbench for theDETER testbed. In Proc. of TridentCom (May 2007).

[19] http-slowloris. https://nmap.org/nsedoc/scripts/http-slowloris.html.

[20] Stavrou, A., Fleck, D., and Kolias, C. A proposed moving-target defense againstDDoS attacks repeatedly shuffles client-to-server assignments to identify and eventuallyquarantine malicious clients. IEEE Computer Magazine 49, 3 (March 2016).

[21] Venkatesan, S., Albanese, M., K.Amin, Jajodia, S., and Wright, M. A MovingTarget Defense Approach to Mitigate DDoS Attacks Against Proxy-Based Architectures.IEEE Computer and Network Security (2016).

16