[Beowulf] CLuster - Mpich - tstmachines - Heeelp !!!!!!!!

[Robert G. Brown]

On Wed, 19 Jul 2006, Geoff Jacobs wrote:

> Robert G. Brown wrote:
>
>> I'm waiting with great interest to see if "keyrings" make any
>> difference. In principle they protect your plaintext keys, but of course
>> that is at the expense of having to type a password to get at them.
>> Which in turn means that when somebody gets your account they get them.
> I was just thinking, the problem may be worse than we are stating, even
> if you are running ssh.
...
> How many howtos recommend exporting home directories via NFS? Or images
> of home directories via TFTP? In both cases, you're going to have
> private keys transmitted in the clear. The only security left would be
> the password encrypting your private key.

Exactly.  Except that nowadays nobody uses hubs anymore, and switches
don't permit snooping point to point connections so if you control
promiscuous access at both ends of a LAN you're sort of OK.  Except that
nowadays everybody has wireless networks, that can be snooped at will if
you are using no encryption or only WEP (a.k.a. "no encryption" for all
practical purposes).  Except that most people don't export NFS over
wireless, and smart people who care about this sort of thing don't use
or let their friends use WEP, they use WPA, which cannot easily be
snooped.  Again.  And so it goes, round and round the security circle...

If you are using NFS, though, yes, you probably still have SOME problems
although it isn't as bad as you might think.  At one point in my ignoble
past I had (for purely noble purposes, given that I already had root
privileges) several rootkits seized from various successful cracking
enterprises around campus (not into our own network, thankfully).  One
had, in addition to ypx and various race tools that no longer work
(thankfully) a little application called something pithy like "nfs" that
permitted one to spoof pretty much any NFS server on a LAN into
permitting a mount of pretty much any filesystem it exported, warping
into pretty much any UID you liked -- from userspace.

In fact, I probably still have the source (since I don't throw stuff
like that away) although it hasn't been built for years and I don't
think it still works, I think that they finally got around to fixing the
bugs it exploited a decade or so ago.  That kind of thing is why
sysadmins even now tend to block port 2049 at their LAN boundaries and
get grey hair, because tools like this (whether or not they require root
privileges to run) make it really EASY to read or write files that are
700 rgb or 700 root on your NFS space, which in turn makes it SO easy to
boost to root pretty much anywhere, with patience and a penchant for
taking risks.

At least, one HOPES that NFS is more secure now than it was back then --
I think now you have to be able to use at least one privileged port to
be able to make an NFS mount (requiring root) but...hmmm, yes, I DO
still have the source, lessee, hack hack hack wrong prototypes grumble
grumble hack hack, there, builds with only a bit of complaint about
gets() (ha!), try to mount from userspace on my home LAN...  no, looks
like I can't do it, at least without further tweaking, at least with
this ancient bit of rootkit.  So maybe NFS is "secure enough" these days
on a point to point switched LAN as long as any old user isn't able to
access promiscuous mode on its endpoints or across a WPA-secured WLAN.

tftp, now, that also used to be ANOTHER bleeding wound of a problem,
mostly because people who used it usually installed it incorrectly so
that anybody in the universe could grab e.g. /etc/passwd, /etc/shadow,
whatever, and then could spend the next day or two running crack and
determining that yes, you DO have complete idiots on your network who
use the name of their cat (fluffy) as a password.  I hadn't really
thought about it being a problem these days (and there are all sorts of
things preventing fluffy passwords, or at least issuing Dire Warnings
should you try to set one), but yes (sigh) I suppose it is (for
different reasons).

Basically, I believe that the host authentication model for both tftp
and nfs as they are generally deployed are pretty weak.  AFAIK, if a
host sends a server a packet having an IP number that is presumed to be
trusted that says "gimme a mount" or "gimme a file", well, most servers
will go ahead and give it the mount or file.  What else can it do?
These services STILL have nothing approximating a private key/public key
handshake and rely on what they see in very ordinary packets to grant or
withhold privileges.  Directory services (LDAP, NIS) are also
notoriously easy to race or spoof if somebody is inside your LAN
boundary with a fast(er) machine than your server(s).

