1 / 21

S. Panjwani and M. Cukier Center for Risk and Reliability Department of Mechanical Engineering

3rd Proactive Problem Prediction, Avoidance and Diagnosis Conference An Experimental Evaluation to Determine if Port Scans are Precursors to an Attack* S. Panjwani and M. Cukier Center for Risk and Reliability Department of Mechanical Engineering

emily
Download Presentation

S. Panjwani and M. Cukier Center for Risk and Reliability Department of Mechanical Engineering

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. 3rd Proactive Problem Prediction, Avoidanceand Diagnosis ConferenceAn Experimental Evaluation to Determine if Port Scans are Precursors to an Attack* S. Panjwani and M. CukierCenter for Risk and ReliabilityDepartment of Mechanical Engineering * Based on the research conducted by S. Panjwani, S. Tan and K. M. Jarrin. This research was supported by NSF CAREER award 0237493.

  2. Motivation • Are port scans precursors to an attack? • The security community has been discussing this issue for some time • Very few studies tried to answer quantitatively this question • Experimental approach to estimate the link between a port scan and an attack • A test-bed using target computers is used to monitoring attackers and collecting attack data • Customized scripts were developed to filter the collected data and group them into scans and attacks

  3. Definitions • Scan: a reconnaissance technique in which the attacker tries to find out something about the target host: • Is the host alive? • What services are running on the host? • What is the host’s operating system? • Is there an exploitable vulnerability? • Types of Scans • ICMP Scan : used to check the availability of a target machine and to fingerprint the target operating system • Port scan : used to check for open or closed ports and for used or unused services • Vulnerability Scan: used to check for specific vulnerabilities within specific services or applications

  4. Experimental Setup • A test-bed based on target computers used for the sole purpose of being attacked • A monitoring network of computers to collect, analyze and correlate data • The test-bed architecture: • Collects data at the host, application and a network levels • Filters user traffic from attacker traffic • Correlates data collected at the host and network level • Controls the target computers from an isolated monitoring network

  5. Test-bed Architecture

  6. Characterization of Port Scans • Approach: • Ran all the different basictypes of port scansavailable in Nmap (network scanner) • Collected all the packetsusing Ethereal(network protocol analyzer) • Observations: • No connection observedwith specific numbers ofpackets (e.g., 5, 6) • 99.88% of port scansconsist of 4 or less packetsper connection • Threshold to characterize a port scan: 5 packets

  7. Characterization of Vulnerability Scans • Approach: • Ran all the vulnerability checking plug-ins available in NeWT/Nessus (network vulnerability scanner) besides the ones characterized as “dangerous” (about 4,000 plug-ins) • Collected all the packets using Ethereal (network protocol analyzer)

  8. Characterization of Vulnerability Scans (Cont.) • Observations: • No connection observed with specific number of packets (e.g., 5, 14) • Less than 0.06% of the vulnerability scans consist of 4 or less packets • 4,024 connections consisting of 6 packets are port scans – in fact, half reversed port scans performed three times (a special script identifies these scans and we counted them as special half reverse port scans with a connection of 2 packets) • 99.9% of vulnerability scans consist of connections having between 6 and 12 packets • 0.03% of the vulnerability scans consist of connections having more than 12 packets • Characterization a vulnerability scan: • More than 4 packets • Less than 13 packets • Connections with more than 12 packets are characterized as attacks

  9. Experimental Results • Data collection: • Location: University of Maryland’s Institute of Systems Research • Network specifications: unmonitored subnet in which IP addresses are dynamically assigned to users • Two target computers: • Windows 2000 with same services (i.e., IIS, FTP, Telnet, NetTime) • Same set of 25 vulnerabilities • Re-imaged twice during the data collection • Traffic: most UDP traffic was filtered out at the gateway level by the campus system administrators • Outbound traffic limited to: • 10 TCP connections per hour • 15 ICMP connections per hour • 15 other connections per hour • Duration: 48 days

  10. List of Vulnerabilities Lefton Both Target Computers

  11. Data Filtering

  12. Data Filtering (Cont.) • Collected data: 908,963 packets of malicious and management activity: • Attack traffic from the Internet • Management traffic like spanning tree protocol (STP) generated by the bridge, DNS resolutions, and NTP queries

  13. Data Analysis • Analysis of 22,710 collected connections going to the target computers: • Port scan: less than 5 packets • Vulnerability scan: between 5 and 12 packets (besides connections of 6 packets recognized as 3 half reverse port scans) • Attack: more than 12 packets • For this experiment, only considered unique scans and attacks

  14. Distribution of Port Scans Types

  15. Distribution of Port Scans Types (Cont.) • Observations: • Not all port scans are covered by this model (8,100 port scans out of 8,432 (96.1%) could be classified using this model) • Over 94% of scans are half reverse scans • Over 4% of scans are half open scans • So, 99% of the scans consist of connections that contain only 2 packets • The very large majority of the port scans are due to connections that are not established • A full connection would significantly increase the visibility of the attacker and is therefore avoided by attackers

  16. Scans Followed by Attacks • Approach: for each scan and combination of scans, we checked if at least one attack followed the scan(s)

  17. Scans Followed by Attacks (Cont.) • Observations: scans: • Almost none of the ICMP scans were followed by an attack • Only 4% of the port scans were followed by an attack • Over 21% of the vulnerability scans were followed by an attack • So, the identification of an ICMP/port/vulnerability scan might be a poor indicator that an attack will follow • Observations: combinations of scans: • Combinations of ICMP and vulnerability scans lead to an attack in about 3% of the cases • Combinations of the three scans lead to an attack in more than 46% of the cases (note: only 15 combinations of three scans were observed) • Combinations of port and vulnerability scans lead to an attack in more than 71% of the cases • So, the identification of a combination of port and vulnerability scans might be a good indicator that an attack will follow

  18. Attacks Preceded by Scans • Approach: for each of the 760 attacks collected from different source IP addresses, we checked if any scan or combination of scans preceded the attack

  19. Attacks Preceded by Scans (Cont.) • Observations: • More than 50% of the attacks were not preceded by a scan • Over 38% of the attacks were preceded by a vulnerability scan • Port scans preceded about 4% of the attacks • Combinations of port and vulnerability scans preceded about 6% of the attacks

  20. Conclusions • Over 50% of the attacks were not preceded by a scan • Among the scans leading the more frequently to an attack were: • vulnerability scans • combinations of port and vulnerability scans • Port scans combined with vulnerability scans might be a relevant indicator of a coming attack. • Only port scans do not appear to be a good indicator of a future attack

  21. Acknowledgements • National Science Foundation • The Institute for Systems Research at UMD (ISR) • ISR IT office at UMD (M. Wilson and his team) • The Office for Information Technology at UMD (OIT) (G. Sneeringer and his team) • ME IT office at UMD (M. Fields and D. Hazelwood)

More Related