[RFC] Zenmap search interface overhaul

[Vladimir Mitrovic <snipe714 () gmail com>]

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 == 10.20.30.40)" 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:
   "apache"

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

- All scanned Linux machines:
   "osclass:linux"

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.

Cheers,
Vladimir

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