Hacking Nmap: Using Nmap to Calculate Network Response Time

| September 23, 2007

How Nmap Calculates Network Response Time

Although Nmap can perform some advanced operating system identification and application service detection, the methods that Nmap uses for these higher-level probes aren’t appropriate to help determine server or application response time. Instead, we’ll focus on using Nmap to provide detailed network response time information only.

Although it’s not obvious when using Nmap with the default options, network response time is constantly monitored by Nmap during a scan. If a system begins to respond slowly, Nmap will also slow down its probes to ensure the most accurate scan. We can use this built-in timing function to provide us with an accurate network response time metric.

Nmap’s internal processes calculate these response time values:

  • srtt – Smoothed Round Trip Time – This estimate of response time is based on the observed traffic between the Nmap station and the remote device. This value is provided in microseconds.
  • rttvar – Round Trip Time Variance – Network communication can be very unpredictable, and Nmap compensates for this uncertainty by creating a range of timeout values. If a response isn’t received within this variance, then Nmap concludes that a response isn’t likely to ever appear.

For the purposes of testing network response time, we’ll focus on using the smoothed round trip time (srtt) metric.

Network Response Time Testing with Nmap

For accurate network response time results, we’ll have Nmap perform its scan with some very specific options:

  • Use the TCP SYN stealth scan (-sS) – The SYN scan is one of the most efficient scans that Nmap uses, and it’s a perfect test for a network response time because it consists of a single frame sent and a single frame expected in response. This is also a very common frame type that should be accepted by any TCP service. This scan type can only be used if Nmap is running as a privileged user (root or Administrator).
  • Disable the Nmap Ping (-P0) – By default, Nmap attempts to elicit a response before it begins a scan. The default Nmap ping refers to an out-of-order ACK frame followed by a traditional ICMP echo request. Since we’re already scanning a known device and we’re only going to send a single frame, this ping process is both unnecessary and inefficient.

  • Disable the Nmap reverse DNS lookup (-n) – The Nmap reverse DNS process is useful when scanning unknown devices, but it creates additional traffic we won’t need for our network response time testing. Disabling this lookup ensures a fast and efficient scan.
  • Specify a single open port for response time testing (e.g., -p80) – Nmap’s default scan will query over a thousand ports, but a scan of that magnitude will certainly skew the response time results. To ensure the most accurate response time information, select a known open port on the remote device (if the remote device is a web server, use port 80). If the application uses a different port number, change this value to match the open port on the device. If you’re not sure of the application’s port number, you may want to completely scan the device with Nmap prior to the response time test.
  • Enable three levels of debug information (-d3) – This command line option provides the important network response time information, and it’s usually not seen unless specifically enabled. Nmap includes multiple levels of debug information, and the network response time information will only be seen at debug level three.

Pages: 1 2 3 4 5 6

Tags: , , ,

Category: Nmap

Comments are closed.

X