Transcript Lecture 17, Part 1

Advanced Topics in Network
Security: IP Spoofing and DDoS
CS 236
On-Line MS Program
Networks and Systems Security
Peter Reiher
CS 236, Spring 2008
Lecture 17
Page 1
Outline
• IP spoofing
– The problem
– Proposed solutions
• Distributed denial of service
– The problem
– Proposed solutions
CS 236, Spring 2008
Lecture 17
Page 2
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 17
Page 3
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 17
Page 4
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 17
Page 5
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 17
Page 6
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 17
Page 7
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 17
Page 8
How Much of a Problem Is
Spoofing?
• The Spoofer Project1 suggests ~30% 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, 30% is a lot
1http://spoofer.csail.mit.edu/summary.php
CS 236, Spring 2008
Lecture 17
Page 9
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 17
Page 10
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 17
Page 11
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 17
Page 12
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 17
Page 13
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 17
Page 14
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 17
Page 15
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 17
Page 16
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 17
Page 17
Spoofing Detection Approaches
I
A
B
J
C
H
D
CS 236, Spring 2008
E
F
G
Lecture 17
Page 18
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 17
Page 19
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 17
Page 20
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 17
Page 21
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 17
Page 22
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 17
Page 23
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 17
Page 24
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 17
Page 25
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 17
Page 26
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 17
Page 27
How Can We Deduce Spoofing?
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 17
Page 28
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 17
Page 29
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 AS knows this interface is wrong
CS 236, Spring 2008
Lecture 17
Page 30
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 17
Page 31
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 17
Page 32