Home page logo

nmap-dev logo Nmap Development mailing list archives

Re: [RFC] Zenmap search interface overhaul
From: Vladimir Mitrovic <snipe714 () gmail com>
Date: Fri, 23 May 2008 03:22:01 +0200

DePriest, Jason R. wrote:
fports: (fp:) - Filtered ports discovered in scan

Oh, right... forgot about that one, thanks.

How about something for services that nmap was not able to properly
discover (when it just sticks a question mark at the end of it) or
operating systems that it was not able to fingerprint.

Good point. Something like "service:?", perhaps?

I've CC'ed this e-mail to the mailing list.



On Thu, May 22, 2008 at 8:09 PM, Vladimir Mitrovic <> wrote:
Hi all,

Zenmap is due for a major facelift during this year's Summer of Code, and
the Search Window is currently number one on my TODO list. I've compiled
some of my ideas here, and it would be great if I could get some input from
you guys.

If you bring up the search tool in Zenmap, you can see that it's very
crowded. Also, the search results list is smaller than the search interface,
which is also not that great. So, I thought about how we can simplify the
interface, but bring more power to the actual search capabilities, and I
thought - Wireshark's filtering engine. It's lean and clean, and you can
contain the whole criteria in a single string. You also have the option of
building the filter string with the help of GUI, so novice users aren't left
behind. So, in light of these ideas, I've freshened up my Inkscape-fu and
produced a quick mockup, attached.

While in Wireshark you make queries like "!(ip.addr ==" or
"tcp.port == 80 || udp.port == 80", I don't think a Zenmap user will ever
need searches as those. After all, our Zenmapper only wants to find a scan
and open it, while a filter is more complex because it's "always on".

In the mockup, you can see an example search for all ping scans. I have
(over)simplified the GUI intentionally, so we can brainstorm on any needed
additions (but I'd keep them at a bare minimum). So, regular search strings
would look something like:

- OS detection scans within the last week:
  "opt:O date:-7"

- Search for "Apache" anywhere in the scan's output:

- Non-verbose scans on scanme.nmap.org:
  "opt:!v target:scanme.nmap.org"

- All scanned Linux machines:

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

OK, so the 1337 guy is happy, he can quickly find what he needs. What about
the other guy? The "Expressions..." button takes you to a popup window where
you can click your way to the search string you need. I didn't draw a
mockup, but it will basically add a visual representation/helper similar to
the existing search GUI, but without the tabs and much simpler. At the
bottom of our window, a generated search string will be displayed. That way,
as the user enters his criteria into the GUI, he can see his search string
being built in runtime - what better way for him to learn to do it by hand
in the future?

The "?" button will pop up a tooltip with a brief reference of all keywords
and their meanings, so that you don't have to go to the Expressions window
and waste time entering gibberish into a field just to find out what the
generated string at the bottom produces.

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

I'm looking forward to discussing these ideas further.


Sent through the nmap-dev mailing list
Archived at http://SecLists.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 ]