NmapFE++

Update: This task to make an all-new Nmap frontend to replace NmapFE was completed and the result is Zenmap, the new official Nmap GUI and results browser.

The goal for this project idea is to make a new, much improved Nmap GUI which is useful for executing Nmap, and results viewing. This is to be done as part of the Google Summer of Code project (see the Nmap GoogleGrants page). Doing this in 10 weeks will be a huge challenge, but should be a great learning experience. We will also probably sponsor 2 or 3 developers to work on independent GUIs (Google doesn't allow teams to work together). At the project end (Sept. 1), perhaps the best features of each could be combined. Or maybe one will be vastly superior to the others and can be used as the default Nmap GUI. Or, maybe they will both be useful to different sets of people, serving different niches. The development will be done in the open on a site such as Sourceforge, and nmap-dev people are allowed (and encouraged) to help them test, contribute patches, etc. A new GUI would be a great boost to the project. This GUI will do a lot more than simply execute Nmap and show the unparsed results in a Window -- that only helps newbies. Read the specs below and you'll see a lot of features designed for advanced users scanning huge networks. Probably 80% of work will be in the results viewer/parser, making the "nmap execution" part relatively easy.

I do want to emphasize that this is NOT intended as a replacement for the beloved command-line version of Nmap. So no need to get defensive about it, as some recent nmap-dev mails were :). Heck, the app will work by executing the command-line version. Even if the app turns out to be everything I want it to be, I'll still use the command-line version for most of my scanning. But it is nice that other people have the option to use the GUI for executing Nmap. And the results viewer aspect (which, again, is most of the work), could be very useful even for the command line gearheads.

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. Here are the proposed features and infrastructure requirements for the new Nmap GUI and results viewer:

Note that even the "required" features are negotiable. Let me know if you can't do some of these.We may have to do some triage to determine the most important bits, while leaving the design open enough that the other features could be added later.

REQUIRED FEATURES

