Nmap Development mailing list archives
Re: Nmap IPC facilities?
From: Daniel Miller <bonsaiviking () gmail com>
Date: Fri, 01 Nov 2013 17:11:43 -0500
On 05/20/2013 06:47 PM, Jacek Wielemborek wrote:
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/
List, This got brought up on IRC again this week. Here are some of my thoughts:* IPC plus threading/multiprocessing could replace the current polling-based keyboard interaction within Nmap itself (1 thread scans, 1 thread for UI) * IPC could let front-ends like Zenmap do less text-processing for status updates, could be leveraged to create adaptive progress displays, etc. * If Nmap scan pipelining were implemented (todo/nmap.txt:177), IPC could allow interactive adding of scan targets. * Getting way out there, IPC could allow Nmap to run in a kind of "server mode" so that unprivileged users could run scans. Obviously certain arguments (e.g. --script) would have to be locked down. Again, a wild pie-in-the-sky variation on the theme.
On the other hand, this would be a huge undertaking. Care would have to be taken to implement a safe, portable solution. With command-line options and XML output, there's not much that other programs need to interact with Nmap, as evidenced by the many programs and language modules that already do. And it could make it more tempting for folks to violate Nmap's license regarding "derivative software," by making more interactions possible.
Your thoughts? Dan _______________________________________________ Sent through the dev mailing list http://nmap.org/mailman/listinfo/dev Archived at http://seclists.org/nmap-dev/
Current thread:
- Re: Nmap IPC facilities? Daniel Miller (Nov 01)