Transcript Packet Tracing and Distributed Denial of Service Attacks

Tracing & Traceability
S. Felix Wu
UC Davis
http://www.cs.ucdavis.edu/~wu
[email protected]
02/15/2007
ecs236
1
Traceability
• spoofing/hiding the origin
– network/host/process identities
• distributed network/system level
information
– security (worm), fault (routing), performance
02/15/2007
ecs236
2
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
3
Each slave emits a “relatively small” amount of attack packets
Slaves
Victim
Masters
Attackers
:
:.
src: random
dst: victim
.com
ISP
...
This will be a problem for
any “static” probabilistic schemes.
02/15/2007
ecs236
4
Example: An Attack Path
1
11
14
attacker
2
0
12
6
4
10
13
Attack traffic
target
3
7
5
8
15
9
02/15/2007
ecs236
5
Attack Path Traceback Problem
• 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.
A2 A3
A1 R10
R11
R7
R6
R3
R8
R4
A6
A4
A5
R9
R5
R2
R1
Vt
02/15/2007
ecs236
6
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(1p)^(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
7
Packet Marking
Slaves
Victim
Masters
Attackers
:
:.
02/15/2007
src: random
dst: victim
.com
ISP
...
ecs236
8
Probabilistic Edge Marking and Sampling
Marking procedure at router R:
for each packet w
• Edge sampling: 3 static fields
let x be a random number from [0..1)
(two 32-bit end addresses, one 8if x < p then
bit distance) can be hashed into
write R into w.start and 0 into w.distance
16-bit IP Identification field.
else
• The number of packet needed to
if w.distance == 0 then
reconstruct a path of length d has
write R into w.end
bounded expectation:
increment w.distance
ln (d)
Path reconstruction procedure at victim v:
E(X)
let G be a tree with root v
p(1  p)(d 1 )
let edges in G be tuples (start, end, distance) •As long as p < = 1/d, the number is
for each packet w from attacker
within a small constant of optimal.
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
02/15/2007
ecs236
9
Encoding edge fragments into the IP identification field
• IP ID field should not be changed if fragmentation is necessary.
ver
hlen
TOS
Total Length
Identification
Time to live
flags
Protocol
offset
Header checksum
Source IP address
Destination IP address
offset
0
2 3
Distance
Edge fragment
7 8
15
• [Song, Franklin] proposed improved advance marking schemes for IP ID field.
02/15/2007
ecs236
10
Probabilistic Marking???
Find a special
honey-pot
reflectors???
Reflectors
Slaves
???
???
Masters
Attackers
:
:.
src: victim
dst: reflector
Victim
.com
ISP
...
src: reflector
dst: victim
02/15/2007
ecs236
11
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….
02/15/2007
ecs236
12
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
13
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
14
iTrace Packets
1
12
6
11
iTrace
2
0
4
14
10
13
iTrace
target
3
7
5
8
15
slave
9
02/15/2007
ecs236
15
Original iTrace
Slaves
Victim
Masters
Attackers
:
:.
02/15/2007
src: random
dst: victim
.com
ISP
...
ecs236
16
iTrace in Reflective DDOS
Slaves
Reflectors
Victim
Masters
Attackers
:
:.
src: victim
dst: reflector
.com
ISP
...
src: reflector
dst: victim
02/15/2007
ecs236
17
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
18
Each slave emits a “relatively small” amount of attack packets
Slaves
Victim
Masters
Attackers
:
:.
src: random
dst: victim
.com
ISP
...
This will be a problem for
any “static” probabilistic schemes.
02/15/2007
ecs236
19
Reflector
• Use a legitimate network server/client as the
reflector to avoid being traced. (stepping
stone).
Reflector
Service Reply Packet
src: Reflector
dst: Victim
Service Request Packet
src: Victim
dst: Reflector
Slave
02/15/2007
Victim
ecs236
20
Who has spoofed me??
Reflector
Service Request Packet
src: Victim
dst: Reflector
Slave
02/15/2007
Service Reply Packet
src: Reflector
dst: Victim
source
Traceback
Messages
ecs236
Victim
21
Improved iTrace
Slaves
Reflectors
Victim
Masters
Attackers
:
:.
src: victim
dst: reflector
.com
ISP
...
src: reflector
dst: victim
02/15/2007
ecs236
22
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.
02/15/2007
ecs236
23
Usefulness of iTrace messages
• “finding” the right attack paths.
• “attack” packets
S1
R5
S2
R6
R2
R7
R3
Sn
R8
R4
Sx
R9
S3
02/15/2007
ecs236
R1
V
24
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
25
iTrace Probability: 1/20,000
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:
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.
02/15/2007
ecs236
26
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.
02/15/2007
ecs236
27
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
28
A simple design
BGP table packet T(I) iTrace
count
flag bit
iTrace
Process
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.).
Then, for each BGP entry, compute the iTrace message
probability PiTrace(I). Finally, get a random number between
0 and 1 to determine which entry should receive
an iTrace message.
02/15/2007
ecs236
29
Intention-Driven iTrace architecture
(draft-ietf-itrace-intention-01.txt)
BGP routing
table
iTrace
generation
module
intention
iTrace
trigger??
P%
intention
iTrace
trigger
iTrace
intention
bits
Intention
selection
module
User (firmware)
copy
copy
iTrace
Execution
bit
1/20K
iTrace
selection
02/15/2007
Kernel (hardware)
ecs236
packetforwarding
table
30
Processing Overhead
1/20K iTrace message trigger occurs:
1. Select and Set one iTrace Intention bit from the BGP table.
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.
02/15/2007
ecs236
31
I(n)
iTrace bit
(1).
Before
iTrace
trigger:
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
0
0
0
0
0
0
(2).
After
iTrace
trigger:
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
0
0
0
0
1
0
02/15/2007
ecs236
32
I(n)
(3).
After
iTrace
sent:
02/15/2007
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
ecs236
iTrace bit
0
0
0
0
0
0
33
Schemes 1 & 2
02/15/2007
ecs236
34
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
35
Signaling (BGP extension)
AS800
AS 100
Intention-bit
update request
AS200
IDS
AS 120
AS250
AS300
BGP update
prefix: 900
attribute: Intend to
receive iTrace
AS500
AS600
02/15/2007
AS900
AS700
ecs236
36
02/15/2007
ecs236
37
02/15/2007
ecs236
38
02/15/2007
ecs236
39
02/15/2007
ecs236
40
02/15/2007
ecs236
41
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
42
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
43
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
44
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
45
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
46
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.
02/15/2007
ecs236
47
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
02/15/2007
ecs236
48
SUIT
Dynamic
Horizontal
Separation
Resource
Contention
IDS
02/15/2007
ecs236
49
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
50
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?
02/15/2007
ecs236
51