Detecting Spoofed Packets: Steven Templeton UC Davis Security Lab

Detecting Spoofed Packets
Steven Templeton
UC Davis Security Lab
29 May 2002
UC Davis Security
Motivation
Next-generation ID approaches require greater information than
predecessors.
Appropriate IDS sensors are not available
Require inference about external entities and local entities when direct
sensing is not available
Examples
Knows/Has __________
Same source
Exploitable __________ exists
Sniffer active
Spoofed packet
Successful exploit
e.g. Forged TCP handshake
29 May 2002
UC Davis Security
What is a Spoofed Packet

Packets sent by an attacker such that the true source is not
authentic
MAC spoofing
IP packet spoofing
Email spoofing
Not same as routing attacks

These cause packets to be redirected
e.g. DNS cache poisoning; router table attacks; ARP spoofing
This talk will focus on IP source address spoofing

29 May 2002
UC Davis Security
IP/TCP Header Review

IP Header Format
version
header
length
TOS
identification
TTL
total length
flags
protocol
fragment offset
header checksum
source IP address
destination IP address
options (if any)
data
29 May 2002
UC Davis Security
20 bytes
IP/TCP Header Review

TCP Header Format
source port number
destination port number
sequence number
acknowledgement number
header
length
reserved
U A P R S F
R C S S Y I
G K H T N N
TCP checksum
window size
urgent pointer
options (if any)

data (if any)
29 May 2002
UC Davis Security
20 bytes
Significance
Spoofed packets are a part of many attacks
SYN-flood
Smurf Attack
Connection Spoofing
Bounce Scanning
Stealth Communication
29 May 2002
UC Davis Security
SYN-flood
TCP Handshake Review
SYN
client
sends SYN packet to server
waits for SYN-ACK from server
server
SYN-ACK
responds w/ SYN-ACK packet

waits for ACK packet from client
client
ACK
sends ACK to server
29 May 2002
UC Davis Security
SYN-flood
TCP
Buffers
Attacker causes TCP buffer

to be exhausted w/ halfopen connections
No reply from target
needed, so source may be
spoofed.
Claimed source must not
be an active host.
169.237.5.23
168.150.241.155
169.237.7.114
Half-open
connection;
Waiting for
ACK
29 May 2002
UC Davis Security
Completed
handshake;
connection
open
empty
buffer
SYN-flood
TCP
Buffers
Attacker causes TCP buffer

to be exhausted w/ halfopen connections
No reply from target
needed, so source may be
spoofed.
Claimed source must not
be an active host.
128.120.254.1
128.120.254.2
128.120.254.3
128.120.254.4
128.120.254.5
128.120.254.6
128.120.254.7
128.120.254.8
128.120.254.9
128.120.254.10
128.120.254.11
128.120.254.12
128.120.254.13
128.120.254.14
169.237.7.114
128.120.254.15
Half-open
connection;
Waiting for
ACK
29 May 2002
UC Davis Security
Completed
handshake;
connection
open
empty
buffer
Smurf Attack
Allows attacker to send
flood target w/ ICMP
packets
Attacker does not need to
see returned packets.
Uses network broadcast
address as packet amplifier.
Claimed source address is
address of target.
Attacker sends an
ICMP echo request to a
particular IP address
Source address is set to target host
29 May 2002
UC Davis Security
Smurf Attack
packets
address of target.
29 May 2002
ICMP echo request

causes an ICMP echo reply
to be sent to target
UC Davis Security
Smurf Attack
packets
address of target.
29 May 2002
Because destination address

was the network broadcast address,
a large number of hosts flood target
with ICMP echo replies.
UC Davis Security
TCP Connection Spoofing

TCP Handshake Review
SYN
client
ack-number
sends SYN packet and ACK

number to server
waits for SYN-ACK from server
w/ matching ACK number
server
responds w/ SYN-ACK packet w/
initial random sequence number
waits for ACK packet from client
with matching sequence number
client
sends ACK to server w/ matching
sequence number (and data)
29 May 2002
UC Davis Security
SYN-ACK
seq-number
ack-number
ACK
seq_number
ack-number+data
Connection Spoofing
Allows attacker to send data
to a target as if it originated
with a trusted host
Requires guessing sequence
numbers.
Attacker does not see
returned packets; attacker
must infer/guess what is
sent.
29 May 2002
Attacker causes DOS on

