02/15/2007ecs2361 tracing & traceability s. felix wu uc davis wu [email protected]

51
02/15/2007 ecs236 1 Tracing & Traceability S. Felix Wu UC Davis http://www.cs.ucdavis.edu/~wu [email protected]

Upload: horatio-hubbard

Post on 18-Dec-2015

219 views

Category:

Documents


0 download

TRANSCRIPT

Page 1: 02/15/2007ecs2361 Tracing & Traceability S. Felix Wu UC Davis wu wu@cs.ucdavis.edu

02/15/2007 ecs236 1

Tracing & Traceability

S. Felix WuUC Davishttp://www.cs.ucdavis.edu/[email protected]

Page 2: 02/15/2007ecs2361 Tracing & Traceability S. Felix Wu UC Davis wu wu@cs.ucdavis.edu

02/15/2007 ecs236 2

Traceability

• spoofing/hiding the origin– network/host/process identities

• distributed network/system level information– security (worm), fault (routing), performance

Page 3: 02/15/2007ecs2361 Tracing & Traceability S. Felix Wu UC Davis wu wu@cs.ucdavis.edu

02/15/2007 ecs236 3

What is the problem?• Egress/ingress filtering possible??• Locating the slaves (compromized hosts in

Universities, e.g.) is a good first step.• Probably easiest to find.• Cut them off to help.• Further track down masters and “the attacker.”

• Recent Proposed Solutions:• discovery the route paths from Slaves to the victim.

» Information sometimes useful to distinguish malicious DDoS attacks (from a few slaves) versus “Internet traffic hot spots.”

Page 4: 02/15/2007ecs2361 Tracing & Traceability S. Felix Wu UC Davis wu wu@cs.ucdavis.edu

02/15/2007 ecs236 4

Each slave emits a “relatively small” amount of attack packets

Masters

Slaves

Victim

... ISP

.com::.

Attackerssrc: randomdst: victim

This will be a problem forany “static” probabilistic schemes.

Page 5: 02/15/2007ecs2361 Tracing & Traceability S. Felix Wu UC Davis wu wu@cs.ucdavis.edu

02/15/2007 ecs236 5

Example: An Attack Path

0

1

2

3 7

5 8

4

6

target

1112

10

9

13

14

15

Attack traffic

attacker

Page 6: 02/15/2007ecs2361 Tracing & Traceability S. Felix Wu UC Davis wu wu@cs.ucdavis.edu

02/15/2007 ecs236 6

Attack Path Traceback Problem

A5A5 R9R9

A3A3

R11R11 A4 A4

R8R8

R4R4

A2 A2

A1A1 R10R10

R7R7R6R6

R3R3 R 5R 5

R2R2

R1R1

VVtt

A6A6

• An attack path is an ordered list of nodes along which the attack packets traveled between Ai and vt .

• The traceback problem is to find the attack path and the associated attack origin for each attacker.

Page 7: 02/15/2007ecs2361 Tracing & Traceability S. Felix Wu UC Davis wu wu@cs.ucdavis.edu

02/15/2007 ecs236 7

Probabilistic Marking and Sampling• [Savage and others] an encoding algorithm (by overloading 16-bit IP

Identification field used for fragmentation) such that all the intermediate routers will probabilistically mark in-flight packets with partial path information. Each marked packet will represent a”sample” of the path it has traveled.

• Node sampling: 32-bit router address– The probability of receiving a marked packet from a router d hops away is p(1-

p)^(d-1).

– Ranking each router by the number of samples it contributes will tend to produce the accurate attack path.

– However, producing the path from the sample distribution is a slow process and possibly incorrect.

– Not robust under DDoS with multiple attackers from the same distance.

Page 8: 02/15/2007ecs2361 Tracing & Traceability S. Felix Wu UC Davis wu wu@cs.ucdavis.edu

02/15/2007 ecs236 8

Packet Marking

Masters

Slaves

Victim

... ISP

.com::.

Attackerssrc: randomdst: victim

Page 9: 02/15/2007ecs2361 Tracing & Traceability S. Felix Wu UC Davis wu wu@cs.ucdavis.edu

02/15/2007 ecs236 9

Probabilistic Edge Marking and SamplingMarking procedure at router R: for each packet w let x be a random number from [0..1) if x < p then write R into w.start and 0 into w.distance else if w.distance == 0 then write R into w.end increment w.distance

Path reconstruction procedure at victim v: let G be a tree with root v let edges in G be tuples (start, end, distance) for each packet w from attacker if w.distance == 0 then insert edge (w.start, v, 0) into G else insert edge (w.start, w.end, w.distance ) into G remove any edge (x, y,d) with d != distance from x to v in G extract path (Ri….Rj) by enumerating acyclic paths in G

