I appreciate the large number of replies and suggestions on this
thread, and ought to reply.

First, two clarifications:  (1) "hugin" is no longer Red Hat-based:
I rebuilt it from the ground up, on Debian 2.0, with shadow passwords
and xinetd.  (I'll hold comments about the new Debian until later.)  
I immediately disabled all "r" commands and all other services in 
xinetd.conf except for telnet and ftp, changed all passwords, and
have not yet issued the new ones to my users.  I also have not yet used 
incoming telnet and ftp (except anonymous), pending my securing them
against sniffing (or finding satisfactory substitutes).

I've installed Qualcomm qpopper (POP3/APOP), imapd, and poppassd,
but likewise haven't yet used them or added them to xinetd.conf.
I've also taken out just about all the stock CGI, though I haven't
seriously worked on Apache (1.3.0) yet.

Since I knew precisely what Berferd had done, and had checksums of
all original files, I didn't _have_ to rebuild, but had independent
reasons to do so.

(2) The "problem" I posed to the list was securing incoming shell access, 
and incoming ftp/POP for my shell users (against neighbour machines on
my LAN running TCP sniffers _without driving my users crazy_ (emphasis 
added).  "Securing" in this context means ensuring that no plaintext
passwords useful for break-in can be sniffed.  (Only shell users' 
passwords are particularly useful for break-in, so non-login users' 
passwords aren't an issue, here.)

Many of these folks (my users) are clueless Windows/Mac people.  I can't 
tell them all to get ssh/scp.  I do not intend to kick them off.  At 
the same time, I have a frequent need for remote access to my machine
from places that lack anything but generic Windows software facilities,
and I cannot change this.

Given the variety of "target" machines at 744 Harrison (mine, Electric
Lichen's, Richard Couture's, The CoffeeNet's, and San Francisco PC Users
Group's), all on the same LAN, it's safest to assume that any of them
might become root-compromised and running a sniffer.  Thus the "problem"
I posed.  "Firewalls" (a vague term that includes filtering routers
and a variety of different types of proxy gateways) are not an option,
for reasons I won't go into.

I envision three phases of protection (or of security breakdown, depending
on your perspective) against LAN-based attack:  (1) The cracker must get
one of your user's passwords, either by sniffing on the LAN, social
engineering, or trying a cracked password the user employed on some other
compromised machine (i.e., your user commits the common error of using the
same password on multiple systems).  (2) Once logged in as your user,
the cracker must gain root, using one of a variety of root exploits, or 
sometimes by running crack against /etc/passwd.  (Note that I now run
shadowed passwords.)  (3) You, the sysadmin, have to not detect the prior
two steps & correct them.

The "problem" I posed concerned step #1, getting one of your user passwords.
Prevent that, and you've stopped TCP-sniffing attacks, entirely.  (Yes,
I'm aware that there are other caregories.)  Step #2 I've partially 
addressed by having as few security-sensitive binaries, this time around,
as possible.  For example, hugin has no X servers/utils.  (It runs 
headless at the moment, so that's not a problem for me.)  Step #3 I
address by _immediately_ doing "cd / ; find -ls > /root/INSTALLED_FILES",
plus lists of all suid/sgid-root files, and store them offline for later
use in validating files.  Please note that this means I don't have to
rely on RPM/dpkg/etc. to validate files -- _and_ can spot new suid/sgid
files that would not be detected by package managers at all.

Yes, I know about tripwire, COPS, SATAN, chkexploits, tiger, etc.  Those 
are available _on_ hugin, in the ftp tree -- by the way.  The idea of
a "security auditing" machine has been kicked around *ix people for some
time:  The machine has no LAN connections, accepts log/auditing information 
on one serial port, and sends out warnings on another.  Difficult to
compromise -- very hardened.  Another idea that I _love_ is putting
static parts of the filesystem (including /etc.) on a SCSI drive whose
write-protect jumper is wired to the (now-useless) front-panel "turbo"
switch.  Mount the drive read-write, but frob the button to render the
drive non-writable.  Thereafter, you can temporarily make it writable
using the switch, do an edit as root, and then switch it back -- no
rebooting.

Problem #1 can also be address through hardware -- switching hubs, which
localise traffic.  One such is the 8-port, 10/100 Mbps NetGear FS508.
Suggested retail is $1,650 for the 8-port version.

Rafael:  I'm surprised that _you're_ surprised about The CoffeeNet's
LAN getting compromised.  Think about the physical situation, and you'll
see that there's an inherent security problem.

Let's discuss each of the three problematic services (that by default
use plaintext passwords) separately:

1.  REMOTE LOGIN:

S/Key rules.  I think I'll install it and mandate its use, before handing
users their new passwords.  (Thank you, Mark.)  My clueless users will 
bleat in dismay over having to use sheets of one-time passwords, but 
they'll get over it.  (I'll have to find it, somewhere.)

SSH 1.2.26 rules, too.  I just now got sshd going, which is a tremendous
relief, because I can finally answer mail in an xterm again.  (Yay!)

I _tried_ to put in ssh 2.0.8.  Misery:  Used the 1.x ssh client at The 
CoffeeNet, and got "no compatible protocols".  Rumour has it that the
free *ix package omits IDEA, Blowfish, and RSA.  That sucketh.  Further 
rumours talk about open-source alternatives that sound extremely unfinished.
I think I'll wait for the dust to settle, before trying again.

I will get a hold of the SecureCRT trial Win32 client, and the free client
from http://www.doc.ic.ac.uk/~ci2/ssh/, and check them out.  If necessary,
I'll shell out for the one from DataFellows.  My users can either follow
suit or start learning to love S/KEY.  ;->

ssh-agent, by the way (included with ssh) is very handy for top security,
as it prevents having to write security-sensitive data on the client
hard drive.  It keeps all such data in RAM, only, rather than stupidly
putting them in an .ssh directory.  This drastically reduces the 
monitoring risk, even if you ssh into your machine from a compromised
host.  I'm guessing that the only 'Doze client with even a prayer of
having such functionality is the DataFellows one.

Marc:  The reason I plan to set non-login users' default shells to
/usr/bin/passwd instead of omitting a shell entirely is that I
consider that binary trustworthy, and it's useful to allow such
users to change their passwords by just telnetting in.


2.  FILE ACCESS (ftp):

Again, I'm reluctant to turn off non-anonymous ftp entirely and tell users 
to get ssh/scp.  (I'm tempted.)  I'm tempted to even advise them to
file-attach their files to e-mail, instead of ftp-ing them in.  Non-anon
ftp is evil, but it's really tough to eliminate.

There's scp.  There's rsync -- which, by the way, you can modify (in the
Makefile) to use ssh instead of r-commands.  The new sshd 2.x includes 
something called "sftpd" -- but I'm staying away from 2.x, for now.

Dave Zarzycki asks:  "What's wrong with scp?"  For _me_, not much -- 
assuming I have a compatible client with me at the Windows-weenie sites 
I often need to get my files to.  Somewhat deficient on user amenities,
e.g., you need an ssh window open, too, to see "ls" listings.  However,
the big problem is my other users.  They need to ftp files in.

For similar reasons, I cannot ssh-encrypt the ftp command channel.

Mark Willey reminded me that S/KEY can be retrofitted to one's ftpd, too.
Thank you once more, Mark.  I may do that.

The academe betas of wu-ftpd, which I run, are very full-featured, which
is why they've been the subject of so many attacks (along with their
ubiquity).  I can deal with that by keeping up with new releases.  
Among the nice features is the ability to confine users to a specified
chroot environment.  I will consider doing that along with S/KEY.

God, I hope I don't have to do a lot of source-code work to accomplish
that:  It's tough enough contending with an unfamiliar distribution 
plus shadow passwords, plus xinetd for the first time, plus BIND 8.x
for the first time.  I have _enough_ to get used to.

Marc:  It's not necessary to recompile wu-ftpd to disallow non-anon
ftp access.  You can do this in /etc/ftp-access.

3.  POP3/APOP/IMAP

You know, if I'm able to secure telnet and ftp using S/KEY challenges,
I probably won't have to worry about this one.

The reason why I don't do POP over SSH should be obvious from the 
foregoing:  I can't impose it on unsophisticated users.  I _would_
like to find out how to mandate APOP, though.  No idea yet how to
manage the apop database -- haven't had time, yet.  Marc:  My 
understanding is that almost all current POP clients _do_ now support
APOP.  I'm willing to exclude those that don't.


MISCELLANY:

Jonathan:  Debian uses an /etc/pam.d directory, rather than /etc/pam.conf.
By default, it contains just an "other" file, with contents I don't yet
understand.  Note that "r" commands are disabled on my system.  However,
I'm tempted to modify adduser to put root-owned, non-writable, zero-length
.rhosts and .shosts files in user home directories, just in case -- and
audit them frequently.

Mark:  Debian 2.0 doesn't appear to come with proper nightly 
security-auditing reports to the root user.  <grumble>  I may have 
to set one up.  I've gotten spoiled by FreeBSD, which does it right.

I'll allow myself one additional comment on Debian 2.0 directly:  It
ships with Sendmail 8.8.8 (which is OK) -- with default open SMTP 
relaying: an act of negligence in this day and age.  Bad, bad, bad.
(Yes, I know Debian wants you to use smail, but that's beside the
point.)  The current version is 8.9.1 plus a security patch to
prune excessively long MIME headers that could be used to attack
mail clients (MUAs).

One more:  dselect's dependency-checking browbeat me into installing
a bunch of X11 libs, for packages that (if I recall correctly) needed
either X _or_ S-Lang.   As mentioned, I was carefully avoiding 
installing X servers or utilities.  This came back to haunt me, today,
when I compiled ssh:  Autoconf detected the X11 libs, concluded that
mine must be an X-supporting system, and then choked and died when
it failed to find xauth.  (I cured this by renaming the /usr/X11R6/lib
directory.)

dselect and I have not tended to get along terribly well.  This last
installation was no exception.  I could say more, but that would be
at the expense of focus, so I won't.

-- 
Cheers,
Rick Moen                      "vi is my shepherd; I shall not font."
rick (at) hugin.imat.com                          -- Psalm 0.1 beta