Transcript pptx

15-744: Computer Networking
L-23 DDoS Attacks
Overview
• Denial of service
• Traceback
• Backscatter Analysis
• Reflector Attacks
2
Denial of Service (DoS): General definition
• DoS is not access or theft of information or
services
• Instead, goal is to stop the service from operating
• Deny service to legitimate users
• Usually a temporary effect that passes as soon as
the attack stops
3
DoS: What is it?
• Crash victim (exploit software flaws)
• Attempt to exhaust victim's resources
• Network: Bandwidth
• Host
• Kernel: TCP connection state tables, etc.
• Application: CPU, memory, etc.
• Often high-rate attacks, but not always
Attacker
Victim
4
TCP Reminder: 3-Way Handshake
C
S
SYNC
Listening
SYNS, ACKC
Create TCB
Wait
ACKS
Connected
slide credit: Feamster
5
Example DoS: TCP SYN Floods
• Each arriving SYN stores state at the server
• TCP Control Block (TCB)
• ~ 280 bytes
• FlowID, timer info, Sequence number, flow control status,
out-of-band data, MSS, other options
• Attack:
• Send TCP SYN packets with bogus src addr
• Half-open TCB entries exist until timeout
• Kernel limits on # of TCBs
• Resources exhausted
requests rejected
6
Preventing SYN floods
• Principle 1: Minimize state before auth
• (3 way handshake == auth)?
• Compressed TCP state
• Very tiny state representation for half-open
conns
• Don't create the full TCB
• A few bytes per connection == can store
100,000s of half-open connections
7
SYN Cookies
• Idea: Keep no state until auth.
• In response to SYN send back self-validating token
to source that source must attach to ACK
• SYN  SYN/ACK+token  ACK+token
• Validates that the receiver's IP is valid
• How to do in SYN? sequence #s!
• top 5 bits: time counter
• next 3: Encode the MSS
• bottom 24: F(client IP, port, server IP, port, t)?
• Downside to this encoding: Loses options.
8
Overview
• Denial of service
• Traceback
• Backscatter Analysis
• Reflector Attacks
9
Distributed Denial of Service (DDoS)
• Motivation (from attacker’s perspective)
• For simple DoS, attacker must be either more
powerful than the target machine
• Can one typical client machine generate enough work
to overcome a powerful server?
• Or request must be significantly more lightweight
than response (e.g., TCP SYN flood)
• Not always the case
• Solution:
• Use many attacking machines!
10
Distributed Denial of Service (DDoS)
11
Distributed Denial of Service (DDoS)
12
Distributed Denial of Service (DDoS)
13
Why DDoS is a hard problem?
• Simple form of attack
• Just send a lot of traffic!
• Prey on the Internet’s strengths
• Simplicity of processing in routers
• Attack machines readily available
• Easy to find 10,000’s vulnerable machines of the Internet
• Attack can look like normal traffic
• E.g., HTTP requests
• Lack of Internet enforcement tools
• No traceability
• Lack of cooperation between targets
• ISPs competition, cooperation only at human timescales
• Effective solutions hard to deploy
• We can’t change the core of the Internet easily
14
Current Trend of DDoS attacks
• Volume
• Becomes larger, at most 0.5 Tbps
• Diversity
• New type of attacks are emerging
15
Evolution of (D)DoS
• Point-to-point DoS attacks
• TCP SYN floods, ping of death, etc.
Time
•
•
•
•
•
Smurf (reflection) attacks
Coordinated DoS
Multi-stage DDoS
P2P botnets
Novel amplification attacks (return
of the smurf)
16
Coordinated DoS
• Simple extension of
DoS
Attackers’
• Coordination
machines
between multiple
parties
• Can be done offband
• IRC channels,
email…
Victims
17
Typical DDoS setup circa 2005
Attacker’s machine
Masters
(Handlers)
Slaves
(Agents)
Infection/recruitment
Command & control
Assault
Victim
19
Modern Botnet setup
Zombies
(P2P)
Attackers
Attackers
Attackers
Peer-to-peer communication
Command & control
Assault
Victim
20
Smurf attacks
1. Attacker spoofs
victim’s IP address
2. Attacker sends
error-generating
packets to
reflectors
3. Reflectors all report
errors to victim
4. Victim is killed by
error messages
Attacker’s machine
Reflectors
(Amplifiers)
Victim
21
Reflector Attacks
•
•
•
•
•
•
Spoof source address
Send query to service
Response goes to victim
If response >> query, “amplifies” attack
Hides real attack source from victim
Amplifiers:
• DNS responses (50 byte query  400 byte resp)?
• ICMP to broadcast addr (1 pkt  50 pkts)
(“smurf”)
22
Amplification factors (DNS)
98 bytes
3902 bytes
39.81x amplification factor
23
Survey of amplifiers
(Rossow NDSS’14)
24
Is this used in practice?
• Intuition: attacker would scan for services
they can use as reflectors
• We can figure out if this happens by
observing scans on network telescopes
• see backscatter analysis
Pick random IP address
Network “telescope”,
e.g., empty /8 network
Asks e.g. “Runs DNS?”
25
Overview
• Denial of service
• Traceback
• Backscatter Analysis
• Reflector Attacks
26
Possible defenses I: Filtering
• Filtering at the victim’s firewall
• Likely to be useless, firewall itself can be targeted
• Filtering at the attacker’s firewall
• Routers drop packets with an “invalid” source IP
address field
• Would need near universal deployment to be
effective
• Besides, does not prevent subnet-level spoofing
• Economic incentives?
27
Ingress/Egress Filtering
Drop all packets with source
address other than
204.69.207.0/24
Internet
204.69.207.0/24
• RFC 2827: Routers install filters to drop
packets from networks that are not
downstream
• Feasible at edges; harder at “core”
28
RPF Checks
Accept packet from interface only if forwarding table entry for
source IP address matches ingress interface
Strict Mode
uRPF Enabled
10.0.18.3 from wrong interface
“A” Routing Table
Destination
10.0.1.0/24
10.0.18.0/24
Next Hop
Int. 1
Int. 2
• Unicast Reverse Path Forwarding
• Cisco: “ip verify unicast reverse-path”
• Requires symmetric routing
Slide Credit: Feamster
29
Possible defenses II: Pushback
• Pushback: rate limit flows that compose large
traffic aggregates to mitigate impact of DDoS
• Distributed solution: the whole network benefits
• Requires router modifications
• Deployment may take very long
30
Filters & Pushback
• Assumption: Can identify anomalous traffic?
• Add “filters” that drop this traffic
• Access control lists in routers
• e.g. deny ip from dave.cmu.edu to victim.com tcp port 80
• Pushback: Push filters further into network
towards the source
• Need to know where to push the filters (traceback)?
• Need authentication of filters...
• Tough problems. Filters usually deployed near
victim.
31
Possible defenses III: Traceback
• Traceback: Means of identifying source of attack
even in presence of IP spoofing
• Useful for forensics if available
• Main problem: reaction time?
• Secondary problem: requires router modification, which
itself limits deployment
• Savage et al. paper, among many others
• Perrig et al., Snoeren et al.,…
32
Possible defenses IV: Network capabilities
• DDoS attacks exploit fundamental problem: receiver has
no control over who can send traffic to it
• We need to enable receiver to stop misbehaving senders
• One possibility is to have a “default disconnect” mode
• You cannot talk to me unless I agree to talk to you first
• Network capabilities
• Capabilities need to be secured against forgery
• Who issues the capabilities?
• Capability server?
• End-host?
33
Pitfalls and fallacies
• Good host security protects against DDoS
• Unfortunately, it’s the others’ lousy security that is a
vehicle for DDoS
• Overprovisioning protects against DDoS
• You can’t be provisioned enough if 10,000+ machines
attack you
• Firewalls protect against DDoS
• One can target the firewall, and you lose your network
access anyway, or the attacker can tunnel through the
firewall
Any machine connected to the Internet is
potentially vulnerable.
34
The Need for Traceback
• Internet Protocol permits anonymity
• Attackers can “spoof” source address
• IP forwarding maintains no audit trails
• Need a traceback facility
• For a given packet, find the path to source
Savage et al., 2000
35
Traceback Schemes
•
•
•
•
•
Input Debugging
Logging
Record Route
ICMP Traceback
Probabilistic Packet
Marking
36
Traceback: Input Debugging
• Input Debugging
• Many routers can filter egress port packets and
determine ingress port.
• Problems
• Slow process to communicate packet signature
for filter to upstream providers
• Difficult to get ISP cooperation
• Only works while attack is active
37
Traceback: Logging
• Logging
• Log packets at key routers.
• Use data mining techniques to determine path.
• Problems
• Enormous resource requirements.
• Large-scale inter-provider database integration.
38
Problem
• Goal
• Determine path from packets
• Assumptions
•
•
•
•
•
•
•
•
an attacker may generate any packet
multiple attackers may conspire
attackers may be aware they are being traced
packets may be lost or reordered
attackers send numerous packets
the route between attacker and victim is fairly stable
routers are both CPU and memory limited
routers are not widely compromised
39
IP Traceback: Record Route
• Record Path
• Each router adds IP address to packet.
• Victim reads path from packet.
40
IP Traceback: Record Route
• Pro:
• fast convergence!
• Cons:
• Requires space in packet.
• Unknown path size.
• Modifying all packets in transit is expensive
41
IP Traceback: Node sampling
42
IP Traceback: Node Sampling
• Node Sampling
• Probabilistically store router address in packet using an IP
header field (IP identifier).
• Fixed space regardless of path length.
• Router distance inferred from frequency of marked packets.
• Problems
• Probability must > 0.5 to be robust against attacker.
• Large probability decreases chance of seeing packets
marked by far routers.
• Ambiguity in case of multiple attackers at the same distance
43
IP Traceback: Edge sampling
• Edge sampling
• Solve node sampling problems by encoding edges &
distance from victim in messages
• Start router sets “start” field with probability p and sets
distance to 0
• If distance is 0, router sets “end” field
• All routers increment distance
• As before, P(receiving mark from router d hops away) =
p(1 – p)d-1
• Multiple attackers can be identified since edge
identifies splits in reverse path
44
IP Traceback: Edge sampling
• Edge sampling
• Easy for victim to reconstruct path to attacker.
• Probably can be much less than for simple marking.
• Optimal is p <= 1/d.
• Effective for multiple attackers.
• Number of required packets grows linearly.
• Problems
• Impossible to trust route further away than the closest
attacker.
• Require additional space in IP packet header.
• 2x 32 bit addresses, 8 bit distance.
45
Edge sampling: Final
• Problem:
• Slow convergence in practice
• Path reconstruction does not scale well against
distributed attacks
• What if the routers are malicious?
46
Overview
• Denial of Service
• Traceback
• Backscatter Analysis
• Reflector Attacks
47
Inferring DoS Activity: Backscatter
IP address spoofing creates random backscatter.
Moore et al., 2001
48
Backscatter Analysis
• Internet telescope/backscatter measurement
Network “telescope”, e.g.,
empty /8 network
(example: SYN flood)
SYN, from IP = A
SYN-ACK, to IP = A
• By monitoring unused portion of address space,
possibility to see evidence of backscatter and infer
type/number of DDoS attacks
49
Backscatter Analysis
• Use a big block of addresses (N of them)?
• People often use a /16 or /8
• Observe X backscatter packets/sec
• How big is actual attack?
• X * (2^32 / N)?
• Assuming uniform distribution
• Sometimes called “network telescope”
50
Calculating attack rate from backscatter
Attack of m packets
n monitored addresses
232 = total IPv4
51
Summary
• DDoS is the networked version of DoS
• DDoS attacks are a real threat
• Easy to carry out
• Toolkits readily available
• Difficult to defend against
• Patching and securing one’s host is not enough
• Principally due to the nature (default connected) of the
Internet
• Prevention is difficult, due to the role other machines play
• Involving multiple jurisdictions
52
Summary
• Amplification attacks
• Abuse existing protocols
• Large amplification factors easy to achieve
• E.g., BAF of 1,000 -> 1GB/s of aggregate traffic yields
1TB/s of DDoS traffic
• Done in practice
• Although people haven’t yet fully realized they could
abuse NTP or P2P networks like Kad
53
Next lecture
• NIDS and NIPS
• Required reading:
• Bro: A System for Detecting Network Intruders in
Real-Time
• Skim:
• Network Intrusion Detection: Evasion, Traffic
Normalization, and End-to-End Protocol Semantics
• Optional:
• Honeycomb – Creating Intrusion Detection
Signatures Using Honeypots
54