Motivation for handling massping with ultra_scan?

[David Fifield <david () bamsoftware com>]

Nmap has a function massping (in targets.cc) that does host discovery
(http://insecure.org/nmap/man/man-host-discovery.html). It is called on
a batch of targets at a time to see if they are up before the rest of
Nmap sees them. I have been tasked with removing the massping function
and recreating its functionality using ultra_scan, the main scanning
engine function.

I get the feeling that some people have known about this proposed change
since before I started the Summer of Code, so I'd like to ask their
advice. What are the reasons motivating this change? What benefits do
you hope to get out of it? What specifically does it have to do, if
different from what massping does now?

Here's my conjectured motivation for this change:
  * massping has its own packet sending engine, sniffer, grouping, and
    timing variables; ultra_scan has the same (superior?) functionality.
Benefits:
  * Reduced code complexity.
  * More uniformity in scanning.
  * Specification of port ranges (1-120), not just individual ports.
And requirements:
  * It must be possible to make default host discovery more
    comprehensive (supporting new ping types like IP protocol ping).
  * It must not continue sending probes once a host's state is known.

Do I have this right?

I've only just begun researching this. Here are my current ideas for
doing it.

Right now massping gets its instructions from its parameters (a list of
targets and a set of ping types) and from the global NmapOps structure
(the lists of ports for each scan type that supports them). I propose,
at least at first, to make the ultra_scan host discovery work the same
way, except that it will get its ping type from NmapOps also.

Instead of calling
        massping(targets, num_targets, pingtype)
you would call
        ultra_scan(targets, NULL, PING_SCAN) // Port lists from NmapOps.

(Specifying NULL for the ports argument is ugly, but that interface
issue can be worked out later. Maybe struct scan_lists could be modified
to contain all the necessary information.)

I think I'll first implement just one ping type, such as ICMP echo, to
see that it works before diving into the rest.

ultra_scan already has some support for host discovery. It handles ARP
pings and has a scan type PING_SCAN_ARP. A scan type PING_SCAN exists,
but using it causes an assertion failure. It has code for updating the
state of a host when replies are received, for example, so this is not
as big a job as I thought at first.

I created a branch for working on this at
svn://svn.insecure.org/nmap-exp/david/nmap-massping-migration. So far I
have just simplified the interface code around the relevant functions to
help me understand them.

I have one more question about some commented code in scan_engine.cc
(doAnyPings function).

  /* Next come global pings */
  /****NOT IMPLEMENTED YET *****
  if (USI->gstats->numprobes < 30 && 
      USI->gstats->lastping_sent_numprobes + 20 && 
      TIMEVAL_SUBTRACT(USI->now, USI-gstats->lastrcvd) > USI->perf.pingtime && 
      TIMEVAL_SUBTRACT(USI->now, USI-gstats->lastping_sent) > USI->perf.pingtime && 
      USI->gstats->sendOK()) {
    sendGlobalPingProbe(USI);
    } ***/

What's a global ping? I don't think it has to do with host discovery,
but I'm curious.

David

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