Capture network hops with nmap?

Hey - quick question. After searching throught the internet and news
groups, I could not locate an answer to my networking problem. Let me
quickly explain:

We have two independent networks that should not be able to communicate
with hosts on the other subnet. However, I noticed today that this is
indeed not the case anymore and I am trying to locate some sort of
"network bridge" or source that is causing this to happen.

In using nmap, I can verify that a host on the other subnet is
reachable.

Example:

nmap -sP 192.16.0.23

Starting nmap V. 3.00 ( www.insecure.org/nmap/ )
Host (192.16.0.23) appears to be up.

However, I would like to track down the inadvertant host(s)/network
devices that is allowing this to take place. I want to see the "network
hops" so to speak. I am somewhat knew to nmap, but it seems to not
display the "network hops" with the various flag options. Tcpdump
doesn't show what I am looking for either. Traceroute times out of
course.

Any ideas? Any help would be appreciated.

bubba wrote:

> Hey - quick question. After searching throught the internet and news
> groups, I could not locate an answer to my networking problem. Let me
> quickly explain:
>
> We have two independent networks that should not be able to communicate
> with hosts on the other subnet. However, I noticed today that this is
> indeed not the case anymore and I am trying to locate some sort of
> "network bridge" or source that is causing this to happen.
>
> In using nmap, I can verify that a host on the other subnet is
> reachable.
>
> Example:
>
> nmap -sP 192.16.0.23
>
> Starting nmap V. 3.00 ( www.insecure.org/nmap/ )
> Host (192.16.0.23) appears to be up.
>
> However, I would like to track down the inadvertant host(s)/network
> devices that is allowing this to take place. I want to see the "network
> hops" so to speak. I am somewhat knew to nmap, but it seems to not
> display the "network hops" with the various flag options. Tcpdump
> doesn't show what I am looking for either. Traceroute times out of
> course.
>
> Any ideas? Any help would be appreciated.

Try traceroute with the "-I" option and see if that takes care of it.

On 4 Jan 2006, in the Usenet newsgroup comp.os.linux.security, in article
<(E-Mail Removed) .com>, bubba wrote:

>We have two independent networks that should not be able to communicate
>with hosts on the other subnet. However, I noticed today that this is
>indeed not the case anymore and I am trying to locate some sort of
>"network bridge" or source that is causing this to happen.

Use tcpdump -en, and determine the source MAC address. If you then don't know
what host is using what MAC address, sniff more, and notice the _other_
traffic that is using that MAC address. (On Ethernet, packets are moved
about using MAC [Media Access Control] or "hardware" addresses, not the
IP address. In a 'tcpdump -e' output, the source hardware address is the
second field, the destination is the third field. The same line lists the
IP address of the _ultimate_ source and destination [which may not be the
same as the "local" destination on this piece of wire] as the sixth and
seventh fields.)

>In using nmap, I can verify that a host on the other subnet is
>reachable.

Before running that, start tcpdump.

>However, I would like to track down the inadvertant host(s)/network
>devices that is allowing this to take place. I want to see the "network
>hops" so to speak. I am somewhat knew to nmap, but it seems to not
>display the "network hops" with the various flag options.

Yes, that's not it's job.

>Tcpdump doesn't show what I am looking for either.

Maybe you don't know what you are looking for. The box you are using nmap
_from_ has to know how to send packets "there". So, a first glance would be
at the routing tables (/sbin/route -n). A second glance would be looking
at the packets going out and coming back (tcpdump -en). What MAC address are
they talking to? Pay attention to the ARP cache (/sbin/arp -a) as well.

>Traceroute times out of course.

Depending on your distribution, the standard LBL 'traceroute' (not the
re-written version by Olaf Kirch for Caldera, used by SuSE) has a -I
option to use 'ping' rather than the default UDP. nmap seems to be able
to ping the host. If you are not getting hop data, the intermediate steps
may be dropping ICMP Type 11. If not seeing the normal end of a UDP trace,
ICMP type 3 is being blocked somewhere. UDP may also be being blocked
somewhere.

Knowing more about the layout (addresses and netmasks) would help. _DO_
be careful about how you're munging addresses - 192.16.0.x has not been
assigned by IANA to any RIR.

Old guy