Scan Threads and Port Statuses

This article lists various scan threads and port statuses that can be utilized to identify scan related information.

Information about scan threads and port statuses

_2013-06-26T15:02:59 [INFO] [Thread: Scan default:1] [Site: Chicago_servers]
This entry states the maximum number of IP addresses each individual Nmap process will scan before that Nmap process exits and a new Nmap process is spawned. These are the work units assigned to each Nmap process. Only 1 Nmap process exists per scan.
_2013-06-26T15:04:12 [INFO] [Thread: Scan default:1] [Site: Chicago_servers]
This entry states the number of IP addresses that the current Nmap process for this scan is scanning. At a maximum, this number can be equal to the maximum listed in the preceding entry. If this number is less than the maximum in the preceding entry, that means the number of IP addresses remaining to be scanned in the site is less than the maximum. Therefore, the process reflected in this entry is the last process used in the scan.

Information about scan tasks within a scan phase

_2013-06-26T15:04:13 [INFO] [Thread: Scan default:1:nmap:stdin] [Site: Chicago_servers] Nmap task Ping Scan started._

A specific task in the Nmap scan phase has started. Some common tasks include the following:

  • Ping Scan: Asset discovery
  • SYN Stealth Scan: TCP port scan using the SYN Stealth Scan method (as configured in the scan template)
  • Connect Scan: TCP port scan using the Connect Scan method (as configured in the scan template)
  • UDP Scan: UDP port scan
_2013-06-26T15:04:44 [INFO] [Thread: Scan default:1:nmap:stdin] [Site: Chicago_servers] Nmap task Ping Scan is an estimated 25.06% complete with an estimated 93 second(s) remaining._ This is a sample progress entry for an Nmap task.
This is a sample progress entry for an Nmap task.

Discovery and port scan status

_2013-06-26T15:06:04 [INFO] [Thread: Scan default:1:nmap:stdin] [Site: Chicago_servers] [10.0.0.1] DEAD (reason=no-response)_
The scan reports the targeted IP address as _DEAD_ because the host did not respond to pings.
_2013-06-26T15:06:04 [INFO] [Thread: Scan default:1:nmap:stdin] [Site: Chicago_servers] [10.0.0.2] DEAD (reason=host-unreach)_
The scan reports the targeted IP address as _DEAD_ because it received an _ICMP host unreachable_ response. Other ICMP responses include _network unreachable, protocol unreachable, administratively prohibited_. See the RFC4443 and RFC 792 specifications for more information.
_2013-06-26T15:06:04 [INFO] [Thread: Scan default:1:nmap:stdin] [Site: Chicago_servers] [10.0.0.2] DEAD (reason=host-unreach)_
The scan reports the targeted IP address as _DEAD_ because it received an _ICMP host unreachable_ response. Other ICMP responses include _network unreachable, protocol unreachable, administratively prohibited_. See the RFC4443 and RFC 792 specifications for more information.
_2013-06-26T15:07:45 [INFO] [Thread: Scan default:1:nmap:stdin] [Site: Chicago_servers] [10.0.0.3:3389/TCP] OPEN (reason=syn-ack:TTL=124)_ or _2013-06-26T15:07:45 [INFO] [Thread: Scan default:1:nmap:stdin] [Site: Chicago_servers] [10.0.0.4:137/UDP] OPEN (reason=udp-response:TTL=124)_
These two entries provide status of a scanned port and the reason for that status. _SYN-ACK_ reflects a SYN-ACK response to a SYN request. Regarding TTL references, if two open ports have different TTLs, it could mean that a man-in-the-middle device between the Scan Engine and the scan target is affecting the scan.
2013-06-26T15:07:45 [INFO] [Thread: Scan default:1:nmap:stdin] [Site: Chicago_servers] [10.0.0.5] ALIVE (reason=echo-reply:latency=85ms:variance=13ms:timeout=138ms)_
This entry provides information on the reason that the scan reported the host as _ALIVE_, as well as the quality of the network the host is on; the latency between the Scan Engine and the host; the variance in that latency; and the timeout Nmap selected when waiting for responses from the target. This type of entry is typically used by Technical Support to troubleshoot unexpected scan behavior. For example, a host is reported _ALIVE_, but does not reply to ping requests. This entry indicates that the scan found the host through a TCP response.

The following list indicates the most common reasons for discovery and port scan results as reported by the scan:

  • conn-refused: The target refused the connection request.
  • reset: The scan received an RST (reset) response to a TCP packet.
  • syn-ack: The scan received a SYN|ACK response to a TCP SYN packet.
  • udp-response: The scan received a UDP response to a UDP probe.
  • perm-denied: The Scan Engine operating system denied a request sent by the scan. This can occur in a full-connect TCP scan. For example, the firewall on the Scan Engine host is enabled and prevents Nmap from sending the request.
  • net-unreach: This is an ICMP response indicating that the target asset's network was unreachable. See the RFC4443 and RFC 792 specifications for more information.
  • host-unreach: This is an ICMP response indicating that the target asset was unreachable. See the RFC4443 and RFC 792 specifications for more information.
  • port-unreach: This is an ICMP response indicating that the target port was unreachable. See the RFC4443 and RFC 792 specifications for more information.
  • admin-prohibited: This is an ICMP response indicating that the target asset would not allow ICMP echo requests to be accepted. See the RFC4443 and RFC 792 specifications for more information.
  • echo-reply: This is an ICMP echo response to an echo request. It occurs during the asset discovery phase.
  • arp-response: The scan received an ARP response. This occurs during the asset discovery phase on the local network segment.
  • no-response: The scan received no response, as in the case of a filtered port or dead host.
  • localhost-response: The scan received a response from the local host. In other words, the local host has a Scan Engine installed, and it is scanning itself.
  • user-set: As specified by the user in the scan template configuration, host discovery was disabled. In this case, the scan does not verify that target hosts are alive; it "assumes" that the targets are alive.

The beginning and completion of a scan phase

_2013-06-26T15:02:59 [INFO] [Thread: Scan default:1] [Site: Chicago_servers] Nmap phase started._
The Nmap (Network Mapper) phase of a scan includes asset discovery and port-scanning of those assets. Also, if enabled in the scan template, this phase includes IP stack fingerprinting.
_2013-06-26T15:25:32 [INFO] [Thread: Scan default:1] [Site: Chicago_servers] Nmap phase complete._
_2013-06-26T15:25:32 [INFO] [Thread: Scan default:1] [Site: Chicago_servers] Nmap phase complete._ The Nmap phase has completed, which means the scan will proceed to vulnerability or policy checks.