denial-of-service attacks and defenses

48
Denial-of-Service Attacks and Defenses Jinyang Li

Upload: phoebe-stanley

Post on 30-Dec-2015

46 views

Category:

Documents


4 download

DESCRIPTION

Denial-of-Service Attacks and Defenses. Jinyang Li. DoS in a nutshell. Goal: overwhelm a victim site with huge workload How? Workload amplification Exploit protocol design oversights Small work for attackers  Lots of work at victims Brute-force flooding Command botnets. - PowerPoint PPT Presentation

TRANSCRIPT

Page 1: Denial-of-Service Attacks and Defenses

Denial-of-Service Attacks and Defenses

Jinyang Li

Page 2: Denial-of-Service Attacks and Defenses

DoS in a nutshell

• Goal: overwhelm a victim site with huge workload

• How?– Workload amplification

• Exploit protocol design oversights• Small work for attackers Lots of work at victims

– Brute-force flooding• Command botnets

Page 3: Denial-of-Service Attacks and Defenses

Lecture overview

• A “tour” of attacks on protocol bugs at many layers– Link, IP, TCP/UDP, DNS, applications

• In-network DoS mitigations– IP Traceback [Savage et al. SIGCOMM’00]– TVA [Yang et al. SIGCOMM’05]

Page 4: Denial-of-Service Attacks and Defenses

Link layer: attacks on 802.11[Bellardo, Savage, USENX Security ‘03]

• De-authentication attack– De-auth packets not authenticated– Attackers forge de-auth packets to AP– De-authenticated clients lose communications

• Trick a victim into setting a large NAV (max=215)– NAV is meant for (honest) nodes to reserve channel

(in RTS/CTS mode)Small work for attacker, lots of overhead at the victim

Page 5: Denial-of-Service Attacks and Defenses

Smurf ping attack

victimattacker

Ping: dst=broadcast src=victim

Page 6: Denial-of-Service Attacks and Defenses

DNS traffic amplification

• Attackers send DNS queries with forged source address

• DNS servers send response to victims• 50X traffic amplification

– DNS query size (60-byte UDP)– DNS reply (w/ extensions) 3000 bytes

Page 7: Denial-of-Service Attacks and Defenses

TCP SYN flood

client server

SYN: SNC

SYN-ACK: SNC,SNS

ACK:SNS

State:daddr,dportSaddr,sport,SNC,SNS

Page 8: Denial-of-Service Attacks and Defenses

TCP SYN flood

• Attackers flood SYN with forged source addresses• Victim keeps connection state while awaiting for ACK• Legitimate connections rejected due to state full

attacker

SYNC1

SYNC2

SYNC3

SYNC4

victim

DoS via state exhaustion

Page 9: Denial-of-Service Attacks and Defenses

TCP SYN Floods

OSBacklog

queue size

Linux 2.6 1024

FreeBSD 2.1.5 128

WinNT 4.0 6

Backlog lingers (3 minutes): victims must re-send SYN-ACKs

• Real world attacks:Blaster (2003) worm launches SYN flood against windowsupdate.com

Page 10: Denial-of-Service Attacks and Defenses

Defense: SYN cookies• Keep no state until connection is fully set up• Encode state in SNS during 3-way handshake

client server

SYN: SNC

SYN-ACK: SNC,SNS

ACK: SNS

T=5-bit counterL=Fkey(saddr,sport,daddr,dport,T)+SNC

SNS=T || L24-bits, no state

Check for SNS validity: if so, allocate state

Page 11: Denial-of-Service Attacks and Defenses

Inferring SYN Flood activity

• Backscatter: victim servers send SYN-ACK to random IPs

• Monitor unused IP address space– Unsolicited SYN-ACKs could be from SYN floods

• Found 400 SYN attacks/week [MVS USENIX Security’01]

Page 12: Denial-of-Service Attacks and Defenses

Higher level DoS

• Flood the victim’s DNS server• Send HTTP requests for large files• Make victims perform expensive ops

– SSL servers must decrypt first message

• Requests for expensive DB operations

Page 13: Denial-of-Service Attacks and Defenses

End-system solutions

Idea: increase clients’ workloads1. Computational client puzzle2. CAPCHAS

Page 14: Denial-of-Service Attacks and Defenses

Client puzzles• Make clients consume CPU before service• Example puzzle:

– Find X s.t. SHA-1(C|x) = 0 at rightmost n bits– Clients take O(2n) time to find answer– Servers take O(n) times to check

• Servers checks solutions before doing work– SSL: server checks solution before decryption

• Make clients solve puzzles only during attack

Tunable: depend on attack volume

