Nmap IPC facilities?

[Jacek Wielemborek <wielemborekj1 () gmail com>]

Hi,

I recently had an idea and I thought it'd be nice to get some feedback
from you guys. On the #nmap IRC channel I was discussing introducing
better facilities to interact with Nmap scanning processes. At first,
I was thinking of ways to add more interactivity to the program, like
a keystroke to pause the current task or skip one of hosts.

I found out that there used to be "interactive mode" in Nmap, removed
by David in 2010 because noone used it. I browsed the code and figured
that the use case of this feature was different from the one I am
thinking of - instead of hiding the nmap arguments in process list, my
goal would be more user friendliness.

Obviously, it would be easy to add so many keystrokes up to the point
when it's clear Nmap got too bloated and the feature set doesn't
belong there. On the other hand, this kind of functionality could be
useful while doing large-scale non-automated scans.

At the moment, if I understand the concept of Zenmap correctly, "the
right way" to interact with Nmap process is to pass the command line
arguments and sniff for the standard output. That means that in order
to tweak some scan settings, one would have to keep re-launching Nmap
process with separate runtime parameters.

Listening and parsing the standard output feels quite hacky and means
that in order to interface with Nmap, there's quite a lot of code that
needs to be written to make sure that the "client" application
wouldn't crash on edge cases. Also, imagine implementing a progress
bar in Zenmap - with current codebase, I guess it would involve
sending return key to the Nmap's standard input and reading the
outcome. This approach feels
kludgy to me and I believe that not only the GUI frontend would
benefit from getting a separate interface.

My idea is to introduce an Nmap IPC pipeline that would allow to read
the scan state and manipulate it, for example by changing the timings.
My first thought was to use a library like a DBUS, but that was
frowned upon on IRC (IIRC, DBUS was "the worst option possible" ;)).
Then I thought of TCP/IP - adding an Nmap "server mode" which would
create a socket used to control Nmap once a scan was started. The
advantage of such approach would be that the user could easily run
Zenmap on a box different than the one performing the scanning, which
would allow to start run scans remotely.

Of course this could lead to interesting applications way beyond the
frontend capabilities. If implemented properly, such functionality
would  make it easier to set up a port scanning environment with a
designated server that listens for jobs and lets its users read the
results. (this kind of reminds me of Nessus, but when I was testing
its GUI functionality, it felt horrible compared to zenmap)

What do you think about it?

Jacek Wielemborek
_______________________________________________
Sent through the dev mailing list
http://nmap.org/mailman/listinfo/dev
Archived at http://seclists.org/nmap-dev/