Nmap Development mailing list archives
Re: Nmap GUI
From: Fyodor <fyodor () insecure org>
Date: Sun, 5 Jun 2005 13:34:28 -0700
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
Current thread:
- Re: Nmap GUI, (continued)
- Re: Nmap GUI digmet (Jun 05)
- Re: Nmap GUI testic (Jun 05)
- Re[2]: Nmap GUI digmet (Jun 05)
- Re: Nmap GUI Etaoin Shrdlu (Jun 05)
- Re: Nmap GUI Manu Garg (Jun 05)
- Re: Nmap GUI jonathan roeder (Jun 05)
- Re[2]: Nmap GUI digmet (Jun 05)
- Re: Nmap GUI testic (Jun 05)
- Re: Nmap GUI Emmanuel Goldstein (Jun 05)
- Re: Nmap GUI grutz (Jun 05)
- Re: Nmap GUI digmet (Jun 05)
- Re[2]: Nmap GUI digmet (Jun 05)
- RE: Nmap GUI Brandon Enright (Jun 05)
- Re: Nmap GUI Andreas Ericsson (Jun 06)
- Re: Nmap GUI Christoph Brüser (Jun 06)
- Re: Nmap GUI Ben Lindsey (Jun 05)
- Re: Nmap GUI Kevin Davis (Jun 05)