New Nmap GUI and Results Browser Requirements Doc

[Fyodor <fyodor () insecure org>]

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
http://www.insecure.org/nmap/GoogleGrants.html ).

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
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 optional features,
while "musts" have to be met.  Here are the proposed features and
infrastructure requirements for the new Nmap GUI and results viewer:

REQUIRED FEATURES:

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
  dialogues.

o Must support interactive display of results which easily allow any
  of the following after scan is run (or after previous-scan XML file
  loaded):
  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
    requested.

  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
  net", etc.

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
  services/systems.

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
  hosts/ports)

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.

INFRASTRUCTURE REQUIREMENTS:

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
       project.

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.

Cheers,
Fyodor


_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev