mailing list archives
Re: [RFC] Zenmap search interface overhaul
From: Vladimir Mitrovic <snipe714 () gmail com>
Date: Fri, 23 May 2008 23:47:36 +0200
I agree with an implicit AND being good, but I think OR can sometimes be
very useful: "opt:v or opt:d"
Hm... this idea just popped up - how about we make the string after the
semicolon a regular expression? That way you can represent "opt:v or opt:d" as
"opt:[vd]". You still wouldn't be able to apply the OR across different
operators, but it gives you more flexibility.
What I had in mind for the search engine is sort of like a version of grep
tailored specifically for Nmap. The goal is not to be able to construct
elaborate search queries, but rather to quickly find the scan(s) that you need.
Do you plan on these being able to be combined, like "opt:d,sV", or will
they be separate like "opt:d opt:sV" ?
Both. They will yield the same results.
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 I had in mind with [ocf]ports: is that you can, for example, search for
scans which have port 22 filtered, and port 80 open - "fports:22 oports:80". I
like the idea of a "port state" operator, but we need to find a way to link it
with the "port number" operator. In what you are currently proposing, if I
specify "portstate:open,filtered port:22,80" that would mean "all scans with
ports 22 and 80 in either open or filtered state", but if I wanted to search
for hosts which explicitly have an open port 80 and filtered port 22, I
wouldn't be able to do that.
I actually like your idea more (the portstate: operator). So, what do the other
developers think about this? "portstate:open,filtered ports:22,80" or
"oports:80 fports:22"? Both, perhaps?
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?
Good point. Proposed syntax: "opt:version-intensity(9)".
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?
No, I was just referring to these operators in the Wireshark filter context. As
you can probably tell, I'm trying not to make the syntax too complex since this
is just one part of my SoC schedule, and it would be good if I don't spend most
of 12 weeks building and debugging a new SQL variant. :) On the other hand, if
you guys really think Zenmap would benefit from a more elaborate querying
engine, perhaps a more thorough design document should be specified, and then I
can focus on bringing only a portion of it to life during SoC.
So, Re: the question about relational operators - I would avoid them for now.
If you guys disagree, please let me know. (Of course, "==" is implicit in the
above example for opt:version-intensity(9).)
Sent through the nmap-dev mailing list
Archived at http://SecLists.Org