Home page logo

nmap-dev logo Nmap Development mailing list archives

Re: What languages/toolkit to use for the new GUI?
From: Dan White <dwhite () securecommercesystems com>
Date: Tue, 07 Jun 2005 17:52:26 -0500 (CDT)

uh hello Will!

ever hear of Apache on Linux running IP Chains and a
local copy of Snort!

Check it out- SSL sessions connect to a secured web server that
displays important security threats - cross correlated 
with holes identified  by  nmap, eeye, and ISS vulnerabity data
to tell you if the attack might succed - All displayed by
millions of lines (kslocs?) of PHP.


So we secure with SPI Dynamics web inspect on a regular
 basis and scanas all diligent security developers should!

Arggh   and NO we don't get FRENCH BENEFITS!

---- Will Beers <whbeers () mbio ncsu edu> wrote:

Andreas Ericsson wrote:
zorkshin () tampabay rr com wrote:

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 ]