Adding new NSE discovered targets to Nmap

[Djalal Harouni <tixxdz () gmail com>]

Hi list,

I've created a new NSE library 'target.lua' which will handle adding new
discovered targets to Nmap. This feature is only available for NSE
scripts (prerule, hostrule and portrule ones, postrule scripts can't
add targets).

First this is the NSEdoc of the target.lua library:
---
-- Utility functions to add new discovered targets to Nmap scan queue.
--
-- The library lets scripts to add new discovered targets to Nmap scan
-- queue. Only scripts that run in the script pre-scanning phase
-- (prerule) and the script scanning one (hostrule and portrule) are
-- able to add new targets, post-scanning (postrule) can't do that.

-- @args newtargets  If specified, lets NSE scripts to add new targets.

-- This is a special variable and it is a global one, so
-- scripts can check it to see if adding targets is allowed,
-- before calling <code>target.add()</code> function.
-- It will be set to true if the script argument 
-- <code>newtargets</code> was specified.
ALLOW_NEW_TARGETS = false


--- Adds the passed arguments to the Nmap scan queue.
--
-- Only prerule, portrule and hostrule scripts can add new targets.
--
-- @param targets  A variable number of targets. Target is a
-- string that represents an IP or a Hostname. If this function
-- is called without an argument then it will perform a check to
-- test if it can add new targets to the scan queue.
-- @usage
-- local status, err = target.add("192.168.1.1")
-- local status, err = target.add("192.168.1.1","192.168.1.2",...)
-- local status, err = target.add("scanme.nmap.org","192.168.1.1",...)
-- local status, err = target.add(unpack(array_of_targets))
-- local status, err = target.add()
-- @return True if it has been able to add a minimum one target, or
--         False on failures and if no targets were added.
-- @return String error message in case of failures.
add = function (...)
    ...
end

To test the feature, you can checkout nmap-exp/djalal/nmap-add-targets


Comments and opinions are welcome:
* First consider that Nmap scanned targets are not saved, and when we
add this feature some parts of the following plan will change.

* Currently targets are strings, they can be IPs, hostnames and
networks. I think that for the moment we should consider target
filtering and parsing in the target.add() function, to only allow
IPs and perhaps hostnames and to avoid other network targets specification
until we have a better solution to filter all Nmap scanned targets.
e.g: avoid this situtation:
    target.add("192.168.0.1/30")
    target.add("192.168.0.1/29")
with the current implementation we'll scan the same targets twice
or perhaps more if they are specified as Nmap targets, but we can't add
the *same* *string* twice:
    target.add("192.168.0.1/30")
    target.add("192.168.0.1/30")
only one string will be added, so these hosts will be scanned only a
one time if they are not specified as Nmap targets.

Filtering and parsing network blocks on NSE will take lot of memory, and
since Nmap handles this perfectly we should let Nmap do the job for us.


* If we took scanme.nmap.org as an example:
scanme.nmap.org == 64.13.134.52
    target.add("scanme.nmap.org","64.13.134.52")
this code will add two new targets. Nmap will do the DNS lookup for us
and will scan the same IP twice, so should we add NSE DNS lookup
functions (Kris has already done some part of it, in his resolveall
prerule script [1]) and do the DNS lookup in target.add() function ?
Personally I prefer to allow only IPs targets for the moment and when we
have a better target filtering engine that checks for already processed
IPv4/IPv6 in TargetGroup::parse_expr() and nexthost() functions, then we
should allow hostnames and different network specifications that are
supported by Nmap, and we could even use a vector to store the new added
targets instead of a tree so it will be easy to read and remove the
targets from the new_targets_cache vector.
Any new NSE valid IP checking should go in the ipOps.lua library.

To sum it up: I'm for allowing only new IPs for the moment and make
adding new hostnames and networks targets future features, what do you
think ?


Other points:
* Should we make target filtering a default behaviour and add an Nmap
option to disable it like: "--no-targetfilter" or disable it by default
and add an option to enable it ? Scanning the duplicate IPs can also be
useful if we want to scan http virtual hosts.

* Should we create a new Nmap option "--max-newtargets <num hosts>"
that will set the maximum of the new added targets ? it will only be
used if the user specified it. --max-newtargets=0 means to not allow
any addition of new targets even if the script argument "newtargets" is
specified. Of course with this we'll give *more* *control* to the user,
but in the other hand he is supposed to do network exploration and if
set then it will for sure ignore some new discovered targets (hidden
IPs!!). I prefer to add support for this option and let the user take
his responsability. Your opinion ?


N.B: currently new NSE Added targets are processed like targets that are
from:
cmdline target specification, or iL <inputfilename> or -iR <num hosts>.

Thx.

[1] http://seclists.org/nmap-dev/2010/q3/327

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