mailing list archives
[RFC] Zenmap search interface overhaul
From: Vladimir Mitrovic <snipe714 () gmail com>
Date: Fri, 23 May 2008 03:09:07 +0200
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:
- Search for "Apache" anywhere in the scan's output:
- Non-verbose scans on 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
- [RFC] Zenmap search interface overhaul Vladimir Mitrovic (May 23)