Transcript Lecture 10

Network Security:
Denial of Service (DoS),
Anonymity
Tuomas Aura
Outline
Denial of Service
1. DoS principles
2. Packet-flooding attacks on the Internet
3. Distributed denial of service (DDoS)
4. Filtering defenses
5. Most effective attack strategies
6. Infrastructural defenses
7. DoS-resistant protocol design
Anonymity
1. Anonymity and privacy
2. High-latency anonymous routing
3. Low-latency anonymous routing — Tor
2
DoS principles
3
Denial of service (DoS)
Goal of denial-of-service (DoS) attacks is to prevent
authorized users from accessing a resource, or to
reduce the quality of service (QoS) that authorized
users receive
Several kinds of DoS attacks:
Destroy the resource
Disable the resource with misconfiguration or by inducing
an invalid state
Exhaust the resource or reduce its capacity
4
Resource exhaustion attacks
Attacker overloads a system to exhaust its capacity
→ never possible to prevent completely
Examples:
Flooding a web server with requests
Filling the mailbox with spam
It is difficult to tell the difference between attack and
legitimate overload (e.g. Slashdotting, flash crowds)
For highly scalable services, may need to try
Some resource in the system under attack becomes a
bottleneck i.e. runs out first → Attacks can exploit a
limited bottleneck resource:
SYN flooding and fixed-size kernel tables
Public-key cryptography on slow processors
6
Packet-flooding attacks on
the Internet
7
Internet characteristics
Gateway
router
Internet
1.2.3.4
1.2.3.0/24
src 1.2.3.4
dst 5.6.7.8
data
Gateway
router
5.6.7.0/24
5.6.7.8
Open network: anyone can join, no central control
End to end connectivity: anyone can send packets to anyone
No global authentication or accountability
Flat-rate charging
Unreliable best-effort routing; congestion causes packet loss
Q: Could these be changed?
8
Packet-flooding attack
Ping flooding: attacker sends a flood of ping packets
(ICMP echo request) to the target
Unix command ping -f can be used to send the packets
Any IP packets can be used for flooding, not just ping
Packets can be sent with a spoofed source IP address
Q: Where is the bottleneck resource that fails first?
Typically, packet-flooding exhausts the ISP link
bandwidth, in which case the router before the
congested link will drop packets
Other potential bottlenecks: processing capacity of the gateway
router , processing capacity of the IP stack at the target host
9
Traffic amplification
Internet
1.2.3.4
Ec
h
src o req
u
ds
t 3 5.6.7 est
.4.
5.2 .8
55
e
ponosnsese
s
e
r
re.r5se.ps1p0op0nonse e
Echcoho.o4
1 p
3
E
h
c
c
ons
srE rEcc3h6.o4..7.r45e
8.rs5e.1
.
s0
.
10 0
.
3
.
sstsr5E
o
5
8
.
.
c
h
4
7
c
.
.1
d sst r5c.63..63.7
.5.8
.4..8
d dsts5
7
rtc5.6
ds st 5.6.7.8
d
5.6.7.8
3.4.5.0/24
Example: Smurf attack in the late 90s used IP broadcast
addresses for traffic amplification
Any protocol or service that can be used for DoS
amplification is dangerous! → Non-amplification is a key
design requirement
10
Traffic reflection
Internet
1.2.3.4
Ec
h
src o req
ds 5.6. uest
t3
.4. 7.8
5.6
n se
e sp o
r
o
h
6
Ec
.4.5.
src 3 .7.8
.6
d st 5
5.6.7.8
3.4.5.6
Reflection attack: get others to send packets to the target
Hides attacker IP address:
Confuses IP traceback
Some forms get around topological filtering and amplify traffic
Example:
Attacker pings various hosts, sets the source address of the ICMP
Echo Request to the attack-target address
12
Attack impact
Honest
client
Honest
packet rate
HR
Attacker
Bottleneck
link capacity
C
Server
Attack
packet rate
AR
When HR+AR < C, some packets dropped by router
With FIFO or RED queuing discipline at router, dropped
packets are selected randomly
Packet loss = (HR+AR-C)/(HR+AR) if HR+AR > C; 0 otherwise
When HR<<AR, packet loss = (AR-C)/AR
13
Attack impact
Packet loss = (HR+AR-C)/(HR+AR) if HR+AR > C; 0 otherwise
When HR<<AR, packet loss = (AR-C)/AR
→ Attacker needs to exceed C to cause packet loss
→ Packet-loss for low-bandwidth honest connections only
depends on AR
→ Any AR > C severely reduces TCP throughput for honest client
→ Some honest packets always make it thought;
to cause 90% packet loss, need attack traffic A = 10 × C,
to cause 99% packet loss, need attack traffic A = 100 × C
14
Distributed denial of
service (DDoS)
15
Botnet and DDoS
Attacker controls thousands of compromised computers and
launches a coordinated packet-flooding attack
Target
Bots
Cloud
Control network
Attacker
Botnets
Bots (also called zombies) are home or office computers
infected with virus, Trojan, rootkit etc.
Controlled and coordinated by attacker, e.g. over IRC, P2P
Hackers initially attacked each other; now used by criminals
Examples:
MyDoom worm, HTTP GET flooding against www.sco.com
Storm botnet, commercially available DDoS service
Conficker >10M hosts
Dangers:
Overwhelming flooding capacity of botnets can exhaust any link; no
need to find special weaknesses in the target
No need to spoof IP address ; filtering by source IP is hard
Q: Are criminals interested in DDoS if they can make money
from spam and phishing? What about politically motivated
attacks or rogue governments?
17
Filtering defenses
18
Filtering DoS attacks
Filtering near the target is the main defense
mechanisms against DoS attacks
Protect yourself → immediate benefit
Configure firewall to drop anything not necessary:
Drop protocols and ports no used in the local network
Drop “unnecessary” protocols such as ping or all ICMP, UDP etc.
Stateful firewall can drop packets received at the wrong state
e.g. TCP packets for non-existing connections
Application-level firewall could filter at application level;
probably too slow
Filter dynamically based on ICMP destination-unreachable
messages
(Q: Are there side effects?)
19
Flooding detection and response
Filter probable attack traffic
Network or host-based intrusion detection to
separate attacks from normal traffic based on traffic
characteristics
Limitations:
IP spoofing → source IP address not reliable for individual
packets
Attacker can evade detection by varying attack patterns
and mimicking legitimate traffic
(Q: Which attributes are difficult to mimic?)
20
Preventing source spoofing
How to prevent spoofing of the source IP address?
Ingress and egress filtering:
Gateway router checks that packets routed from a local
network to the ISP have a local source address
Generalization: reverse path forwarding
Deployment slow: selfless defense without immediate
payoff
IP traceback
Mechanisms for tracing IP packets to their source
Limited utility: take-down thought legal channels is slow;
automatic blacklisting of attackers can be misused
SYN cookies (we’ll come back to this)
21
Most effective attack
strategies
22
SYN flooding
Attackers goal: make filtering ineffective → honest
and attack packets dropped with equal probability
Target destination ports that are open to the
Internet, e.g. HTTP (port 80), SMTP (port 25)
Send initial packets → looks like a new honest client
SYN flooding:
TCP SYN is the first packet of TCP handshake
Sent by web/email/ftp/etc. clients to start communication
with a server
Flooding target or firewall cannot know which SYN packets
are legitimate and which attack traffic → has to treat all
SYN packets equally
23
DNS flooding
DNS query is sent to UDP port 53 on a DNS server
Attack amplification using DNS:
Most firewalls allow DNS responses through
Amplification: craft a DNS record for which 60-byte query
can produce 4000-byte responses (fragmented)
Botnet queries the record via open recursive DNS servers
that cache the response → traffic amplification happens at
the recursive server
Queries are sent with a spoofed source IP address, the
target address → DNS response goes to the target
24
Infrastructural defenses
25
Over-provisioning
Increase bottleneck resource capacity to cope with
attacks
Recall:
Packet loss = (HR+AR-C)/(HR+AR) if HR+AR > C; 0 otherwise
When HR<<AR, packet loss = (AR-C)/AR
→ Does doubling link capacity C help? Depends on AR:
If attacker sends 100×C to achieve 99% packet loss,
doubling C will result in 98% packet loss
If attacker sends 10×C to achieve 90% packet loss,
doubling C will result in 80% packet loss
If attacker sends 2×C to achieve 50% packet loss, doubling
C will result in zero (or minimal) packet loss
26
QoS routing
QoS routing mechanisms can guarantee service quality
to some important clients and services
Resource reservation, e.g. Intserv, RSVP
Traffic classes, e.g. Diffserv, 802.1Q
Protect important clients and connections by giving them a
higher traffic class
Protect intranet traffic by giving packets from Internet a lower
class
Prioritizing existing connections
After TCP handshake or after authentication
Potential problems:
How to take into account new honest clients?
Cannot trust traffic class of packets from untrusted sources
Political opposition to Diffserv (net neutrality lobby)
27
Some research proposals
IP traceback to prevent IP spoofing
Pushback for scalable filtering
Capabilities, e.g. SIFF, for prioritizing authorized
connections at routers
New Internet routing architectures:
Overlay routing (e.g. Pastry, i3), publish-subscribe models
Claimed DoS resistance remains to be fully proven
DoS-resistant protocol
design
29
Stateless handshake (IKEv2)
Kr
Initiator
i
HDR(A,0), SAi1, KEi, Ni
HDR(A,0), N(COOKIE)
HDR(A,0), N(COOKIE), SAi1, KEi, Ni
HDR(A,B), SAr1, KEr, Nr, [CERTREQ]
HDR(A,B), SK{ IDi, [CERT,] [CERTREQ,] [IDr,] AUTH,
SAi2, TSi, TSr }
HDR(A,B), ESK (IDr, [CERT,] AUTH, SAr2, TSi, TSr)
Responder
r
Store state
...
Responder stores per-client state only after it has received valid cookie:
COOKIE = hash(Kr , initiator and responder IP addresses)
where Kr is a periodically changing key known only by responder
→ initiator cannot spoof its IP address
No state-management problems caused by spoofed initial messages
31
TCP SYN Cookies
Client
SYN, seq=x, 0
Server
SYN|ACK, seq=y, ack=x+1
ACK, seq=x+1, ack=y+1
data
Store state
...
Random initial sequence numbers in TCP protect against IP
spoofing: client must receive msg 2 to send a valid msg 3
SYN cookie: stateless implementation of the handshake;
y = hash(Kserver, client addr, port, server addr, port)
where Kserver is a key known only to the server.
Server does not store any state before receiving and verifying the
cookie value in msg 2
Sending the cookie as the initial sequence number; in new
protocols, a separate field would be used for the cookie
32
Client puzzle (HIP)
Initiator
I
Solve puzzle
O(2K)
I1: HIT-I, HIT-R
R1: HIT-I, HIT-R,
Puzzle(I,K), (gx, PKR, Transforms)SIG
Responder
R
I2: (HIT-I, HIT-R, Solution(I,K,J),
SPI-I, gy, Transforms, {PKI}) SIG
Verify solution O(1)
R2: (HIT-I, HIT-R, SPI-R, HMAC) SIG
...
Store state,
public-key crypto
Client “pays” for server resources by solving a puzzle first
Puzzle is brute-force reversal of a K-bit cryptographic hash; puzzle
difficulty K can be adjusted according to server load
Server does not do public-key operations before verifying solution
Server can also be stateless; puzzle created like cookies above
33
Weaknesses in new
protocols
36
Routing loop
Against mobility protocols with a forwarding agent:
Mobile IP, MIPv6, NEMO etc.
Home address
I’ve moved!
Home address H1
New address H2
Mobile
computer =
attacker
H1
C
I’ve moved!
Home address H2
New address H1
H2
Another
home address
Further reading
David Moore, Geoffrey M. Voelker, and Stefan,
Savage, Inferring Internet Denial-of-Service Activity,
ACM TACS, 24(2), May 2006.
http://www.cs.ucsd.edu/~savage/papers/Tocs06.pdf
Stefan Savage, David Wetherall, Anna Karlin, and
Tom Anderson, Network Support for IP Traceback
SIFF: A Stateless Internet Flow Filter to Mitigate
DDoS Flooding Attacks
http://www.ece.cmu.edu/~adrian/projects/siff.pdf
Mahajan et al., Aggregate-Based Congestion Control
http://www.icir.org/pushback/pushback-tohotnets.pdf
38
Anonymity and privacy
39
Anonymity terminology
Identity, identifier
Anonymity — they don’t know who you are
Unlinkability — they cannot link two events or actions
(e.g. messages) with each other
Pseudonymity — intentionally allow linking of some
events to each other
E.g. sessions, payment and service access
Authentication — strong verification of identity
Weak identifier — not usable for strong authentication
but may compromise privacy
E.g. nickname, IP address, SSID, service usage profile
Authorization — verification of access rights
Does not always imply authentication (remember SPKI)
40
Anonymity in communications
Anonymity towards communication peers
Sender anonymity — receiver does not know who and where
sent the message
Receiver anonymity — can send a message to a recipient
without knowing who and where they are
Third-party anonymity — an outside observer cannot
know who is talking to whom
Unobservability — an outside observer cannot tell whether
communication takes place or not
Strength depends on the capabilities of the adversary
Anonymity towards access network
Access network does not know who is roaming there
Relate concept: location privacy
41
Who is the adversary?
Discussion: who could violate your privacy and
anonymity?
Global attacker, your government
e.g. total information awareness, retention of traffic data
Servers across the Internet, colluding commercial
interests
e.g. web cookies, trackers, advertisers
Criminals
e.g. identity theft
Employer
People close to you
e.g. stalkers, co-workers, neighbors, family members
45
Strong anonymity?
Anonymity and privacy of communications
mechanisms are not strong in the same sense as
strong encryption or authentication
Even the strongest mechanisms have serious
weaknesses
Need to trust many others to be honest
Services operated by volunteers and activists
Side-channel attacks
Anonymity tends to degrade over time for
persistent communication
46
High-latency anonymous
routing
Mix (1)
A
E
EMix(F,M1)
B
C
D
Mix
M1
EMix(H,M2)
M2
EMix(G,M3)
M3
EMix(E,M4)
M4
F
G
H
Mix is an anonymity service [Chaum 1981]
Attacker sees both sent and received messages but cannot link
them to each other → sender anonymity, third-party anonymity
against a global observer
The mix receives encrypted messages (e.g. email), decrypts them,
and forwards to recipients
48
Mix (2)
A
E
EMix(F,M1)
B
C
D
Mix
M1
EMix(H,M2)
M2
EMix(G,M3)
M3
EMix(E,M4)
M4
F
G
H
Attacker can see the input and output of the mix
Attacker cannot see how messages are shuffled in the mix
Anonymity set = all nodes that could have sent (or could be
recipients of) a particular message
49
Mix (3)
A
E
EMix(F,M1)
B
C
Mix
M1
EMix(H,M2)
M2
EMix(G,M3)
M3
EMix(E,M4)
M4
D
F
G
H
Two security requirements:
Bitwise unlinkability of input and output messages — cryptographic
property, must resist active attacks
Resistance to traffic analysis — add delay or inject dummy messages
Not just basic encryption!
Resist adaptive chosen-ciphertext attacks (IND-CCA2 i.e. NM-CCA2)
Replay prevention and integrity check needed at the mix
Examples of bad mix designs:
Missing random initialization vector, padding or freshness
Malleable encryption, e.g. stream cipher, or no integrity check
FIFO order of delivering messages
50
Mixing in practice
Threshold mix — wait to receive k messages before
delivering
Anonymity set size k
Pool mix — mix always buffers k messages, sends one
when it receives one
Both strategies add delay → high latency
Not all senders and receivers are always active
In a closed system, injecting cover traffic can fix this; in the
Internet, not
Real communication (email, TCP packets) does not
comprise single, independent messages but common
traffic patterns such as connections
Attacker can observe beginning and end of connections
Attacker can observe requests and response pairs
→ statistical attacks
51
Who sends to whom?
Round 1
A
B
C
D
Round 2
E
F
G
H
A
B
C
D
Round 4
A
B
C
D
E
F
G
H
A
B
C
D
Round 5
E
F
G
H
A
B
C
D
Round 7
A
B
C
D
Round 3
Round 6
E
F
G
H
A
B
C
D
Round 8
E
F
G
H
A
B
C
D
E
F
G
H
E
F
G
H
Round 9
E
F
G
H
A
B
C
D
E
F
G
H
Threshold mix with threshold 3
52
Anonymity metrics
Size of the anonymity set: k-anonymity
Suitable for one round of threshold mixing
Problems with k-anonymity:
Multiple rounds → statistical analysis based on understanding
common patterns of communications can reveal who talks to whom,
even if k for each individual message is high
Pool mix → k = ∞
Entropy: E = Σi=1…n (pi ∙ log2pi)
Measures the amount of missing in information in bits: how much
does the attacker not know
Can measure entropy of the sender, recipient etc.
Problems with measuring anonymity:
Anonymity of individual messages vs. anonymity in a system
Depends on the attacker’s capabilities and background information
Anonymity usually degrades over time as attacker collects more
statistics
53
Trusting the mix
The mix must be honest
Example: anonymous remailers for email
anon.penet.fi 1993–96
→ Route packets through multiple mixes to avoid
single point of failure
Attacker must compromise all mixes on the route
Compromising almost all may reduce the size of the
anonymity set
54
Mix network (1)
55
Mix network (2)
Mix network is just a distributed implementation of mix
56
Mix networks
Mix cascade — all messages from all senders are routed through
the same sequence of mixes
Good anonymity, poor load balancing, poor reliability
Free routing — each message is routed independently via multiple
mixes
Other policies between these two extremes
But remember that the choice of mixes could be a weak identifier
Onion encryption:
Alice → M1: EM1(M2,EM2(M3,EM3(Bob,M)))
M1 → M2: EM2(M3,EM3(Bob,M))
M2 → M3: EM3(Bob,M)
M3 → Bob: M
Encryption at every layer must provide bitwise unlinkability
→ detect replays and check integrity
→ for free routing, must keep message length constant
Re-encryption mix — special crypto that keeps the message length
constant with multiple layers of encryption
57
Sybil attack
Attack against open systems which anyone can join
Mixes tend to be run by volunteers
Attacker creates a large number of seemingly
independent nodes, e.g. 50% off all nodes →
some routes will go through only attacker’s nodes
Defence: increase the cost of joining the network:
Human verification that each mix is operated by a different
person or organization
The IP address of each mix must be in a new domain
Require good reputation of some kind that takes time and
effort to establish
Select mixes in a route to be at diverse locations
Sybil attacks are a danger to most P2P systems, not just
anonymous routing
E.g. reputation systems, content distribution
58
Other attacks
(n-1) attack
Attacker blocks all but one honest sender, floods all mixes
with its own messages, and finally allows one honest
sender to get though → easy to trace because all other
packets are the attacker’s
Potential solutions: access control and rate limiting for
senders, dummy traffic injection, attack detection
Statistical attacks
Attacker may accumulate statistics about the
communication over time and reconstruct the senderreceiver pairs based on its knowledge of common traffic
patterns
59
Receiver anonymity
Alice distributes a reply onion:
EM3(M2,k3,EM2(M1,k2,EM1(Alice,k1,EAlice(K))))
Messages from Bob to Alice:
Bob → M3: EM3(M2,k3,EM2(M1,k2,EM1(Alice,k1,EAlice(K)))), M
M3 → M2: EM2(M1,k2,EM1(Alice,k1,EAlice(K))), Ek3(M)
M2 → M1: EM1(Alice,k1,EAlice(K)), Ek2(Ek3(M))
M1 → Alice: EAlice(K), Ek1(Ek2(Ek3(M)))
Alice can be memoryless:
ki = h(K, i)
60
Low-latency anonymous
routing
61
Tor
“2nd generation onion router”
Mix networks are ok for email but too slow for interactive
use like web browsing
New compromise between efficiency and anonymity:
No mixing at the onion routers
All packets in a session, in both directions, go through the same
routers
Short route, always three onion routers
Tunnels based on symmetric cryptography
No cover traffic
Protects against local observers at any part of the path, but
vulnerable to a global attacker
More realistic attacker model: can control some nodes, can
sniff some links, not everything
SOCKS interface at clients → works for any TCP connection
62
Tunnels in Tor
Alice
OR1
OR2
[Danezis]
OR3
Bob
Authenticated DH
Alice – OR1
K1
Alice not
authenticated,
only the ORs
K1
Encrypted with K1
Authenticated DH, Alice – OR2
K2
K1,K2
Encrypted with K1, K2
K1,K2,K3
Authenticated DH, Alice – OR3
K3
Encrypted with K1, K2, K3
TCP connection Alice –Bob
Last link
unencrypted
63
Tunnels in Tor
Alice
OR1
OR2
[Danezis]
OR3
Bob
Authenticated DH
Alice – OR1
K1
Alice not
authenticated,
only the ORs
K1
Encrypted with K1
Authenticated DH, Alice – OR2
K2
K1,K2
Encrypted with K1, K2
K1,K2,K3
Authenticated DH, Alice – OR3
K3
Encrypted with K1, K2, K3
Additionally, linkwise
TLS connections:
Alice–OR1–OR2–OR3
TCP connection Alice –Bob
Last link
unencrypted
64
Tor limitations (1)
Identifying packet streams is very easy
Passive fingerprinting by packet size, timing
Active traffic shaping (stream watermarking)
→ Anonymity compromised if attacker can see or control
the first and last link
Includes attackers who own the first and last OR
→ longer routes do not help
If c is the fraction of compromised ORs, probability of
compromise is c2
Why three routers?
Out of habit?
Attacker in control of 1st or last router cannot immediately go
and compromise the other when there is a middle router
65
Tor limitations (2)
Client must know the addresses and public keys of
all onion routers
If client only knows a small subset of routers, it will always
choose all three routers from this subset → implicit
identifier
E.g. client knows 10 out of 1000 routers = 1%
→ Attacker in control of the last router can narrow down
the client identity to (0.01)2 = 0.01% of all clients
→ Attacker in control of two last routers can narrow the
client identity down to (0.01)3 = 0.0001% of all clients
Blacklisting of entry or exit nodes
66
Applications of anonymous routing
Censorship resistance, freedom or speech
Protection against discrimination, e.g. geographic
access control or price differentiation
Business intelligence, police investigation, political
and military intelligence
Whistle blowing, crime reporting
Electronic voting
Crime, forbidden and immoral activities?
67