mailing list archives
Re: [RFC] Zenmap search interface overhaul
From: Vladimir Mitrovic <snipe714 () gmail com>
Date: Wed, 28 May 2008 18:49:16 +0200
It would be nice if you included some practical examples on the page.
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
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
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
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
Anyway, those are my initial thoughts. Keep up the good work!
Sent through the nmap-dev mailing list
Archived at http://SecLists.Org
Re: [RFC] Zenmap search interface overhaul Fyodor (May 28)