intermediate (the trusted host)
UC Davis Security
Connection Spoofing
with a trusted host
numbers.
sent.
29 May 2002
Attacker sends spoofed packet to

target with a claimed source of
the intermediate.
UC Davis Security
Connection Spoofing
with a trusted host
numbers.
sent.
29 May 2002
Target sends SYN-ACK reply to

intermediate.
Because of DOS, intermediate
does not see packet and does not
reply (w/ RST)
UC Davis Security
Connection Spoofing
with a trusted host
numbers.
sent.
29 May 2002
Attacker sends ACK packet to

target with guessed sequence
number (+data)
UC Davis Security
Bounce Scanning
Allows attacker to scan a
target without revealing the
true source of the scan
Requires an intermediate
host with little traffic
Relies on change pattern of
IP ID (fragmentation ID)
Attacker sees effects; does
not need to see actual
returned packet
29 May 2002
Attacker sends packets to

intermediate, monitoring IP
ID in replies.
(e.g. TCP SYN Packets)
UC Davis Security
Bounce Scanning
returned packet
29 May 2002
Attacker sends SYN packet

with spoofed source address
to scan target
UC Davis Security
Bounce Scanning
returned packet
29 May 2002
Target sends SYN-ACK to

intermediate if port is open,
RST otherwise.
UC Davis Security
Bounce Scanning
returned packet
29 May 2002
If intermediate receives a RST

nothing happens.
If intermediate receives a
SYN-ACK, it will send a RST
and increment its IP ID
UC Davis Security
Bounce Scanning
returned packet
29 May 2002
Attacker sends
packets to intermediate,
monitoring IP ID in replies.
If ID incremented by 1, port
was closed
If ID incremented by 2, port
was open
UC Davis Security
from an arbitrary host
Uses TTL timeout.
Packets sent to target do not
have a spoofed source
address.
Info for target passed as
ICMP data (original IP
header + 8 bytes data).
29 May 2002
Attacker sends packet to

arbitrary host, w/ source address
spoofed to be target.
UC Davis Security
Uses TTL timeout.
address.
29 May 2002
Packet is passed between routers

toward destination
UC Davis Security
Uses TTL timeout.
address.
29 May 2002
Each hop decrements TTL.

When TTL reaches zero,
packet is dropped and an
ICMP TTL-expired message
is sent to claimed sender.
UC Davis Security
Detection Methods
Routing-based
Active
proactive
reactive
Passive
29 May 2002
UC Davis Security
Routing-based Methods
For a given network topology
certain source IP addresses
should never be seen
Internal addresses arriving on
external interface
External addresses arriving on
internal interface
IANA non-routable addresses
on external interface
Other special addresses
29 May 2002
UC Davis Security
External NIC
Internal NIC
Special Addresses
0.0.0.0/8
10.0.0.0/8
127.0.0.0/8
169.254.0.0/16
172.16.0.0/12
192.0.2.0/24
192.168.0.0/16
240.0.0.0/5
248.0.0.0/5
255.255.255.255/32
29 May 2002
- Historical Broadcast
- RFC 1918 Private Network
- Loopback
- Link Local Networks
- TEST-NET
- Class E Reserved
- Unallocated
- Broadcast
UC Davis Security
Routing-based Methods
Most commonly used method
firewalls, filtering routers
Relies on knowledge of network topology and

routing specs.
Primarily used at organizational border.
Cannot detect many examples of spoofing
Externally spoofed external addresses
Internally spoofed internal addresses
29 May 2002
UC Davis Security
Proactive methods
Looks for behavior that would not occur if
client actually processed packet from client.
Method: change IP stack behavior
Can observe suspicious activity
Examples
TCP window games
SYN-Cookies (block w/o detection)
29 May 2002
UC Davis Security
TCP Window Games

SYN
ack-number
Modified TCP Handshake
client
server
sends SYN packet and ACK number to server

waits for SYN-ACK from server w/ matching
ACK number
seq-number, ack-number
window = 0
responds w/ SYN-ACK packet w/ initial

random sequence number
Sets window size to zero
waits for ACK packet from client with
matching sequence number
ACK
sends ACK to server w/ matching sequence

