Nmap Development mailing list archives
Re: Script selection interface - Update
From: David Fifield <david () bamsoftware com>
Date: Tue, 25 May 2010 13:39:57 -0600
On Tue, May 25, 2010 at 07:34:58PM +0530, kirubakaran S wrote:
I have given link to my final mock interface[0]
I like this. I think you need to make the link more prominent so people can find it easily, so here it is again: http://docs.google.com/View?id=dwn8dz7_51cz637bg7
Before you start implementing this, I want you to do the review of NSE Facilitator and OpenVAS-Client. It is best to see what others have done and how it can be improved.Hi, I reviewed OpenVAS. They call scripts as plugins. OpenVAS organised plugins into group of Families. We call it category in nmap.Unlike nmap,in OpenVAS a plugin can present in only one family. I found the following things interesting about openVAS. ** Filtering Feature : OpenVAS filters plugins according to pattern supplied by user. The pattern is applied on various attributes of plugins. The attributes on which the pattern is to supplied are selected by user.
This is a nice feature. I'm trying to decide if we need a separate filter language, or if we should limit it to the filter already supported by NSE, strings like "(default or vuln) and not intrusive". Using our existing filter language is nice from the point of view of doing live update with the command line. However I can also see wanting to do a fulltext search on the script descriptions.
** Plugin MetaData : Plugin metadata are presented to user in a separate dialog box, when the user double-clicks the particular plugin.
I think this is a reasonable design decision, when there's extra information that doesn't need to be shown all the time. Your proposed NSEDoc links work like this, actually.
** Check box is given to each script so whenever the user wants to select the script. They can simply check the check box and supply the arguments.
I've got some ideas on shwoing which scripts are selected below.
Regarding this one, I think we only need the most important fields. I'd suggest a link to the script's NSEDoc page for people to get "license" and "author" field values.** The Reason I have given link to NSEDoc instead of showing all the metadata is that, it will eat up more space and leaves less space for arguments.
The NSEDoc link is a good idea. I think it's important to show the entire script description (several paragraphs) on this page. That's easy enough to put in a scrolling text field. I think I agree with Fyodor that we can leave out the author and license fields. Or just append that data to the end of the text field, so people can see it by scrolling down.
** It is difficult to remove Help section Because it will affect all other tabs.Help is a text viewer already packed in to the window.
I don't care if it's difficult. Let's design a good interface, and then write to code to make it happen. If it turns out to be too hard, then we'll forget it. But don't let presumed implementation difficulties limit your vision. Anyway, I don't think it will be that hard to remove the help box from this tab, or change its shape to fit the interface better. I would much rather use up 25% of the space on a bigger description text box. You are going to have to deal with space for arguments anyway, because there's no limit to the number of arguments that a script can have. I want you to design the interface for a script with 20 arguments. For that you will need to use scrolling or a popup box or something.
** I haven't included check box for each of the script.My interface designer don't have that option.I am planning to provide that in real interface.
That's a good thing to bring up, how we're going to show which scripts are selected out of the master list of scripts. We could highlight or checkbox the specific scripts, but that will get annoying when you have to scroll up and down to see which scripts you've selected. Of course in the final interface, the command line will always reflect the scripts you've chosen, so at least there's a clue there. We could have another box listing just the selected scripts (this could double as a preview of scripts that will run with a specification like "http-*"). I dislike the interfaces where there are two boxes with → ← arrows between them, and anyway that doesn't fit well with the requirement that we have to get a list of scripts from a typed specification. Let me give you an example of what I'm thinking of with regard to the specification parsing. If you enter "vuln" in the command line, it should somehow list all the vuln scripts, indicating that they will be run. Then if you click one of those, say http-enum, and remove it, the interface would update the specification to read "vuln and not http-enum" David Fifield _______________________________________________ Sent through the nmap-dev mailing list http://cgi.insecure.org/mailman/listinfo/nmap-dev Archived at http://seclists.org/nmap-dev/
Current thread:
- Script selection interface - Update kirubakaran S (May 25)
- Re: Script selection interface - Update David Fifield (May 25)
- <Possible follow-ups>
- Re: Script selection interface - Update kirubakaran S (May 25)