Re: What languages/toolkit to use for the new GUI?

[Dan White <dwhite () securecommercesystems com>]

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.

http://www.securecommercesystems.com/guardtower.htm

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).
>
> Will
>
>
> _______________________________________________
> Sent through the nmap-dev mailing list
> http://cgi.insecure.org/mailman/listinfo/nmap-dev


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