number, but no data
Waits for ACK w/ window > 0
After receiving larger window, client sends
data.
window = 4096
client
SYN-ACK
Spoofer will not see 0-len window and will send

data without waiting.
29 May 2002
seq_number, ack-number
(no data)
ACK
ACK
seq_number, ack-number
w/ data
UC Davis Security
SYN-Cookies
SYN
Modified TCP Handshake

Example of stateless handshake
client
SYN-ACK
responds w/ SYN-ACK packet w/ initial SYN-cookie

sequence number
Sequence number is cryptographically generated value
based on client address, port, and time.
No TCP buffers are allocated
NO BUFFER ALLOCATED
client
sends SYN packet and ACK number to server

waits for SYN-ACK from server w/ matching ACK
number
server
ack-number
sends ACK to server w/ matching sequence number
seq-number as SYN-cookie,
ack-number
ACK
seq_number
ack-number+data
server
If ACK is to an unopened socket, server validates

returned sequence number as SYN-cookie
If value is reasonable, a buffer is allocated and socket is
opened.
Spoofed packets will not consume TCP buffers
29 May 2002
SYN-ACK
TCP BUFFER ALLOCATED
UC Davis Security
Reactive methods
When a suspicious packet is received, a probe of
the source is conducted to verify if the packet was
spoofed
May use same techniques as proactive methods
Example probes
Is TTL appropriate?
Is ID appropriate?
Is host up?
Change window size
29 May 2002
UC Davis Security
Passive Methods
Learn expected values for observed packets
When an anomalous packet is received,
treat it as suspicious
Example values
Expected TTL
Expected client port
Expected client OS idiosyncrasies
29 May 2002
UC Davis Security
Experiments
determine the validity of various spoofedpacket detection methods
Predictability of TTL
Predictability of TTL (active)
Predictability of ID (active)
29 May 2002
UC Davis Security
Experiment Description - Passive

Monitor network traffic
Record
Source IP address
TTL
Protocol
Count occurrences of all unique combinations

Statistically analyze predictability of the data
29 May 2002
UC Davis Security
Results - Passive
Data collected over several 2 week periods
data being reported: finals + spring break
Seclab traffic at Olympus

23,000,000 IP packets observed
23461 source IP addresses
110 internal
23351 external
29 May 2002
UC Davis Security
Results - Passive
Predictability measure
Conditional Entropy (unpredictability)
H (Y | X ) P ( x, y ) log P ( x | y )
x, y
Values closer to zero indicate higher

predictability
29 May 2002
UC Davis Security
Results - Passive
All packets
Protocol
H mean
H variance
Number
Addresses
Number
Packets
All
0.055759
0.029728
23461
22999999
ICMP
0.027458
0.023726
801
223341
IGMP
23
297
TCP
0.046149
0.023114
15891
20925893
UDP
0.065164
0.040655
7397
1850468
29 May 2002
UC Davis Security
Results - Passive
External addresses only
Protocol
H mean
H variance
Number
Addresses
Number
Packets
All
0.055505
0.029731
23351
9229608
ICMP
0.026159
0.023271
780
88371
IGMP
26
TCP
0.046324
0.023201
15825
8857983
UDP
0.065537
0.041015
7306
283228
29 May 2002
UC Davis Security
Results - Passive
Internal Addresses Only
Protocol
H mean
H variance
Number
Addresses
Number
Packets
0.109633
0.026097
110
13770391
0.075714
0.03822
21
134970
20
271
0.004189
0.000321
66
12067910
0.035207
0.010859
91
1567240
All
ICMP
IGMP
TCP
UDP
29 May 2002
UC Davis Security
Results - Passive
Only Addresses w/ more than 250 packets
Protocol
H mean
H variance
Number
Addresses
Number
Packets
All
0.060041
0.035521
2876
22338795
ICMP
0.035778
0.020212
33
219605
IGMP
TCP
0.051132
0.027288
2713
20332940
UDP
0.165818
0.175238
148
1779896
29 May 2002
UC Davis Security
Results - Passive
Only Addresses w/ more than 500 packets
Protocol
H mean
H variance
Number
Addresses
Number
Packets
All
0.050635
0.031506
2306
22140140
ICMP
0.022401
0.014516
30
218560
IGMP
TCP
0.042716
0.022273
2190
20150197
UDP
0.164326
0.209436
104
1764716
29 May 2002
UC Davis Security
Results - Passive
TTL differs by protocol
UDP most unreliable
traceroute is major contributor (can be filtered)
certain programs set TTL anomalously
ToS may be useful in reducing inconsistencies
TTL on local network highly regular

