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
Received on Jul 11 2007
Intro
