dsafsadfsafsacsadfsdafsdafsdaf cyber security DOS Attacks.ppt

cacabelosmonchette 7 views 43 slides Oct 27, 2025
Slide 1
Slide 1 of 43
Slide 1
1
Slide 2
2
Slide 3
3
Slide 4
4
Slide 5
5
Slide 6
6
Slide 7
7
Slide 8
8
Slide 9
9
Slide 10
10
Slide 11
11
Slide 12
12
Slide 13
13
Slide 14
14
Slide 15
15
Slide 16
16
Slide 17
17
Slide 18
18
Slide 19
19
Slide 20
20
Slide 21
21
Slide 22
22
Slide 23
23
Slide 24
24
Slide 25
25
Slide 26
26
Slide 27
27
Slide 28
28
Slide 29
29
Slide 30
30
Slide 31
31
Slide 32
32
Slide 33
33
Slide 34
34
Slide 35
35
Slide 36
36
Slide 37
37
Slide 38
38
Slide 39
39
Slide 40
40
Slide 41
41
Slide 42
42
Slide 43
43

About This Presentation

about internet security


Slide Content

Outline
•Definition
•Point-to-point network denial of service
–Smurf
•Distributed denial of service attacks
•TCP SYN Flooding and Detection

Objectives
•Understand the concept of DoS attacks and
its current threat trends
•Understand the SYN flooding attacks and be
able to detect at the network level and
defense them (SYN cookie)

Denial of Service Attack Definition
•An explicit attempt by attackers to prevent
legitimate users of a service from using that
service
•Threat model – taxonomy from CERT
–Consumption of network connectivity and/or bandwidth
–Consumption of other resources, e.g. queue, CPU
–Destruction or alternation of configuration information
•Malformed packets confusing an application, cause it to freeze
–Physical destruction or alternation of network
components

Status
•DoS attacks increasing in frequency, severity and
sophistication
–32% respondents detected DoS attacks (1999 CSI/FBI survey)
–August 6, 2009, several social networking sites, including
Twitter, Facebook, Livejournal, and Google blogging pages
were hit by DDoS attacks
•Aimed at Georgian blogger "Cyxymu".
–Internet's root DNS servers attacked on
•Oct. 22, 2002, 9 out of 13 disabled for about an hour
•Feb. 6, 2007, one of the servers crashed, two reportedly "suffered
badly", while others saw "heavy traffic”
•An apparent attempt to disable the Internet itself

Two General Classes of Attacks
•Flooding Attacks
–Point-to-point attacks: TCP/UDP/ICMP flooding,
Smurf attacks
–Distributed attacks: hierarchical structures
•Corruption Attacks
–Application/service specific
•Eg, polluting P2P systems

Smurf DoS Attack
•Send ping request to brdcst addr (ICMP Echo Req)
•Lots of responses:
–Every host on target network generates a ping reply
(ICMP Echo Reply) to victim
–Ping reply stream can overload victim
Prevention: reject external packets to brdcst address.
gateway
DoS
Source
DoS
Target
1 ICMP Echo Req
Src: Dos Target
Dest: brdct addr
3 ICMP Echo Reply
Dest: Dos Target

Distributed DOS
Handler
AgentAgentAgentAgentAgentAgentAgentAgent AgentAgent
Victim
Unidirectional commands
Attack traffic
Coordinating
communication
BadGuy
Handler Handler
Stacheldraht is a classic example of a DDoS tool.

Can you find source of attack?
•Hard to find BadGuy
–Originator of attack compromised the handlers
–Originator not active when DDOS attack occurs
•Can try to find agents
–Source IP address in packets is not reliable
–Need to examine traffic at many points, modify
traffic, or modify routers

Targets of Attack
•End hosts
•Critical servers (disrupt C/S network)
–Web, File, Authentication, Update
–DNS
•Infrastructure
–Routers within org
–All routers in upstream path

The DDoS Landscape

High
Low
1980 1985 1990 1995 2001
password guessing
password cracking
exploiting known vulnerabilities
disabling audits
back doors
hijacking
sessions
sniffers
packet spoofing
GUI
automated probes/scans
denial of service
www attacks
Tools
Attackers
Intruder
Knowledge
Attack
Sophistication
“stealth” / advanced
scanning techniques
burglaries
network mgmt. diagnostics
distributed
attack tools
binary encryption
Source: CERT/CC
Attack Tools Over Time

(D)DoS Tools Over Time
•1996 - Point-to-point
•1997 – Combined w/ multiple tools
•1998 - Distributed (small, C/S)
•1999 - Add encryption, covert channel comms, shell
features, auto-update, bundled w/rootkit
–trin00, Stacheldraht, TFN, TFN2K
•2000 - Speed ups, use of IRC for C&C
•2001 - Added scanning, IRC channel hopping, worms include
DDoS features
–Code Red (attacked www.whitehouse.gov)
–Linux “lion” worm (TFN)
•2002 - Added reflection attack
•2003 – IPv6 DDoS

Outline
•Definition
•Point-to-point network denial of service
–Smurf
•Distributed denial of service attacks
–Trin00, TFN, Stacheldraht, TFN2K
•TCP SYN Flooding and Detection/Defense

