Re: Nmap/libnetutil: route tables rework

[Hani Benhabiles <kroosec () gmail com>]

On 07/15/2012 03:47 PM, Djalal Harouni wrote:
> On Fri, Jul 13, 2012 at 04:22:59PM +0100, Hani Benhabiles wrote:
> > Hi list, Hi Djalal,
> >
> > I have been experimenting wrong values in Nmap routing table with tap
> > interfaces while using the latest svn version (r29192).
> >
> > $ route -n
> > Kernel IP routing table
> > Destination     Gateway         Genmask         Flags Metric Ref Use Iface
> > 192.168.220.0   192.168.2.2     255.255.255.0   UG    0 0        0 tap0
> > 192.168.2.0     0.0.0.0         255.255.255.0   U     0 0        0 tap0
> > 192.168.1.0     0.0.0.0         255.255.255.0   U     2 0        0 wlan0
> > 169.254.0.0     0.0.0.0         255.255.0.0     U     1000 0        0 wlan0
> > 0.0.0.0         192.168.1.1     0.0.0.0         UG    0 0        0 wlan0
> >
> > $ nmap --iflist
> >
> > Starting Nmap 6.02 ( http://nmap.org ) at 2012-07-12 11:02 CET
> > ************************INTERFACES************************
> > DEV   (SHORT) IP/MASK                      TYPE     UP MTU   MAC
> > lo    (lo)    127.0.0.1/8                  loopback up 16436
> > lo    (lo)    ::1/128                      loopback up 16436
> > eth0  (eth0)  (null)/0                     ethernet up 1500
> > 00:26:2D:92:55:8E
> > wlan0 (wlan0) 192.168.1.51/24              ethernet up 1500
> > C4:17:FE:D2:53:05
> > wlan0 (wlan0) fe80::c617:feff:fed2:5305/64 ethernet up 1500
> > C4:17:FE:D2:53:05
> > tap0  (tap0)  192.168.2.1/24               ethernet up 1500
> > 52:1A:E1:78:1B:61
> > tap0  (tap0)  fe80::501a:e1ff:fe78:1b61/64 ethernet up 1500
> > 52:1A:E1:78:1B:61
> >
> > **************************ROUTES**************************
> > DST/MASK         DEV   GATEWAY
> > 192.168.220.0/24 tap0  192.168.2.2
> > 192.168.2.0/24   wlan0
> > 192.168.1.0/24   wlan0
> > 169.254.0.0/16   wlan0
> > 0.0.0.0/0        wlan0 192.168.1.1
> >
> > yet, nmap --route-dst shows the correct interface to use (tap0) for
> > 192.168.2.0/24
> >
> > $ nmap --route-dst 192.168.2.2
> > 192.168.2.2
> > tap0 tap0 srcaddr 192.168.2.1 direct
> >
> >
> > Nmap has no problem finding the correct device for 192.168.220.0/24
> > (route manually added), but fails to do so with 192.168.2.0/24 (directly
> > connected to tap0) and puts instead wlan0.
> >
> > This is related to what you reported, although the very very long patch
> > didn't solve the issue, building from your Github repo [1] seems to fix
> > the issue. :)
> Ok, I'll try to sync the patch.
>
>
> > $ nmap --iflist
> >
> > Starting Nmap 6.02 ( http://nmap.org ) at 2012-07-12 12:46 CET
> > ************************INTERFACES************************
> > DEV   (SHORT) IP/MASK                      TYPE     UP MTU   MAC
> > lo    (lo)    127.0.0.1/8                  loopback up 16436
> > lo    (lo)    ::1/128                      loopback up 16436
> > eth0  (eth0)  (null)/0                     ethernet up 1500
> > 00:26:2D:92:55:8E
> > wlan0 (wlan0) 192.168.1.51/24              ethernet up 1500
> > C4:17:FE:D2:53:05
> > wlan0 (wlan0) fe80::c617:feff:fed2:5305/64 ethernet up 1500
> > C4:17:FE:D2:53:05
> > tap0  (tap0)  192.168.2.1/24               ethernet up 1500
> > 52:1A:E1:78:1B:61
> > tap0  (tap0)  fe80::501a:e1ff:fe78:1b61/64 ethernet up 1500
> > 52:1A:E1:78:1B:61
> >
> > **************************ROUTES**************************
> > DST/MASK         DEV   GATEWAY
> > 192.168.220.0/24 tap0  192.168.2.2
> > 192.168.2.0/24   tap0
> > 192.168.1.0/24   wlan0
> > 0.0.0.0/0        wlan0 192.168.1.1
> > ::1/128          lo
> > fe80::/64        wlan0
> > fe80::/64        tap0
> >
> > So this is a +1 for merging the work.
> >
> > But what I have been experimenting now is that in NSE, code like this:
> >
> > local sock = nmap.new_dnet()
> > sock:ip_open()
> > sock:ip_send(packet)
> >
> > would send the packet through the default route interface (for multicast
> > targets, at least) and not the one specified by the -e option.
> > I don't know if this is really related bug or is due to another issue.
> Thank you for reporting this.
>
> Are you sending at the ethernet level ? please add '--send-eth' and see.
>
>
>
> If your packets are still routed through the default route interface, then
> I can see the problem:
>
> nse_dnet.cc:ip_send()
>    => nmap_route_dst() returns 0
>
> And we jmp to the 'usesock' label using the IP layer.
>
>
> We can fix this by forcing libnetutil/netutil.cc:route_dst_generic() to
> use the interface users choose, I can't see another solution especially if
> we miss the route tables check, and this will be the case of all non
> handled IPs.
>
> At that point we can consider that users know what they want. I'll fix it
> later.
When I add --send-eth, I get a "failed to determine next hop MAC 
address" error from the ip_send() function.

Cheers,
Hani.

--
Hani Benhabiles

Twitter: https://twitter.com/#!/kroosec
Blog: http://kroosec.blogspot.com

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