Handling IP Spoofing Advanced Network Security Peter Reiher August, 2014

1. Handling IP SpoofingAdvanced Network Security Peter ReiherAugust, 2014

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

3. 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

4. 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

5. 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

6. 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

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

8. 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

9. 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

10. 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

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

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

13. 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

14. 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

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

16. 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

17. 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

18. 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

19. 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

20. 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

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

22. 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

23. 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

24. 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

25. 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

26. 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?

27. 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

28. 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

29. 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

30. 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

31. 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