Nmap Autodiscovery

Nmap Autodiscovery

Nmap (network mapper) is a tool primarily used for security scanning. However, it can be used to “guess” which services are running on which ports. Device42 uses Nmap to discover which services are running on which ports and automatically marries this data to NetFlow data to automatically create a map of services and application dependencies.

Add an Nmap Autodiscovery Job

Select Discovery > Nmap to display the Nmap autodiscovery page, then click Add Nmap autodiscovery spec to display the Add Nmap autodiscovery page.

The following fields are required an Nmap job:

  • Name – name of the job
  • Start IP Address – the starting IP address
  • End IP Address – the ending IP address
  • Remote Collector – the D42 ID for the remote collector to use for the job

Available Nmap job options:

  • Nameserver to use for reverse DNS – the IP/FQDN of the nameserver
  • OS Detection – detect operating system(s) and versions (default on)
  • Services Detection – detect running services (default on)
  • Object Category for discovered devices – select an existing object category or add a new category
  • VRF Group for discovered IP addresses and subnets – select an existing group or add a new group
  • Overwrite existing object categories – overwrite the object categories for existing discovered devices and child devices.
  • Tags for discovered devices – comma separated list of device tags

You can also create an Auto Discovery Schedule for the job – click Add another Auto Discovery Schedule at the bottom of the page.

Click Save to save the job and add it to the jobs list. You can then run the job immediately if you want.

Nmap / NetFlow Autodiscovery Notes

In Device42, NetFlow and Nmap can be used by themselves, together, or in combination with point-in-time discovery. Using NetFlow and Nmap data together but without point-in-time discovery results in a good services dependency mapping capability. However, just using these two sources of data is still limited in the following ways.

  1. A map of service inter-dependencies and interrelationships can be created. However, many services often combine to form an application. For example, there might be multiple Oracle services plus configuration files that together form the Oracle application. Applications and associated information (e.g., installed apps on a web server and instances and named pipes on a database) cannot be discovered by the NetFlow/Nmap combination.
  2. The services that Nmap finds are guesses and the guessed version number is probably wrong as often as it is right.
  3. Some enterprises have such restrictive firewall rules that Nmap will discover few if any services.
  4. NetFlow can’t “see” application interactions inside a physical/virtual/cloud server. NetFlow can only see interactions that go through the router. So, many dependencies will be missed.
  5. While NetFlow works well for physical routers and switches, it is not great for the virtual routers and switches found in hyper-visors because many hyper-visors do not support NetFlow.
  6. On routers and switches, NetFlow must be setup for every segment. If some segments are not setup, the application interactions will not be found.

To overcome these limitations, it is better to use NetFlow/Nmap in conjunction with point-in-time discovery.