Re: Motivation for handling massping with ultra_scan?

[Fyodor <fyodor () insecure org>]

On Fri, Jul 06, 2007 at 04:25:15PM -0600, David Fifield wrote:
> 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?

Hi David.  Yes, that sounds about right.  The idea is that host
discovery is not very different from port scanning.  For example, the
commandsd "nmap -P0 -sS -p22,80 <target net>" and "nmap -sP -PS22,80
<target net>" both do roughly the same thing.  Writing, optimizing,
and testing these scan engines is a huge amount of work.  So its best
for us to try and get it right once with ultra_scan than to try and
maintain two of them.  Also, ultra_scan() is more scalable and has
better algorithms than massping.  For exampel, you can do a SYN scan
with -p1-1024.  But you can't do -PS1-1024 because massping couldn't
handle that many probes.

> 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.)

Sounds good.  And I agree that finding a clean way to pass the probe
information in a parameter might be a bit cleaner.

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

Makes sense.

> 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.

Good point.  I had forgotten that ARP scan already uses ultra_scan().
In fact it was when adding ARP scan that I decided that everything
should move to ultra_scan().

> 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.

Right, this doesn't have to do with host discovery.  The "host pings"
collect timing information from heavily firewalled hosts to speed up
scanning.  I think the idea for "global ping" was to use pings against
one host to infer timing information about its network neighbors.  But
I decided not to implement those.

Cheers,
Fyodor

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