mailing list archives
New Nmap GUI and Results Browser Requirements Doc
From: Fyodor <fyodor () insecure org>
Date: Sun, 12 Jun 2005 13:07:06 -0700
The Google Summer of Code application deadline (Tuesday) is fast
approaching, so I decided to write up this requirements/suggestions
document specifying what I think the new GUI should offer. Of course
there are other SoC projects which will probably be sponsored, but the
GUI attracted the most interest and is the most open ended. And it is
still not too late to apply if you are a university student (see
This is a huge list to accomplish in 10 weeks. But some of the
applicants seem quite skilled and motivated. Still, it will be a
major challenge and huge accomplishment. If applicants think it is
too hard, let me know and we may be able to pare it down for your
application. If you think it is too easy, that is no problem as there
is always room for you to do more or add finishing touches. Or if you
somehow create a great GUI meeting all these requirements in 7 weeks,
then you deserve to sit on your butt with a Playstation 2 for the
remaining 3 :). 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
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 optional features,
while "musts" have to be met. Here are the proposed features and
infrastructure requirements for the new Nmap GUI and results viewer:
o 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.
o Must support all significant Nmap options, and in a well-organized
way (probably multiple tabs or panels)
o Must show Nmap command line as it is being built through options
o Must support interactive display of results which easily allow any
of the following after scan is run (or after previous-scan XML file
o Show details (open ports, os, etc.) for a certain host by typing
in IP or hostname, or by browsing to it in results window.
o Show all machines with a certain port number or service name
listening. If a service name is selected
o 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.
o 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
o Sort all results by IP address
o 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.
o Might be nice if you can create and store named profiles, such as
"full scan of chicago division", "ipv6 check", "arp scan of local
o 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 :).
o 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
o 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.)
o Must support all of the major Nmap output information (port states,
os detection, version detection, uptime, mac address, etc.)
o Must 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.
o Must be able to compare 2 scans (show the new/removed/changed
o 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).
o 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 :).
o 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.
o Must 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.
o 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.)
o Should have a non-proprietary installer for Windows which handles
file installation, windows registry changes, uninstall, etc.
o Generally intuitive, aesthetically pleasing, well organized, stable,
fast, etc. Of course, these are mostly subjective goals, but they
are still important.
o Must support and be tested under Linux, Mac OS X, and Windows.
There should be no barrier towards supporting other systems such as
Free/Net/OpenBSD and Solaris, though no need to test on all of those
initially. That is what users are for :).
o Must be done in Python, C/C++, or Perl. Tcl/Tk is probably OK too.
No Java or .Net. This may be the most controversial policy, but
there are two important reasons for it:
o 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.
o 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
o Must not be done with Glade, QTDesigner, or similar GUI code creation
tool. The code they produce is just too ugly, and often inflexible.
o 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).
o 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.
Sent through the nmap-dev mailing list
- New Nmap GUI and Results Browser Requirements Doc Fyodor (Jun 12)