• Edge sampling: 3 static fields (two 32-bit end addresses, one 8-bit distance) can be hashed into 16-bit IP Identification field.• The number of packet needed to reconstruct a path of length d has bounded expectation:

•As long as p < = 1/d, the number is within a small constant of optimal.

)(dp)p(

(d)E(X)

11

ln−−

<

Page 10: 02/15/2007ecs2361 Tracing & Traceability S. Felix Wu UC Davis wu wu@cs.ucdavis.edu

02/15/2007 ecs236 10

ver hlen TOS Total Length

Identification flags offset

Time to live Protocol Header checksum

Source IP address

Destination IP address

offset Distance Edge fragment

0 2 3 7 8 15

Encoding edge fragments into the IP identification field

• IP ID field should not be changed if fragmentation is necessary.

• [Song, Franklin] proposed improved advance marking schemes for IP ID field.

Page 11: 02/15/2007ecs2361 Tracing & Traceability S. Felix Wu UC Davis wu wu@cs.ucdavis.edu

02/15/2007 ecs236 11

Probabilistic Marking???

Masters

Slaves

Victim

... ISP

.com::.

Reflectors

Attackerssrc: victim

dst: reflector

src: reflectordst: victim

???

???Find a specialhoney-potreflectors???

Page 12: 02/15/2007ecs2361 Tracing & Traceability S. Felix Wu UC Davis wu wu@cs.ucdavis.edu

02/15/2007 ecs236 12

portscan Honeypot$ portscan 128.3X.XX.XXX

Port 21 ("ftp" service) connection ... open.

Port 23 ("telnet" service) connection ... open.

Port 25 ("smtp" service) connection ... open.

The hackers will not know which IP addresseshave been aggregated into a honey-pot.

If a good portion of the reflectors for a particularslave belongs to a single portscan Honeypot….

Page 13: 02/15/2007ecs2361 Tracing & Traceability S. Felix Wu UC Davis wu wu@cs.ucdavis.edu

02/15/2007 ecs236 13

ICMP Traceback• For a very few packets (about 1 in 20,000), each

router will send the destination a new ICMP message indicating the previous hop for that packet.

• Net traffic increase at endpoint is about .1% -- probably acceptable.

• Issues: authentication, loss of traceback packets, load on routers.

Page 14: 02/15/2007ecs2361 Tracing & Traceability S. Felix Wu UC Davis wu wu@cs.ucdavis.edu

02/15/2007 ecs236 14

Probabilistic ICMP Traceback Sampling

• [bellovin]: When forwarding packets, router can randomly generate a new ICMP traceback message (ITRACE) with a low probability (e.g., 1/20,000) along the path and sent to the destination. The information in samples can then be chained together to construct the path.

• Each ITRACE contains – back link on the previous hop

– forward link on the next hop

– timestamp

– traced packet

– authentication: for preventing fake traceback messages.

Page 15: 02/15/2007ecs2361 Tracing & Traceability S. Felix Wu UC Davis wu wu@cs.ucdavis.edu

02/15/2007 ecs236 15

iTrace Packets

0

1

2

3 7

5 8

4

6

target

1112

10

9

13

14

15

iTrace

slave

iTrace

Page 16: 02/15/2007ecs2361 Tracing & Traceability S. Felix Wu UC Davis wu wu@cs.ucdavis.edu

02/15/2007 ecs236 16

Original iTrace

Masters

Slaves

Victim

... ISP

.com::.

Attackerssrc: randomdst: victim

Page 17: 02/15/2007ecs2361 Tracing & Traceability S. Felix Wu UC Davis wu wu@cs.ucdavis.edu

02/15/2007 ecs236 17

iTrace in Reflective DDOS

Masters

Slaves

Victim

... ISP

.com::.

Reflectors

Attackerssrc: victim

dst: reflector

src: reflectordst: victim

Page 18: 02/15/2007ecs2361 Tracing & Traceability S. Felix Wu UC Davis wu wu@cs.ucdavis.edu

02/15/2007 ecs236 18

ICMP Traceback

• For a very small probability (about 1 in 20,000), each router will send the destination (and/or the source) a new ICMP message indicating the previous hop for that packet.

• Net traffic increase at endpoint is probably acceptable.

iTrace it or not??

Page 19: 02/15/2007ecs2361 Tracing & Traceability S. Felix Wu UC Davis wu wu@cs.ucdavis.edu

02/15/2007 ecs236 19

Each slave emits a “relatively small” amount of attack packets

Masters

Slaves

Victim

... ISP

.com::.

Attackerssrc: randomdst: victim

This will be a problem forany “static” probabilistic schemes.

Page 20: 02/15/2007ecs2361 Tracing & Traceability S. Felix Wu UC Davis wu wu@cs.ucdavis.edu

02/15/2007 ecs236 20

Reflector

• Use a legitimate network server/client as the reflector to avoid being traced. (stepping stone).

Reflector

VictimSlave

Service Request Packetsrc: Victimdst: Reflector

Service Reply Packet src: Reflector dst: Victim

Page 21: 02/15/2007ecs2361 Tracing & Traceability S. Felix Wu UC Davis wu wu@cs.ucdavis.edu

02/15/2007 ecs236 21

Reflector

VictimSlave

Service Request Packetsrc: Victimdst: Reflector

Service Reply Packet src: Reflector dst: Victim

sourceTracebackMessages

Who has spoofed me??

Page 22: 02/15/2007ecs2361 Tracing & Traceability S. Felix Wu UC Davis wu wu@cs.ucdavis.edu

02/15/2007 ecs236 22

Improved iTrace

Masters

Slaves

Victim

... ISP

.com::.

Reflectors

Attackerssrc: victim

dst: reflector

src: reflectordst: victim

Page 23: 02/15/2007ecs2361 Tracing & Traceability S. Felix Wu UC Davis wu wu@cs.ucdavis.edu

02/15/2007 ecs236 23

iTrace Probability: 1/20,000

Attack traffic

Background traffic

For a router with “lots” of background traffic, it will takea long time before we really generate a “useful” iTrace.

Page 24: 02/15/2007ecs2361 Tracing & Traceability S. Felix Wu UC Davis wu wu@cs.ucdavis.edu

02/15/2007 ecs236 24

Usefulness of iTrace messages• “finding” the right attack paths.

• “attack” packets

V

R2

R1

R5

R3

R4

R6

R7

R8

R9

S1

S2

S3

Sx

Sn

Page 25: 02/15/2007ecs2361 Tracing & Traceability S. Felix Wu UC Davis wu wu@cs.ucdavis.edu

02/15/2007 ecs236 25

Value(iTrace) =

(Attack(iTrace) * Intention(dst-ID) * hopCount(rtr-ID dst-ID) Received(ID dst-ID) * Generated(rtr-ID)

1th useful itrace

Page 26: 02/15/2007ecs2361 Tracing & Traceability S. Felix Wu UC Davis wu wu@cs.ucdavis.edu

02/15/2007 ecs236 26

iTrace Probability: 1/20,000

For routers closer to the victim, valid iTrace messages will beproduced very frequently. But, for routers closer to a slavewith a low packet rate, it can take a long time, statistically,for the “right” iTrace messages to be generated.

A high-rate attack flow from the slave:

A low-rate attack flow from the slave:

Aggregation of lower-rate flows at routers near the victims:

Page 27: 02/15/2007ecs2361 Tracing & Traceability S. Felix Wu UC Davis wu wu@cs.ucdavis.edu

02/15/2007 ecs236 27

Intention-driven iTracedistribute the Internet tracing resources

• Different destination hosts, networks, domains/ASs have different “intention levels” in receiving iTrace packets.

• Some of them might not care about iTrace, and some of them might not be under DDoS attacks, for example.

Page 28: 02/15/2007ecs2361 Tracing & Traceability S. Felix Wu UC Davis wu wu@cs.ucdavis.edu

02/15/2007 ecs236 28

iTrace Intention iTrace

• Tracing Resources:– Fixed, 1/20,000 packets

– Stateless

• Edge/Core coordination:• Practical Consideration:

– Internet-wide Scalability

– Partial Deployment

– Minimum Changes to the Routing Infrastructure

Page 29: 02/15/2007ecs2361 Tracing & Traceability S. Felix Wu UC Davis wu wu@cs.ucdavis.edu

02/15/2007 ecs236 29

A simple design

Compute traffic distributionfor every ~20,000 packets(roughly the size of the BGP table -- when a route entry in the BGP table is referenced, add one to that counter.).

BGP table packet T(I) iTrace count flag bit

Then, for each BGP entry, compute the iTrace messageprobability PiTrace(I). Finally, get a random number between0 and 1 to determine which entry should receive an iTrace message.

iTraceProcess

Page 30: 02/15/2007ecs2361 Tracing & Traceability S. Felix Wu UC Davis wu wu@cs.ucdavis.edu

02/15/2007 ecs236 30

packet-forwardingtable

Intentionselectionmodule

iTracegeneration

module

BGP routingtable

copy

iTraceintentionbits

Intention-Driven iTrace architecture (draft-ietf-itrace-intention-01.txt)

1/20KiTrace

selection

intentioniTrace

trigger??P% intention

iTracetrigger

copy

iTraceExecutionbit

User (firmware)

Kernel (hardware)

Page 31: 02/15/2007ecs2361 Tracing & Traceability S. Felix Wu UC Davis wu wu@cs.ucdavis.edu

02/15/2007 ecs236 31

Processing Overhead

Processing for each data packet:1. if the iTrace Execution bit is 1,

(1). Copy this packet to the iTrace daemon.(2). reset the iTrace Execution bit to 0.

1/20K iTrace message trigger occurs:1. Select and Set one iTrace Intention bit from the BGP table.

Page 32: 02/15/2007ecs2361 Tracing & Traceability S. Felix Wu UC Davis wu wu@cs.ucdavis.edu

02/15/2007 ecs236 32

152.1.23.0/24 0169.20.3.0/24 0192.1.0.0/16 0

207.3.4.183/20 0152.1.0.0/16 0155.0.0.0/16 0

152.1.23.0/24 0169.20.3.0/24 0192.1.0.0/16 0

207.3.4.183/20 0152.1.0.0/16 1155.0.0.0/16 0

(1).BeforeiTracetrigger:

(2).AfteriTracetrigger:

I(n) iTrace bit

Page 33: 02/15/2007ecs2361 Tracing & Traceability S. Felix Wu UC Davis wu wu@cs.ucdavis.edu

02/15/2007 ecs236 33

152.1.23.0/24169.20.3.0/24192.1.0.0/16

207.3.4.183/20152.1.0.0/16155.0.0.0/16

(3).AfteriTracesent:

000000

I(n) iTrace bit

Page 34: 02/15/2007ecs2361 Tracing & Traceability S. Felix Wu UC Davis wu wu@cs.ucdavis.edu

02/15/2007 ecs236 34

Schemes 1 & 2

Page 35: 02/15/2007ecs2361 Tracing & Traceability S. Felix Wu UC Davis wu wu@cs.ucdavis.edu

02/15/2007 ecs236 35

FRiTrace• Edge Passive Tracing

– ISP and Router Venders resistance– Let’s start using iTrace as end users– Intention is just a downloadable configuration

file

Page 36: 02/15/2007ecs2361 Tracing & Traceability S. Felix Wu UC Davis wu wu@cs.ucdavis.edu

02/15/2007 ecs236 36

Signaling (BGP extension)

AS500

AS 120

AS200

AS300

AS250

AS600

AS800

AS900

AS700

AS 100

IDS

Intention-bitupdate request

BGP updateprefix: 900attribute: Intend to receive iTrace

Page 37: 02/15/2007ecs2361 Tracing & Traceability S. Felix Wu UC Davis wu wu@cs.ucdavis.edu

02/15/2007 ecs236 37

Page 38: 02/15/2007ecs2361 Tracing & Traceability S. Felix Wu UC Davis wu wu@cs.ucdavis.edu

02/15/2007 ecs236 38

Useful Messages (16,000 pps Background Traffic)

0

10

20

30

40

50

60

70

0 2000 4000 6000 8000 10000 12000 14000 16000 18000

Attack Rate (pps)

normal

API_10

API_25

API_50

Page 39: 02/15/2007ecs2361 Tracing & Traceability S. Felix Wu UC Davis wu wu@cs.ucdavis.edu

02/15/2007 ecs236 39

Useful Messages (2,000 pps Attack Rate)

0

10

20

30

40

50

60

70

80

90

100

0 2000 4000 6000 8000 10000 12000 14000 16000 18000

Background Traffic Rate (pps)

normal

API_10

API_25

API_50

Page 40: 02/15/2007ecs2361 Tracing & Traceability S. Felix Wu UC Davis wu wu@cs.ucdavis.edu

02/15/2007 ecs236 40

Useful Messages (16,000 pps Background Traffic)

0

10

20

30

40

50

60

70

80

0 2000 4000 6000 8000 10000 12000 14000 16000 18000

Attack Rate (pps)

API_10

API_25

API_50

APII_10

APII_25

APII_50

Page 41: 02/15/2007ecs2361 Tracing & Traceability S. Felix Wu UC Davis wu wu@cs.ucdavis.edu

02/15/2007 ecs236 41

Useful Messages (2,000 pps Attack Rate)

0

20

40

60

80

100

120

0 2000 4000 6000 8000 10000 12000 14000 16000 18000

Background Traffic Rate (pps)

API_10

API_25

API_50

APII_10

APII_25

APII_50

Page 42: 02/15/2007ecs2361 Tracing & Traceability S. Felix Wu UC Davis wu wu@cs.ucdavis.edu

02/15/2007 ecs236 42

IETF iTrace has been killed!!

• No killer application!

• The victim would know, hopefully, where the attack sources are.– But, why would this be ever useful?

Page 43: 02/15/2007ecs2361 Tracing & Traceability S. Felix Wu UC Davis wu wu@cs.ucdavis.edu

02/15/2007 ecs236 43

But, why was iTrace proposed…

• In the inter-domain Internet, we have “very limited” mechanisms to monitor and analyze the traffic/application behavior.– distributed network/system management

information– a bunch of SNMP/MIB’s (scattered and they

are not forming a global view effectively).– ICMP is all we have…..

Page 44: 02/15/2007ecs2361 Tracing & Traceability S. Felix Wu UC Davis wu wu@cs.ucdavis.edu

02/15/2007 ecs236 44

Example: iTrace• the FRiTrace software package• running against your LAN and send out iTrace

messages statistically– “router X has seen this packet (of yours) at 11:35 p.m. today.”– I could have added: “BTW, the BGP route path toward you is

…” or “the rate of packets toward your network has been…”.

• A few iTrace applications are considered initially, but the list is extensible via a “controlled and moderated” open source development process.

• Intention registry– http://www.itrace.org/intention.txt

Page 45: 02/15/2007ecs2361 Tracing & Traceability S. Felix Wu UC Davis wu wu@cs.ucdavis.edu

02/15/2007 ecs236 45

IETF iTrace has been killed!!

• No killer application!

• The victim would know, hopefully, where the attack sources are.– But, why would this be ever useful?

Page 46: 02/15/2007ecs2361 Tracing & Traceability S. Felix Wu UC Davis wu wu@cs.ucdavis.edu

02/15/2007 ecs236 46

Wrong or Incomplete Information Economics

• The information is given to the entity (the victim) that can do probably nothing about the source of the problem (foreign domains).– We don’t really need iTrace information to do

local defense.

• The foreign domains/ISPs have very little incentive to provide iTrace information.– To get sued?– How to recover the cost?

Page 47: 02/15/2007ecs2361 Tracing & Traceability S. Felix Wu UC Davis wu wu@cs.ucdavis.edu

02/15/2007 ecs236 47

SUITScaleable Universal Internet Tagging

• One entity observes a piece of original “information”, and it adds a special tag representing a query.– A query regarding this piece of information.

• The tagged information is received by another entity– Between here and the “victim”.

• The other entity interprets the tag, and provides the answer to the query.

Page 48: 02/15/2007ecs2361 Tracing & Traceability S. Felix Wu UC Davis wu wu@cs.ucdavis.edu

02/15/2007 ecs236 48

iTrace SUITScaleable Universal Internet Tagging

• An AS picks one data packet with ~Prob(1/20K)– iTrace (a Router) SUIT (an AS)

• Generate a tag– This tag might be just a 1024-bit secure random #.

• Send an SUIT message toward the destination IP address– Global universal query about the packet (or the

destinations) might be attached:• Example: Is this packet part of a DDoS flooding

Page 49: 02/15/2007ecs2361 Tracing & Traceability S. Felix Wu UC Davis wu wu@cs.ucdavis.edu

02/15/2007 ecs236 49

SUIT

IDS

DynamicHorizontalSeparation

ResourceContention

Page 50: 02/15/2007ecs2361 Tracing & Traceability S. Felix Wu UC Davis wu wu@cs.ucdavis.edu

02/15/2007 ecs236 50

Better Information Economics• The information is given to the entity (the foreign

domain or ISP) that can do something about the source of the problem.– Example: Unwanted Traffic Filtering

• Everybody has some reasonable incentive to collaborate (as an example)– ISP: I spend resources to generate a SUIT, but hopefully, I

will be able to get some IDS results from somewhere else to allow me to perform better local defense.

– Victim: I am under attacks and I hope that the attacks could be filtered much earlier.

Page 51: 02/15/2007ecs2361 Tracing & Traceability S. Felix Wu UC Davis wu wu@cs.ucdavis.edu

02/15/2007 ecs236 51

Remarks• We do have technical solutions to solve the

tracing problem, but the economic model is not clear in general.– 50+ academic papers probably no real impact

• For tracing in the Internet,– User community sharing based on FRiTrace– SUIT: a better information economics– Something else?