must filter traceroute traffic
29 May 2002
UC Davis Security
ToS Review
priority
minimize
delay
maximize
throughput
maximize
reliability
Minimize
$$ cost
May differ by protocol and service
Telnet:
DNS - UDP:
DNS - TCP:
NNTP:
29 May 2002
1
1
0
0
0
0
0
0
0
0
0
0
0
0
0
1
UC Davis Security
reserved
Experiment Description Reactive

Record IP address, Protocol, TTL and ID
Send probe packet(s)
ICMP echo reply packet
TCP syn packet
UDP packet
Note the differences between the stored TTL/ID to

that of the returning probes.
29 May 2002
UC Davis Security
Results - Reactive
Evaluate
initial vs. probe reply TTL
Initial vs. probe reply ID (delta from original)
Predictability measure
Conditional Entropy (unpredictability)
Values closer to zero indicate higher

predictability
29 May 2002
UC Davis Security
Results - Reactive
Preliminary only
Ran for 18 hours
8058 probes sent
218 unique addresses
173 external
45 internal
29 May 2002
UC Davis Security
Results - Reactive
TTL off by:
Total # probes
+/- 2 or less
+/-1 or less
0
29 May 2002
8058
6467
6096
5110
1591
371
986
UC Davis Security
80%
75%
63%
Results - Reactive
ID off by:
Total # probes 8058
Offset
1
2
4
6
5
7
8
29 May 2002
Count
601
57
21
16
14
11
9
Offset
256
512
768
1280
UC Davis Security
Count
73
5
22
10
Future and Ongoing Work

Complete and evaluate reactive experiments
Evaluate predictability of unobserved IP addresses
using neural network or other ML method.
Complete and test SPD program
Determine if packet is suspicious using passive system
If suspicious, use reactive methods to determine if
packet was spoofed.
29 May 2002
UC Davis Security
Conclusion
Spoofed-packets used in many different
attacks
Spoofed-packets can be detected by a
number of methods
High predictability in TTL and ID allow use
of passive and active methods
29 May 2002
UC Davis Security

Detecting Spoofed Packets: Steven Templeton UC Davis Security Lab

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Detecting Spoofed Packets: Steven Templeton UC Davis Security Lab

Uploaded by

Copyright:

Available Formats

Detecting Spoofed Packets

What is a Spoofed Packet

Not same as routing attacks

This talk will focus on IP source address spoofing

IP/TCP Header Review

IP/TCP Header Review

destination port number

options (if any)

responds w/ SYN-ACK packet

sends ACK to server

Attacker causes TCP buffer

Attacker causes TCP buffer

ICMP echo request

Because destination address

TCP Connection Spoofing

sends SYN packet and ACK

Attacker causes DOS on

Attacker sends spoofed packet to

Target sends SYN-ACK reply to

Attacker sends ACK packet to

Attacker sends packets to

Attacker sends SYN packet

Target sends SYN-ACK to

If intermediate receives a RST

Attacker sends packet to

Packet is passed between routers

Each hop decrements TTL.

Relies on knowledge of network topology and

TCP Window Games

Modified TCP Handshake

sends SYN packet and ACK number to server

responds w/ SYN-ACK packet w/ initial

sends ACK to server w/ matching sequence

Spoofer will not see 0-len window and will send

Modified TCP Handshake

responds w/ SYN-ACK packet w/ initial SYN-cookie

sends SYN packet and ACK number to server

sends ACK to server w/ matching sequence number

If ACK is to an unopened socket, server validates

Spoofed packets will not consume TCP buffers

Experiment Description - Passive

Count occurrences of all unique combinations

Seclab traffic at Olympus

Values closer to zero indicate higher

TTL on local network highly regular

May differ by protocol and service

Experiment Description Reactive

Note the differences between the stored TTL/ID to

Values closer to zero indicate higher

Future and Ongoing Work

You might also like