denial-of-service attacks and defenses jinyang li
Post on 20-Dec-2015
223 views
TRANSCRIPT
![Page 1: Denial-of-Service Attacks and Defenses Jinyang Li](https://reader035.vdocuments.us/reader035/viewer/2022062313/56649d415503460f94a1bfe6/html5/thumbnails/1.jpg)
Denial-of-Service Attacks and Defenses
Jinyang Li
![Page 2: Denial-of-Service Attacks and Defenses Jinyang Li](https://reader035.vdocuments.us/reader035/viewer/2022062313/56649d415503460f94a1bfe6/html5/thumbnails/2.jpg)
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 Jinyang Li](https://reader035.vdocuments.us/reader035/viewer/2022062313/56649d415503460f94a1bfe6/html5/thumbnails/3.jpg)
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 Jinyang Li](https://reader035.vdocuments.us/reader035/viewer/2022062313/56649d415503460f94a1bfe6/html5/thumbnails/4.jpg)
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 Jinyang Li](https://reader035.vdocuments.us/reader035/viewer/2022062313/56649d415503460f94a1bfe6/html5/thumbnails/5.jpg)
Smurf ping attack
victimattacker
Ping: dst=broadcast src=victim
![Page 6: Denial-of-Service Attacks and Defenses Jinyang Li](https://reader035.vdocuments.us/reader035/viewer/2022062313/56649d415503460f94a1bfe6/html5/thumbnails/6.jpg)
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 Jinyang Li](https://reader035.vdocuments.us/reader035/viewer/2022062313/56649d415503460f94a1bfe6/html5/thumbnails/7.jpg)
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 Jinyang Li](https://reader035.vdocuments.us/reader035/viewer/2022062313/56649d415503460f94a1bfe6/html5/thumbnails/8.jpg)
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 Jinyang Li](https://reader035.vdocuments.us/reader035/viewer/2022062313/56649d415503460f94a1bfe6/html5/thumbnails/9.jpg)
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 Jinyang Li](https://reader035.vdocuments.us/reader035/viewer/2022062313/56649d415503460f94a1bfe6/html5/thumbnails/10.jpg)
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 Jinyang Li](https://reader035.vdocuments.us/reader035/viewer/2022062313/56649d415503460f94a1bfe6/html5/thumbnails/11.jpg)
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 Jinyang Li](https://reader035.vdocuments.us/reader035/viewer/2022062313/56649d415503460f94a1bfe6/html5/thumbnails/12.jpg)
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 Jinyang Li](https://reader035.vdocuments.us/reader035/viewer/2022062313/56649d415503460f94a1bfe6/html5/thumbnails/13.jpg)
End-system solutions
Idea: increase clients’ workloads1. Computational client puzzle2. CAPCHAS
![Page 14: Denial-of-Service Attacks and Defenses Jinyang Li](https://reader035.vdocuments.us/reader035/viewer/2022062313/56649d415503460f94a1bfe6/html5/thumbnails/14.jpg)
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 Jinyang Li](https://reader035.vdocuments.us/reader035/viewer/2022062313/56649d415503460f94a1bfe6/html5/thumbnails/15.jpg)
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 Jinyang Li](https://reader035.vdocuments.us/reader035/viewer/2022062313/56649d415503460f94a1bfe6/html5/thumbnails/16.jpg)
DoS mitigations inside the network
![Page 17: Denial-of-Service Attacks and Defenses Jinyang Li](https://reader035.vdocuments.us/reader035/viewer/2022062313/56649d415503460f94a1bfe6/html5/thumbnails/17.jpg)
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 Jinyang Li](https://reader035.vdocuments.us/reader035/viewer/2022062313/56649d415503460f94a1bfe6/html5/thumbnails/18.jpg)
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 Jinyang Li](https://reader035.vdocuments.us/reader035/viewer/2022062313/56649d415503460f94a1bfe6/html5/thumbnails/19.jpg)
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 Jinyang Li](https://reader035.vdocuments.us/reader035/viewer/2022062313/56649d415503460f94a1bfe6/html5/thumbnails/20.jpg)
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 Jinyang Li](https://reader035.vdocuments.us/reader035/viewer/2022062313/56649d415503460f94a1bfe6/html5/thumbnails/21.jpg)
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 Jinyang Li](https://reader035.vdocuments.us/reader035/viewer/2022062313/56649d415503460f94a1bfe6/html5/thumbnails/22.jpg)
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 Jinyang Li](https://reader035.vdocuments.us/reader035/viewer/2022062313/56649d415503460f94a1bfe6/html5/thumbnails/23.jpg)
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 Jinyang Li](https://reader035.vdocuments.us/reader035/viewer/2022062313/56649d415503460f94a1bfe6/html5/thumbnails/24.jpg)
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 Jinyang Li](https://reader035.vdocuments.us/reader035/viewer/2022062313/56649d415503460f94a1bfe6/html5/thumbnails/25.jpg)
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 Jinyang Li](https://reader035.vdocuments.us/reader035/viewer/2022062313/56649d415503460f94a1bfe6/html5/thumbnails/26.jpg)
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 Jinyang Li](https://reader035.vdocuments.us/reader035/viewer/2022062313/56649d415503460f94a1bfe6/html5/thumbnails/27.jpg)
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 Jinyang Li](https://reader035.vdocuments.us/reader035/viewer/2022062313/56649d415503460f94a1bfe6/html5/thumbnails/28.jpg)
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 Jinyang Li](https://reader035.vdocuments.us/reader035/viewer/2022062313/56649d415503460f94a1bfe6/html5/thumbnails/29.jpg)
Challenge #1Problem: Request floods
• Request do not carry capabilities
![Page 30: Denial-of-Service Attacks and Defenses Jinyang Li](https://reader035.vdocuments.us/reader035/viewer/2022062313/56649d415503460f94a1bfe6/html5/thumbnails/30.jpg)
Solution: rate limit requests
• More problem: attackers’ requests cripple good requests
cap capcap
![Page 31: Denial-of-Service Attacks and Defenses Jinyang Li](https://reader035.vdocuments.us/reader035/viewer/2022062313/56649d415503460f94a1bfe6/html5/thumbnails/31.jpg)
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 Jinyang Li](https://reader035.vdocuments.us/reader035/viewer/2022062313/56649d415503460f94a1bfe6/html5/thumbnails/32.jpg)
Problem: Flood using allowed packets
capcap
cap
cap
cap
![Page 33: Denial-of-Service Attacks and Defenses Jinyang Li](https://reader035.vdocuments.us/reader035/viewer/2022062313/56649d415503460f94a1bfe6/html5/thumbnails/33.jpg)
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 Jinyang Li](https://reader035.vdocuments.us/reader035/viewer/2022062313/56649d415503460f94a1bfe6/html5/thumbnails/34.jpg)
• 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 Jinyang Li](https://reader035.vdocuments.us/reader035/viewer/2022062313/56649d415503460f94a1bfe6/html5/thumbnails/35.jpg)
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 Jinyang Li](https://reader035.vdocuments.us/reader035/viewer/2022062313/56649d415503460f94a1bfe6/html5/thumbnails/36.jpg)
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 Jinyang Li](https://reader035.vdocuments.us/reader035/viewer/2022062313/56649d415503460f94a1bfe6/html5/thumbnails/37.jpg)
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 Jinyang Li](https://reader035.vdocuments.us/reader035/viewer/2022062313/56649d415503460f94a1bfe6/html5/thumbnails/38.jpg)
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 Jinyang Li](https://reader035.vdocuments.us/reader035/viewer/2022062313/56649d415503460f94a1bfe6/html5/thumbnails/39.jpg)
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 Jinyang Li](https://reader035.vdocuments.us/reader035/viewer/2022062313/56649d415503460f94a1bfe6/html5/thumbnails/40.jpg)
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 Jinyang Li](https://reader035.vdocuments.us/reader035/viewer/2022062313/56649d415503460f94a1bfe6/html5/thumbnails/41.jpg)
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 Jinyang Li](https://reader035.vdocuments.us/reader035/viewer/2022062313/56649d415503460f94a1bfe6/html5/thumbnails/42.jpg)
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 Jinyang Li](https://reader035.vdocuments.us/reader035/viewer/2022062313/56649d415503460f94a1bfe6/html5/thumbnails/43.jpg)
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 Jinyang Li](https://reader035.vdocuments.us/reader035/viewer/2022062313/56649d415503460f94a1bfe6/html5/thumbnails/44.jpg)
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 Jinyang Li](https://reader035.vdocuments.us/reader035/viewer/2022062313/56649d415503460f94a1bfe6/html5/thumbnails/45.jpg)
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 Jinyang Li](https://reader035.vdocuments.us/reader035/viewer/2022062313/56649d415503460f94a1bfe6/html5/thumbnails/46.jpg)
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 Jinyang Li](https://reader035.vdocuments.us/reader035/viewer/2022062313/56649d415503460f94a1bfe6/html5/thumbnails/47.jpg)
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 Jinyang Li](https://reader035.vdocuments.us/reader035/viewer/2022062313/56649d415503460f94a1bfe6/html5/thumbnails/48.jpg)
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