Transcript COMP7320

COMP 7320
Internet Security:
Prevention of DDoS Attacks
By Dack Phillips
Presentation Overview
What are DoS Attacks?
DoS Facts and Figures
Current Solutions
Problems
Proposed Solutions
Conclusions
References
Questions
What are DoS Attacks?
A malicious attack that consumes
“resources of remote hosts or
networks denying or degrading
service to legitimate users,” [11].
Types of DoS Attacks
Bandwidth Consumption
Program Flaw Exploitation
Resource Starvation
Routing/DNS Attacks
SYN Floods
DDoS Attacks
Bandwidth Consumption
A computer having more bandwidth floods
a smaller server with packets. The smaller
server can not respond to the
overwhelming load.
A computer with small bandwidth
convinces a network to flood a host with
more bandwidth
- A 56 Kbps modem can take down a
T1 line like this
Program Flaw Exploitation
An attacker sends an operating
system, application, or hardware
exceptional conditions that it can’t
handle.
- OOB
Port 139 on
Windows 95 boxen
- F00FC7C8 Pentium Instruction
Resource Starvation
Attacker aims to deplete system,
rather than network resources.
- CPU
- Memory
- File System Quotas
Routing/DNS Attacks
Routing Information Protocol (RIP) and
Border Gateway Protocol (BGP) have very
weak authentication. Routing tables are
changed to route traffic through an
attacker’s network, another network, or a
“black hole” (non-existent network)
DNS is similar except DNS tables are
falsified
SYN Floods
TCP Connection Handshake
client sends server TCP SYN
server sends client TCP SYN ACK
client sends server ACK or RST
In case of a spoofed source address,
server keeps trying to send SYN ACKs.
Connection Queue fills up with these
requests and no legitimate traffic is served
DDoS Attacks
An attacker compromises many
machines (agents or zombies) and
installs DoS daemons
The attacker uses a controlling
machine (handler) to control the
zombie machines to attack a server.
More than one handler to prevent
single point of failure
DoS Facts and Figures
One of the hardest security problems
Simple to implement
Difficult to prevent
Difficult to trace
1989 – 95: CERT reports DoS attacks
increased 50% per year
Tools are easy to find and use – Smurf,
Fraggle, Teardrop, Stream, TFN, Trinoo
Stacheldracht, Shaft, Plague, Trinity, et al.
February 2000 – eBay, Yahoo, Amazon,
etc.
Current Solutions
Preventative:
Make the OS/IP stack more robust
Reactive
Phone ISPs and trace back manually, call
next ISP in the chain…
This is time consuming and ISPs are often
unwilling to spend time doing this. In
addition, the trace has to be done while
the attack is still in progress.
Problems
The Internet is stateless; destination
driven
Source addresses can be easily falsified
(spoofed)
Attackers use connection chains to hide
identities
Routers can be compromised
Login chains and address spoofing have
legitimate uses
Proposed Solutions
Ingress Filtering
Upstream Router Mapping
Counter Flooding Trace
Probabilistic Packet Marking
ICMP Traceback Messages
Stepping Stone Tracking
Traceback Network (CenterTrack or STM)
Ingress Filtering
Defined in RFC 2267
Edge Routers drop and log packets with
invalid Source IPs or those coming from
outside the network
Border Routers should not be allowed to
transmit broadcast packets (MAC address
FF:FF:FF:FF:FF:FF) to other routers by
default
Ingress Filtering (cont)
System Diagnostic UDP packets from
outside domains should not be
allowed into a network
Ingress filtering poses problems with
Mobile IP. Currently the Mobile IP
Working Group is investigating
“reverse tunneling” to solve this
problem.
Upstream Router Mapping
Network Administrators should make
an upstream router map
Manually via traceroute
Mercator – program that uses hop
limited probes and source routers to
create upstream maps
Counter Flooding
Network Administrators send UDP
chargen floods upstream (small
scale DoS attack). If a router is
perturbed then it is probably being
used in the attack. Repeat upstream.
Ethical issue – If the trace causes
more damage than the attack, should
it be used?
PPM
PPM – Probabilistic Packet Marking
4 schemes
Savage, Wetherall, Karlin & Anderson
 Song & Perrig
 Park & Lee
 Dean, Franklin & Stubblefield

