Nmap Development mailing list archives
Re: Motivation for handling massping with ultra_scan?
From: Fyodor <fyodor () insecure org>
Date: Wed, 11 Jul 2007 14:05:19 -0700
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
Current thread:
- Motivation for handling massping with ultra_scan? David Fifield (Jul 06)
- Re: Motivation for handling massping with ultra_scan? Fyodor (Jul 11)