tracking port scanners on the ip backbone tao ye sprint burlingame, ca avinash sridharan university...
TRANSCRIPT
Tracking Port Scanners on the IP Backbone
Tao Ye
Sprint
Burlingame, CA
Avinash Sridharan
University of Southern
California
2
Goals
• Port scanning a major propagation channel> Costly Virus and worm outbreaks: $245M North America
operators 2004, Blaster $1B , Code Red $1.2B world wide> Denial of Service: blackmail commerce websites
• Our goals> Detect and track> Understand long term behavior of scanners> On the backbone network
3
Motivation and Challenges
• Why Backbone ? > Detection: Existing work most at stub networks, limited
visibility > Tracking: Honeypots can be evaded> More scanning activities visible at core> Peering point unique vantage point
• Challenges> Backbone traffic unidirectional, asymmetric> High speed (OC-48, OC-192) links, needs fast algorithm> Diverse traffic mix, needs efficient data structure
4
Outline
• Motivation and Challenges
• Methodology> Detection Algorithm: TAPS> Online Implementation Architecture
• Results: Scanner Behavior
• Conclusion
5
Outline
• Motivation and Challenges
• Methodology> Detection Algorithm: TAPS> Online Implementation Architecture
• Results: Scanner Behavior
• Conclusion
7
TAPS: Time-based Access Pattern Sequential hypothesis testing
• Based on 5-tuple flow summary on unidirectional link
• Scanner suspects: source IPs accesses IP/port (or port/IP) ratio > k in time-bin
• Sequential Hypothesis Testing
1
1
0
1
1
0
[ 1 | ] IPif
[ 1 | ] Port
[ 0 | ] IPif
[ 0 | ] Port
i
i
P Y Hk
P Y HiP Y H
kP Y H
8
TAPS
( ) 1Y
1( )Y
0( )Y
Threshold for tagging source as scanner
Increment when IP/port > K
Decrement when IP/port < K
Threshold for tagging source as benignScanner if i 1
Benign if i 0
> <
SrcIP
9
Outline
• Motivation and Challenges
• Methodology> Detection Algorithm: TAPS> Online Implementation Architecture
• Results: Scanner Behavior
• Conclusion
10
Online Implementation Architecture
• Use CMON to produce flows in NetFlow5
• Flow Daemon distributes flows
• Keep flows in circular buffer
CMON Flow Collector
Flow
Daemon
Core
App Handler
TAPS Other
Disk Writer
Disk Reader
Circular Buffer
Disk
Flow Daemon
11
Design choices: Circular Buffer
• How many minutes of data do we buffer?
• Queuing model> Slotted single queue, service data after Q bytes are stored> Time slot t, Receives A(t) arrivals, has U(t) backlog, service rate
μ(t) when U(t) >= Q> Use Lyapunov drift theorem to bound expected back log queue:
> Assuming E(μ(t)) = 1.1λ
> Measured arrival rate, U ~ 11min (300MB), we set to 60min.
13
Design choices: Approximation Counters
• Issues: > Need to keep the fan-out count
for each IP> Heap implementation has
prohibitively high memory requirements
• Probabilistic Counters: > Many recently proposed
counters: • Small SRAM Implementation:
Multi-resolution bitmap, trigger bitmap
> Simple Flajolet-Martin counter
• FM counter performance> 8 hash functions accurate
enough for <>k test> 256, 32 and 8 hash functions
14
Outline
• Motivation and Challenges
• Methodology> Detection Algorithm: TAPS> Online Implementation Architecture
• Results: Scanner Behavior
• Conclusion
15
Results
• Data set> OC48 Peering link incoming, ~320Mbps, 22 days> OC48 Peering link outgoing, ~560Mbps, 3 days
21
Conclusion
• Online Scan Detection and Tracking> Targets unidirectional backbone link> Detector: Time-based Access Pattern Sequential
Hypothesis (TAPS)• Combines rate limiting with statistical tests on destination IP
and port access patterns> Implementation design: Queue model and FM counter
• Scanner Behavior> 90-10 split of scanning rate, scanning duration behavior> Spike in number of scanners detected