Nmap Graphical Display

If Nmap is going to be called the Network Mapper, perhaps it should be able to generate a map. This Google Summer of Code project (see the Nmap GoogleGrants page) aims to create pretty diagrams of a network from Nmap XML output. It should use fields such as the target OS (OS detection), service and application name (port scanning and version detection), and path information (may include implementing advanced traceroute functionality). You may look at other network visualization projects such as fe3d and Cheops/Cheops-NG for inspiration. This project calls for both excellent coding skills, and expertise in designing aestheticly pleasing and efficient interfaces.

Pretty Pictures

We'll start this requirement doc with everyone's favorite part, the screen shots! Then we get to the nitty gritty.

Here are a few pics from similar existing applications, and ideas sent in by potential SoC students:

From Cheops:

From fe3d:
From Cole Nevins' SoC App:

From Adriano Marques' SoC App:

REQUIRED FEATURES

If you guys think of other important features/requirements for this document, of feel it should be changed in other ways, let me know. Labels such as "should" or "would be nice" denote less-critical features that can be worked on last, while "musts" have to be met unless we agree to make changes. Here are the proposed features and infrastructure requirements for the new Nmap graphical display application:

• Everything in the General Requirements document.
• Must be tested to work on at least Linux, Windows, Mac OS X, and Free- or Open-BSD.
• Must have an interactive mode for users to scroll and/or zoom through a well-organized and pretty 2D or 3D diagram of the network based on reading Nmap XML output. User must be able to export any diagram to an image in PNG or SVG format (you only need to support one of these formats, though additional formats are desirable).
• Must also have a non-interactive mode other applications can use to generate images to be used by Nmap GUIs, in HTML reports, etc. You could support this either by command-line arguments, or a programmatic library API (or both).
• Must scale, so that it supports a network of hundreds of thousands of hosts, or a scan of a single host. You should be able to zoom into a single host from a large network view.
• Must provide the most important information from Nmap output, including open ports, OS type, version detection results, and device type. But it should gracefully function even without OS detection, version detection, and/or device type information. It must work even with a simple host discovery scan.
• Must (at least in some mode) show network connections based on traceroute results. Since Nmap doesn't yet support traceroute, you may need to add it (or it is possible that someone else will do that task). Here is a description of the task:

  Add parallel traceroute support to Nmap. It should come after the port scanning and host enumeration sections, and utilize a port/protocol that Nmap has found to be accessible on the particular target. Multiple hosts should be done in parallel (as with most Nmap scans), and multiple probes done in parallel too. The Nmap parallel rDNS infrastructure should be used to look up the intermediate hosts (unless -n was specified), add them to etchosts hash table (be sure to verify that they are indeed being cached, as many of the intermediate hosts will be repeated for each machine). Printing to normal output should be concise -- for example you can show the whole path for the first system and then only show for the first point of path divergience for the next system. You may even be able to do the probes backwards and cease probing once you find a machine that you already know the path to. XML output format should give the entire route for each host, since space isn't as serious of a constraint there.

• You may want to show latency as a component of the diagram.
• The application must display the Nmap command-line used (this is in the XML file), or offer a way to do so.
• It would be cool if you could do some simple sorting/filtering, such as specify that you only want to see hosts with port 23 open, or hosts identified as Linux. Or type in an IP/hostname to see just that box.
• Since design is so critical, it is important to proceed in stages:
  1. First develop an initial detailed proposal to nmap-dev so that people can provide feedback and suggestions. Explain how the interface(s) work, and maybe give rough sketches/mockups as appropriate.
  2. If you are tasked with adding traceroute support to Nmap, this might be a good time to do it.
  3. Create better mock-ups of the application and send them to nmap-dev for review.
  4. Create the actual application. Try to create a very limited, but usable, version first. Then start adding all of the features. Beta releases should be sent to the nmap-dev list every couple weeks or so.
• Must be able to show small icons for operating systems and/or device type and/or known services. These must be stored in such a way that they are easy to change, and there must be a default for unknown services/systems.
• Users must be able to control the detail level. For example, they may want to show uptime of hosts, but not round trip times (latency) between them.
• Maybe user should be able to execute a scan (by typing the command-line into a field) and have the graphical results automatically be displayed. The app should have a progress bar showing when Nmap is expected to finish, and showing partial data (updated as new machines complete) would be cool.
• A graphical comparison of two Nmap results files might be useful to show what has changed. Maybe this should be done with an nmap-diff program which finds the differences (which someone else might write). Then this app just needs to be able to display an nmap-diff XML file.
• Must have a man page, written in DocBook XML so that it is easy to convert to HTML or NROFF. You can use the Nmap man page XML as an example.
• It might be cool to allow comments to be added to hosts.
• Must provide overall stats for loaded results, such as number of hosts scanned, number of hosts online, number of ports in each state (open, closed, filtered, etc.) This may be a separate dialogue user can request through a menu or whatever.
• Must have NSIS installer for Windows to handle file installation, windows registry changes, uninstall, etc. NSIS is what Nmap uses for its installer.
• Must be generally intuitive, aesthetically pleasing, well organized, stable, fast, etc. Of course, these are mostly subjective goals, but they are still important.
• The app may be written in Python, C/C++, Perl, Ruby. If you wish to use a different language, we need to discuss it first. We will consider Java, but .Net is out of the question.
• A feature to geocode the IP addresses and overlay them on a map would be neat.
• The app needs to be both pretty and useful.