Distributed Denial of Service Attacks

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 of Speak-up 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

Random Drops and Aggressive Retries Thinner implements proportional allocation by admitting incoming requests with some probability p to make the total load reaching the sever be c Clients send repeated retries in a congestion controlled stream without waiting for please-retry signals The price for access is number of retires r However, ? = ?+? can not be calculated since B and G are not known by the server! ?

Explicit Payment Channel Conceptually, the thinner asks clients to pad their requests with dummy bytes. The price here is number of bytes But how much price should be charged? Assume both the good clients are spending everything, the average price is ?+? ? bytes per request As previous approach, B and G are not known to the server. What should we do next? Let s Bid!

Explicit Payment Channel 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 However, the auction might allow gaming where adversaries constantly pay a lower-than-average price This approach is robust to cheating In a system with regular service intervals, any client that continuously transmits an ? fraction of the average bandwidth received by the thinner gets at least an ?/2 fraction of service, regardless of how the bad clients time or divide up their bandwidth

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.

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 Each client s requests are driven by a Poisson process of rate ? requests/sec A client never allows more than w (window) of outstanding requests All requests are identical and server process a request on average every 1/c seconds. Bad clients send requests faster and have bigger window Good client: ? = 2,? = 1 Bad client: ? = 40,? = 20

Validating the Thinners Allocation 50 clients, 2Mbit/s per client Server s capacity ? = 100 requests/sec

Validating the Thinners Allocation 25 good, 25 bad ???= 100

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 5 categories, 10 clients in each category with bandwidth 0.5 * i Mbits/sec All clients good Server s capacity ? = 10 requests/s

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 30 clients, each with 2 Mbps, connected to thinner through link I = 40 Mbits/s 10 good, 10 bad clients, each with 2Mbps, connected directly to thinner ? = 10 requests/s

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!

Concerns 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

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

Discussion 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?

Reference https://conference.apnic.net/data/37/l7ddos_apricot_1393257782.pdf https://blog.sucuri.net/2015/09/analyzing-popular-layer-7-application- ddos-attacks.html https://staff.washington.edu/dittrich/misc/ddos/

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