Home page logo

nmap-dev logo Nmap Development mailing list archives

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

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 appreciated!)

I'm looking forward to discussing these ideas further.


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 ]