Home page logo

nmap-dev logo Nmap Development mailing list archives

Re: [RFC] Zenmap search interface overhaul
From: Kris Katterjohn <katterjohn () gmail com>
Date: Thu, 22 May 2008 20:43:14 -0500

Hash: SHA1

Vladimir Mitrovic wrote:
Hi all,

Hey Vladimir,

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 

Definitely :)

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.


Kris Katterjohn

Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org


Sent through the nmap-dev mailing list
Archived at http://SecLists.Org

  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]