•90% of DoS attacks use TCP SYN floods
•Streaming spoofed TCP SYNs
•Takes advantage of three way handshake
•Server start “half-open” connections
•These build up… until queue is full and all
additional requests are blocked
SYN Flooding Attack

TCP Connection Management
Recall: TCP sender, receiver
establish “connection”
before exchanging data
segments
•initialize TCP variables:
–seq. #s
–buffers, flow control
info (e.g. RcvWindow)
•client: connection initiator
•server: contacted by client
Three way handshake:
Step 1: client host sends TCP SYN
segment to server
–specifies initial seq #
–no data
Step 2: server host receives SYN,
replies with SYNACK segment
–server allocates buffers
–specifies server initial seq. #
Step 3: client receives SYNACK,
replies with ACK segment, which
may contain data

TCP Handshake
C S
SYN
C
SYN
S, ACK
C
ACK
S
Listening
Store data
Wait
Connected

TCP segment structure
source port #dest port #
32 bits
application
data
(variable length)
sequence number
acknowledgement number
Receive window
Urg data pnterchecksum
FSRPAU
head
len
not
used
Options (variable length)
URG: urgent data
(generally not used)
ACK: ACK #
valid
PSH: push data now
(generally not used)
RST, SYN, FIN:
connection estab
(setup, teardown
commands)
# bytes
rcvr willing
to accept
counting
by bytes
of data
(not segments!)
Internet
checksum
(as in UDP)

SYN Flooding
C S
SYN
C1 Listening
Store data
SYN
C2
SYN
C3
SYN
C4
SYN
C5

SYN Flooding Explained
•Attacker sends many connection requests with spoofed
source addresses
•Victim allocates resources for each request
–New thread, connection state maintained until timeout
–Fixed bound on half-open connections
•Once resources exhausted, requests from legitimate
clients are denied
•This is a classic denial of service attack
–Common pattern: it costs nothing to TCP initiator to send a
connection request, but TCP responder must spawn a thread
for each request - asymmetry!

Flood Detection System on
Router/Gateway
•Can we maintain states for each connection flow?
•Stateless, simple detection system on edge (leaf)
routers desired
•Placement: First/last mile leaf routers
–First mile – detect large DoS attacker
–Last mile – detect DDoS attacks that first mile would miss
•What metrics can capture the SYN flooding
attacks?

TCP Connection Management: Closing
Step 1: client end system
sends TCP FIN control
segment to server
Step 2: server receives FIN,
replies with ACK. Closes
connection, sends FIN.
Step 3: client receives FIN,
replies with ACK.
–Enters “timed wait” - will
respond with ACK to
received FINs
Step 4: server, receives ACK.
Connection closed.
client
FIN
server
ACK
ACK
FIN
closing
closing
closed
t
i
m
e
d

w
a
i
t
closed

TCP Connection Messages

Detection Methods (I)
•Utilize SYN-FIN pair behavior
•Or SYNACK – FIN
•Can be both on client or server side
•However, RST violates SYN-FIN behavior
–Passive RST: transmitted upon arrival of a packet at a
closed port (usually by servers)
–Active RST: initiated by the client to abort a TCP
connection (e.g., Ctrl-D during a telnet session)
•Often queued data are thrown away
–So SYN-RST
active pair is also normal

SYN – FIN Behavior
•Generally every SYN has a FIN
•We can’t tell if RST is active or passive
•Consider 75% active

Vulnerability of SYN-FIN Detection
•Send out extra FIN or RST with different
IP/port as SYN
•Waste half of its bandwidth

Detection Method II
•SYN – SYN/ACK pair behavior
•Hard to evade for the attacking source
•Problems
–Need to sniff both incoming and outgoing traffic
–Only becomes obvious when really swamped

Preventing Denial of Service
•DoS is caused by asymmetric state allocation
–If responder opens new state for each connection
attempt, attacker can initiate thousands of
connections from bogus or forged IP addresses
•Cookies ensure that the responder is stateless
until initiator produced at least two messages
–Responder’s state (IP addresses and ports of the
connection) is stored in a cookie and sent to initiator
–After initiator responds, cookie is regenerated and
compared with the cookie returned by the initiator

SYN Cookies
C S
SYN
C
Listening…
Does not store state
F(source addr, source port,
dest addr, dest port,
coarse time, server secret)
SYN
S, ACK
C
sequence # = cookie
Cookie must be unforgeable
and tamper-proof
Client should not be able
to invert a cookie
F=Rijndael or crypto hash
Recompute cookie,
compare with with the one
received, only establish
connection if they match
ACK
S(cookie)
Compatible with standard TCP;
simply a “weird” sequence number scheme
More info: http://cr.yp.to/syncookies.html

Backup Slides

Attack using Trin00
•In August 1999, network of > 2,200 systems
took University of Minnesota offline for 3 days
–scan for known vulnerabilities, then attack with UDP
traffic
–once host compromised, script the installation of the
DDoS master agents
–According to the incident report, took about 3
seconds to get root access

