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.
- 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
- Must support interactive display of results which easily allow any
of the following after scan is run (or after previous-scan XML file
- 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
- 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
- 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
- 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
- Would be cool if it can draw a pretty network diagram of
- 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.
- 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
- 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.