Re: [RFC] Zenmap search interface overhaul

[Vladimir Mitrovic <snipe714 () gmail com>]

Hi Kris,

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

Thanks,
Vladimir

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