Lecture 5 Page 1 CS 236, Spring 2008 IP Spoofing CS 236 Advanced Computer Security Peter Reiher April 29, 2008
Feb 25, 2016
Lecture 5Page 1CS 236, Spring 2008
IP SpoofingCS 236
Advanced Computer Security Peter Reiher
April 29, 2008
Lecture 5Page 2CS 236, Spring 2008
Groups for This Week
1. Golita Benoodi, Nikolay Laptev, Faraz Zahabian2. Darrell Carbajal, Abishek Jain, Peter Wu3. Andrew Castner, Min-Hsieh Tsai, Chen-Kuei Lee4. Chia-Wei Chang, Zhen Huang, Ionnis Pefkianakis5. Chien-Chia Chen, Peter Peterson, Kuo-Yen Lo6. Yu Yuan Chen, Michael Hall, Hootan Nikbakht7. Michael Cohen, Chieh-Ning Lien, Vishwar Goudar8. Jih-Chung Fan, Jason Liu, Sean MacIntyre
Lecture 5Page 3CS 236, Spring 2008
Outline
• What is IP spoofing?• What is it used for?• How do you stop it?
Lecture 5Page 4CS 236, Spring 2008
The Problem of IP Spoofing
Who sent you the fatal packet?
IP header IP payload
Destination addressSource address
Now we’re getting somewhere!
Now we’ll capture the desperate
criminal!So has someone hacked
Granny’s machine?
No, someone spoofed Granny’s IP address!
Lecture 5Page 5CS 236, Spring 2008
What Really Happened
183.11.46.194
183.11.46.194
183.11.46.194
76.128.4.33
The dirty liar!
Lecture 5Page 6CS 236, Spring 2008
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
Lecture 5Page 7CS 236, Spring 2008
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 . . .
Lecture 5Page 8CS 236, Spring 2008
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
Lecture 5Page 9CS 236, Spring 2008
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
Lecture 5Page 10CS 236, Spring 2008
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
Lecture 5Page 11CS 236, Spring 2008
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
Lecture 5Page 12CS 236, Spring 2008
Combating Spoofing• Basic approaches:
1. Authenticate address2. Prevent delivery of packets with spoofed
addresses3. Trace packets with spoofed addresses to
their true source4. Deduce bogosity from other packet header
information5. Deduce bogosity of entire data streams with
shared IP addresses
Lecture 5Page 13CS 236, Spring 2008
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?
Lecture 5Page 14CS 236, Spring 2008
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?
Lecture 5Page 15CS 236, Spring 2008
Challenges for In-Network Address Authentication
• Large scale authentication problem–Key management, etc.
• Crypto costs• Partial deployment• Costs of updates?
Lecture 5Page 16CS 236, Spring 2008
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
Lecture 5Page 17CS 236, Spring 2008
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?
Lecture 5Page 18CS 236, Spring 2008
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
Lecture 5Page 19CS 236, Spring 2008
Ingress Filtering Example
128.171.192.*
95.113.27.12 56.29.138.2
My network shouldn’t be creating packets with this
source address
Lecture 5Page 20CS 236, Spring 2008
Spoofing Detection Approaches
A
B
C
DE F G
I
J
H
Lecture 5Page 21CS 236, Spring 2008
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?
Lecture 5Page 22CS 236, Spring 2008
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
Lecture 5Page 23CS 236, Spring 2008
INCOMING INTERFACE
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
23
FORWARDING INTERFACE
C 2
ADDRESS
1 2
3
4 5
6
7 8
9
10
11
B 3D 3E 3
FORWARDING TABLEB A
A 7
ADDRESS
INCOMING TABLE
A
C
B
E
D
RA
RC
RB
RE
RD
Lecture 5Page 24CS 236, Spring 2008
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
24
Lecture 5Page 25CS 236, Spring 2008
• Intermediate routers update their incoming tables
B 3
Updates Benefit Multiple Routers
25
INCOMING INTERFACE
A
C
B
E
DFORWARDING INTERFACE
C 2
ADDRESS
1 2
3
4 5
6
7 8
9
10
11
D 3E 3
FORWARDING TABLE
D A
A 7
ADDRESS
INCOMING TABLE
D A
INCOMING INTERFACE
A 11
ADDRESS
INCOMING TABLE
D ARA
RC
RB
RE
RD
Lecture 5Page 26CS 236, Spring 2008
• Intermediate router can piggyback its incoming interface information to a passing update
B 3
Updates Can Be Aggregated
26
INCOMING INTERFACE
FORWARDING INTERFACE
C 2
ADDRESS
1 2
3
4 5
6
7 8
9
10
11
D 3E 3
FORWARDING TABLE
D A
A 7
ADDRESS
INCOMING TABLE
D A B
INCOMING INTERFACE
A B 11
ADDRESS
INCOMING TABLE
D A BA
B
C
E
D
RA
RC
RB
RE
RD
Lecture 5Page 27CS 236, Spring 2008
• Addresses in forwarding tables are highly aggregated• At some point, the paths diverge
B 3
Sometimes Updates Must Be Split
27
INCOMING INTERFACE
FORWARDING INTERFACE
C 2
ADDRESS
1 2
3
4 5
6
7 8
9
10
11
DE 3FORWARDING TABLE
DE AA 7
ADDRESS
INCOMING TABLE
E AB
INCOMING INTERFACE
A B 11
ADDRESS
INCOMING TABLED 9
FORWARDING INTERFACE
E 8
ADDRESS
FORWARDING TABLE
D ABD AB
E ABA
B
C
E
D
A B 10
ADDRESS
INCOMING TABLE
INCOMING INTERFACE
RA
RC
RB
RERD
Lecture 5Page 28CS 236, Spring 2008
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
Lecture 5Page 29CS 236, Spring 2008
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
Lecture 5Page 30CS 236, Spring 2008
iSAVE at Work
1
2
3
4
AB
Y
X
5
7
6
8
X AB
iSAVE update
User traffic to X
Send an iSAVE update
to XAB 5
Lecture 5Page 31CS 236, Spring 2008
Using the Incoming Table A
BY
X
5
7
6
8
X A
X A
AB 5
Incoming table
X AX AX AX AX AX AX AX AX AX AX AX AX AX A But the incoming table says messages from A come on interface 5,
not interface 6
Lecture 5Page 32CS 236, Spring 2008
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
Lecture 5Page 33CS 236, Spring 2008
iSAVE’s Little Flaw
• It doesn’t work• Why?• Is it fixable?
Lecture 5Page 34CS 236, Spring 2008
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
Lecture 5Page 35CS 236, Spring 2008
An ASPIRE Deployment
AS 1
AS 3
AS 6
AS 5AS 4
AS 2
AS 6Source Prefixes: s1, s2, . . . , sn
AS 2Destination Prefix: d1
ASPIRE Capable AS Legacy AS
Lecture 5Page 36CS 236, Spring 2008
When ASPIRE First Starts on AS 6
AS 1
AS 3
AS 6
AS 5AS 4
AS 2
AS 6Source Prefixes: s1, s2, . . . , sn
AS 2Destination Prefix: d1
Initially, ASPIRE-capable ASs disallow traffic from s1, s2, . . . , sn to d1 from any neighbour
Disallow incoming
packets from s1, s2, . . . , sn to d1.
Lecture 5Page 37CS 236, Spring 2008
AS 2 Sends a BGP Update to AS 6
AS 1
AS 3
AS 6
AS 5AS 4
AS 2
AS 6Source Prefixes: s1, s2, . . . , sn
AS 2Destination Prefix: d1
AS 6 chooses the AS path (3, 1, 2) to route to d1
d1 AS2d1 AS1,AS2d1 AS3,AS1,AS2
Lecture 5Page 38CS 236, Spring 2008
ASPIRE Springs Into Action!
AS 1
AS 3
AS 6
AS 5AS 4
AS 2
AS 6Source Prefixes: s1, s2, . . . , sn
AS 2Destination Prefix: d1
s1-snAS3,AS1,AS2d1 s1-snAS3,AS1,AS2d1s1-snAS3,AS1,AS2d1
Lecture 5Page 39CS 236, Spring 2008
What Has ASPIRE Achieved Here?
AS 1
AS 3
AS 6
AS 5AS 4
AS 2
Packets can now flow from s1, . . ., sn to d1 on their proper pathBut all other false paths for these packets are blocked
d1s1 WRONG!!!!
Lecture 5Page 40CS 236, Spring 2008
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
Lecture 5Page 41CS 236, Spring 2008
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
Lecture 5Page 42CS 236, Spring 2008
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?
Lecture 5Page 43CS 236, Spring 2008
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
Lecture 5Page 44CS 236, Spring 2008
Using TTL To Detect Spoofing
A
B
C
DE F G
I
J
H
323231
3029
28 27
A 27BDEFGHI
27265827263030
A 2730
Lecture 5Page 45CS 236, Spring 2008
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?
Lecture 5Page 46CS 236, Spring 2008
Diagram for Deducing From Data Stream Information
AS
Packets from 131.179.192.* have been coming in on one interfaceNow packets from those addresses show up on anotherRoute change or spoofing?Drop a few and see what happens
Lecture 5Page 47CS 236, Spring 2008
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?
Lecture 5Page 48CS 236, Spring 2008
What If It’s Bad Traffic?
AS
TCP to the rescue!Receiver tells sender to retransmit “lost” packetsBut “sender” never heard of those packets!So it doesn’t retransmitSo knows this interface is wrong
Lecture 5Page 49CS 236, Spring 2008
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?
Lecture 5Page 50CS 236, Spring 2008
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?