Tracking Port Scanners on the IP Backbone Tao Ye Sprint Burlingame, CA Avinash Sridharan University of Southern California

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




• Conclusion

6

Intuition: Access Patterns

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




• 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.

12

Detector and Tracker Architecture

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




• Conclusion

15

Results

• Data set> OC48 Peering link incoming, ~320Mbps, 22 days> OC48 Peering link outgoing, ~560Mbps, 3 days

16

Scanner Duration

22 days 3 days

17

Scanner Rate

18

Scanner Footprint (22 days)

Scanners lasting < 2 hrs Scanners lasting > 2 hrs

19

Number of Scanner Detected (1)

• Time series of Number of scanners detected (3days)

20

Number of Scanner Detected (2)

• Time series of Number of scanners detected (22days)

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

Documents

Tracking Port Scanners on the IP Backbone Tao Ye Sprint Burlingame, CA Avinash Sridharan University of Southern California