Handling IP Spoofing Advanced Network Security Peter Reiher August, 2014

Outline The spoofing problem Approaches to handle spoofing Spoofing, backscatter and DDoS detection

The Problem Existing Internet protocols and infrastructure allow forgery of some IP packet header fields In particular, the source address field can often be forged

Why Is That a Problem? Can’t trust where packets came from If packet causes trouble, can’t determine its true source Particularly important for distributed denial of service attacks A requirement for reflector attacks But relevant for other situations

Limitations of the Problem If attacker forges source address in packet, probably won’t see the response So spoofing only useful when attacker doesn’t care about response Usually denial of service attacks Many TCP attacks don’t work with spoofing This point is not universally true

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

Combating Spoofing Basic approaches: Authenticate address Prevent delivery of packets with spoofed addresses Trace packets with spoofed addresses to their true source

Address Authentication Would require cryptography at the packet level Can be done with IPSec Incurs cryptographic costs Could we afford to do this for all packets? Requires key infrastructure for all IP addresses E.g., a PK pair for each address Or PK pair for each subnet and an authority to do the signing Simple IPSec approach requires all senders to cooperate

Preventing Delivery of Spoofed Packets Somehow recognize that address is spoofed Usually based on information about network topology and addresses Methods could be simple or complex Different methods require different deployment strategies

General Spoofing Detection Approaches Detect in the core Detect at the sending end I A B J C H Detect at the receiving end D G F E

Examples of These Approaches Source end: Ingress filtering Destination end: Egress filtering Hop count filtering Core deployment: SAVE

My network shouldn’t be creating packets with this source address Ingress Filtering 95.113.27.12 56.29.138.2 My network shouldn’t be creating packets with this source address 128.171.192.* So drop the packet

The Problem With Ingress Filtering It protects other people from spoofing It doesn’t protect you from spoofing A slightly different version offers slight protection But it doesn’t offer anyone else protection People don’t deploy defenses that only help others Some question on how widely ingress filtering is deployed Also, ingress filtering can’t stop all spoofing You can still spoof other addresses on your subnet

Deployment of Ingress Filtering Becoming more common All modern routers include it as an option Spoofer Project estimates that 60-80% of the Internet is unspoofable I am unconvinced by their methodology But probably is a significant fraction

Packets with this source address should be going out, not coming in Egress Filtering 128.171.192.5 128.171.192.7 Packets with this source address should be going out, not coming in 128.171.192.* So drop the packet

The Problem With Egress Filtering Good deployment incentive, since it protects deploying network Works great For what it does But it doesn’t do much It can only catch a small fraction of all spoofed addresses No easy way to extend its range

Hop Count Filtering A destination end approach Destinations keep track of the hop count in IP packets Per source address They later compare hop counts of new packets to stored ones If no match, assume spoofing

Problems With Hop Count Filtering Assumes spoofer can’t guess correct hop count Assumes correct hop count doesn’t change much Assumes we do our learning when no spoofing is happening

SAVE A core deployment strategy Ensure that routers know proper incoming interface for particular source addresses Check each packet at its incoming interface Drop or flag packets on the wrong interface Key problem: How to build these tables? “Reversing routing tables” doesn’t work

The SAVE Protocol Create the tables by having routers send each other “reverse routing” messages “I send you packets with these source addresses” Receiving router observes interface these updates arrived on Uses update and interface info to build the tables

SAVE at Work Packets coming in on wrong interface can be dropped C RE 4 B D 5 E 6 C 4 5 RE 1 2 10 RC 6 E A B A RA 3 RD FORWARDING INTERFACE 11 ADDRESS C 2 7 8 D B 3 B 2 RB 9 D 2 A 7 C 8 D 9 E A 8 C D 9 E E 2 INCOMING TABLE B FORWARDING TABLE Packets coming in on wrong interface can be dropped

Did SAVE Work? Yes, but . . . Only in full deployment All routers had to run SAVE Otherwise, not all routing updates would be reflected by SAVE updates Not a realistic requirement

Tracing Spoofed Packets Don’t prevent spoofing But figure out who sent the spoofed packets Hard to do after the fact Internet doesn’t keep records of packets sent through routers Only feasible for ongoing streams of spoofed packets

Traceback An approach to trace the source of streams of spoofed packets Assumes bad nodes are sending long lasting streams of spoofed packets Not necessarily with the same spoofed addresses But to the same destinations Designed for DDoS

Problems With Traceback Approaches Require long lasting stream of spoofed packets Requires cooperation of core routers In contiguous deployment Even if it works, what then? Doesn’t stop the spoofing itself

Spoofing and Backscatter Many DDoS attacks use IP spoofing So packets with spoofed addresses get delivered to the victim Who tries to respond to them What happens to the responses?

The Result of Delivering a Spoofed Packet 105.17.22.111 73.117.65.4 A response to the spoofed packet gets delivered Not to the true sender But to the owner of the spoofed address 73.117.65.4

What Does the Recipient Do With This Reply? In most cases, nothing He didn’t ask for it, so he’ll probably discard it But what if he’s a node whose job it is to watch for bad network stuff? He just got a signal of bad network stuff I.e., spoofing

Detecting DDoS With Backscatter A big DDoS attack sends lots of spoofed packets Typically with randomly chosen addresses If a set of machines watches for unsolicited responses, It can deduce stuff about DDoS attacks

What Can Backscatter Tell Us? That an attack is ongoing Who is being attacked How big the attack is How long it lasts Requires some sophisticated analysis But people have done it successfully

Conclusion IP spoofing allows many harmful attacks to take place It’s an unavoidable outcome of the design of IP Existing solutions are only somewhat effective Spoofing still widely used