Re: Can not use Syn-scan or any root scan with MacOSX 10.4.11, Nmap 4.76

[David Fifield <david () bamsoftware com>]

On Sat, Nov 29, 2008 at 12:16:43AM -0500, Myshkin LeVine wrote:
>              I am using Nmap v4.76 on MacOSX 10.4.11. I searched the  
> mailing-list archives and found several reports of my kind of problem, 
> but did not find any solution. When running nmap I cannot use the 
> Syn-scan nor run any scan as root. When I try the Syn-scan I get an error 
> message: "WARNING: Unable to find appropriate interface for system route 
> to 10.5.67.1" That address is my router/DSL modem. I can however run 
> scans as root when scanning localhost.
>             After reading all the related posts I see that  
> troubleshooters will ask for the output of both nmap --iflist & ifconfig 
> -a. I have seen other posters offer also the output of netstat -rn so 
> below is the output of all 3 of those commands:

Thanks for this thorough report. I think I see what is going on. Nmap is
trying to figure out which interface each route belongs to. It does this
by matching up a route's gateway address with the address and netmask
assigned to each interface. That's this code in tcpip.cc:

  for(i = 0; i < dcrn->numifaces; i++) {
    sin = (struct sockaddr_in *) &dcrn->ifaces[i].addr;
    mask = htonl((unsigned long) (0-1) << (32 - dcrn->ifaces[i].netmask_bits));
    if ((sin->sin_addr.s_addr & mask) == (entry->route_gw.addr_ip & mask)) {
      dcrn->routes[dcrn->numroutes].device = &dcrn->ifaces[i];
      break;
    } 
  }
  if (i == dcrn->numifaces) {
    error("WARNING: Unable to find appropriate interface for system route to %s", addr_ntoa(&entry->route_gw));
    return 0;
  }

Your interfaces are

> DEV  (SHORT) IP/MASK            TYPE        UP MAC
> lo0  (lo0)   127.0.0.1/8        loopback    up
> ppp0 (ppp0)  141.153.157.101/16 point2point up

And your routes (reordered) are

> 10.5.67.1          141.153.157.101    UH          8        0   ppp0
> 127                127.0.0.1          UCS         0        0    lo0
> 127.0.0.1          127.0.0.1          UH          9   239717    lo0
> default            10.5.67.1          UGSc        7       16   ppp0
> 141.153            ppp0               USc         0        0   ppp0

There is no trouble with the first three routes because the addresses
141.153.157.101 and 127.0.0.1 match the IP/mask of an interface. But the
default route has a gateway address that doesn't match the IP/mask of
any interface. That explains the warnings and why that route doesn't
appear in Nmap's list of routes:

> WARNING: Unable to find appropriate interface for system route to 10.5.67.1
> **************************ROUTES**************************
> DST/MASK     DEV  GATEWAY
> 10.5.67.1/32 ppp0 141.153.157.101
> 127.0.0.1/32 lo0  127.0.0.1
> 127.0.0.0/8  lo0  127.0.0.1

(I don't know why the 141.153 route doesn't show up; maybe libdnet is
not reporting it. I don't think that's the cause of the problem.)

The trick is that while the default route can't be directly matched to
an interface, it goes through another route associated with ppp0. So it
seems we need more than a one-step matching of routes to interfaces.
Each route also has to look at other routes to see if it can pick up an
interface through one of them.

A way to do this would be to run route_loop on collect_dnet_routes as
usual, then do a postprocessing step. For every route that doesn't have
an interface, loop through the list of routes and try to find one whose
destination address is the same as the unknown interface's gateway
address. If it is found, assign that interface to the gateway address.
Do this n - 1 times (n is the number of routes) or until all routes have
an interface. If, at the end of this process, a route remains without
an assigned interface, then print the "Unable to find appropriate
interface" warning.

Is anyone willing to try implementing this algorithm? It would go after
the call to route_loop at line 3162 in tcpip.cc. It should only be about
a dozen lines. If not, I'll work on it some time.

David Fifield

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