Transcript Slides from Juergen Brendel`s talk.

Distributed Denial of Service
The current state and counter measures
Juergen Brendel
CTO & Architect
Esphion Ltd.
The University of Auckland, June 3, 2003
Copyright © 2003
The University of Auckland, 2003
Agenda
1.
DoS attacks: Background
2.
DDoS techniques and tools
3.
Attack detection
4.
Possible defenses
5.
Filters
6.
Specialized DDoS solutions
Copyright © 2003
The University of Auckland, 2003
Agenda
1.
DoS attacks: Background
2.
DDoS techniques and tools
3.
Attack detection
4.
Possible defenses
5.
Filters
6.
Specialized DDoS solutions
Copyright © 2003
The University of Auckland, 2003
The nature of DoS
• DoS: Denial of Service, NOT intrusion or data theft!
• Aim:
Making sure that legitimate users of the
site / server / resource cannot be served
• Effects:
–
–
–
–
–
–
Business is essentially ‘closed’
Disgruntled customers
Damaged customer/partner relationships
Bad press
Loss in advertising revenue
Higher bandwidth-cost for victim (some attacks)
Copyright © 2003
The University of Auckland, 2003
The two natures of DoS
• Attacks on specific weaknesses:
– Using OS or application bugs to crash routers or servers
– Poisoning DNS
– Reconfiguring routers
• Resource consuming attacks:
–
–
–
–
–
Memory on servers
Router packet forwarding capacity
Name servers
Network bandwidth
Often accomplished by flooding
Copyright © 2003
The University of Auckland, 2003
Flood attacks
• Massive amounts of packets result in:
–
–
–
–
Clogged network connections
Crashed routers or servers
Higher bandwidth cost for victim
“Parking 500 cars in your driveway…”
• Typically cannot be defended against with patches
• Often using many compromised systems as traffic
generators (“Zombies” , “Agents” or “Bots”)
• Distributed Denial of Service (DDoS) attacks
• Tools available for download
• Result:
Flood attacks are easy (ScriptKiddies)!
Copyright © 2003
The University of Auckland, 2003
Targets
• ISPs
• News sites
• E-commerce sites
• Financial institutions
• Government sites
• Dialup accounts and other home users (!)
• IRC servers (!)
• Network infrastructure (!)
Copyright © 2003
The University of Auckland, 2003
Motivation
• Sabotage
• Terrorism
• Blackmailing
• Political protest
• Boredom
• Thrill and headlines (bragging rights)
• Misdirected, clueless anger
Copyright © 2003
The University of Auckland, 2003
Attack history
• Feb 2000 estimated US$100 million in lost revenue
– Done by 15 year old Canadian hacker: Mafiaboy
•
•
•
•
•
•
•
•
Yahoo
Buy.com
eBay
CNN
Amazon.com
E-trade
Datek
ZDNet
3 hours
3 hours
90 minutes
120 minutes
1 hour
90 minutes
30 minutes
3 hours
– Was only caught because he bragged about it
Copyright © 2003
The University of Auckland, 2003
Harsh punishment…
Copyright © 2003
The University of Auckland, 2003
Attack history (continued)
• Jan 2001 US$10 million damage by Microsoft attack
• May 2001 Whitehouse site down for 6 hours
• June 2001 CERT downed twice for more than seven
hours
• Aug 2001 Whitehouse targeted by CodeRed (fizzles)
• Nov 2001 Latest trend: Attacking routers
• June 2002 Fox network web-site attacked
• Today
4000 flood-style DoS attacks per week (!)
Copyright © 2003
The University of Auckland, 2003
Agenda
1.
DoS attacks: Background
2.
DDoS techniques and tools
3.
Attack detection
4.
Possible defenses
5.
Filters
6.
Specialized DDoS solutions
Copyright © 2003
The University of Auckland, 2003
Making a zombie / agent / bot
• Compromise an unsuspecting host:
– RootKits
– Trojans
– Worms / Viruses
• Preferred target:
–
–
–
–
‘Always On’ systems
Connected via cable-modem, DSL, etc.
Mostly home-computers, servers if possible
More Windows machines
• Two-stage attack
– First the Zombie is compromised, tools are installed…
– … followed by the actual DDoS attack on another victim
Copyright © 2003
The University of Auckland, 2003
Attack network
Attacker
Handler
Handler
Handler
Agent Agent Agent Agent Agent Agent
Victim
Copyright © 2003
The University of Auckland, 2003
Spoofing the source address
• Two reasons for spoofing:
– Attack is difficult to track
– A third party can get into trouble
– Can be used to utilize third-party (SMURF, Reflection)
• Not all DDoS attacks use spoofed addresses:
– Some UDP flood tools don’t spoof the source
– SYN-flood always spoofs
– SMURF attack packets have proper source, but reply to a
spoofed address
Copyright © 2003
The University of Auckland, 2003
Types of flood attacks
• ICMP flood
• UDP flood
– Source address not always
spoofed, so that root access
is not necessary
• SYN flood
– Starts TCP-handshake,
without completing
– Server sends ACK packet
and allocates memory
– Consumes bandwidth and
memory resource
• Fragmentation attack
– Missing fragments overload
reassembly queues on
server
– Sending large number of
ICMP packets
• SMURFs
– Send a spoofed ICMP-EchoRequest packet to a ‘SMURF
amplifier’ network
– Directed broadcast
– All hosts in amplifier
network reply to spoofed
address: The actual victim
• More TCP floods
–
–
–
–
Copyright © 2003
Stream attack
Null flood
Mixed flags
Reflection attack
The University of Auckland, 2003
Types of flood attacks
• ICMP flood
• UDP flood
– Source address not always
spoofed, so that root access
is not necessary
• SYN flood
– Starts TCP-handshake,
without completing
– Server sends ACK packet
and allocates memory
– Consumes bandwidth and
memory resource
• Fragmentation attack
– Missing fragments overload
reassembly queues on
server
– Sending large number of
ICMP packets
• SMURFs
– Send a spoofed ICMP-EchoRequest packet to a ‘SMURF
amplifier’ network
– Directed broadcast
– All hosts in amplifier
network reply to spoofed
address: The actual victim
• More TCP floods
–
–
–
–
Copyright © 2003
Stream attack
Null flood
Mixed flags
Reflection attack
The University of Auckland, 2003
SYN flood
• Normal TCP connection via three-way handshake:
Client
Server
SYN
reserve
memory
connection
establishment
SYN+ACK
ACK
move
memory
ACK+PUSH
Copyright © 2003
request…
The University of Auckland, 2003
SYN flood (continued)
• Open many connections, but do not close them:
SYN
SYN
SYN
SYN
SYN
SYN
SYN+ACK
SYN
SYN+ACK
SYN
SYN+ACK
SYN
SYN+ACK
SYN
SYN+ACK
SYN
SYN+ACK
SYN
SYN+ACK
SYN
SYN+ACK
SYN
SYN+ACK
SYN
SYN+ACK
SYN
SYN+ACK
SYN+ACK
SYN+ACK
SYN+ACK
SYN+ACK
SYN+ACK
Server
Copyright © 2003
Out of
Memory
The University of Auckland, 2003
Types of flood attacks
• ICMP flood
• UDP flood
– Source address not always
spoofed, so that root access
is not necessary
• SYN flood
– Starts TCP-handshake,
without completing
– Server sends ACK packet
and allocates memory
– Consumes bandwidth and
memory resource
• Fragmentation attack
– Missing fragments overload
reassembly queues on
server
– Sending large number of
ICMP packets
• SMURFs
– Send a spoofed ICMP-EchoRequest packet to a ‘SMURF
amplifier’ network
– Directed broadcast
– All hosts in amplifier
network reply to spoofed
address: The actual victim
• More TCP floods
–
–
–
–
Copyright © 2003
Stream attack
Null flood
Mixed flags
Reflection attack
The University of Auckland, 2003
SMURF
• Send PING via subnet-directed broadcast address to
some network (SMURF amplifier), pretend to be victim:
Attacker
Badly
administered
network
Victim
Copyright © 2003
The University of Auckland, 2003
Types of flood attacks
• ICMP flood
• UDP flood
– Source address not always
spoofed, so that root access
is not necessary
• SYN flood
– Starts TCP-handshake,
without completing
– Server sends ACK packet
and allocates memory
– Consumes bandwidth and
memory resource
• Fragmentation attack
– Missing fragments overload
reassembly queues on
server
– Sending large number of
ICMP packets
• SMURFs
– Send a spoofed ICMP-EchoRequest packet to a ‘SMURF
amplifier’ network
– Directed broadcast
– All hosts in amplifier
network reply to spoofed
address: The actual victim
• More TCP floods
–
–
–
–
Copyright © 2003
Stream attack
Null flood
Mixed flags
Reflection attack
The University of Auckland, 2003
Reflection attack
• Flood victim with SYN+ACKs from well-known servers:
cnn.com
yahoo.com
Attacker
ebay.com
SYN
SYN+ACK
(pretend from victim)
amazon.com
Victim
Copyright © 2003
The University of Auckland, 2003
Tools of the trade
TrinOO
TFN
Stacheldraht
Shaft
TFN 2k
Stacheldraht
v2.666
Trinity
v3
Date
Early to mid
1999
Mid
1999
Fall
1999
End of
1999
Early
2000
Mid to fall
2000
Fall
2000
UDP
Yes
Yes
Yes
Yes
Yes
Yes
Yes
SYN
No
Yes
Yes
Yes
Yes
Yes
Yes
SMURF
No
Yes
Yes
No
Yes
Yes
No
ICMP
No
Yes
Yes
Yes
Yes
Yes
No
Stream
No
No
No
No
No
Yes
Yes
Commprotocol
TCP / UDP
ICMP
TCP / ICMP
TCP / UDP
TCP/UDP/
ICMP/
decoys (!)
TCP / ICMP
IRC (!)
Encryption
Partially
No
Partially
No
Yes
Partially
No
Notes
No root
required
Requires
root
Requires
root
Root req.,
gathers
stats
Copyright © 2003
Root req.,
silent
clients (!)
Root req.,
TCP floods
Root req.,
TCP floods,
fragments
The University of Auckland, 2003
Agenda
1.
DoS attacks: Background
2.
DDoS techniques and tools
3.
Attack detection
4.
Possible defenses
5.
Filters
6.
Specialized DDoS solutions
Copyright © 2003
The University of Auckland, 2003
Statistical detection: Volume
• An increased number of packets of a particular type
can indicate an attack
• But: Increased legitimate demand can cause an
increase as well
• And: Need to adjust volume monitoring to regularly
changing patterns
Copyright © 2003
The University of Auckland, 2003
Statistical detection: Volume
Copyright © 2003
The University of Auckland, 2003
Statistical detection: Volume
Copyright © 2003
The University of Auckland, 2003
Statistical detection: Addresses
• Normal distribution of source addresses is not
random, but clustered
• Certain IP address ranges are not public
(for example 192.0.0.0)
• ‘Dissolving’ clusters can be an indication of a DDoS
attack with randomly spoofed source addresses
• But: Influx of new clients, or routing problems can
dissolve established clusters
Copyright © 2003
The University of Auckland, 2003
Copyright © 2003
224.0.0.0
213.0.0.0
209.0.0.0
205.0.0.0
200.0.0.0
195.0.0.0
185.0.0.0
171.0.0.0
167.0.0.0
163.0.0.0
159.0.0.0
155.0.0.0
151.0.0.0
147.0.0.0
143.0.0.0
139.0.0.0
134.0.0.0
130.0.0.0
80.0.0.0
64.0.0.0
57.0.0.0
24.0.0.0
16.0.0.0
4.0.0.0
Statistical detection: Addresses
Clusters of addresses
2500
2000
1500
1000
500
0
The University of Auckland, 2003
Statistical detection: Packet size
• Histogram of packet sizes represents one ‘fingerprint’
of a network / site
• Fingerprint depends on traffic profile
• Change in size-histogram may indicate an attack
• But: Increased legitimate demand for particular files /
service can also change histogram
Copyright © 2003
The University of Auckland, 2003
Statistical detection: Packet size
100%
Large packets
80%
60%
40%
20%
Small packets
0%
14:00 14:10 14:20 14:30 14:40 14:50 15:00 15:10 15:20 15:30 15:40
Copyright © 2003
The University of Auckland, 2003
Statistical detection: Ratio
• Attackers typically can only control the incoming
traffic
• Monitoring the ratio of certain incoming vs. outgoing
packets can help identifying an attack more surely
• A form of ‘remote host-based’ detection!
• But: Volume attacks based on legitimate requests can
go undetected
Copyright © 2003
The University of Auckland, 2003
Statistical detection: Ratio
Copyright © 2003
The University of Auckland, 2003
Statistical detection: Ratio
Copyright © 2003
The University of Auckland, 2003
Agenda
1.
DoS attacks: Background
2.
DDoS techniques and tools
3.
Attack detection
4.
Possible defenses
5.
Filters
6.
Specialized DDoS solutions
Copyright © 2003
The University of Auckland, 2003
Preventive measures
• Stopping the spread of attack tools:
–
–
–
–
Anti-Virus software
Trip-wire
Use fire-wall to stop communication in attack network
Keep system current with latest patches
• Hardening the network:
– Don’t allow incoming subnet-directed broadcast
– Don’t allow outgoing packets with external IP addresses
(anti-spoof)
Copyright © 2003
The University of Auckland, 2003
Defensive measures?
• Train for the emergency
• After attack is detected, characterize it
(protocol, source addresses, type of packet, etc.)
• Implement filters on your routers to keep network
attack-traffic free (ingress filtering). Works better
on some routers than on others.
• Get more bandwidth
Copyright © 2003
The University of Auckland, 2003
Defensive measures?
• Call your up-stream provider and hope for the best…
– Hard to find the proper contact
– Filters may reduce performance for other customers
– They still like to bill you for the used bandwidth
• Maintain relationship with provider
– Know who to contact
– Ask provider what they would be willing to do
• Choose up-stream providers, which have DDoS
solutions installed or at least some sort or strategy:
– Either they offer it as add-on for extra fee, always on…
– …or you can rent the protection when you need it
Copyright © 2003
The University of Auckland, 2003
Agenda
1.
DoS attacks: Background
2.
DDoS techniques and tools
3.
Attack detection
4.
Possible defenses
5.
Filters
6.
Specialized DDoS solutions
Copyright © 2003
The University of Auckland, 2003
What are we filtering?
• Tricky…
• Site-specific knowledge
– “This protocol is not used by that client”
– “These ports are not in use”
– Etc.
• Patterns in floods
– Many floods have patterns, but not all do…
• Session-state
– Very powerful
– Very CPU/memory intensive
– Difficult in asymmetric routing environments
Copyright © 2003
The University of Auckland, 2003
Where to place filters?
• Not an easy question
• Some floods attack the bandwidth
• Other floods attack servers or routers
• Example: Yahoo!’s bandwidth was not maxed out
(multiple OC-12). Instead, their routers
crashed because of high packet rate.
• Example: Attack on dial-up user requires only
some 50 – 60 kbit/s to succeed.
Nobody will crash, but the line is
effectively dead.
Copyright © 2003
The University of Auckland, 2003
Filtering at the target
Resource
Maximum available
resource
Legitimate Traffic
Time
Copyright © 2003
The University of Auckland, 2003
Filtering at the target
Resource
Maximum available
resource
Attack Traffic
Legitimate Traffic
Time
Copyright © 2003
The University of Auckland, 2003
Filtering at the target
Resource
All available resources utilized
Maximum available
resource
Attack Traffic
Legitimate Traffic
Time
Copyright © 2003
The University of Auckland, 2003
Filtering at the target
Resource
All available resources utilized
Maximum available
resource
Attack Traffic
Legitimate Traffic
Time
Copyright © 2003
The University of Auckland, 2003
Filtering at the target
Resource
All available resources utilized
Maximum available
resource
Attack Traffic
Remaining statistical trickle…
Legitimate Traffic
Time
Copyright © 2003
The University of Auckland, 2003
Filtering at the target
Resource
All available resources utilized
Activating filters
Maximum available
resource
Attack Traffic
Legitimate Traffic
Time
Copyright © 2003
The University of Auckland, 2003
Filtering at the target: Pros/Cons
+ Protects internal network/computing resources
+ Network remains operational
+ Can be deployed in ‘your’ network
– The link is still maxed out!
Resource
All available resources utilized
Activating filters
Maximum available
resource
Attack Traffic
Legitimate Traffic
Time
Copyright © 2003
The University of Auckland, 2003
Filtering higher up
Resource
Activating filters
Maximum available
resource
Excess Bandwidth
Attack Traffic
Legitimate Traffic
Time
Copyright © 2003
The University of Auckland, 2003
Filtering higher up: Pros/Cons
+ Protects internal network/computing resources
+ The attack fails completely
– Complicated by asymmetric routing
– Needs to handle high-capacity links
Resource
– Probably not under
your control
Activating filters
Maximum available
resource
Attack Traffic
Legitimate Traffic
Time
Copyright © 2003
The University of Auckland, 2003
Filters? What filters?
• Everything that is capable of dropping packets
or rate limiting packets
• Firewalls
– Not built for extremely high bandwidth AND packet rate
– Often too close to the receiving end
• Routers
– Filtering a big performance impact on some routers
– ACLs are not enough, need to inspect header
• Dedicated DoS solutions
Copyright © 2003
The University of Auckland, 2003
Agenda
1.
DoS attacks: Background
2.
DDoS techniques and tools
3.
Attack detection
4.
Possible defenses
5.
Filters
6.
Specialized DDoS solutions
Copyright © 2003
The University of Auckland, 2003
Deployment modes
Notification mode:
Router
Internet
DoS solution
Servers
Copyright © 2003
The University of Auckland, 2003
Deployment modes
Active mode:
Router
Internet
DoS solution
Servers
Copyright © 2003
The University of Auckland, 2003
Deployment modes
Controller mode:
Router
Internet
configure
DoS solution
Servers
Copyright © 2003
The University of Auckland, 2003
Deployment modes
• Notification mode
+
+
+
–
No impact on network
Statistical sampling possible
Lots of value in early warning
No direct possibility to stop attack
• Active mode
+
–
–
–
Can actively filter attack traffic
“Bump in the wire”, introduces latency
Single point of failure
Powerful hardware needed
• Controller mode
+ Active addition to Notification mode, using other devices
– Controlling routers in complex network very difficult
– Skepticism by network operators
Copyright © 2003
The University of Auckland, 2003
Esphion’s netDeFlect
• Statistical anomaly detection
– Neural Networks, traffic statistics as input
– Very fast: Detection within seconds
• Attack analysis
– Identifies patterns, if attack packets have something in common
– Recommends filtering possibilities
• Supports distributed deployment
– Requirement for complex networks
• Alerting
– GUI, E-Mail, SNMP
• Deployed on Intel / Linux platform
Copyright © 2003
The University of Auckland, 2003
Thank you very much…
For any questions or feedback:
[email protected]
Copyright © 2003
The University of Auckland, 2003