PPM (cont)
These schemes overload the IP
Identification field used for packet
fragmentation
In most schemes, a hashing function
computes a hash of the router’s IP
address and writes this hash to the
Identification field
A distance field is normally included as
well that keeps track of how many hops a
packet has travelled
PPM (cont)
Typical IP Packet
PPM (cont)
Dean, etc. employ an algebraic
scheme rather than a hash based
wherein routers stamp coefficients of
their IP addresses % a prime number
PPM (cont)
Assumptions:
Most paths are less than 25 hops
Packets can be addressed to more
than one host
Duplicate Packets can exist
Routers can be compromised
Attackers know they can be traced
PPM (cont)
PPM schemes must minimize false
positives while eliminating false
negatives
Adding bits to IP headers causes
packet fragmentation
PPM (cont)
Problems
Packets can take more than one path
to a destination
IPSec requires IP Identification field
IP fragmentation is small (<0.25% of
traffic) but does exist
Routers do not need more overhead
ICMP Traceback
Traceroute only works in the forward
direction, not in reverse
Routers send out ICMP traceback
information (interface name, Time stamp)
probabilistically (1/1000 – 1/20000)
Public key system used to authenticate
packets
TTL set to 255 to show distance
Problem – ICMP is filtered in some
networks
Stepping Stone Traceback
Stepping Stone – one link in a connection
chain
If ON/OFF timing between 2 hosts is
similar, it is probably a stepping stone
Packets often encrypted, check headers
Check clear text packets to see if the text
from one host is transmitted to another
Problem – too much legitimate traffic, not
an adequate solution
CenterTrack
Edge routers are connected to a
special overlay network composed of
tracing routers via IP Tunnels
In case of attack, the packets are
forwarded to the tracking routers
which follow the stream back to the
source of the attack
CenterTrack (cont)
Full packet capture can be added
easily to provide attack evidence
Problems – Attacks have to be
detected to be rerouted
TTL is modified and ICMP TTL
exceeded messages are sent back,
possibly alerting the attacker to the
trace
CenterTrack (contd)
GW –
Gateway
CT –
CenterTrack
Router
TR/XR –
Transfer
Router
STM Network
SPIEs (Source Path Isolation Engines) are
installed in routers, or connected to them
These SPIEs generate packet digests from
28 non changing bits in the packet (20
from the header, 8 from the payload).
The digest is stored in router memory or
external storage
STM Network (cont)
SPIEs transfer data to SCARs (SPIE
Collection and Reduction Agents) if
interesting traffic occurs
A SCAR can produce an attack graph of a
local network
STMs (SPIE Traceback Managers) can
request information from one or more
SCARs and generate a complete attack
graph
Conclusions
ISPs, unless they offer Mobile IP
should use Ingress Filtering
Network Administrators should make
upstream router maps
IPv6 should employ better packet
tracing methods
References
[1]
S. Bellovin. ICMP traceback messages. Internet Draft,
IETF, Mar. 2000. draft-bellovin-itrace-05.txt (work in
progress).
[2]
H. Burch and B. Cheswick. “Tracing anonymous
packets to their approximate source.” In Proc. USENIX
LISA ’00 (Dec. 2000).
[3] D. Dean, M. Franklin, and A. Stubblefield, "An
Algebraic Approach to IP Traceback," in Network and
Distributed System Security Symposium, NDSS '01,
February 2001.
References
[4]
S. Dietrich, N. Long, and D. Dittrich, “Analyzing
ditributed denial of service attack tools: The shaft
case,” in 14th Systems Administration Conference,
LISA 2000, 2000,
http://netsec.gsfc.nasa.gov/spock/lisa2000-shaft.pdf.
[7]
P. Ferguson and D. Senie. “Network ingress filtering:
Defeating denial of service attacks which employ IP
source address spoofing.” May 2000.RFC 2827. IEEE
INFOCOM 2001.
[8]
R. Govindan and H. Tangmunarunkit. “Heuristics for
Internet Map Discovery.” In Proc. of the 2000 IEEE
INFOCOM Conference, Tel Aviv, Israel, Mar. 2000.
References
[10] K. Park and H. Lee. “On the effectiveness of
probabilistic packet marking for IP traceback under
denial of service attack.” In Proc. IEEE INFOCOM
2001, pages 338-347, 2001.
[11] S. Savage, D. Wetherall, A. Karlin, and T. Anderson.
“Practical network support for IP traceback.” In Proc.
of ACM SIGCOMM ‘00, pages 295-306, Aug.2000.
[12] A. Snoeren, and C. Partridge. “Hash-based IP
Traceback.” In Proc. ACM SIGCOMM ‘01, pages 3-14,
Aug. 2001.
References
[13] D. Song and A. Perrig. “Advanced and authenticated
marking schemes for IP traceback.” Technical Report
UCB/CSD-00-1107, Computer Science Department,
University of California, Berkeley, 2000. In Proc. IEEE
INFOCOM 2001.
[14] R. Stone. “CenterTrack: An IP Overlay Network for
Tracking DoS Floods.” In Proc. of the 2000 USENIX
Security Symposium, Denver, CO, July 2000.
[15] *J. Scambray, S. McClure, and G. Kurtz. Hacking
Exposed: Network Security Secrets and Solutions.
Second Edition. New York: Osborne/McGraw-Hill,
2001. pages 484-506.
References
[17] Y. Zhang and V. Paxson. “Stepping Stone Detection.”
In Proc. of the 2000 USENIX Security Symposium,
Denver, CO, July 2000.
Questions?