Re: Nmap/libnetutil: route tables rework

[Hani Benhabiles <kroosec () gmail com>]

On 07/09/2012 02:34 PM, Djalal Harouni wrote:
> On Sun, Jul 01, 2012 at 10:02:51PM +0100, Djalal Harouni wrote:
> [...]
> > David,
> >
> > I've attached a new patch which fixes the ppp connection issue [1] + some
> > libdnet fixes...
> >
> > This will also handle some special situations like: inside OpenVZ
> > containers where all traffic is routed through a virtual device.
> >
> > David I'm on a trip, so perhaps I'll not be able to reply.
> >
> >
> > You can also find the branch at:
> > https://github.com/tixxdz/nmap/tree/nmap-routes
> >
> > [1] http://seclists.org/nmap-dev/2012/q3/3
> Attached a patch to clear libdnet route entries.
>
> Thanks.
>
>
> _______________________________________________
> Sent through the nmap-dev mailing list
> http://cgi.insecure.org/mailman/listinfo/nmap-dev
> Archived at http://seclists.org/nmap-dev/
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. :)

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

[1] https://github.com/tixxdz/nmap/tree/nmap-routes

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/