1 / 41

Portscans

Portscans. Jonathon Giffin giffin@cs.wisc.edu April 25, 2001. In This Talk. Why scan? Anatomy of a portscan Methods Classical detection methods Statistical packet anomaly detection Responding to a portscan Q&[maybe]A. Why Portscan: Black Hats. Locate exploitable machines

gizi
Download Presentation

Portscans

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Portscans Jonathon Giffin giffin@cs.wisc.edu April 25, 2001

  2. In This Talk... • Why scan? • Anatomy of a portscan • Methods • Classical detection methods • Statistical packet anomaly detection • Responding to a portscan • Q&[maybe]A

  3. Why Portscan: Black Hats • Locate exploitable machines Say, FTP Servers: cecil.cs.wisc.edu (128.105.175.17): open bobby.cs.wisc.edu (128.105.175.18): closed ross.cs.wisc.edu (128.105.175.19): closed joyce.cs.wisc.edu (128.105.175.20): open • Fingerprint operating systems

  4. Administrators • Monitor services running on own networks • Test security policies

  5. Anatomy of a Portscan • Scan footprint • Set of IPs and ports scanned • Defines attacker’s information gathering requirements • Horizontal scan • Scan same port across multiple machines • Idea: attacker has an exploit for this particular service

  6. Scan Footprint • Vertical scan • Scan multiple ports on a single machine • Idea: looking for vulnerable services on a specific machine e3-16.foundry2.cs.wisc.edu (128.105.100.247): 23/tcp open telnet 25/tcp filtered smtp 111/tcp filtered sunrpc 515/tcp filtered printer

  7. Scan Footprint • Block scan Host 21 telnet 22 ssh 23 ftp cygnet open open open cilantro open open open xena open open open bodik-soho closed closed closed salsa open open open bobby closed closed closed

  8. Anatomy of a Portscan • Scan script • Method of carrying out scan • Defines how a given footprint will be scanned • Footprint and script together compose a portscan

  9. Methods • Scan tools available • Nmap • http://www.insecure.org/nmap/ • Portscans, OS fingerprinting • QueSO • http://apostols.org/projectz/queso/ • OS fingerprinting

  10. Ping Scan • Reveals network topology Host krishna.cs.wisc.edu (128.105.175.45) appears to be up. Host ursula.cs.wisc.edu (128.105.175.51) appears to be up. Host antipholus.cs.wisc.edu (128.105.175.111) appears to be up. Host ferdinand.cs.wisc.edu (128.105.175.112) appears to be up. Host wonderwoman.cs.wisc.edu (128.105.175.113) appears to be up. Host thugbert.cs.wisc.edu (128.105.175.114) appears to be up. Host paneer.cs.wisc.edu (128.105.175.115) appears to be up. Host coral.cs.wisc.edu (128.105.175.116) appears to be up. Host crow.cs.wisc.edu (128.105.175.118) appears to be up. Host chef.cs.wisc.edu (128.105.175.120) appears to be up.

  11. UDP Scan • Send any data to UDP port • Receive ICMP port unreachable: port closed • No response: port open or blocked

  12. Vanilla SYN Scan Client Server socket connect connect returns close socket bind listen accept accept returns SYN SYNACK ACK FIN

  13. Vanilla SYN Scan crash10.cs.wisc.edu.42977 > malakai.cs.wisc.edu.telnet: S malakai.cs.wisc.edu.telnet > crash10.cs.wisc.edu.42977: S ack crash10.cs.wisc.edu.42977 > malakai.cs.wisc.edu.telnet: . ack crash10.cs.wisc.edu.42977 > malakai.cs.wisc.edu.41212: F • Defense • Log completed connections that are immediately closed

  14. Half-Open SYN Scan Client Server raw socket bind constructed packet constructed packet socket bind listen accept SYN SYNACK RES

  15. Half-Open SYN Scan crash10.cs.wisc.edu.42977 > malakai.cs.wisc.edu.telnet: S malakai.cs.wisc.edu.telnet > crash10.cs.wisc.edu.42977: S ack crash10.cs.wisc.edu.42977 > malakai.cs.wisc.edu.telnet: R • Defense • Log all SYN packets received

  16. Stealth Scans • Attempt to avoid server logging • Send invalid TCP packets • SYNFIN scan • XMAS scan • FIN scan • Windows avoids this scan because its stack is broken (surprise) • Null scan

  17. FTP Bounce Scan • RFC 959 defines FTP proxy • Run portscan via an FTP proxy

  18. Other Possibilities • RFC 1413 defines ident protocol • Find services running as root crash10.cs.wisc.edu: Port State Service Owner 23/tcp open telnet root 25/tcp open smtp root 79/tcp open finger root 80/tcp open http apache 111/tcp open sunrpc rpc 113/tcp open auth nobody

  19. Other Possibilities • Insert decoy scans microsoft.com.54177 > malakai.cs.wisc.edu.352: S malakai.cs.wisc.edu.660 > crash10.cs.wisc.edu.54177: R crash10.cs.wisc.edu.54177 > malakai.cs.wisc.edu.128: S

  20. OS Fingerprinting • Identification of the operating system running on a remote machine • Different kernels perform differently • TCP options • Initial sequence number • ICMP error messages • IP fragment overlap

  21. OS Fingerprinting Machine Operating System www Solaris 2.6-2.7, Solaris 7 pub-nt2 WinNT4 / Win95 / Win98 malakai Linux 2.1.122 - 2.2.14 e3-16.foundry2 No OS Match dns Solaris 2.6-2.7, Solaris 7 crash8 Linux 2.1.122 - 2.2.14 crash10 Linux 2.1.122 - 2.2.14 crash12 No OS Match openbsd.org Solaris 2.6

  22. Classical Detection • N events in time M • Typically measure hits on closed ports • Slow scan down to avoid detection • Heuristics • Hits on empty IP addresses

  23. Statistical Packet Anomaly Detection • Stuart Staniford, James Hoagland, and Joseph McAlerny of Silicon Defense • “Practical Automated Detection of Stealthy Portscans” • Conjecture • Traffic patterns characteristic of portscans have low rates of occurrence

  24. Statistical Packet Anomaly Detection Anomaly correlation engine Layer 2 Layer 1 Anomaly detection engine Packet collection; Probability table construction Layer 0

  25. Layer 0 • Build characteristic of expected traffic • Packet collection • Filtering • Probability table construction • Using header features, store probability of any given packet entering the network • Adapt probabilities to changing network use

  26. Layer 1 • Anomaly detection • Rate the anomalousness of each incoming packet • Pass any packet with anomalousness above an anomaly threshold to the correlator

  27. Layer 2 • Anomaly correlation • Reconstruct portscans from anomalous traffic • Find clusters of similar packets

  28. Data Flows Alarms Anomaly correlation engine Anomaly detection engine Incoming packets Packet collection Prob table construction

  29. Implementation • Packet collection • Restricting to SYN packets • Probability tables • Relevant header fields • Joint probabilities • Bayes’ Net

  30. Mutual Entropy 4.9 million SYN packets incoming to CS networks H( DestAddr ): 6.927819 H( DestAddr | SrcAddr ): 2.091069 H( DestAddr | DestPort ): 4.064494 H( DestAddr | SrcAddr, DestPort ): 1.274497 H( DestAddr | SrcPort ): 4.631317 H( DestAddr | SrcAddr, SrcPort ): 1.075178 H( DestAddr | DestPort, SrcPort ): 2.580522 H( DestAddr | Time ): 5.348499 H( DestAddr | SrcAddr, Time ): 0.862256 H( DestAddr | DestPort, Time ): 1.540623 H( DestAddr | SrcPort, Time ): 1.508940

  31. Bayes’ Net DestPort SrcPort Timestamp SrcIP DestIP

  32. Anomaly Detection Engine • Staniford’s model: packets in isolation • Experiment: N size window p1 pN Given packets , :

  33. Anomaly Correlation Engine • Staniford’s algorithm: bond graph • ad hoc clustering method • Experiment: use established clustering algorithms

  34. Field Relationships in a Vertical Scan Example 128.105.175.29:3776 > 146.151.62.116:224,TCP 128.105.175.29:3777 > 146.151.62.116:662,TCP 128.105.175.29:3778 > 146.151.62.116:768,TCP 128.105.175.29:3779 > 146.151.62.116:789,TCP 128.105.175.29:3780 > 146.151.62.116:2016,TCP 128.105.175.29:3781 > 146.151.62.116:194,TCP 128.105.175.29:3782 > 146.151.62.116:6009,TCP 128.105.175.29:3783 > 146.151.62.116:570,TCP 128.105.175.29:3784 > 146.151.62.116:493,TCP 128.105.175.29:3785 > 146.151.62.116:1393,TCP 128.105.175.29:3786 > 146.151.62.116:1007,TCP

  35. Open Questions • Data set size necessary to establish traffic characteristic • Relevant header fields • Manner of measuring probability • Threshold values • Malleability of traffic characteristic • Packet types captured

  36. Advantages of Statistical Packet Anomaly Detection • Adaptive to changing network topology • Encompasses classical detection methods • Useful beyond port scans

  37. Disadvantages • Learning curve may be slow • Anomalous packets skew expected traffic characteristic • Does not evaluate payload • Few relevant header fields • Correlator must handle many false positives

  38. Responding to a Port Scan • What is appropriate action? • No legal recourse • Block at firewall? Set up for DoS: microsoft.com > malakai.cs.wisc.edu: icmp: echo request • Log for later legal purposes? • Tighten network security?

  39. Recap • Purposes • Exploration of remote services • OS fingerprinting • Port scans have evolved to counter detection methods • Classical detection methods inadequate • Statistical packet anomaly detection offers an adaptive scan identifier

  40. Questions? • Maybe I’ll know the answer • But hey, I do know slides are posted at http://www.cs.wisc.edu/~giffin

  41. References • Fyodor. “The Art of Port Scanning.” Phrack 51, volume 7. September 1, 1997. • Fyodor. “Remote OS detection via TCP/IP Stack Fingerprinting.” Phrack 54, volume 8. December 25, 1998. • Maimon, Uriel. “Port Scanning Without the SYN Flag.” Phrack 49, volume 7. • Man pages, nmap. • Solar Designer. “Designing and Attacking Port Scan Detection Tools.” Phrack 53, volume 8. July 8, 1998. • Staniford, Stuart, James A. Hoagland, Joseph M. McAlerny. “Practical Automated Detection of Stealthy Portscans.”

More Related