IP Spoofer Project Observations on four-years of data Rob Beverly, - - PowerPoint PPT Presentation

▶
ip spoofer project
SMART_READER_LITE
LIVE PREVIEW

IP Spoofer Project Observations on four-years of data Rob Beverly, - - PowerPoint PPT Presentation

Jan 01, 2024 100 likes •697 views

IP Spoofer Project Observations on four-years of data Rob Beverly, Arthur Berger, Young Hyun {rbeverly,awberger}@csail.mit, youngh@caida ISMA AIMS 2009 February 12, 2009 Spoofer Project Background Recent Relevance Project

slide-1
SLIDE 1

IP Spoofer Project

ISMA AIMS 2009 February 12, 2009

Rob Beverly, Arthur Berger, Young Hyun

{rbeverly,awberger}@csail.mit, youngh@caida

Observations on four-years of data

slide-2
SLIDE 2

2

Spoofer Project

  • Background
  • Recent Relevance
  • Project Description
  • What’s New: Methodology
  • What’s New: Data
  • Parting Thoughts
slide-3
SLIDE 3

3

Spoofed-Source IP Packets

  • Circumvent host network stack to forge or

“spoof” source address of an IP packet

  • Lack of source address accountability a

basic Internet weakness:

– Anonymity, indirection [VP01], amplification

  • Security issue for more than two-decades

[RTM85, Bellovin89]

  • Still an attack vector?
slide-4
SLIDE 4

4

Circa 2004…

IP Source Spoofing doesn’t matter!

a) All providers filter b) All modern attacks use botnets c) Compromised hosts are behind NATs

slide-5
SLIDE 5

5

Circa 2004…

IP Source Spoofing doesn’t matter!

a) All providers filter b) All modern attacks use botnets c) Compromised hosts are behind NATs

!?!?!

slide-6
SLIDE 6

6

The Spoofer Project

  • Strong opinions from many sides:

– Academic – Operational – Regulatory

  • …but only anecdotal data
slide-7
SLIDE 7

7

spoofer.csail.mit.edu

  • Internet-wide active measurement effort:

– Quantify the extent and nature of Internet source address filtering

  • We learn and form inferences over:

– Filtering policies/currently employed defenses – Filtering specificity, locations, providers, etc. – Distribution of filtering

  • Began Feb. 2005
slide-8
SLIDE 8

8

Spoofer Project

  • Background
  • Recent Relevance
  • Project Description
  • What’s New: Methodology
  • What’s New: Data
  • Parting Thoughts
slide-9
SLIDE 9

9

Prediction: spoofing increasingly a problem in the future

  • Spoofed traffic complicates a defenders job
  • Tracking spoofs is operationally difficult:

– [Greene, Morrow, Gemberling NANOG 23] – Hash-based IP traceback [Snoeren01] – ICMP traceback [Bellovin00]

  • Consider a 10,000 node zombie DDoS

– Today (worst case scenario): if non-spoofing zombies are widely distributed, a network operator must defend against attack packets from 5% of routeable netblocks. – Future: if 25% of zombies capable of spoofing significant volume of the traffic could appear to come any part of the IPv4 address space

  • Adaptive programs that make use of all local host

capabilities to amplify their attacks

Slide from SRUTI 2005

slide-10
SLIDE 10

10

Prominent 2008 Example: DNS Amplifier Attack

Victim Attacker 3rd Party DNS Servers hack.com large TXT record

slide-11
SLIDE 11

11

Prominent 2008 Example: DNS Amplifier Attack

Victim Attacker 3rd Party DNS Servers hack.com large TXT record IP Src: V DNS Query: hack.com TXT

slide-12
SLIDE 12

12

Prominent 2008 Example: DNS Amplifier Attack

Victim Attacker 3rd Party DNS Servers hack.com large TXT record IP Src: V DNS Query: hack.com TXT $$ result

slide-13
SLIDE 13

