Auto-Scaling Attacks and Defenses: Technical Report

Technical Report: Auto-Scaling Attacks
and Price Evaluation
A NALYSIS AND F URTHER E VALUATION
7
Analysis
We begin by analyzing the EDoS attack vector; the analysis
for the DoS attack is similar. First, we deal with the question
of how much damage can an attacker cause, using different
attack strategies.
6
Avg. Cost per Hour (USD)
In this technical report we continue the analysis of the
auto-scaling attacks and defenses presented in our main paper,
submitted to CCS [1], discuss additional empirical results, and
present CDN-on-Demand pricing evaluation and comparison
with commercial CDN providers.
5
4
3
2
1
0
1. Without Attack
2. Attacked
3. Attacked, R-Measure Deployed
60
Let ri represent the system scale level with i unjustified
resources (e.g., number of servers); in particular, r0 is the scale
level in benign environment. Next, let ρ represent the attacker’s
resources that need to be applied on the system in order to scale
it up once, i.e., from ri to ri+1 1 . Hence, in order to repeatedly
scale-up the system n times, from r0 to rn , an attacker has to
apply a total of at least ρ·n·(n+1)
of his resources.
2
To maximize the impact, the efficient attacker predicts
the measurement intervals; he wastes no resources while the
system is in ‘cooldown’ and applies just enough of them to
trigger a scale-up during the measurement interval.
We simplify and assume that the attacker’s resources are
replenished linearly with some steady rate ξ; i.e., over interval
of length t, attacker receives ξ · t resources. Denote by m
and c the length of the measurement and cooldown intervals
respectively; note that m < c (e.g., Amazon EC2, the defaults
are m = 1 minute and c = 5 minutes). Then, in order for the
attacker to cause n consecutive scale-ups, he must start with
− ξ · (m + c) · (n − 1) resources.
at least ρ·n·(n+1)
2
Next, we turn to the question of which system scale rn is
sustainable by the attacker. Suppose the attacker can no longer
scale-up the system once the latter allocates n resources (e.g.,
when the attacker exhausts his resources, or after reaching
the system’s upper scale limit). The attacker may now choose
between pressing on the attack, or recover his resources by
letting the system scale-down. In order to keep the system at
rn , the attacker needs to replenish his resources at a substantial
rate of ξ ≥ ρ·n
m ; we assume this rate is unsustainable by our
weak attacker.
However, the attack is feasible even for a much weaker
attacker (with a lesser ξ). This attacker chooses to temporarily
lift the pressure to regain his resources, followed by renewal
of his attack, causing fluctuation. Let φ be the fluctuation size,
1 Notice
that ρ does not depend on i, since the metric is system-wide, rather
than per-instance.
80
100
120
Upper Threshold (Number of Clients)
Fig. 1: EDoS attack and defense. Effect of threshold on system
cost.
measured in consecutive scale-downs after which the attack
renews. We have seen that ξφ=0 ≥ ρ·n
m . For φ = 1, the attacker
launches his attack to bring the system to rn , and then lets it
scale-down to rn−1 before renewing the attack; hence, ξφ=0 ≥
ρ·n
ξφ=1 ≥ 2·(m+c)
, and in the general case
mρn −
ξφ=m ≥
m−1
P
i·ρ
i=0
2 · (m + c)
=
2mρn − ρm · (m − 1)
4m · (m + c)
(1)
We see that the fluctuated attack requires significantly less
resources as φ grows, and is feasible even for weak attackers.
The average effect, or damage, of a sustainable, fluctuating
attack that lasts T minutes is therefore T · (n − φ2 ), measured
in needlessly spent resources by the system.
Lastly, we analyze the probabilistic defense, to identify
which values of measurement probability p will make it
infeasible for the attacker to cause the system to allocate rn
resources. The probabilistic defense measures the system’s
performance with probability p every measurement interval.
Hence the attacker is expected to launch the attack p1 times
until he succeeds to manipulate a measurement. Before the
attack begins, a single cooldown period is followed by probabilistic measurement intervals, which provide the attacker with
m
(c + m
p ) · ξ resources. However, launching the attack p times
requires replenishment of
(c+ m
p )
m
p
·ξ =
c·p+m
m
· ξ resources per
interval; therefore, a scale level rn for which n ≥
infeasible.
c·p+m
m·ρ
· ξ is
7
1. Attacked
2. Attacked, R-Measure Deployed
CDN Provider
Out Traffic cost
(USD/GB)
SSL fee range
(USD/month)
Use-case Cost
(USD/month)
Akamai
not published
not published
Refuses service to
smaller sites
Cloudflare
0
200
200 (costs are
reported to grow in
case of DoS attack)
Amazon Cloudfront
0.08
600
680
Microsoft Azure CDN
0.0725
39
111.5
Fastly
0.08
100-1500 + initial fee
of 500
180
Cdn77
0.0395
58.25
97.75
MAXCDN
0.0575
39
96.5
Cachefly
0.2945
99-409
393.5
CDN-on-Demand, DoS / flash
crowds 5% of the time
0.0619
0
16.605
CDN-on-Demand, no DoS / flash
crowds
0.0504
0
5.04
6.5
Avg. Cost per Hour (USD)
6
5.5
5
4.5
4
3.5
3
2.5
0
400
800
1200
Attacker Power (Number of Bots)
Fig. 3: Pricing Comparison of CDN Providers. Collected
during June-July 2015.
Fig. 2: EDoS attack and defense. Effect of attacker’s power on
system cost.
offer various DoS-protection plans. These pricing models are
contrasted against CDN-on-Demand which leverages selected
public clouds only when handling a flash-crowd or DoS attack;
in benign scenarios, CDN-on-Demand is dormant running only
watchdogs to monitor the content-origin server and incurring
minimal costs.
Additional Experimental Results
To further examine the effectiveness and efficiency of the
EDoS attack vector, as well as the proposed defense, we
conduct several additional experiments. In the measurements
below we use the setup described in the main paper.
a) Methodology: To estimate the expenses of using
commercial CDNs and CDN-on-Demand, we collected the
advertised pricing data from different CDNs, presented in Figure 3. The figure shows the costs of the following key services,
provided by CDNs: outgoing communication (incoming traffic
is typically free) and SSL/TLS support. For CDN-on-Demand
we also measure the cost for operating the cloud machines
(watchdogs and proxies), which is low when the system is
dormant (since we only deploy watchdogs) and higher when
under heavy-load. In order to compare the price-tag of existing
CDNs against CDN-on-Demand, we measured the total cost
of using a CDN for one month. We assume a small/medium
HTTPS website (i.e., requiring SSL/TLS support), using defenses against DoS attacks (if provided), and serving 1TB
of data to legitimate clients (if the CDN charges according
to client location, we assume that only the nearest ‘most
low-cost’ clients connect). We measure the cost of operating
CDN-on-Demand under two scenarios: (1) a benign month
without flash-crowds or DoS attacks (i.e., CDN-on-Demand is
dormant), and (2) a month with DoS floods or flash crowds
happening 5% of the time.
First, we examine the effect of changing the threshold
values. When the average metric being measured (such as CPU
workload or network traffic) surpasses the upper threshold
value, the system scales up; hence, raising this threshold should
decrease the attack effectiveness, as the attacker must use more
of his resources to achieve a scale-up. This is demonstrated
in Figure 1, where we measure the average hourly cost of
renting cloud machines for different threshold values. We note,
however, that increasing the threshold also results in mapping
additional clients to each server, causing heavier workload and
longer latency.
Second, we examine the influence of the attacker’s strength.
We measure the system cost with several attackers; starting
with the weakest attacker that has no zombie machines and
gradually increase the number of zombies under attacker’s
control. Figure 2 demonstrates the results; we observe that even
a relatively weak attacker, controlling 200 zombies, causes
a 30% increase in cost. In this experiment, we limit the
maximum number of cloud servers; after reaching this limit,
the attacker does not benefit from additional (over 800) zombies. We also notice that our R-Measure defense successfully
mitigates even stronger attackers (compare lines 1 and 2 in
Figure 2).
b) Our Results: Our price survey shows that CDN-onDemand’s price-tag in benign months is at least an order of
magnitude lower than the ‘next in line’ CDN service. In the
second case, where the system handles flash crowds and DDoS
attacks, CDN-on-Demand’s cost is 5.8 times lower than the
following commercial CDN service. This is expected, since
optional services such as CDNs’ SSL/TLS support and traffic
filters incur significant costs, while most clouds support these
services without fee (in particular EC2 and GCE where we
deploy CDN-on-Demand). In addition, CDN-on-Demand is
only deployed when the need for extra servers and robust
infrastructure exists (e.g., 5% of the time). We note that despite
the fact that some CDN providers offer ‘free’ DoS protection,
there have been complaints that the free service is limited
Pricing: Survey and Comparison
In this subsection we provide a pricing survey for commercial CSPs and CDNs, and compare these usage costs to
the estimated cost of using CDN-on-Demand.
CDN providers offer a variety of pricing plans and optional
services; in particular, some providers have only fixed-price
plans, while others offer elastic pay-per-use services. Prices
may also vary according to the geographic location of deployed services and connecting clients. Many providers also
2
(e.g., see [2], [3]). Finally, we note that some CDN providers,
including Akamai, the most popular provider, do not reveal
their pricing plans. We also contacted Akamai to query about
their prices and found that they refuse to provide service for
our small website (this paper’s focus).
R EFERENCES
[1]
[2]
[3]
Cdn-on-demand: Fighting dos with untrusted clouds. Submitted anonymously to ACM CCS 2015.
EASTDAKOTA . How much traffic is too much traffic for cloudflare?
https://news.ycombinator.com/item?id=5214480, Jan 2013.
HOSTGATORHOST . Cloudflare free plan can be good for save ddos attack? http://www.webhostingtalk.com/showthread.php?t=1358852, Mar
2014.
3