Status Report for Djalal - #15 of 16

[Djalal Harouni <tixxdz () gmail com>]

Status Report #15 of 16

Hi all,

As you know I'm working on a new feature that will let NSE scripts to
add new discovered targets to Nmap scan queue. The big issue is to check
for duplicate targets to avoid runaway scans, and since in the current
implementation of Nmap there are no checks for duplicate scanned targets,
adding this feature will *drastically change* how Nmap handles targets and
can consume lot of memory, so this feature of checking all targets
(all targets: targets scanned by Nmap and new pending ones) needs more
time and a better complexe data structure to handle and save them.
N.B.: We must also note that some times it is useful to scan duplicate
IPs to discover http vhosts.

The current task is to get the logic of saving new discovered targets
working, and for this we use a simple std::map tree (this will filter
new added duplicate targets, if we do not do that we'll hit a runaway
scan for *sure*, yes imagine a scanned target that will add it self
as a new discovered target one => DoS), but we should not forget that it
needs a better data structure handling.


Some implementation details:
----------------------------
* Only NSE scripts can add new targets. The code is available if Nmap
was compiled with Lua support.
To add traceroute hops to the scan queue we'll need a new NSE script
that will add them (hops are saved in the Target object). The script can
have some arguments to let the user to specify which or how many hop
to scan.

* The feature will be activated by --script-args "newtargets". Perhaps
we'll add an Nmap alias option ("--script-newtargets" or "-iA" or "-iC"
or "-iS").

* A new NSE library target.lua which will be used to add targets to Nmap
scan queue.
  - target.add() must be used to add targets, this function can take
    several arguments: targets and lists of target values as arrays.
    (target is a string: IP or hostname).
    We can also call it without an argument to check if we are able to
    add new discovered targets to the scan queue.
  - target.ALLOW_NEW_TARGETS is a special *global* variable that can be
        used by scripts to check if the script argument "newtargets" was
        used (--script-args "newtargets"). However the current
        implementation of target.add() will also check this variable and
        make it sure that scripts do not add targets. We need to take a
        dicision on this: do the check in the library or let scripts check
        it.

e.g of a script adding new targets:

  target = require 'target'
  ...
  if target.ALLOW_NEW_TARGETS then
    target.add("10.0.0.1","10.0.0.2","10.0.0.3")
    target.add({"10.0.1.1","10.0.1.2",...},"10.0.1.30",...)
  end


This is not implemented, and it needs more discussion:
* Perhaps we should create an additional Nmap core option
--max-new-targets to force the max of new added targets, perhaps we
should not set a default value, and let the user decide, like the -iR
option.


Accomplishments:

* Fixed Script Pre-scanning and Post-scanning bugs and compiler warnings.
* Fixed some Script Pre-scanning and Post-scanning code documentation.
* Merged the Script Pre-scanning and Post-scanning features.
* Fixed The NSE Script Scanning phases documentation.
* Updated the add targets proposal.
* Added the NewTargets class support, to handle and to store new
  NSE discovered targets. This code will be compiled if Nmap is compiled
  with Lua support.
* Added NSE function nmap.add_targets().
* Added a new NSE target.lua library, which will be used to add targets.
* Added a check for the --script-args "newtargets" argument.
* Ajusted some debug output.

Priorities:

* Finish the "Add new targets to Nmap" feature.
* Post more details about the feature to nmap-dev.
* Clean and fix the code.
* Write documentation for this feature.
* Merge the NSE Script Scanning phases documentation.
* Update Nmap book to show the new Script Scanning phase documentation.
* Work on dns-service-discovery script when time permits (add a prerule
support).

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