Page 15: Denial-of-Service Attacks and Defenses

CAPTCHAS

• Make clients devote “human” resources

• Make clients solve CAPCHAS before performing DB ops during attack [Killbots NSDI’05]

Page 16: Denial-of-Service Attacks and Defenses

DoS mitigations inside the network

Page 17: Denial-of-Service Attacks and Defenses

Network-level solution: source identification

• Goal: block attacks at the source• Problem: attack traffic forge source IPs• Possible solution: ingress filtering

– ISP should only forward packets with legitimate source IP

Requires all ISPs (in all countries) to perform filtering

Page 18: Denial-of-Service Attacks and Defenses

IP traceback [Savage et al. SIGCOMM‘00]

• Goal: Determine paths to attack sources based on attack packets

• Insights:– Routers record info in packets– Victim assembles info from large amounts of attack packets

• Assumptions:– Attackers might generate any packet (with markings)– There could be 1 attack paths– Routers are not compromised– Paths are stable during attack

Page 19: Denial-of-Service Attacks and Defenses

Caveat: traceback is approximate

A1 A2 A3

R5 R6 R7

R3 R4

R2

V

Ideal traceback:A2,R6,R3,R2,V

Approximate but robust traceback:R10 R9 R3 R6 R3 R2 V

Page 20: Denial-of-Service Attacks and Defenses

Potential solutions: #1 node append

• A router appends its address to each packet

Each packet contains the entire attack path

Not enough space in packet Can be expensive to implement

Page 21: Denial-of-Service Attacks and Defenses

Potential solutions:#2 node sampling

• A router records its address in a single field with probability p

• Victim orders recorded routers into a path– Place routers with fewer samples farther away

Easy to implement p must be > 0.5

-- so forged markings cannot change path order Converges slowly Not robust against multiple attacks

Page 22: Denial-of-Service Attacks and Defenses

Traceback solution:Edge sampling

• Record edge with probability p in packets

//pkt.start, pkt.end encodes an edge//pkt.distance is the distance between edge and victimr = random(0,1)If (r < p) pkt.start = self pkt.distance=0Else if pkt.distance==0 pkt.end=self else pkt.distance++

Page 23: Denial-of-Service Attacks and Defenses

Reduce space usage

• Record edge-id = start end– Work backwards to construct path

• Record one of k fragments of edge-id at a time• Include hash(edge-id) to verify edge-id

correctness after reconstruction

a + b b + c c + d da b c d V

Result: overload 16-bit IP identifier field to mark packets

Page 24: Denial-of-Service Attacks and Defenses

Limitations: reflectors

• Reflectors are nodes that responds to traffic– Attackers forge source so responses are sent to

victims

• Examples:– DNS servers– Web servers – …

• Traceback cannot track across requests and their responses at higher levels

Page 25: Denial-of-Service Attacks and Defenses

Limitations: DDoS

• Numerous sources and reflectors attack simultaneously

• Traceback needs O(mk) to find each valid edge-id

Page 26: Denial-of-Service Attacks and Defenses

Capabilities based solution

• Traceback: detect sources after attack has happened

• Capabilities: prevent nodes from sending unwanted traffic – let receivers explicitly specify what it wants

• [Yang et al. SIGCOMM’05] [Yaar et al. IEEE S&P’04] [Anderson et al. SIGCOMM ‘04]

Page 27: Denial-of-Service Attacks and Defenses

Sketch of network capabilities

1. Source requests permission to send.2. Destination authorizes source for limited transfer, e.g, 32KB

in 10 secs• A capability is the proof of a destination’s authorization.

3. Source places capabilities on packets and sends them.4. Network filters packets based on capabilities.

cap

Page 28: Denial-of-Service Attacks and Defenses

TVA Challenges

1. Counter flooding attack– Flood initial requests– Flood (mistakenly) permitted packets

2. Design unforgeable capabilities3. Make capability verification efficient

Page 29: Denial-of-Service Attacks and Defenses

Challenge #1Problem: Request floods

• Request do not carry capabilities

Page 30: Denial-of-Service Attacks and Defenses

Solution: rate limit requests

• More problem: attackers’ requests cripple good requests

cap capcap

Page 31: Denial-of-Service Attacks and Defenses

Solution: fair queue requests based on path id

• Routers insert path identifier tags [Yarr03].• Fair queue requests using the most recent tags.

Per path-id queues1 2

1 1

Page 32: Denial-of-Service Attacks and Defenses

Problem: Flood using allowed packets

capcap

cap

cap

cap

Page 33: Denial-of-Service Attacks and Defenses

