Distributed Denial of Service Yi Zhang April 26, 2016

Outline DDoS Overview DDoS Attacks and Defenses DDoS Defense by Offense

DDoS Overview DDoS is a type of DoS attack where an attacker uses a large number of compromised hosts to exhaust resources (e.g. bandwidth, CPU, memory and etc.) of a target An important factor in DDoS is the amplification effect Botnet amplification Network-layer amplification and spoofed requests Application-layer amplification

DDoS Attacks Past DDoS attacks were mainly Layer 3/ Layer 4 Attacks.

Layer 3 DDoS Attack Layer 3 DDoS attack floods TCP/UDP/ICMP/IGMP packets, overloads infrastructure due to high rate processing/discarding of packets and fills up the packet queues, or saturate pipes Example UDP flood to non-listening port

Layer 4 DDoS Attack Layer 4 DDoS attack is more sophisticated. It consumes extra memory, available connections Examples TCP SYN flood TCP new connections flood TCP concurrent connections exhaustion

Layer 7 DDoS Attack Layer 7 DDoS attack abuses the server memory and performance limitations – masquerading as legitimate transactions Examples HTTP POST/GET flood DNS query flood Low rate, high impact attacks – e.g. Slowloris, HTTP POST DoS

HTTP GET DDoS Attack

HTTP POST DDoS Attack

DDoS Defenses Over-provision massively Purchase enough resources to serve attackers and good clients Detection and blocking Distinguish between good and bad clients E.g. IP address profiling/CAPTCHA-based defenses/capabilities Charging all clients in a currency An attacked server gives a client service only after it pays some currency Currency: CPU/memory cycles, money, bandwidth

DDoS Defense by Offense Michael Walfish, Mythili Vutukuru, Hari Balakrishnan, David Karger, and Scott Shenker

Overview This paper proposes a defense mechanism known as Speak Up to defend servers against application-level DDoS attacks The idea is to encourage all clients to speak up that is automatically send more traffic to an attacked server Only good clients can react to encouragement as they use a small fraction of their available bandwidth and thereby they capture more of the server

Threat Model A server is any network-accessible service with scarce computational resources An attacker is an entity this is trying to deplete server’s resources with legitimate-looking requests. Attackers send traffic from botnets and the server has no easy way to tell from a single request with ill intent Servers cannot determine a request’s difficulty a priori

Applicability Conditions Adequate Link Bandwidth There must be enough spare bandwidth to allow for speak-up inflate traffic Adequate Client Bandwidth The aggregate bandwidth of all good clients must be on the same order of magnitude (or more) than the attackers’ No pre-defined clientele Non-human clientele Unequal request or spoofing or smart bots

Design of Speak-up Observation Bad clients send requests to victimized servers at much higher rates than legitimate clients do Some factors (e.g bandwidth) prevent bad clients from sending more requests Good clients use only small portion of their available bandwidth

Design Goal Allocate resources to competing clients in proportion to their available bandwidths Design of Speak-up

Required Mechanisms Mechanism to limit the requests to the server to c per second Mechanism to reveal available bandwidth (perform encouragement) Proportional allocation mechanism – admits clients at rates proportional to their delivered bandwidth Design of Speak-up

Random Drops and Aggressive Retries

Explicit Payment Channel Let’s Bid!

When the server is overloaded, the thinner asks a requesting client to open a separate payment channel A client sends bytes on its channel and becomes a contender The thinner tracks how much bytes each contender sends When server is free, thinner admits the highest bidder and closes its channel Explicit Payment Channel

Handle Heterogeneous Requests Charging the same amount for unequal requests gives unfair advantage to attackers The thinner breaks time into qaunta and treat each request as comprising equal-sized chunks. Charge per chunk instead of per request. Explicit Payment Channel

Evaluation What are evaluated? Validating the Thinner’s allocation Speak-up’s latency and byte cost Adversarial advantage Heterogeneous network conditions Good and bad clients sharing a bottleneck Impact of Speak-up on other traffic

Setup

Validating the Thinner’s Allocation

Latency Cost Measure the length of time that clients spend on uploading dummy bytes

Byte Cost Measure the average number of bytes uploaded for served requests

Varied Bandwidth

RTT Hypothesis: RTT between a good client and the thinner will affect the allocation 5 categories, 10 clients each with RTT = 100*i ms, bw=2Mbits/s All clients good and all bad

Good and bad sharing a bottleneck

Impact of Speak-up on other traffic Bottleneck link m shared between speak-up clients and TCP endpoint H 10 good speak-up clients, 1 HTTP client downloading with wget Server capacity c = 2 requests/s

Concerns Bandwidth envy High-bandwidth good clients are “more better-off” ISPs could offer high bw proxies to low bw clients Variable bandwidth costs In some countries, customers pay their ISPs “per bit” proxy Incentives for ISPs Will speak-up gives ISPs an incentive to encourage botnets as a way to increase bandwidth demand The basic goodness of society will protect us!

Solving the wrong problem Cleaning up botnets is good, but we need to do something in the meantime Flash crowds It is reasonable to treat them as attacks Speak-up is not applicable to low bw sites at first place Concerns

Conclusion It is not sure who wants/ needs speed-up It requires a market survey to find out Speak-up does what it proposes to do

Comments Advantages The network elements are not necessary to change Speak-up only requires modifying servers and adding thinners Disadvantages The applicability regime is limited There are lots conditions to hold for it to work Speak-up may hurt edge network

Are speak-up’s assumptions reasonable? What are the use cases for Speak-up? Is it practical to implement a thinner especially for heterogeneous requests? Discussion

Reference ddos-attacks.html ddos-attacks.html

Heterogeneous Requests 1.At time t, v is active connection, u is the highest contender 2.u > v, SUSPEND v, ADMIT (RESUME) u, reset u’s payment 3.v > u, let v continue sending, but reset its payment counter for time t+1 4.ABORT requests that have been suspended too long