mailing list archives
Re: [RFC] Zenmap search interface overhaul
From: Kris Katterjohn <katterjohn () gmail com>
Date: Thu, 22 May 2008 20:43:14 -0500
-----BEGIN PGP SIGNED MESSAGE-----
Vladimir Mitrovic wrote:
The "and" operator is implicit, and I don't think we will ever need an "or"
operator. Having the "and" operator implicit makes it easier for us to parse
the string, without resorting to more advanced concepts such as syntax trees.
I agree with an implicit AND being good, but I think OR can sometimes be
very useful: "opt:v or opt:d"
It also allows us to make runtime searches while the query is being entered,
since we don't need an entire string in order to run the search. So in the
first example above, when you finish typing "opt:O" the results list is already
populated with all OS detection scans, and the subsequent date constraint is
only applied to the results list (fast!).
In Wireshark, the input box background is red when the string being entered is
illegal, and turns green when it becomes a legal string. Very cool! Also, we
can add a one second "cooldown" time - we only run a search after 1s of
keyboard inactivity (1.5s? 0.5s?). Parsing can take place on every keystroke
because it generally takes much less time than searching.
I like this idea, and 1s sounds good to me.
Sorry for the long e-mail! Now where I need most help from the community is
deciding on search keywords. The search string syntax will have to be well
defined before I start any coding, and it will probably be a mess to modify it
later. To sum up:
o "Bare" search strings (without an operator) match anything, anywhere in the
scan's output (like that "apache" example, above).
o The "and" operator is implicit
o Various fields in the scan are mapped to operators:
// operator (alias) - description
name: (n:) - Name of the scan
target: (t:) - Scan target(s)
opt: (o:) - Scan options (this includes everything in the command line,
except "nmap" and the target list)
date: (d:) - Date when scan was performed
osclass: (os:) - The detected OS
oports: (op:) - Open ports discovered in a scan
cports: (cp:) - Closed ports discovered in a scan
(I think I nailed the most important ones, but input is most appreciated!)
Do you plan on these being able to be combined, like "opt:d,sV", or will
they be separate like "opt:d opt:sV" ?
How about a generic operator for port state, rather than oports and
cports? Like "portstate:open,open|filtered". There are a lot of port
states which you would need to take into account for separate operators
(I like the ACK Scan which can give the "unfiltered" state for stateless
firewalls, for instance).
What about options which take additional arguments, like
- --version-intensity ? I may have missed it, but how would I be able to
search on the arguments passed?
Going along with the last one, I think "==", "<", ">", "<=", etc
operators would be useful, and can be used like "opt:version-intensity
== 9" or whatever. I noticed you mentioned syntax containing these
operators, but were you talking specifically about them?
I'm looking forward to discussing these ideas further.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
Sent through the nmap-dev mailing list
Archived at http://SecLists.Org