Post on 20-Dec-2015
transcript
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
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]
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
Smurf ping attack
victimattacker
Ping: dst=broadcast src=victim
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
TCP SYN flood
client server
SYN: SNC
SYN-ACK: SNC,SNS
ACK:SNS
State:daddr,dportSaddr,sport,SNC,SNS
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
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
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
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]
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
End-system solutions
Idea: increase clients’ workloads1. Computational client puzzle2. CAPCHAS
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
CAPTCHAS
• Make clients devote “human” resources
• Make clients solve CAPCHAS before performing DB ops during attack [Killbots NSDI’05]
DoS mitigations inside the network
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
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
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
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
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
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++
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
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
Limitations: DDoS
• Numerous sources and reflectors attack simultaneously
• Traceback needs O(mk) to find each valid edge-id
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]
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
TVA Challenges
1. Counter flooding attack– Flood initial requests– Flood (mistakenly) permitted packets
2. Design unforgeable capabilities3. Make capability verification efficient
Challenge #1Problem: Request floods
• Request do not carry capabilities
Solution: rate limit requests
• More problem: attackers’ requests cripple good requests
cap capcap
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
Problem: Flood using allowed packets
capcap
cap
cap
cap
Solution: Fair queue permitted packets w.r.t.
destinations
• Per-destination queues• TVA bounds the number of queues (later)
cap
cap
cap cap
capcap
• 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
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
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
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
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
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]
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
Project administravia
• Dec 10: In-class presentation/demo • Dec 11: CS department poster/demo• Dec 17: Final report
Project presentation
• 8 groups – 10 min presentation + 5 min Q&A– Demo is preferred
• 10 minutes ≈10 content slides
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?
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
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
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
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
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