13

Prominent 2008 Example: DNS Amplifier Attack

Victim Attacker 3rd Party DNS Servers hack.com large TXT record IP Src: Carol IP Dst: V Large DNS TXT response

slide-14
SLIDE 14

14

Prominent 2008 Example: DNS Amplifier Attack

Victim Attacker 3rd Party DNS Servers hack.com large TXT record

  • Small spoofed DNS query is

amplified into large (anonymous) response toward victim

  • Largest reported attack: 40Gbps*

*Arbor networks 2008 infrastructure security survey

slide-15
SLIDE 15

15

Reasons to Believe Spoofing Matters (2009)

  • DNS Amplifier Attacks
  • In-Window TCP Reset Attacks
  • Spam Filter Circumvention
  • DNS Cache Poisoning
  • UW reverse traceroute
  • Spoofer web site statistics
slide-16
SLIDE 16

16

The Operational Side

  • Arbor:

– “Reflective amplification attacks responsible for the largest attacks exploit IP spoofing” – “No bots were used in this attack. The attacker had a small number of compromised Linux boxes from which he’d launch the spoofed source DNS query.”

  • What’s an operator to do?

*Arbor networks 2008 infrastructure security survey

slide-17
SLIDE 17

17

Operational View

Switch, DOCSIS Static ACL uRPF Bogon Filters Possible Defense Neighbor Spoof RFC1918 private Valid (In BGP table) Unallocated Description Client IP ⊕ (2N) 192.168.1.1 6.1.2.3 1.2.3.4 Example Source IP

IPv4 Address Space

  • Not all sources are created equal
  • IETF BCP38 best filtering practice
slide-18
SLIDE 18

18

Operational View

  • We have defenses, what’s the problem?
  • BCP38 suffers from:

– Incentive problem – Lack of hardware support (see NANOG) – Management nightmare (edge filters)

> 30% don’t filter!

*Arbor networks 2008 infrastructure security survey

slide-19
SLIDE 19

19

Spoofer Project

  • Background
  • Recent Relevance
  • Project Description
  • What’s New: Methodology
  • What’s New: Data
  • Parting Thoughts
slide-20
SLIDE 20

20

Spoofer Test Client

  • Willing participants run “spoofer” client to

test policy, perform inference, etc.

– Binaries, source publicly available

slide-21
SLIDE 21

21

Spoofer Operation

Client spoofer server Spoofed Source Packets DB Correlate Record

  • Clients attempt to send series of spoofed

UDP packets to collection server:

– 5 of each type with random inter-packet delay – UDP port 53 to avoid secondary filtering – Payload includes unique14 byte identifier

  • Server stores received packets in DB
slide-22
SLIDE 22

22

Spoofer Operation

Client spoofer server TCP Control Connection Spoofed Source Packets DB Correlate Record

  • Spoofer client sends a report of

spoofed packets to server via TCP

  • Client traceroutes to server and

sends result

  • TCP destination port 80 used to

avoid secondary filtering effects

slide-23
SLIDE 23

23

Client Population

Advertised to NANOG, dshield,

  • etc. mailing lists

Slashdot! Still receiveing results

slide-24
SLIDE 24

24

Client Population Distribution

slide-25
SLIDE 25

25

Filtering Specificity

  • Clients test own IP ⊕

(2^n) for 0<n<24

  • Filtering on a /8

boundary enables a client within that network to spoof ~16M addresses

  • >30% of clients

“unable” to spoof can spoof neighbors

  • Exclude “neighbor

spoof” from macro results

slide-26
SLIDE 26

26

  • Spoofable: spoofing of private, unallocated, or

valid IP packets possible from these locations

  • Agrees to a first-order with Arbor survey
  • But… these numbers cause even more

disagreement!

slide-27
SLIDE 27

27

Spoofer Project

  • Background
  • Recent Relevance
  • Project Description
  • What’s New: Methodology
  • What’s New: Data
  • Parting Thoughts
