Re: Nmap GUI

[Fyodor <fyodor () insecure org>]

On Sun, Jun 05, 2005 at 12:20:05PM +0200, "Grodås, Ole Morten" wrote:
> There is a chance that one of the summer of code projects
> (code.google.com) is going to be the creation of a new nmap GUI.

Excellent point!  The next-generation Nmap GUI project has been by far
the most popular, with well over half of the applicants choosing it.
So now is our chance to decide what sort of GUI we really want.

Keep in mind that it is not too late to apply for Google sponsorship
if you are a student at some university and available for the summer.
The details are at:

http://www.insecure.org/nmap/GoogleGrants.html

The goal of a new GUI, IMHO, is not just to help the newbies and
casual users who have trouble remembering Nmap's (literally) hundreds
of command-line options.  NmapFE already does a decent job of that.  I
believe a graphical interface can be extremely powerful in a different
way than command-line.  In particular, it can make real-time sorting and
browsing of results easier.  The new GUI will probably take Nmap XML
input, so you'll have the option of scanning with the GUI, or using
the command line and then importing the results.  Maybe the GUI can
store results in a DB, compare different runs, etc.  Perhaps it could
have a history function so that you could look back and view previous
run results.

Here are some ideas and questions.  I would be interested in hearing
other users' input:

o Portability - I believe that the frontend should work on UNIX,
                Windows, and MAC OS X.  I just don't think we have the
                resources to maintain multiple top-notch GUIs.  I
                believe that a Windows GUI is especially important
                because cmd.exe just sucks.  I use bash on Cygwin
                instead, but it is still hobbled by Windows
                limitations.

o Machine code or interpreter?  People have applied to do the new
  GUI in C/C++ with various libraries (Qt, GTK2, etc.), Java, Python,
  and even .Net/Mono.  I tend to favor C/C++ because the distributed
  application wouldn't require users to download a large interpreter.
  But perhaps some interpreters (Python?) may be small enough to
  distribute in the installer.

o Installer -- Supporting an executable installer on Windows sounds
  like a good idea to me.  Windows users seem to expect that.

o Nmap XML Output -- The GUI should read at least this format, IMHO,
  and possibly others.  The GUI should offer to run Nmap for you
  (supporting all of the major options in a well-organized serious of
  tabs/dialogs), or allow you to simply import your own results.

o 3rd party libraries should be kept to a minimum for portability and
  maintenance reasons.  A graphical library such as GTK or Qt makes
  perfect sense, but don't overdo it with tons of libraries that can
  cause dependency hell.

o Searching, sorting, and drilling-down into results.  It
  would sort of features people would value here.  Maybe I should
  solicit mock-ups from the applicants to see what they have in mind.
  Or maybe provide a list of tasks that should be made easy ("Find all
  systems running OpenSSH", "Find all systems with port 80 open",
  "Find all Solaris boxes", etc.)  Anyone want to take a stab at such
  a list?

o Comparing results.  An option to show the differences between last
  weeks scan and the one I did today would be quite valuable.

o Show the command line.  One feature I like about NmapFE is that it
  shows the exact Nmap command-line that will be executed as you
  construct it through the options dialogue.  This may help teach people
  to use the command line and I feel that it should be supported unless
  there is a great reason not to.

o Eye candy -- One (potential) advantage of a GUI is that it can
  support pretty pictures and icons.  I'm not talking about going
  overboard with dancing pigs here, but unobtrusive icons can be
  helpful.  For example, the host list could have icons next to the
  host name with a linux penguin, BSD daemon, or other
  platform-specific icon.  Perhaps even the services could be
  deliniated in a similar way so that you easily recognize (say) ssh
  daemons or mail servers in the results.

o Extensible -- the interface must be designed so that it leaves room
  for growing new features later.

o Stability, security -- these go without saying.

Does anyone have other suggestions?

Also, what graphical libraries (or scripting interpreters, i suppose)
do you guys like?  Anyone have examples of good cross-platform open
source GUIs we can use as a model to look at what they did right?

Cheers,
Fyodor


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