html5-img
1 / 50

IP Spoofing CS 236 Advanced Computer Security Peter Reiher April 29, 2008

IP Spoofing CS 236 Advanced Computer Security Peter Reiher April 29, 2008. Groups for This Week. Golita Benoodi, Nikolay Laptev, Faraz Zahabian Darrell Carbajal, Abishek Jain, Peter Wu Andrew Castner, Min-Hsieh Tsai, Chen-Kuei Lee Chia-Wei Chang, Zhen Huang, Ionnis Pefkianakis

marvin
Télécharger la présentation

IP Spoofing CS 236 Advanced Computer Security Peter Reiher April 29, 2008

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. IP SpoofingCS 236Advanced Computer Security Peter ReiherApril 29, 2008

  2. Groups for This Week • Golita Benoodi, Nikolay Laptev, Faraz Zahabian • Darrell Carbajal, Abishek Jain, Peter Wu • Andrew Castner, Min-Hsieh Tsai, Chen-Kuei Lee • Chia-Wei Chang, Zhen Huang, Ionnis Pefkianakis • Chien-Chia Chen, Peter Peterson, Kuo-Yen Lo • Yu Yuan Chen, Michael Hall, Hootan Nikbakht • Michael Cohen, Chieh-Ning Lien, Vishwar Goudar • Jih-Chung Fan, Jason Liu, Sean MacIntyre

  3. Outline • What is IP spoofing? • What is it used for? • How do you stop it?

  4. Destination address Source address The Problem of IP Spoofing IP header IP payload Now we’ll capture the desperate criminal! So has someone hacked Granny’s machine? Who sent you the fatal packet? No, someone spoofed Granny’s IP address! Now we’re getting somewhere!

  5. 183.11.46.194 183.11.46.194 What Really Happened 183.11.46.194 76.128.4.33 The dirty liar!

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

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

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

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

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

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

  12. Combating Spoofing • Basic approaches: • Authenticate address • Prevent delivery of packets with spoofed addresses • Trace packets with spoofed addresses to their true source • Deduce bogosity from other packet header information • Deduce bogosity of entire data streams with shared IP addresses

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

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

  15. Challenges for In-Network Address Authentication • Large scale authentication problem • Key management, etc. • Crypto costs • Partial deployment • Costs of updates?

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

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

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

  19. 95.113.27.12 56.29.138.2 Ingress Filtering Example My network shouldn’t be creating packets with this source address 128.171.192.*

  20. Spoofing Detection Approaches I A B J C H D G F E

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

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

  23. B A SAVE Protocol C RE 4 5 1 10 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 2 RC 6 E A RA 3 RD 11 FORWARDING INTERFACE RB ADDRESS D 7 8 C 2 B 3 INCOMING INTERFACE 9 ADDRESS D 3 A 7 3 E INCOMING TABLE FORWARDING TABLE B 23

  24. 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 oftriggered SAVE update for the changed entry 24

  25. D A D A D A Updates Benefit Multiple Routers C RE 4 5 1 10 2 RC 6 E A RA 3 RD 11 FORWARDING INTERFACE RB ADDRESS Intermediate routers update their incoming tables D 7 8 C 2 B 3 9 D 3 INCOMING INTERFACE INCOMING INTERFACE ADDRESS ADDRESS 3 E A 11 A 7 FORWARDING TABLE B INCOMING TABLE INCOMING TABLE 25

  26. D A B D A B D A Updates Can Be Aggregated C RE 4 5 1 10 2 RC 6 E A RA 3 RD Intermediate router can piggyback its incoming interface information to a passing update 11 FORWARDING INTERFACE RB ADDRESS D 7 8 C 2 B 3 9 D 3 INCOMING INTERFACE INCOMING INTERFACE ADDRESS ADDRESS 3 E A B 11 A 7 FORWARDING TABLE B INCOMING TABLE INCOMING TABLE 26

  27. DE A D AB D AB E AB E AB Sometimes Updates Must Be Split INCOMING INTERFACE ADDRESS C A B 10 4 5 INCOMING TABLE 1 10 2 RC 6 E A RE RA 3 RD Addresses in forwarding tables are highly aggregated At some point, the paths diverge 11 FORWARDING INTERFACE RB ADDRESS D 7 8 C 2 B 3 9 DE 3 FORWARDING TABLE INCOMING INTERFACE ADDRESS B FORWARDING INTERFACE INCOMING INTERFACE ADDRESS A B 11 ADDRESS E 8 A 7 INCOMING TABLE D 9 INCOMING TABLE FORWARDING TABLE 27

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

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

  30. User traffic to X 3 1 4 2 6 5 X AB iSAVE update 7 8 AB 5 iSAVE at Work A B Y Send an iSAVE update to X X

  31. X X X X X X X X X X X X X X X X A A A A A A A A A A A A A A A A 6 5 7 8 AB 5 Incoming table Using the Incoming Table A B But the incoming table says messages from A come on interface 5, not interface 6 Y X

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

  33. iSAVE’s Little Flaw • It doesn’t work • Why? • Is it fixable?

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

  35. An ASPIRE Deployment AS 3 AS 2 AS 2 Destination Prefix: d1 AS 6 AS 1 AS 6 Source Prefixes: s1, s2, . . . , sn AS 4 AS 5 ASPIRE Capable AS Legacy AS

  36. Disallow incoming packets from s1, s2, . . . , sn to d1. When ASPIRE First Starts on AS 6 AS 3 AS 2 AS 2 Destination Prefix: d1 AS 6 AS 1 AS 6 Source Prefixes: s1, s2, . . . , sn AS 4 AS 5 Initially, ASPIRE-capable ASs disallow traffic from s1, s2, . . . , sn to d1 from any neighbour

  37. d1 d1 d1 AS2 AS1,AS2 AS3,AS1,AS2 AS 2 Sends a BGP Update to AS 6 AS 3 AS 2 AS 2 Destination Prefix: d1 AS 6 AS 1 AS 6 Source Prefixes: s1, s2, . . . , sn AS 4 AS 5 AS 6 chooses the AS path (3, 1, 2) to route to d1

  38. d1 d1 d1 s1-sn s1-sn s1-sn AS3,AS1,AS2 AS3,AS1,AS2 AS3,AS1,AS2 ASPIRE Springs Into Action! AS 3 AS 2 AS 2 Destination Prefix: d1 AS 6 AS 1 AS 6 Source Prefixes: s1, s2, . . . , sn AS 4 AS 5

  39. WRONG!!!! d1 s1 What Has ASPIRE Achieved Here? AS 3 AS 2 AS 6 AS 1 AS 4 AS 5 Packets can now flow from s1, . . ., sn to d1 on their proper path But all other false paths for these packets are blocked

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

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

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

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

  44. 30 27 28 29 30 31 32 32 A 27 A 27 B 27 D 26 E 58 F 27 G 26 H 30 I 30 Using TTL To Detect Spoofing I A B J C H D G F E

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

  46. Diagram for Deducing From Data Stream Information 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

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

  48. 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 knows this interface is wrong

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

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

More Related