slide-28
SLIDE 28

28

What’s New: Methodology

  • Goal:

– Resolve ambiguity – Increase confidence

  • New:

– tracefilter – Tied into CAIDA’s ark distributed measurement infrastructure – More detailed analysis – Longitudinal analysis over four-years of data

slide-29
SLIDE 29

29

tracefilter

  • A tool for locating source address

validation (anti-spoofing) filters along path

  • “traceroute for BCP38”
  • Better understand who is/is not filtering
slide-30
SLIDE 30

30

tracefilter

Client (c) spoofer server (S)

  • Client c works in conjunction with our

server S

slide-31
SLIDE 31

31

tracefilter

Client (c) spoofer server (S) IP Src: s IP Dst: s+1 TTL: 2

  • c sends spoofed packet with:
  • ttl=x, src=S, dst=S+1 for 0<x<pathlen
slide-32
SLIDE 32

32

tracefilter

Client (c) spoofer server (S) IP Src: rtr IP Dst: s ICMP TTL exceeded

  • S receives ICMP expiration messages

from routers along path

  • For each decoded TTL, S records which

spoofed packets are received

slide-33
SLIDE 33

33

tracefilter

Client (c) spoofer server (S) IP Src: s IP Dst: s+1 TTL: 3

  • Increase TTL, repeat
  • Largest TTL indicates filtering point
slide-34
SLIDE 34

34

tracefilter

  • How can S determine originating TTL of c’s

packets?

  • ICMP echo includes only 28 bytes of expired

packet

  • c encodes TTL by padding payload with zeros

SRC: S DST: S+1 TTL: 0 SRC: SessID Len: 8+x Type: TTL Exceeded ICMP IP UDP Echo

Response:

SRC: S DST: S+1 TTL: x SRC: SessID DST: 53 0x IP UDP Payload

Probe:

slide-35
SLIDE 35

35

tracefilter Results

  • 70% of filters at 1st

hop; 81% within first two hops

slide-36
SLIDE 36

36

tracefilter Results

  • 70% of filters at 1st

hop; 81% within first two hops

  • 97% of filters within

first AS

slide-37
SLIDE 37

37

tracefilter Results

  • 70% of filters at 1st

hop; 81% within first two hops

  • 97% of filters within

first AS

If a spoofed packet passes through first two hops, likely to travel unimpeded to destination

slide-38
SLIDE 38

38

Ark Support

  • Spoofer tester now tied into CAIDA’s

archipelago distributed measurement infrastructure (Ark)

  • Provides invaluable additional inference

capability

  • Allows us to resolve aforementioned

ambiguity

slide-39
SLIDE 39

39

Utilizing Ark Infrastructure

Client spoofer server TCP Control Connection ark sjc-us ark hlz-nz ark san-us ark her-gr

  • Server and Ark nodes agree on common HMAC key
  • Provide client with (SRC, DST, KEY, SEQ) tuples
slide-40
SLIDE 40

40

Utilizing Ark Infrastructure

Client spoofer server TCP Control Connection Spoofed Source Packets ark sjc-us ark hlz-nz ark san-us ark her-gr

  • Client sends HMAC keyed spoof probes to ark nodes
  • Client runs traceroute to each ark node in parallel
slide-41
SLIDE 41

41

Utilizing Ark Infrastructure

Client spoofer server TCP Control Connection Spoofed Source Packets ark sjc-us ark hlz-nz ark san-us ark her-gr Ark Tuple Space

  • Ark nodes publish to tuple space
  • Server asynchronously picks up results
slide-42
SLIDE 42

42

Value of Ark

  • How does Ark allow us better inference
  • Example:
slide-43
SLIDE 43

43

Multiple Destinations

Client Commercial R&E Univ NZ MIT .mil Univ ES

slide-44
SLIDE 44

44

