Re: [RFC] Zenmap search interface overhaul

[Vladimir Mitrovic <snipe714 () gmail com>]

Fyodor wrote:
> It would be nice if you included some practical examples on the page.

Will do.

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

For scans in the DB, that's the name you get in the results section of the 
current search window, for example "Intense Scan on scanme.nmap.org". For saved 
scans, I think this should match the filename on disk.

Now that I mentioned it, do you have any ideas on how we'll enable searching a 
given directory? I was thinking of making it an option in the "Expressions..." 
dialog. That way when a user selects a directory to search, the search string 
gets appended with "dir:/selected/dir". Sound good?

> 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?

Well, the only place I can see it appearing is in the traceroute output of 
another host's scan, if the machine is a router. Which, I guess, is not that 
big of a deal. Perhaps we should keep it for completeness? I see no harm in 
keeping it, and it should be almost-trivial (tm) to implement.

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

First let's get this straight: bare search strings shouldn't be case sensitive 
right? Typing "debian" should be the same as "Debian". Ok, so let's say you 
wanted to find all connect scans you ran (let's keep it at that). If you would 
use the bareword search, "sT" would match every scan you've ever made, because 
"st" is a part of "host", which appears everywhere. If you used "-st" to narrow 
it down, you would still get all scans that have "--stylesheet" set, for 
example. (It's not a very good example, but still.)

I see no reason why we should ditch any of these "standard" operators. From a 
user's standpoint, if I see operators like "target:", "date:", etc. I would 
expect "opt:" or "options:" to be there, too.

> 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.

I vote for "os:" matching all OS-related fields, "osc:" for OS class, "osv:" 
for version, and for keeping the operator. Having an os: operator does not 
restrict the user from making a freetext search.

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

As jah previously suggested (http://seclists.org/nmap-dev/2008/q2/0440.html), 
this will match the port if it was scanned (if I understood correctly). 
However, if you combine it with the "portstate:" operator, then it matches 
ports that have been scanned *and* that were found to be in a certain state. 
For example, "portstate:filtered port:22" finds all filtered ssh ports.

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

Yes, he did, but it still needs a final decision.

> 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.

Yes, it will match all version detection related fields. And you can still give 
freetext search a try, if you like. :)

> 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.

Well, if you're administering a small network, you can specify 
inroute:router_ip to get scans for all machines in the network *except* the 
router. I don't know if that's a sufficient reason to keep it, though. Freetext 
search does sound better in this case.

> 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.

I've mentioned previously (http://seclists.org/nmap-dev/2008/q2/0442.html) that 
the string following the semicolon can be a regular expression. This can apply 
only to certain fields, since we don't need regexps for some fields (like 
dates, for instance). Perhaps a regexp is a bit of an overkill, but a simple 
"or" sub-operator can be implemented on a per-operator basis. So, for your 
example, "os:debian|ubuntu".

What do you guys think, a regexp or a simpler version with an "|" operator?

I think making the "or" operator on the query level is making the whole story 
more complicated, and less doable in 4 weeks time. I would also like to repeat 
what I said previously, "not elaborate queries, but quickly finding what you need."

> Is there a way to specify that strings belong together?  I might want
> to search for "red hat"...

Good point, you should be able to wrap it with quotation marks.

> 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.

Zenmap currently searches the DB, a directory (if given) and the currently open 
tabs for matches. I'm not sure what you mean by "to only show hosts which match 
the given criteria". If by this you mean that Zenmap should pull hosts that 
match the criteria from inside the scan (since a scan can contain lots of 
hosts), and present them as separate results, then no. But I like this, maybe 
we should work in this direction (see below).

On the other hand, if you meant "to only show *open scans* which match the 
given criteria", then yes.

>  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.

Yes.

>  I think I would usually want the filter to be applied
>   to the hosts shown when I open the scan.

Like I said, I like this. How did you imagine this, visually? Should the hosts 
somehow be highlighted in the opened scan tab, or perhaps a "host viewer" 
should be introduced? RadialNet has the Host Viewer already, so maybe I can mix 
it together with the search interface once I start coding my proposal later 
this summer.

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

Thanks. :)

Cheers,
Vladimir


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