Solution: Fair queue permitted packets w.r.t.

destinations

• Per-destination queues• TVA bounds the number of queues (later)

cap

cap

cap cap

capcap

Page 34: Denial-of-Service Attacks and Defenses

• Routers stamp pre-capabilities on request packets– (timestamp, hash(src, dst, key, timestamp)

• Destinations return fine-grained capabilities– (N, T, timestamp, hash(pre-cap, N, T))– send N bytes in the next T seconds, e.g. 32KB in 10

seconds

pre1 pre2

cap1 cap2

Challenge #2: Capability design

Page 35: Denial-of-Service Attacks and Defenses

Validating capabilities

cap1 cap2 data

N, T, timestamp, hash(pre-cap, N, T)

• Each router verifies hash correctness– Check for expiration: timestamp + T < now– Check for byte bound: sent_pkts * pkt_len < N

Page 36: Denial-of-Service Attacks and Defenses

Challenge #3:Efficiently count with bounded state

• Create counting state only for fast flows– Fast flows: a capability with rate > N/T

• A link with capacity C have < fast flows – min N/T = 3.2 Kbps 312,500 records at routers

with 1Gbps link

• Implementation: expire state at rate N/T, reuse expired state

C

N /T

Page 37: Denial-of-Service Attacks and Defenses

Efficiency: bound queues

• Tag space bounds the number of request queues.• Number of destination queues is bounded by C/R

path-identifier queue

Validate capability

requests

per-destination queueregular packets

Y

Nlow priority queuelegacy packets

Queue on most recent tags

Keeps a queue if a destination receives faster than a threshold rate R

Page 38: Denial-of-Service Attacks and Defenses

Efficiency: reduce capabilities’ packet overhead

• A sender associates a nonce with a capability

• Routers cache nonce to <src,dst> mapping – nonce is found in cache => permitted packet

• Caveat: if nonce is evicted, packets are treated as legacy and put on slow paths

Page 39: Denial-of-Service Attacks and Defenses

Other DoS defenses

• Pushback filtering– Iterative “push back” traffic filters towards

attack sources along the paths– [Mahajan et al. CCR’02, Ioannidis et al. NDSS’02,

Argyraki USENIX’05]

• Overlay filtering– Offline authenticators determine who can send– Overlay performs admission control using

authenticators– [Keromytis, SIGCOMM’02, Andersen USITS’03]

Page 40: Denial-of-Service Attacks and Defenses

Conclusion

• One must design protocols with DoS attacks in mind

• Current Internet is ill-suited for coping with DDoS attacks

• Many good proposals for detection, mitigation, prevention

Page 41: Denial-of-Service Attacks and Defenses

Project administravia

• Dec 10: In-class presentation/demo • Dec 11: CS department poster/demo• Dec 17: Final report

Page 42: Denial-of-Service Attacks and Defenses

Project presentation

• 8 groups – 10 min presentation + 5 min Q&A– Demo is preferred

• 10 minutes ≈10 content slides

Page 43: Denial-of-Service Attacks and Defenses

System-based projects• (2) Explain motivation

– What is the problem you are tackling?– Why is it interesting or important?– What are existing designs/systems?– Why are they not good enough?

• (4) Explain your design– Give a strawman – Specify key challenges– Explain your solutions

• (4) Convince with results– Did you system tackle the stated problem?– Did your design prove to be essential?

Page 44: Denial-of-Service Attacks and Defenses

Measurement-based projects

• Explain goal– What problem? Similar studies not sufficient?– Your study will be useful for …?

• Designing new protocols• Debunking old myths

• Explain measurement methodology– A list of experiments and hypothesis– How each experiment proves/disproves

hypothesis• Discuss results

Page 45: Denial-of-Service Attacks and Defenses

Bottom-line

• What is your proudest technical nugget?– Convince others it’s cool

• What did you learn from your project?– Share your lessons with others

• Demo helps– Seeing is believing

Page 46: Denial-of-Service Attacks and Defenses

How can you do a good job?

• Prepare, prepare, prepare• Practice talks to non-group members

– Did they understand your problem & solution?

• Discuss your slides with me

Page 47: Denial-of-Service Attacks and Defenses

Project poster demo

• Why do it?– Seek a wider audience; publicize your work– Diverse feedbacks– Check out what others have done– Mingle with people

• CS department wide: graphics, vision etc.• Reuse talk slides for poster• Demo helps

Page 48: Denial-of-Service Attacks and Defenses

Project report

• 8 page maximum• Same flow as the talk but has room

for details• Email me by Dec 17 (Mon)

– The PDF report– A bundle of your source code