This makes LAN management easy, of course.  If you are installing a new
client, you can just ifconfig its network up so that it has the right
(trusted) IP number and as root mount the LAN home directories and so on
and be ready to go.  Ditto for more complex stuff -- PXE, DHCP, TFTP and
diskless boot and install, all easy easy easy (in an expert-friendly
sort of way, of course:-).

Leaving you still amazingly vulnerable to John U Cracker and his Amazing
Laptop of Doom in many environments... IF that laptop can actually hook
into the wired LAN.  I mean, nowadays one can even fairly trivially
change your MAC address, so not even MAC based host
filtering/authentication is sacrosanct.  There is no limit to the Evil
that John Q Can Do once he is inside the physical boundaries of your LAN
snapped into an unmanaged port that can reach your server without
interference or molestation, although he may well leave footprints on
system logs while he is doing it.  Since the U stands for Uber, he may
well NOT leave footprints -- he may be there already, grinding away.

However, security is no longer my hobby the way it once was -- lots of
folks on list are likely more up to date on what is currently
exploitable, what they are paranoid about on their well-managed LANS
(the exploits that they know exist and that they can't really do
anything about except keep the sucker rod and dumpster full of broken
glass handy:-).  There have perty much always been at least a few of
those, and they are one of the reasons that sysadmins have been known to
drink heavily and visit their 7-11 for cocaine from the shelves (cocaine
from the shelves?  still trying to follow this metaphor, hmmm).

Of course ATTEMPTING a lot of these exploits and FAILING often leaves
big, nasty wet footprints all over the system logs -- stuff like:

Jul 20 01:49:23 uriel rpc.mountd: refused mount request from
   lilith.rgb.private.net for /home/rgb (/home): illegal port 32810 
Jul 20 01:50:11 uriel rpc.mountd: bad path in mount request from
   192.168.1.129: "rgb"

Professionals actually READ the systems logs looking for slime (or use
automated tools to winnow out the 1 KB of slime from the 1 MB of cheery
"Hi there, I'm, dhpcd and yes, I'm functioning..." and read just
that).

We have very professional sysadmins.  That is why I try things like this
in my HOME LAN instead of at Duke.  Our sysadmin in physics doesn't use
a sucker rod -- he keeps a hammer in his office.  One with MY NAME ON
IT.  No kidding.  No, silly beanie, not for THAT reason -- because it
happens (by strange chance) to be my hammer.  Long story.  Anyway, I'm
allergic to broken glass...

Now, I believe that IPSec is coming to save the day here and add a
shared secret handshake to the mount process (probably in such a way
that it will slow NFS performance to a crawl while heating up server
CPUs to the point where they melt down like Chernobyl, but hey, can't
have your cake and eat it too:-).  Outside of that, I think that the
only "efficient" solution is to use strictly managed networks and simply
ignore hosts that connect to a LAN port without port by port, host by
host configuration.

That still isn't QUITE secure -- port management often relies on e.g.
MAC address matches to decide what to pass, MAC addresses of connected
workstations can easily be determined from userspace, and MAC addresses
are no longer the hardwired things they never really were even back when
they were supposed to be.  So John Uber Cracker could still in PRINCIPLE
disconnect a legitimate host (where he had no root privileges or easy
way to boost same) and plug his LOD in and spoof both MAC and IP
addresses to achieve a least client-level access and root at the same
time (where yes, he could su to all users and read their .ssh
directories, take their keys, plug in self-erasing password trap
trojans, and a day later own the Universe -- or at least all the hosts
in your LAN).  Presuming that you don't read your logs, notice the host
reboot, autoscan for self-erasing password trap trojans, or otherwise
twig, in which case JUC is likely instead to find himself bruised and
bleeding in a glass-filled dumpster with his LOD smashed into itty bitty
pieces by his side...

    rgb

-- 
Robert G. Brown	                       http://www.phy.duke.edu/~rgb/
Duke University Dept. of Physics, Box 90305
Durham, N.C. 27708-0305
Phone: 1-919-660-2567  Fax: 919-660-2525     email:rgb at phy.duke.edu