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

• 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

• DoS attacks increasing in frequency, severity and sophistication
– 32% respondents detected DoS attacks (1999 CSI/FBI survey)
– Yahoo, Amazon, eBay and MicroSoft DDoS attacked
– About 4,000 attacks per week in 2000
– 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

• 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

DoS
Source
1 ICMP Echo Req
Src: Dos Target
Dest: brdct addr
3 ICMP Echo Reply
Dest: Dos Target gateway
DoS
Target
• 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.

Handler
BadGuy
Handler
Unidirectional commands
Handler
Coordinating communication
Agent Agent Agent Agent Agent Agent Agent Agent Agent Agent
Attack traffic
Victim

• 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

• 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

• 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

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

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

• 1996 - Point-to-point
• 1997 - Combined
• 1998 Distributed (small, C/S)
• 1999 - Add encryption, covert channel comms, shell features, auto-update, bundled w/rootkit
• 2000 - Speed ups, use of IRC for C&C
• 2001 - Added scanning, BNC, IRC channel hopping
• 2002 - Added reflection attack, closed port back door, Worms include DDoS features
• 2003 - IPv6 (back to 1996…)

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

• 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

socket door
RFCs: 793, 1122, 1323, 2018, 2581
• point-to-point: • full duplex data:
– one sender, one receiver
– bi-directional data flow in same connection
• reliable, in-order byte steam: – MSS: maximum segment size
– no “message boundaries”
• connection-oriented:
• pipelined:
– TCP congestion and flow control set window size
• send & receive buffers
– handshaking (exchange of control msgs) init’s sender, receiver state before data exchange application writes data
TCP send buffer segment application reads data
TCP receive buffer socket door
• flow controlled:
– sender will not overwhelm receiver

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

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

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

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

Step 1: client end system sends TCP FIN control segment to server client server closing
Step 2: server receives FIN, replies with ACK. Closes connection, sends FIN.
closing
Step 3: client receives FIN, replies with ACK. closed closed
Step 4: server , receives ACK.
Connection closed.

• 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

• 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

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

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

• 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

• 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

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

– 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

• 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)

• 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

• 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)

• 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

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]

• 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

• 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