Multiple Destinations

  • Blue line is bogon traffic (IP:

1.2.3.4)

  • Much greater inference power
  • Detect bogon filtering at multiple

ASes

  • MIT server alone finds bogons

filtered; too coarse!

Commercial R&E Univ NZ MIT .mil Univ ES

slide-45
SLIDE 45

45

Multiple Destinations

  • Metric of spoofability now a path

rather than a client

  • Allows inference on the

complete AS graph

  • Better understanding of where to

employ spoofing defenses

Commercial R&E Univ NZ MIT .mil Univ ES

slide-46
SLIDE 46

46

Spoofer Project

  • Background
  • Recent Relevance
  • Project Description
  • What’s New: Methodology
  • What’s New: Data
  • Parting Thoughts
slide-47
SLIDE 47

47

Deeper Analysis

  • Question we want to answer:

– Geographic analysis – Large or small providers filter? – What kinds of providers?

slide-48
SLIDE 48

48

Geographic (Tests)

slide-49
SLIDE 49

49

Geographic (Spoofable)

10.5% Africa 9.2% Europe 9.7% Australia 20.3% Asia 8.7% North America 10.5% South America Spoofable Region

slide-50
SLIDE 50

50

DNS Stats

  • Asia, Mexico high

spoofing success

  • OS blocked rates

encouraging

  • Large numbers of

non-NAT hosts, especially .edu

slide-51
SLIDE 51

51

Connection Classes

  • DSL, cable

easiest to control (built into architecture)

  • Commercial,

unknown highest spoofing rates

slide-52
SLIDE 52

52

AS Degree

  • Small or large

providers filtering?

  • Surprisingly,

no clear trend

  • Work required

across the board (or a new solution)

slide-53
SLIDE 53

53

Spoofer Project

  • Background
  • Recent Relevance
  • Project Description
  • What’s New: Methodology
  • What’s New: Data
  • Longitudinal Analysis
  • Parting Thoughts
slide-54
SLIDE 54

54

Parting Thoughts (1)

58% Bogon Filters Unallocated 1.2.3.4 Static ACL uRPF Defense 1% 90% Percent RFC1918 private Valid (In BGP table) Description 172.16.1.100 6.1.2.3 Spoofed Source

  • Among clients able to spoof, what sources

can they spoof?

slide-55
SLIDE 55

55

Parting Thoughts (1)

58% Bogon Filters Unallocated 1.2.3.4 Static ACL uRPF Defense 1% 90% Percent RFC1918 private Valid (In BGP table) Description 172.16.1.100 6.1.2.3 Spoofed Source Low hanging fruit already employed, problem is harder!

slide-56
SLIDE 56

56

Parting Thoughts (2)

  • Tracefilter exposes operational tension between

current filtering incentives and difficulty managing edge filters

  • If a spoofed packet isn’t filtered at edge, will

travel unimpeded to destination

  • Should we think about core filtering techniques?

– StackPI – ML approaches with soft response (rbeverly thesis work) – Others

slide-57
SLIDE 57

57

Parting Thoughts

  • Even after all these years, source spoofing

problem not solved

– BCP38 has been around for 9 years – BCP38 great, but incentives wrong

  • Single unfiltered ingress can compromise entire

Internet system

– Can we plug every hole? – Regulatory Response? … but multinational? – Spoofer page for public provider flogging?

  • What’s needed (biased opinion!):

– Clean slate design – Filtering in the core

slide-58
SLIDE 58

58

Parting Thoughts

  • Even after all these years, source spoofing

problem not solved

– BCP38 has been around for x years – BCP38 great, but incentives wrong

  • Single unfiltered ingress can compromise entire

Internet system

– Can we plug every hole? – Regulatory Response? … but multinational? – Spoofer page for public provider flogging?

  • What’s needed (biased opinion!):

– Clean slate design – Filtering in the core

Thanks!

http://spoofer.csail.mit.edu