1. Lecture 17 Page 1 CS 236, Spring 2008 Advanced Topics in Network Security: IP Spoofing and DDoS CS 236 On-Line MS Program Networks and Systems Security Peter Reiher

2. Lecture 17 Page 2 CS 236, Spring 2008 Outline IP spoofing –The problem –Proposed solutions Distributed denial of service –The problem –Proposed solutions

3. Lecture 17 Page 3 CS 236, Spring 2008 The Problem of IP Spoofing Who sent you the fatal packet? IP headerIP payload Destination address Source 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!

4. Lecture 17 Page 4 CS 236, Spring 2008 What Really Happened 183.11.46.194 76.128.4.33 The dirty liar!

5. Lecture 17 Page 5 CS 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

6. Lecture 17 Page 6 CS 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...

7. Lecture 17 Page 7 CS 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

8. Lecture 17 Page 8 CS 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

9. Lecture 17 Page 9 CS 236, Spring 2008 How Much of a Problem Is Spoofing? The Spoofer Project 1 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 1 http://spoofer.csail.mit.edu/summary.php

10. Lecture 17 Page 10 CS 236, Spring 2008 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

11. Lecture 17 Page 11 CS 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?

12. Lecture 17 Page 12 CS 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?

13. Lecture 17 Page 13 CS 236, Spring 2008 Challenges for In-Network Address Authentication Large scale authentication problem –Key management, etc. Crypto costs Partial deployment Costs of updates?

14. Lecture 17 Page 14 CS 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

15. Lecture 17 Page 15 CS 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?

16. Lecture 17 Page 16 CS 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

17. Lecture 17 Page 17 CS 236, Spring 2008 Ingress Filtering Example 128.171.192.* 95.113.27.1256.29.138.2 My network shouldn’t be creating packets with this source address

18. Lecture 17 Page 18 CS 236, Spring 2008 Spoofing Detection Approaches A B C D E F G I J H

19. Lecture 17 Page 19 CS 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?

20. Lecture 17 Page 20 CS 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

21. Lecture 17 Page 21 CS 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 FORWARDING INTERFACE C 2 ADDRESS 1 2 3 45 6 78 9 10 11 B 3 D3 E 3 FORWARDING TABLE B A A 7 ADDRESS INCOMING TABLE A C B E D RARA RCRC RBRB RERE RDRD

22. Lecture 17 Page 22 CS 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

23. Lecture 17 Page 23 CS 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

24. Lecture 17 Page 24 CS 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?

25. Lecture 17 Page 25 CS 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

26. Lecture 17 Page 26 CS 236, Spring 2008 Using TTL To Detect Spoofing A B C D E F G I J H 32 3130292827 A B D E F G H I 26 58 27 26 30 A27 30

27. Lecture 17 Page 27 CS 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?

28. Lecture 17 Page 28 CS 236, Spring 2008 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

29. Lecture 17 Page 29 CS 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?

30. Lecture 17 Page 30 CS 236, Spring 2008 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

31. Lecture 17 Page 31 CS 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?

32. Lecture 17 Page 32 CS 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?