View
219
Download
0
Category
Preview:
Citation preview
02/15/2007 ecs236 1
Tracing & Traceability
S. Felix WuUC Davishttp://www.cs.ucdavis.edu/~wuwu@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
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.”
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.
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
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.
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.
02/15/2007 ecs236 8
Packet Marking
Masters
Slaves
Victim
... ISP
.com::.
Attackerssrc: randomdst: victim
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−−
<
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.
02/15/2007 ecs236 11
Probabilistic Marking???
Masters
Slaves
Victim
... ISP
.com::.
Reflectors
Attackerssrc: victim
dst: reflector
src: reflectordst: victim
???
???Find a specialhoney-potreflectors???
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….
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.
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.
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
02/15/2007 ecs236 16
Original iTrace
Masters
Slaves
Victim
... ISP
.com::.
Attackerssrc: randomdst: victim
02/15/2007 ecs236 17
iTrace in Reflective DDOS
Masters
Slaves
Victim
... ISP
.com::.
Reflectors
Attackerssrc: victim
dst: reflector
src: reflectordst: victim
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??
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.
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
02/15/2007 ecs236 21
Reflector
VictimSlave
Service Request Packetsrc: Victimdst: Reflector
Service Reply Packet src: Reflector dst: Victim
sourceTracebackMessages
Who has spoofed me??
02/15/2007 ecs236 22
Improved iTrace
Masters
Slaves
Victim
... ISP
.com::.
Reflectors
Attackerssrc: victim
dst: reflector
src: reflectordst: victim
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.
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
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
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:
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.
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
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
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)
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.
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
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
02/15/2007 ecs236 34
Schemes 1 & 2
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
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
02/15/2007 ecs236 37
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
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
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
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
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?
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…..
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
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?
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?
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.
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
02/15/2007 ecs236 49
SUIT
IDS
DynamicHorizontalSeparation
ResourceContention
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.
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?
Recommended