Transcript incoming table

IP Spoofing
CS 236
Advanced Computer Security
Peter Reiher
April 29, 2008
CS 236, Spring 2008
Lecture 5
Page 1
Groups for This Week
1.
2.
3.
4.
5.
6.
7.
8.
Golita Benoodi, Nikolay Laptev, Faraz Zahabian
Darrell Carbajal, Abishek Jain, Peter Wu
Andrew Castner, Min-Hsieh Tsai, Chen-Kuei Lee
Chia-Wei Chang, Zhen Huang, Ionnis Pefkianakis
Chien-Chia Chen, Peter Peterson, Kuo-Yen Lo
Yu Yuan Chen, Michael Hall, Hootan Nikbakht
Michael Cohen, Chieh-Ning Lien, Vishwar Goudar
Jih-Chung Fan, Jason Liu, Sean MacIntyre
CS 236, Spring 2008
Lecture 5
Page 2
Outline
• What is IP spoofing?
• What is it used for?
• How do you stop it?
CS 236, Spring 2008
Lecture 5
Page 3
The Problem of
IP Spoofing
Now we’ll capture
the desperate
criminal!
So has someone hacked
Granny’s machine?
IP header
IP payload
Who sent you
the fatal packet?
Destination address
No, someone spoofed
Source address
Granny’s IP address!
Now we’re getting somewhere!
CS 236, Spring 2008
Lecture 5
Page 4
What Really Happened
183.11.46.194
183.11.46.194
76.128.4.33
183.11.46.194
CS 236, Spring 2008
The dirty liar!
Lecture 5
Page 5
What Is IP Spoofing?
• Existing Internet protocols and infrastructure
allow forgery of some IP packet header fields
• In particular, the source address field can often be
forged
• If packet causes trouble, can’t determine its true
source
• Particularly important for distributed denial of
service attacks
– But relevant for other situations
CS 236, Spring 2008
Lecture 5
Page 6
What Is Spoofing Used For?
• If attacker forges source address,
probably won’t see the response
• So spoofing only useful when attacker
doesn’t care about response
– Usually denial of service attacks
• This point is not universally true
– If attacker can sniff the path . . .
CS 236, Spring 2008
Lecture 5
Page 7
IP Spoofing and Reflector Attacks
• Some network sites accept remote requests
and provide answers (or take actions)
– E.g., DNS servers, broadcast addresses
• Responses go to whoever’s in the source
address of the request
• If response is a lot bigger than the request,
the attacker can cause more traffic at victim
than attacker must send out
CS 236, Spring 2008
Lecture 5
Page 8
IP Spoofing and Smurf Attacks
• Attack on vulnerability in IP broadcasting
• Send a ping packet to an IP broadcast address
– With forged IP source address of your target
• Ping gets broadcast to all addresses in broadcast
group
– Still with forged address
• Each broadcast recipient responds to the ping
– Inundating the victim of the attack
• Easy to fix at the intermediary
– No IP broadcasts from outside your network
• No good solutions for victim
CS 236, Spring 2008
Lecture 5
Page 9
Types of Spoofing
• General spoofing
– Attacker chooses a random IP address for
source address
• Subnet spoofing
– Attacker chooses an address from the
subnet his real machine is on
– With suitable sniffing, can see responses
– Harder for some types of filtering
CS 236, Spring 2008
Lecture 5
Page 10
How Much of a Problem Is
Spoofing?
• The Spoofing Project suggests 16-25% of
Internet is spoofable
– Because of ingress filtering
• Methodology based on limited number of
volunteers running their code
– Arguably the folks most likely to deploy
ingress filtering
• Even if they’re right, 20% is a lot
CS 236, Spring 2008
Lecture 5
Page 11
Combating Spoofing
•
Basic approaches:
1. Authenticate address
2. Prevent delivery of packets with spoofed
addresses
3. Trace packets with spoofed addresses to
their true source
4. Deduce bogosity from other packet header
information
5. Deduce bogosity of entire data streams with
shared IP addresses
CS 236, Spring 2008
Lecture 5
Page 12
Authenticate Address
•
•
•
•
Probably requires cryptography
Can be done with IPSec
Incurs cryptographic costs
Only feasible when crypto
authentication is feasible
• Could we afford to do this for all
packets?
CS 236, Spring 2008
Lecture 5
Page 13
Pushing Authentication Out
• Destination node can’t afford to check
authentication
– Since, usually, spoofing done at high volumes
• Could we push authentication out into the
network?
– Enlist core routers to check authentication?
• Sounds crazy
– They’re already busy
• But maybe they can do it only when needed?
• Or maybe it can be built into fast hardware?
CS 236, Spring 2008
Lecture 5
Page 14
Challenges for In-Network
Address Authentication
• Large scale authentication problem
– Key management, etc.
• Crypto costs
• Partial deployment
• Costs of updates?
CS 236, Spring 2008
Lecture 5
Page 15
Packet Passports
• A simplification of the approach
• Destination sends secret stamps to sources it
likes
• Only packets with the right stamp get
delivered
– For their source address
• Spoofers don’t know the stamp
– So their packets get dropped
• Maybe far out in the network
CS 236, Spring 2008
Lecture 5
Page 16
Issues for Stamping Approaches
•
•
•
•
Are stamps related to packet contents?
If not, can attackers “steal” a stamp?
How often do you change stamps?
How to you issue stamps to legitimate
nodes?
• Where do you put stamps?
• How do you check them fast enough?
CS 236, Spring 2008
Lecture 5
Page 17
Detect Spoofed Addresses
• Recognize that address is spoofed
– Usually based on information about:
• Network topology
• Addresses
• Simple version is ingress filtering
• More sophisticated methods are
possible
CS 236, Spring 2008
Lecture 5
Page 18
Ingress Filtering Example
95.113.27.12 56.29.138.2
My network shouldn’t be
creating packets with this
source address
128.171.192.*
CS 236, Spring 2008
Lecture 5
Page 19
Spoofing Detection Approaches
I
A
B
J
C
H
D
CS 236, Spring 2008
E
F
G
Lecture 5
Page 20
Potential Problems With Approaches
Requiring Infrastructure Support
• Issues of speed and cost
• Issues of trustworthiness
• Issues of deployment
– Why will it be deployed at all?
– How will it work partially deployed?
CS 236, Spring 2008
Lecture 5
Page 21
SAVE
• At each router, build table of proper
“incoming” interface
– For source addresses, which
interface should packets arrive?
• Kind of a generalization of ingress
filtering
• But how to get the information?
– Leverage routing table
CS 236, Spring 2008
Lecture 5
Page 22
SAVE Protocol
• SAVE builds incoming table at each router through:
– Generating SAVE updates
– Processing and forwarding SAVE updates
• Final result is that all routers build proper tables
C
4
1
2
RE
5
10
RC 6
A
E
RA 3
ADDRESS
C
B
D
E
FORWARDING
INTERFACE
2
3
3
3
7
RB
RD
D
8
9
ADDRESS
A
INCOMING
INTERFACE
7
INCOMING TABLE
FORWARDING TABLE
CS 236, Spring 2008
11
B
Lecture 5
Page 23
2
SAVE Update Generation
• Each SAVE router is assigned a source address
space (SAS)
• Range of IP addresses that use this router
as an exit router for some set of destinations
• Independent of the underlying routing protocol
• A periodic SAVE update is generated for every
entry in the forwarding table and sent to the next hop
• Forwarding table change invokes the generation of
triggered SAVE update for the changed entry
CS 236, Spring 2008
Lecture 5
Page 24
24
Updates Benefit Multiple Routers
• Intermediate routers update their incoming tables
C
4
1
2
RE
5
10
RC 6
A
RA 3
ADDRESS
C
B
D
E
FORWARDING
INTERFACE
2
3
3
3
FORWARDING TABLE
CS 236, Spring 2008
7
RB
11
E
RD
D
8
9
B
ADDRESS
INCOMING
INTERFACE
ADDRESS
INCOMING
INTERFACE
A
7
A
11
INCOMING TABLE
INCOMING TABLE
Lecture 5
Page 25
25
Updates Can Be Aggregated
• Intermediate router can piggyback its
incoming interface information to a passing update
C
4
1
2
RE
5
10
RC 6
A
RA 3
ADDRESS
C
B
D
E
FORWARDING
INTERFACE
2
3
3
3
FORWARDING TABLE
CS 236, Spring 2008
7
RB
11
E
RD
D
8
9
ADDRESS
B
A
INCOMING
INTERFACE
7
INCOMING TABLE
ADDRESS
AB
INCOMING
INTERFACE
11
INCOMING TABLE
Lecture 5
Page 26
26
Sometimes Updates Must Be Split
• Addresses in forwarding tables are highly aggregated
• At some point, the paths diverge
ADDRESS
C
AB
4
1
2
5
10
RA 3
ADDRESS
FORWARDING
INTERFACE
C
B
DE
2
3
3
7
RB
11
E
RE
RD
D
8
9
FORWARDING TABLE
ADDRESS
10
INCOMING TABLE
RC 6
A
INCOMING
INTERFACE
ADDRESS
FORWARDING
INTERFACE
E
D
8
9
FORWARDING TABLE
CS 236, Spring 2008
B
ADDRESS
A
INCOMING
INTERFACE
7
INCOMING TABLE
AB
INCOMING
INTERFACE
11
INCOMING TABLE
Lecture 5
Page 27
27
Did SAVE Work?
• Yes, just fine
• In full deployment . . .
• In partial deployment, update splitting
is extremely challenging
– Since non-deployers won’t split your
updates
• Thus, of academic interest
CS 236, Spring 2008
Lecture 5
Page 28
The iSAVE Protocol
• Attempt to solve SAVE’s deployment
problem
– Designed for partial deployment
• Router proactively send updates when
they’re actually sending traffic
– Augmented with on-demand requests
from iSAVE routers
CS 236, Spring 2008
Lecture 5
Page 29
iSAVE at Work
User traffic to X
A
1
B
2
3
4
X AB
6
5
iSAVE 8
update
7
AB
X
CS 236, Spring 2008
Y
5
Send an
iSAVE update
to X
Lecture 5
Page 30
Using the Incoming Table
X A
A
X AAA
X
X
X AAA
X
X
X AAA
X
X
X AAA
X
X
6 X
XX AAA
B
5
7
8
AB
X
5
But the
Y
incoming table
says messages
from A come on
interface 5,
not interface 6
Incoming table
CS 236, Spring 2008
Lecture 5
Page 31
On-Demand iSAVE Entries
• What if a router gets traffic when it
doesn’t have information on the proper
interface?
• Might be good traffic or spoofed traffic
• So ask the iSAVE router in charge of
the source address for an update
CS 236, Spring 2008
Lecture 5
Page 32
iSAVE’s Little Flaw
• It doesn’t work
• Why?
• Is it fixable?
CS 236, Spring 2008
Lecture 5
Page 33
Another Possible Approach
• ASPIRE
• Use BGP info to validate paths
• Essentially, when path chosen, tell
other routers that you chose that path
– And that path is the right one for
packets with these addresses
CS 236, Spring 2008
Lecture 5
Page 34
An ASPIRE Deployment
AS 3
AS 6
AS 2
AS 1
AS 2
Destination
Prefix: d1
AS 6
Source Prefixes:
s1, s2, . . . , sn AS 4
ASPIRE Capable AS
CS 236, Spring 2008
AS 5
Legacy AS
Lecture 5
Page 35
When ASPIRE First Starts on AS 6
Disallow
incoming
packets from
s1, s2, . . . ,
sn to d1.
AS 3
AS 6
AS 6
Source Prefixes:
s1, s2, . . . , sn
AS 2
AS 1
AS 4
AS 2
Destination
Prefix: d1
AS 5
Initially, ASPIRE-capable ASs disallow traffic from s1, s2,
. . . , sn to d1 from any neighbour
CS 236, Spring 2008
Lecture 5
Page 36
AS 2 Sends a BGP Update to AS 6
AS 3
d1 AS3,AS1,AS2
AS 6
AS 6
Source Prefixes:
s1, s2, . . . , sn
AS 2
d1 AS1,AS2
d1 AS2
AS 1
AS 4
AS 2
Destination
Prefix: d1
AS 5
AS 6 chooses the AS path (3, 1, 2) to route to d1
CS 236, Spring 2008
Lecture 5
Page 37
ASPIRE Springs Into Action!
AS 3
d1 s1-sn AS3,AS1,AS2
d1 s1-sn AS3,AS1,AS2
d1 s1-sn AS3,AS1,AS2
AS 6
AS 6
Source Prefixes:
s1, s2, . . . , sn
CS 236, Spring 2008
AS 2
AS 1
AS 4
AS 2
Destination
Prefix: d1
AS 5
Lecture 5
Page 38
What Has ASPIRE Achieved Here?
AS 3
AS 6
d1s1
AS 2
AS 1
AS 4
WRONG!!!!
Packets can now flow from s1, . . ., sn to d1 on
their proper path
But all other false paths for these packets
are blocked
CS 236, Spring 2008
AS 5
Lecture 5
Page 39
ASPIRE And Partial Deployment
• Non-participating Ases don’t get their
traffic protected
• Spoofed traffic can be introduced
through non-participating AS
– If it’s on the proper path
CS 236, Spring 2008
Lecture 5
Page 40
Why ASPIRE Can Never Work
• You’ll never get full deployment
• Security will kill you
– PKI required . . .
• The overheads will be unacceptable
• These all might (or might not) be true
CS 236, Spring 2008
Lecture 5
Page 41
Packet Tracing
• Figure out where the packet really came
from
• Generally only feasible if there is a
continuing stream of packets
– Usually for DDoS
• Challenges when there are multiple sources
of spoofed addresses
• For many purposes, the ultimate question is
– so what?
CS 236, Spring 2008
Lecture 5
Page 42
Using Other Packet Header Info
• Packets from a particular source IP address
have stereotypical header info
– E.g., for given destination, TTL probably
is fairly steady
• Look for implausible info in such fields
• Could help against really random spoofing
• Attacker can probably deduce many
plausible values
• There aren’t that many possible values
CS 236, Spring 2008
Lecture 5
Page 43
Using TTL To Detect Spoofing
32
A
I
31
29
30
28
B
27
J
30
C
D
CS 236, Spring 2008
E
F
G
H
A
B
D
E
F
G
H
I
27
27
26
58
27
26
30
30
Lecture 5
Page 44
Deducing Spoofing From Data
Stream Information
• Streams of packets are expected to have certain
behaviors
– Especially TCP
• Observe streams for proper behavior
– Maybe even fiddle with them a little to see
what happens
• Obvious example:
– Drop some packets from TCP stream with
suspect address
– Do they get retransmitted?
CS 236, Spring 2008
Lecture 5
Page 45
Diagram for Deducing From Data
Stream Information
AS
Packets from 131.179.192.* have been coming in on one interface
Now packets from those addresses show up on another
Route change or spoofing?
Drop a few and see what happens
CS 236, Spring 2008
Lecture 5
Page 46
What If It’s Good Traffic?
✔
✔
AS
TCP to the rescue!
Receiver tells sender to
retransmit “lost” packets
Since all dropped packets
retransmitted, they weren’t spoofed
What about that other interface?
CS 236, Spring 2008
Lecture 5
Page 47
What If It’s Bad Traffic?
AS
TCP to the rescue!
Receiver tells sender to
retransmit “lost” packets
But “sender” never heard
of those packets!
So it doesn’t retransmit
So knows this interface is wrong
CS 236, Spring 2008
Lecture 5
Page 48
Clouseau
• A system designed to do this
• Allows router to independently detect
spoofing
• Doesn’t require crypto
– No PKI!
• Must deal with attempted deception
• How could you deceive Clouseau?
– How would Clouseau detect it?
CS 236, Spring 2008
Lecture 5
Page 49
Open Questions On Spoofing
• Are there entirely different families of
approaches?
• How can you actually build tables for
detection approaches?
• Can detection approaches work in practical
deployments?
• Are crypto approaches actually feasible?
• How do you evaluate proposed systems?
CS 236, Spring 2008
Lecture 5
Page 50