"The Linux Gazette...making Linux just a little more fun!"

Routing Mystery

From Faber Fedor on Mon, 06 Mar 2000

Hi there!

Got an interesting little problem for you. In my Linux class (yes, the one where I distribute your subnet answer to me from a ways back) I have four student computers on the 131.107.4.0/24 subnet. My computer is on the 131.107.2.0/24 subnet. We are not configured to use any routers. There is a router on our network, but it is on a different subnet.

Here's the interesting part: my students are able to ping and FTP to me!!! We can't figure out how or why. Even my student who is getting his Cisco certification doesn't know what's going on.

Any ideas?

-- Faber Fedor

Hmm. I can't answer the question based on the information presented here.

However I can offer some suggestions and some questions.

First I assume that the routing tables on the student machines look something like:

Kernel IP routing table
Destination   Gateway   Genmask       Flags Metric Ref    Use Iface
131.107.4.0   0.0.0.0   255.255.0.0   U     0      0    12162 eth0
127.0.0.0     0.0.0.0   255.0.0.0     U     0      0        3 lo

... that you have no default route. If you do have a default route that points to any router that knows how to get to your ...2 net then there should be no question.

It's possible that your netmasks are a bit broader than you need. (In my example above I set it as a class B mask). If that's the case then you might be seeing the effects of a proxyarp configured system that bridges the two nets. In fact there might even be a real bridge between them -- or you might be running on a VLAN, such that the two IP networks aren't truly on separate ethernet segments at all.

Basically the different netmasks could be causing these four systems to do ARPs and the network infrastructure could be supporting those (by supplying the ARP replies).

There are other possibilities. I'd suggest drawing an ASCII diagram of the network, labeling the routers and hosts on each of the segments, and footnoting all of the routing tables and ifconfig -a output for each of them.

I'd also fire up copies of 'tcpdump -n -vvv' at strategic points on these segments. You can do those in separate xterm windows, on separate VCs (virtual consoles) or using splitvt, or the new "split" command in my favorite utility --- 'screen'.

• (The 'screen' utility recently added this feature. You simply use the C-a or other 'screen' meta key with S (capital 'S') to split the screen, C-a, [Tab] to switch to other sections, and C-a, Q to make the current screen section take over the whole terminal window/screen once again).

Anyway. Using those techniques you can see what sorts of traffic are going on on these segments. You might want to use the following command to limit the volume of outout a bit:

tcpdump -n -vvv icmp

.... that limits tcpdump to looking for ICMP (internet control message protocol) packets. I'm curious if there are some sort of ICMP redirect packets floating around.

BTW tcpdump has a filtering language that allows you to use hostnames, host numbers, negation, port numbers, and service names, protocol names, and connectives like "and" and "or" and direction specifiers.

So, if you're going to view a tcpdump output on remote system you definitely want to exclude the traffic from that shell/tcpdump session as it gets to your remote terminal!

(Otherwise you'll flood your network with tcpdump relaying traffic about the traffic that it just saw from the traffic that it just relayed to you. Got it? Good!)

In other words, if you ssh from B to A and run tcpdump there, the least you should to is :

tcpdump -i eth0 -vvv -n not src port ssh and not dst port ssh

... which should get all of the traffic on that segment except for the ssh sessions. You could be more explicit if you wanted to type more complex filtering expressions.

Of course, in a busy college lab you might have to play with much more selective filters to drown out all the traffic that you know is unrelated to your question.

tcpdump is the premier tool for learning about this sort of thing. Showing you students of this will be very useful to their eventual careers. (Note: This sniffer is also the most innocuous of them all. It normally only captures headers, and it only displays payload data in hex. So this can't be used to "accidentally" capture people's passwords or confidential data over your LAN segments.

I think it's also of some value to show them less innocuous tools that are readily available. Show them copies of sniffit (http://www.freshmeat.net/appindex/1998/07/15/900550583.html), and hunt (http://www.freshmeat.net/appindex/1998/12/03/912689682.html).

Those are tools that make it trivially easy to sniff a network, steal passwords, hijack peoples telnet and rlogin sessions, read their e-mail "over their shoulder" across the network and generally be highly unethical.

Fast ethernet switches may offer some obscurity from this problem since every data frame isn't re-broadcast across every wire in a switched network. However, this should not be relied upon. The only solution to sniffing problem is the ubiquitous use of cryptography (ssh, Kerberos, SSL, etc).

If your students are going to be professional network administrators and engineers --- they might as well learn this lesson sooner than later.

Copyright © 2000, James T. Dennis
Published in The Linux Gazette Issue 52 April 2000

HTML transformation by Heather Stern of Tuxtops, Inc., http://www.tuxtops.com/

					1	2	3	4
				5	6	7	8	9
10	11	12	13	14	15	16	17
18	19	20	21	22	23	24