Home page logo

nmap-dev logo Nmap Development mailing list archives

Re: What languages/toolkit to use for the new GUI?
From: Matthew Franz <mfranz () cisco com>
Date: Tue, 07 Jun 2005 15:40:35 -0500

The sweet spot would be to have *both* and re-use as much code as 
possible between the two components (database, XML, user interface, 
hooks to nmap, etc.) so that you end up with:

1) GUI Nmap "Thick Client" with all the features that have been listed 
before plus the ability to sync up with #2. ADO.NET has some really cool 
API (DataSets) for providing memory resident database that are 
comparable to SQL and allow easy import/export from XML..

2) Centralized Nmap Scanning Server with database, correlation, etc. and 
SOAP/XML-RPC interfaces so we can have nmap web services ;) 

C# (as in Mono) would be an obvious choice (cross platform, probably 
better performance than Java, .NET runtime available on modern Windows 
OS, and Mono is becoming more common in the Linux world, even easier use 
of native libraries than Python)

Use Mono XSP (or Apache+mod-mono) and Gtk-sharp on the client side :)

But I'm sure most nmap-dev-ers think anything that comes out of Redmond 
is evil, so probably Python could satisfy this as well.... 

For what it is worth...

- mdf


Question: What about a completely web-based (PHP/Perl/Python/etc) 
based GUI? Rather than bother with messy gui libraries or Java, it 
would make it very elegant as a cross platform tool (in general).


I hope you're kidding. If you're not, and for those who starts thinking 
it's a good idea, I'd like to stomp firmly on this track of thought 
right now.

Having a webbased gui would require every user wanting to use it to 
install a webserver on the computer they wish to run it from. Webservers 
are advanced. Webservers with advanced script-languages are even more 
advanced. The millions of lines of codes with potential bugs rhymes 
extremely poorly with the entire concept of a security scanner.


Actually if you look at the archives a bit, I've made a fairly detailed 
outline of the features I intend to implement in my web based proposal 
(under the "Nmap GUI" subject).

Now, my goal isn't to replace the role of a standalone GUI app in any 
respect - this is a tool for people or institutions that routinely scan a 
network over a long period of time and like to know what's listening on 
which machines on their network, or when something new starts 
listening...without having to keep tons of text/xml files around and 
perform manual diffs of them.  I'd contend that my goals would be MUCH more 
easily implemented and utilized in a central, web-based environment than as 
a standalone application.

I'd also contend that most people likely to deploy an application of this 
nature would already have a web server running in some capacity somewhere 
for internal purposes.  The fact that the web server it runs on is 
potentially vulnerable is also to an extent irrelevant for that reason. 
Maintaining said web server would (hopefully) already be an exercised 
practice.  As far as the security aspect of the tool itself goes, such a 
tool would ideally be deployed with proper precautions taken to isolate it 
from unsafe networks and internal threats (behind appropriate firewalls, 
access controlled, etc).


Sent through the nmap-dev mailing list

Sent through the nmap-dev mailing list

  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]