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

2. 1 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. 2 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. 3 Outline Motivation and Challenges Methodology >Detection Algorithm: TAPS >Online Implementation Architecture Results: Scanner Behavior Conclusion

5. 4 Outline Motivation and Challenges Methodology >Detection Algorithm: TAPS >Online Implementation Architecture Results: Scanner Behavior Conclusion

6. 5 Intuition: Access Patterns

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

8. 7 TAPS Threshold for tagging source as scanner Increment when IP/port > K Decrement when IP/port < K Threshold for tagging source as benign

9. 8 Outline Motivation and Challenges Methodology >Detection Algorithm: TAPS >Online Implementation Architecture Results: Scanner Behavior Conclusion

10. 9 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 TAPSOther Disk Writer Disk Reader Circular Buffer Disk Flow Daemon

11. 10 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. 11 Detector and Tracker Architecture

13. 12 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. 13 Outline Motivation and Challenges Methodology >Detection Algorithm: TAPS >Online Implementation Architecture Results: Scanner Behavior Conclusion

15. 14 Results Data set >OC48 Peering link incoming, ~320Mbps, 22 days >OC48 Peering link outgoing, ~560Mbps, 3 days

16. 15 Scanner Duration 22 days 3 days

17. 16 Scanner Rate

18. 17 Scanner Footprint (22 days) Scanners lasting < 2 hrs Scanners lasting > 2 hrs

19. 18 Number of Scanner Detected (1) Time series of Number of scanners detected (3days)

20. 19 Number of Scanner Detected (2) Time series of Number of scanners detected (22days)

21. 20 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

22. 21 Scanning Ports Port accessed

23. 22 Choose a Detection Algorithm Requirements >Unidirectional backbone link >Do not rely on TCP connections or server configuration information >Protocol Independence: capture TCP and UDP scanners. >High detection rate, low false positives Evaluated >Snort >TRW >TAPS

24. 23 Duration (3 day)

25. 24 Scanner Footprint (2) Scanners lasting < 5.5 hrsScanners lasting > 5.5 hrs

26. 25 Port Scan Detector Evaluation of existing detectors >Industry SNORT, Netscreen Static thresholding: “> n dest/m sec” = scanner >Research TRW (Jung et al 2004 Oakland Conf) –Connection failure as indicator –Sequential Hypothesis Testing using Threshold Random Walk –Needs an ORACLE –TRWSYN »Our backbone adaptation of TRW »SYN flows indicate failure Design TAPS >Combine rate-limiting and hypothesis testing

27. 26 Performance: TCP OC-48