Presentation is loading. Please wait.

Presentation is loading. Please wait.

02/15/2007ecs2361 Tracing & Traceability S. Felix Wu UC Davis

Similar presentations


Presentation on theme: "02/15/2007ecs2361 Tracing & Traceability S. Felix Wu UC Davis"— Presentation transcript:

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

2 02/15/2007ecs2362 Traceability spoofing/hiding the origin –network/host/process identities distributed network/system level information –security (worm), fault (routing), performance

3 02/15/2007ecs2363 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.”

4 02/15/2007ecs2364 Each slave emits a “relatively small” amount of attack packets Masters Slaves Victim... ISP.com ::::. Attackers src: random dst: victim This will be a problem for any “static” probabilistic schemes.

5 02/15/2007ecs2365 Example: An Attack Path 0 1 2 3 7 58 4 6 target 11 12 10 9 13 14 15 Attack traffic attacker

6 02/15/2007ecs2366 Attack Path Traceback Problem A5R9 A3 R11 A4 R8 R4A2 A1 R10 R7 R6 R3 R 5 R2 R1 Vt Vt Vt Vt A6 An attack path is an ordered list of nodes along which the attack packets traveled between A i and v t. The traceback problem is to find the attack path and the associated attack origin for each attacker.

7 02/15/2007ecs2367 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.

8 02/15/2007ecs2368 Packet Marking Masters Slaves Victim... ISP.com ::::. Attackers src: random dst: victim

9 02/15/2007ecs2369 Probabilistic Edge Marking and Sampling Marking 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.

10 02/15/2007ecs23610 verhlenTOSTotal Length Identificationflagsoffset Time to liveProtocol Header checksum Source IP address Destination IP address offsetDistanceEdge fragment 02 37 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.

11 02/15/2007ecs23611 Probabilistic Marking??? Masters Slaves Victim... ISP.com ::::. Reflectors Attackers src: victim dst: reflector src: reflector dst: victim ??? Find a special honey-pot reflectors???

12 02/15/2007ecs23612 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 addresses have been aggregated into a honey-pot. If a good portion of the reflectors for a particular slave belongs to a single portscan Honeypot….

13 02/15/2007ecs23613 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.

14 02/15/2007ecs23614 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.

15 02/15/2007ecs23615 iTrace Packets 0 1 2 3 7 58 4 6 target 11 12 10 9 13 14 15 iTrace slave iTrace

16 02/15/2007ecs23616 Original iTrace Masters Slaves Victim... ISP.com ::::. Attackers src: random dst: victim

17 02/15/2007ecs23617 iTrace in Reflective DDOS Masters Slaves Victim... ISP.com ::::. Reflectors Attackers src: victim dst: reflector src: reflector dst: victim

18 02/15/2007ecs23618 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??

19 02/15/2007ecs23619 Each slave emits a “relatively small” amount of attack packets Masters Slaves Victim... ISP.com ::::. Attackers src: random dst: victim This will be a problem for any “static” probabilistic schemes.

20 02/15/2007ecs23620 Reflector Use a legitimate network server/client as the reflector to avoid being traced. (stepping stone). Reflector VictimSlave Service Request Packet src: Victim dst: Reflector Service Reply Packet src: Reflector dst: Victim

21 02/15/2007ecs23621 Reflector VictimSlave Service Request Packet src: Victim dst: Reflector Service Reply Packet src: Reflector dst: Victim source Traceback Messages Who has spoofed me??

22 02/15/2007ecs23622 Improved iTrace Masters Slaves Victim... ISP.com ::::. Reflectors Attackers src: victim dst: reflector src: reflector dst: victim

23 02/15/2007ecs23623 iTrace Probability: 1/20,000 Attack traffic Background traffic For a router with “lots” of background traffic, it will take a long time before we really generate a “useful” iTrace.

24 02/15/2007ecs23624 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

25 02/15/2007ecs23625 Value(iTrace) = (Attack(iTrace) * Intention(dst-ID) * hopCount(rtr-ID  dst-ID) Received(ID  dst-ID) * Generated(rtr-ID) 1th useful itrace

26 02/15/2007ecs23626 iTrace Probability: 1/20,000 For routers closer to the victim, valid iTrace messages will be produced very frequently. But, for routers closer to a slave with 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:

27 02/15/2007ecs23627 Intention-driven iTrace distribute 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.

28 02/15/2007ecs23628 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

29 02/15/2007ecs23629 A simple design Compute traffic distribution for 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 message probability P iTrace (I). Finally, get a random number between 0 and 1 to determine which entry should receive an iTrace message. iTrace Process

30 02/15/2007ecs23630 packet- forwarding table Intention selection module iTrace generation module BGP routing table copy iTrace intention bits Intention-Driven iTrace architecture (draft-ietf-itrace-intention-01.txt) 1/20K iTrace selection intention iTrace trigger?? P% intention iTrace trigger copy iTrace Execution bit User (firmware) Kernel (hardware)

31 02/15/2007ecs23631 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.

32 02/15/2007ecs23632 152.1.23.0/240 169.20.3.0/240 192.1.0.0/160 207.3.4.183/200 152.1.0.0/160 155.0.0.0/160 152.1.23.0/240 169.20.3.0/240 192.1.0.0/160 207.3.4.183/200 152.1.0.0/161 155.0.0.0/160 (1). Before iTrace trigger: (2). After iTrace trigger: I(n) iTrace bit

33 02/15/2007ecs23633 152.1.23.0/24 169.20.3.0/24 192.1.0.0/16 207.3.4.183/20 152.1.0.0/16 155.0.0.0/16 (3). After iTrace sent: 0 0 0 0 0 0 I(n) iTrace bit

34 02/15/2007ecs23634 Schemes 1 & 2

35 02/15/2007ecs23635 FRiTrace Edge Passive Tracing –ISP and Router Venders resistance –Let’s start using iTrace as end users –Intention is just a downloadable configuration file

36 02/15/2007ecs23636 Signaling (BGP extension) AS500 AS 120 AS200 AS300 AS250 AS600 AS800 AS900 AS700 AS 100 IDS Intention-bit update request BGP update prefix: 900 attribute: Intend to receive iTrace

37 02/15/2007ecs23637

38 02/15/2007ecs23638

39 02/15/2007ecs23639

40 02/15/2007ecs23640

41 02/15/2007ecs23641

42 02/15/2007ecs23642 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?

43 02/15/2007ecs23643 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…..

44 02/15/2007ecs23644 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

45 02/15/2007ecs23645 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?

46 02/15/2007ecs23646 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?

47 02/15/2007ecs23647 SUIT Scaleable 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.

48 02/15/2007ecs23648 iTrace  SUIT Scaleable 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

49 02/15/2007ecs23649 SUIT IDS Dynamic Horizontal Separation Resource Contention

50 02/15/2007ecs23650 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.

51 02/15/2007ecs23651 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?


Download ppt "02/15/2007ecs2361 Tracing & Traceability S. Felix Wu UC Davis"

Similar presentations


Ads by Google