False Positive Possibilities
•Many new online users with long-lived TCP
sessions
–More SYNs coming in than FINs
•An overloaded server would result in 3 SYNs
to a FIN or SYN-ACK
–Because clients would retransmit the SYN

Source Address Validity
•Spoofed Source Address
–random source addresses in attack packets
–Subnet Spoofed Source Address
- random address from address space assigned to the agent
machine’s subnet
–En Route Spoofed Source Address
- address spoofed en route from agent machine to victim
•Valid Source Address
- used when attack strategy requires several
request/reply exchanges between an agent and the
victim machine
- target specific applications or protocol features

Attack Rate Dynamics
Agent machine sends a stream of packets to the
victim
•Constant Rate
- Attack packets generated at constant rate,
usually as many as resources allow
•Variable Rate
–Delay or avoid detection and response
–Increasing Rate
- gradually increasing rate causes a slow exhaustion of
the victim’s resources
– Fluctuating Rate
- occasionally relieving the effect
- victim can experience periodic service disruptions

Up to 1996
•Point-to-point (single threaded)
–SYN flood
–Fragmented packet attacks
–“Ping of Death”
–“UDP kill”

1997
–Combined attacks
•Targa
–bonk, jolt, nestea, newtear, syndrop, teardrop, winnuke
•Rape
–teardrop v2, newtear, boink, bonk, frag, fucked, troll icmp,
troll udp, nestea2, fusion2, peace keeper, arnudp, nos,
nuclear, sping, pingodeth, smurf, smurf4, land, jolt, pepsi

1998
•fapi (May 1998)
–UDP, TCP (SYN and ACK), ICMP Echo, "Smurf" extension
–Runs on Windows and Unix
–UDP comms
–One client spoofs src, the other does not
–Built-in shell feature
–Not designed for large networks (<10)
–Not easy to setup/control network
•fuck_them (ADM Crew, June 1998)
–Agent written in C; Handler is a shell script
–ICMP Echo Reply flooder
–Control traffic uses UDP
–Can randomize source to R.R.R.R
(where 0<=R<=255)

1999
•More robust and functional tools
–trin00, Stacheldraht, TFN, TFN2K
•Multiple attacks (TCP SYN flood, TCP ACK flood, UDP
flood, ICMP flood, Smurf…)
•Added encryption to C&C
•Covert channel
•Shell features common
•Auto-update

2000
•More floods (ip-proto-255, TCP NULL flood…)
•Pre-convert IP addresses of 16,702 smurf amplifiers
–Stacheldraht v1.666
•Bundled into rootkits (tornkit includes stacheldraht)
http://www.cert.org/incident_notes/IN-2000-10.html
•Full control (multiple users, by nick, with talk and stats)
–Omegav3
•Use of IRC for C&C
–Knight
–Kaiten
•IPv6 DDoS
–4to6 (doesn’t require IPv6 support)

Single host in DDoS

2001
•Worms include DDoS features
–Code Red (attacked www.whitehouse.gov)
–Linux “lion” worm (TFN)
•Added scanning, BNC, IRC channel hopping (“Blended
threats” term coined in 1999 by AusCERT)
–“Power” bot
–Modified “Kaiten” bot
•Include time synchronization (?!!)
–Leaves worm

Power bot
foo: oh damn, its gonna own shitloads
foo: on start of the script it will erase everything that it has
foo: then scan over
foo: they only reboot every few weeks anyways
foo: and it will take them 24 hours to scan the whole ip range
foo: !scan status
Scanner[24]:[SCAN][Status: ][IP: XX.X.XX.108][Port: 80][Found: 319]
Scanner[208]:[SCAN][Status: ][IP: XXX.X.XXX.86][Port: 80][Found: 320]
. . .
foo: almost 1000 and we aren't even close
foo: we are gonna own more than we thought
foo: i bet 100thousand
[11 hours later]
Scanner[129]: [SCAN][Status: ][IP: XXX.X.XXX.195][Port: 80][Found: 34]
Scanner[128]: [SCAN][Status: ][IP: XXX.X.XXX.228][Port: 80][Found: 67]
Scanner[24]: [SCAN][Status: ][IP: XX.XX.XX.42][Port: 80][Found: 3580]
Scanner[208]: [SCAN][Status: ][IP: XXX.XXX.XXX.156][Port: 80][Found: 3425]
Scanner[65]: [SCAN][Status: ][IP: XX.XX.XXX.222][Port: 80][Found: 3959]
bar: cool

2002
•Distributed reflected attack tools
–d7-pH-orgasm
–drdos (reflects NBT, TCP SYN :80, ICMP)
•Reflected DNS attacks, steathly (NVP protocol) and
encoded covert channel comms, closed port back door
–Honeynet Project Reverse Challenge binary
http://project.honeynet.org/reverse/results/project/020601-
Analysis-IP-Proto11-Backdoor.pdf

2003
•Slammer worm (effectively a DDoS on local
infrastructure)
•Windows RPC DCOM insertion vector for “blended
threat” (CERT reports “thousands”)
•More IPv6 DoS (requires IPv6 this time)
–ipv6fuck, icmp6fuck
Tags