• Must be able to execute Nmap and read the XML output, and also be able to parse existing XML files. Must be able to save Nmap results to an XML file, even after Nmap runs. Would be nice to save in other formats as well, such as normal output and HTML. Maybe an option to store in a DB. Input from Nmap "normal output" would be nice as well.
• Must support all significant Nmap options, and in a well-organized way (probably multiple tabs or panels)
• Must show Nmap command line as it is being built through options dialogues.
• Must support interactive display of results which easily allow any of the following after scan is run (or after previous-scan XML file loaded):
• Show details (open ports, os, etc.) for a certain host by typing in IP or hostname, or by browsing to it in results window.
• Show all machines with a certain port number or service name listening. If a service name is selected
• Show all found instances of a certain application, via version detection results. must allow a regular expression match of the version, product, and extrainfo fields. Nmap already includes libpcre for portable perl-style regexp support.
• Sort results by open port number or service name (this would just be a big table of open (or, perhaps open|filtered) ports, with columns for IP address, port number, service, maybe the host OS, etc. Obviously sorted by port number or service name, as requested.
• Sort all results by IP address
• After you load an XML (say from the "recent scans" menu item or just from file browsing), or even when you are viewing results from a just-done scan, there should be a "repeat this scan" option to let you run the same scan again. Maybe the best way to do this is to check the relevant options for the command used when the user loads an XML (or keep them when the user performs a scan). Then repeating the scan is just a matter of pressing "scan" again. For example, you might want to scan your new server, disable some stupid services in an ssh window, then repeat the scan to ensure that the ports are now closed. This should be easy. The solution of setting/preserving options when XML is loaded or Nmap is run may solve the "named profile" item below as well.
• Might be nice if you can create and store named profiles, such as "full scan of chicago division", "ipv6 check", "arp scan of local net", etc.
• Must have a graphical paperclip or other mascott which provides advice and suggestions as you plan your scan. Like this one: http://www.counterhack.net/base_clippy_image.html . OK, maybe not :)
• Must be able to show small icons for operating systems and/or device type and 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.
• Must be able to store persistant state (probably in a file for portability reasons). This could hold stuff such as preferences, recent scan information (XML file location, options used, etc.
• Must support all of the major Nmap output information (port states, os detection, version detection, uptime, mac address, etc.)
• Should support Nmap timing estimates for progress bars and such. This will probably require adding that support to the XML output (I don't think it is there yet), or parsing Nmap "normal" output. Or maybe you could just show normal output while the scan proceeds, then switch to parsed mode when it completes.
• Should be able to compare 2 scans (show the new/removed/changed hosts/ports)
• Would be cool if it can draw a pretty network diagram of discovered network.
• Would be nice to be able to load multiple files into the results view, e.g. if you have one scan file for each subnet. The results would be merged, and it would be OK to have rules like only showing the 1st results of a given host (if that is found in subsequent files, you could ignore those instances of it).
• Should have a big red "hack this server" button which uses AI and a cache of 0-day exploits to identify weaknesses, create and launch exploit code, then deface the web site with a poorly spelled self-aggrandizing rant about how lazy and stupid the syadamin must be and how 'l33t the Nmap user is. It should automatically report the defacement to Zone-H and the other archives :). Not really.
• Must be fully documented in a man page and HTML. One good option is to write the docs in Docbook XML and then use automated conversion to get man page (nroff) and html. Or you could write the nroff directly and convert to html. Or write separate HTML and man pages. HTML generated from a non-text source (Word, Dreamweaver, Frongpage, etc.) is unacceptable unless you have a rare tool that produces readable and concise HTML. Interactive help in the application may be nice too. At the bare minimum, it should at least have a help button/menu that points users to the help web page or man page.
• Should allow annotations (text strings) to be made to hosts and ports. These are saved in the XML (and/or other formats like HTML if offered) file when the user does a save option. User is prompted to save if NmapFE is closed when annotations have been added/changed since last save. User can search for these annotations in the GUI, or have the displayed in the relevant port tables, etc.
• 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.)
• Should have a non-proprietary installer for Windows which handles file installation, windows registry changes, uninstall, etc.
• Consider supporting multiple concurrent scans.
• Must be generally intuitive, aesthetically pleasing, well organized, stable, fast, etc. Of course, these are mostly subjective goals, but they are still important.

INFRASTRUCTURE REQUIREMENTS

• Must support and be tested under Linux, Windows, and one of the following: Mac OS X, Free-, Net-, or Open-BSD, and Solaris. There should be no barrier towards supporting most of the other systems, though no need to test on all of those initially. That is what users are for :).
• Must be done in Python, C/C++, or Perl. Tcl/Tk is OK too. No Java or .Net. This may be the most controversial policy, but there are two important reasons for it:
• I really believe the project will have trouble catching on if a java interpretor or .net infrastructure are required. Python/Perl/Tcl are small enough that the interpreter can basically be shipped with the binary.
• A great front end deserves to be maintained long after the Summer of Code project ends. While it is great if the author steps forward to continue maintance, they may be unable/unwilling to do so at some point. Many Nmap front ends have been abandoned for these reasons, and sometimes I end up maintaining them (e.g. my maintenance of NmapFE and long-time hosting of Nmapwin). I am unwilling to maintain a Java or .Net project.
• I would prefer that you do this without Glade, QTDesigner, or similar GUI code creation tool. The code they produce is often ugly, and often inflexible. But if you really think it will make you much more productive, such tools are probably OK. But mail me first. And also, write up a document explaining how to load and modify Nmap using the designer tool.
• Must limit the number of external libraries/programs it depends on. Anything that ships with Nmap is OK, and you'll probably need a graphical widget library such as GTK or QT and an XML parser, but don't go overboard in adding a bunch of new dependencies. It must not require DB libraries or installation of a database (though that is OK as an option).
• The Frontend must be able to perform the vast majority of its functionality even if the user has not installed and set up a database.
• Development must be done in the open, hosted on a project server such as Sourceforge. Test versions and such should be sent to the nmap-dev list (just send links, not the binaries themselves). That is a good list for bouncing ideas around too.