Final presentation
Download
Report
Transcript Final presentation
Denial of Service Attacks and
Countermeasures Analysis
Dang Nguyen Duc
School of Engineering
(2001816)
Contents
1. Introduction
2. What is DoS attacks?
3. Well-known DoS attacks
4. Intermediate countermeasures
5. Protocols against DoS
6. Conclusion
7. References
2
1.Introduction
We are at war, not at risk.
DoS is very simple but powerful attack
To defeat attack, we need to analyze it
We need intermediate solutions
We need long-term solutions (make use of cryptogra
phic primitives)
3
2.1. What is DoS attack?
attempts to flood a network, thereby preventing
legitimate network traffic
attempts to disrupt connections between two
machines, thereby preventing access to a service
attempts to prevent a particular individual from
accessing a service
attempts to disrupt to a specific system or person.
4
2.1.Distributed DoS
Slave
Master
Slave
Slave
Network
Real attacker
Slave
Victim
5
2.2. Modes of attacks
Consumption of limited or non-renewable Resources:
network connectivity, bandwidth, etc.
Destruction or Alteration of Configuration Information
Physical Destruction or Alteration of Network Components
6
3.1. Smurf attack (ping of death)
ICMP echo (spoofed source address of victim)
Sent to IP broadcast address
ICMP echo reply
Internet
Perpetrator
Victim
7
3.1. SYN flood
Source
Destination
SYNn
Listen
Attacker
Victim
SYNn
Listen
SYNn+1
SYNm, ACKn+1
SYN_RECVDD
SYN_RECVDD
SYNm, ACKn+1
SYNm+1
Port flooding occurs
CONNECTED
8
3.1. UDP flood (fraggle)
Similar to Smurf attack
UDP echo messages always expects UDP reply mess
ages
9
Distributed DoS attacks
Trinoo
Tribe Flood Network (TFN)
Stacheldraht
Shaft
TFN2K
10
4. Intermediate countermeasures
Software patches
Secure host computer from hacking, trojan horse, vir
us, back door,…
Configure router to deny spoofed source address
Reduce time-out of half-open connections
Increase resources for half-open connections (backl
og)
Close unused TCP/UDP port
Firewall
Etc.
11
5.1. Why IPsec not work?
Too many design goals
High complexity
Provide authentication but introduce another attack:
abuse resources for expensive operations (i.e. expon
entiation)
12
5.2. Client Puzzle
Puzzle
Server does not store state data
or perform expensive
computation
Client commits its resources
into solving the puzzle
Solution
Server verifies the solution
If it accepts, it may now commit
resources to expensive parts of
the authentication
13
5.2. Client Puzzle (cont.)
Creating a puzzle and verifying puzzle’s solution is inexpensive for the
server
The cost of solving the puzzle is easy to adjust from zero to impossible
(i.e. when server’s resource is getting exhausted, server should increase
the difficulty level).
It is not possible to precompute solutions
While client is solving the puzzle, the server does not need to store the
solution or other client specific data.
The same puzzle may be given to several clients. Knowing the solution
of one or more clients does not help a new client in solving the puzzle
A client can reuse a puzzle by creating several instances of it
14
5.2. Puzzle by hash function
Hash function is simplest cryptographic primitive, free of charg
e
H(Ns, x) = 0ky
Ns: Server’s Nonce (Puzzle)
X : solution to puzzle
Y: anything
K : difficulty level
Client find x by brute-force method
Unique solution
H(client_id, Nc, Ns, x) = 0ky
Nc : Client’s nonce
client_id : Client identity
15
5.2. Authentication protocol
Client
Sever
Hello
Server periodically decides difficulty level k,
generates nonce Ns and sends following message
together with its signature
Ns, k, sign(Ns, k)
Client verifies signature on Ns, k. It then
generates a nonce Nc and find solution x by
brute-force method:
h(client_id, Ns, Nc, x) = 0ky
Client sends following message
Server in idle state during client
solving puzzle
Client_id, Ns, Nc, x
Server verifies that Ns is recently in use and
client_id, Ns, Nc not used before, and checks that
h(client_id, Ns, Nc, x) = 0ky
If it accepts, server now commit resources for
expensive operation.
Server also stores client_id, Ns, Nc while Ns is
recently in use.
16
6. Conclusion
Analyze attacks and countermeasures
Client Puzzle using hash function
We are behind attackers
Combination of countermeasures is required
17
7. References
[1] http://www.cert.org
[2] Jussipekka Leiwo, Towards Network Denial of Service Resistant
Protocols.
[3] Christoph L. Schuba, Ivan V.Krusl, Markus G. Kuhn, et al., Analysis of a
Denial of Service Attack on TCP.
[4] Felix Lau, Stuart H. Rubin, Michael H. Smith, Ljiljana Trajkovic,
Distributed Denial of Service.
[5] Tuomas Aura, Pekka Nikander, Jussipekka Leiwo, DoS-Resistant
Authentication with Client Puzzles.
[6] Pasi Eronen, Denial of Service In Public Key Protocols.
[7] Douglas E. Comer, Internetworking with TCP/IP, Principles, Protocols,
and Architectures – Volume 1, Fourth Edition
[8] RFC(s)
[9] David Dittrich et al, The distributed denial of service attack tool series.
[10] Niels Ferguson and Bruce Schneier, A Cryptographic Evaluation of
IPsec.
18