Re: [RFC] Zenmap search interface overhaul

[Fyodor <fyodor () insecure org>]

On Mon, May 26, 2008 at 07:11:13PM +0200, Vladimir Mitrovic wrote:
> Hi all,
>
> I've assembled all of our ideas into a blog post: 
> http://zenmap-soc08.blogspot.com/2008/05/search-window-todo.html . Thanks 
> everyone for your input. This is only the first iteration of the operator list, 
> since I'm quite sure ideas will keep popping up as we go.

This looks like a great draft.  I also agree with pretty much all of
David's suggested improvements too.  In particular, he's right that we
shouldn't make it more complex than it needs to be.  There is no point
adding a qualifier if nobody can specify a need for it.

My favorite part is probably the bare searchwords which match
anything.  I suspect that may be the most commonly used.

It would be nice if you included some practical examples on the page.

I have some comments on the operators:

name: (n:) - what name is this?  Is this a name you give when you save
it?  The name of the profile you used?

target: (t:) - I agree with David that this should match broadly.  But
in that case, maybe we can ditch it and free text search will be
sufficient.  How likely is it that a target name from one scan will
appear in the output of another scan in such a way that you don't want
it included in the search?

opt: (o:) - Do we have use cases for the sort of queries people would
actually use this for?

date: (d:), after: (a:), before (b:) - These are good ones

osclass: (os:), osversion (osv:) - I guess these may be useful if the
GUI has a selection list.  If you are going to have osclass, I think
it should be osc.  If there is an os:, I think it should match all the
OS related fields (including vendor, device type, os details, os
class, os version, etc.)  But we may not need an os: since free text
may be sufficient.

port: (p:) - I'm not sure I understand the functionality of this.

oport, cport, fport, porstate: - I think David sent some
comments/ideas regarding these.

service: (s:) - Sounds good

serviceversion: (sv:) - So this would match any of the version
detection related fields?  Sounds reasonable, but omitting it and
letting people use freetext search may be OK as well.

inroute: (ir:) - Freetext search may suffice for this.  The name/IP of
a machine on the route is unlikely to appear in any scans for which it
is not in the route.

Also, you note that "the "and" operator is implicit.  It would be nice
if you could at least select between and/or for the whole string.
That is a compromise between always requiring "and" and allowing both
and/or in a single statement.  I can think of many cases where you
would want "or".  For example, Debian bugs are often found in
derivitive distributions (like Ubuntu) as we saw with the OpenSSL
fiasco.  So you might want to search for Debian or Ubuntu.

Is there a way to specify that strings belong together?  I might want
to search for "red hat" and require that whole string to come
together, rather than just "red" and "hat" appearing in the results.

Also, I think there are several possible reasons to search:
 o To filter current scan results (e.g. in the scan I just did or
   results file I just opened) to only show hosts which match the given
   criteria.

 o To find scans in my history which match the given criteria
  (e.g. show me scans I've done in the last week) so I can find a
  certain scan.  I think I would usually want the filter to be applied
  to the hosts shown when I open the scan.

Will this feature be used for both of these applications, or just one
of them?

Anyway, those are my initial thoughts.  Keep up the good work!

Cheers,
-F

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