Subject: Connection problem with disconnected outside network

From: "David C. Winters" <[email-masked]>
Date: Wed, 8 Oct 1997 15:18:02 -0400 (EDT)

I need some advice on where I should start looking to solve a problem.  I
maintain a couple of clusters of Linux boxen that are used as teaching
classrooms during the day, and are open to students at night.  I'm running
Red Hat Linux's 4.2 distribution, with the 2.0.30 kernel.  The instructors'
machine in each room is running wu-ftpd 2.4.2b12 so the students can turn in
work after quizzes/exams.  The machines are on AFS and /bin/login first
talks to the AFS cell's Kerberos servers to authenticate users before 
looking at the local /etc/passwd.

During exams, we isolate the cluster(s) from the network by pulling an
Ethernet cable.  The problem is that while isolated, the students' machines
can't access the wu-ftpd server running on the instructor's machine.  The
instructor's machine is listed in all the /etc/hosts files, but "ftp class1"
is met with nothing--the ftp process simply hangs.  Control-C won't
interrupt it; we have to put it in the background with Control-Z and then
kill it.

There's no question that the hang is caused by the cluster being isolated.
If the Ethernet cable is replaced while a couple of machines are trying to
connect, they'll finish making the connection almost immediately.

My first thought was that wu-ftpd makes use of the machine's /bin/login in
order to authenticate in, even when you want to attach as "anonymous".  If
that was true, the hang could be explained as being the interval during
which /bin/login is waiting to time out against the AFS Kerberos servers
before looking at the local /etc/passwd.  I had kept the machines' original
/bin/login and dropped it in in place of the AFS-Kerberos version, with the
same result: the clients hang upon initially attaching.  I tried
substituting the original /bin/login on a couple of client machines, with
the same result.  The clients just can't make the ftp connection to the
server while the network is isolated.

What mechanism/file does wu-ftpd use to authenticate clients and establish
the connection?  I had thought that it used /bin/login, but substituting
different ones didn't change the outcome.  I really need to come up with
some way of making this work. (Having to have the network disconnected
causes a number of headaches, but that's not my decision.)  Thanks.

D.

David [email-masked], CLSA		"You are a fiend and a coward, and
Office: 3503 WeH, x86720		 you have bad breath."
					   -- Golgotha to a luser, Sep' 97

---

From: Jenice Darner <[email-masked]>
Date: Wed, 08 Oct 1997 16:18:35 -0400

David C. Winters wrote:
> the connection?

>From the O'Reilly Managing Internet Information Services:

"Two mechanisms are available for authenticating remote users; the very
common but pretty-darn-insecure 'none', and RFC 931 authentication."

the RFC 931 is a "request for comment" that needs to be run on the host
side that the user is coming from...which is not always the case. If you
look at your wu-ftp log output, the xferlog files, this action is logged
in the 16th field. A 0 denotes 'none' is being used, and a 1 denotes the
RFC 931.

With 'none' the ftpd is accepting that the host that the user is ftping
from is actually the real host name.
  
> I had thought that it used /bin/login, but substituting

Most likely, the easiest way to solve this is to install tcp/ip wrappers
and rotate the /etc/hosts.allow & /etc/hosts.deny files through a cron
entry. However...you must be very careful doing this while running
Kerberos...

The advantages to this are that you can control what kind of access
anyone gets to your network. Decide if there are time chunks that the
students can upload/download via ftp and create an appropriate
hosts.allow file, have cron put the file in place during those times.
You get a nice log of activity and all attempts to ftp outside of that
time is also logged through the wrappers and so you can track the needs
of the students/instructors. There shouldn't be a reason why you need to
disconnect any ethernet cabling.

Another good idea, since you are using Red Hat is to set up a Red Hat
firewall and filter through that. The firewall would be more powerful in
that not only tcp packets would be filtered, but udp and snmp packets
can be blocked/monitored. But that would make another machine on your
network that would need to be cared for...it's more work, but more
powerful.

-- 
--------------------
Denise Garner
FTP Administrator
Internet Operations

---

From: "David C. Winters" <[email-masked]>
Date: Tue, 14 Oct 1997 16:36:06 -0400 (EDT)

I've gotten this problem solved.  It was a name resolution thing: The ftp
server couldn't resolve the hostname/FQDN/IP of the client machines, which
was causing the hang.  It was suggested that I install named on the client
machine.  The actual solution turned out to be even simpler: /etc/hosts had
gotten corrupted and putting a new, clean copy on the machine solved
everything.  Thanks to Koos van den Hout for pointing me in this direction, 
and to everyone who responded.

D.