From: Jesse Pollard <pollard@tomcat.admin.navo.hpc.mil>
To: joe@mathewson.co.uk, linux-kernel@vger.kernel.org
Subject: Re: [OFFTOPIC] Secure network fileserving Linux <-> Linux
Date: Wed, 5 Sep 2001 17:12:48 -0500 (CDT) [thread overview]
Message-ID: <200109052212.RAA64901@tomcat.admin.navo.hpc.mil> (raw)
In-Reply-To: <200109051913.f85JD2K01304@ambassador.mathewson.int>
Joseph Mathewson <joe@mathewson.co.uk>:
>
> Sorry to ask another annoying question so quickly after my SCSI problems,
> but
>
> Does anyone know of/use a secure network filesharing system on a Linux
> network? We currently have a room of about 10 machines, mostly Linux
> clients (some MacOS X, soon to come Sun and HP-UX boxes) and servers (all
> running Linux).
>
> For some time now, we've been using NFS for filesharing /home and have been
> extremely concerned about security. All the clients in theory run the same
> uids/gids, thanks to LDAP, but that doesn't stop someone plugging in an
> unauthorized machine and merrily destroying everyone's home directories.
>
> Apparently some work was done to Kerberize various bits of NFS, and Sun
> have a secure(r) implementation in Solaris.
>
> Does anyone know of a free (preferably easy :) way of secure Linux <->
> Linux filesharing? Apologies if that seems like a flame, maybe I've missed
> the obvious solution. (Preferably a solution that doesn't involve editing
> /etc/exports to only allow connections from specified IPs, because if
> someone was going to go to the length of destroying our data, they could
> fake that. Similarly, MAC addresses.)
Free if someone already owns a .357 Magnum.... (well, cost of ammo:)....
First answer:
Not possible.
1. You pose an unsecured network (anyone can plug in a host)
2. Physical access to the hosts (anyone could reconfigure a host)
3. No physical security (anyone can get in the room, with unauthorized
equipment).
Kerberos won't help either - The only parts of NFS that were kerberized
was the initial mount. Everything else uses filehandles/UDP. Encryption
doesn't help either - slows the entire network down too much.
Second answer:
1. Get physical security over the network. Prevent unauthorized
personnel from adding unauthorized equipment.
2. Now prevent external logical monitoring of the network with a
switched environment (prevents one host from seeing traffic
targeted at a different host).
3. Use kerberos for general user logins.
4. Do not let users have direct physical access to the hosts.
Usually, you don't have enough money invested in a user lab (which is what
it sounds like) to make it worth the effort to apply.
Third answer:
A more reasonable way is to configure the user accessable systems as
just X terminals (no MACs though) on a switched ethernet. Configure
the switch with a fixed MAC address for each target (prevents hardware
substitution). Now you can put the actual user work machines as compute
servers in a different room. The compute servers (the ones users log
into) can then use a physically isolated network (users can't plug
things into it) for NFS to a file server.
This is still more extensive (and expensive) than a small lab is usually
willing to accept.
Fourth answer:
The minimum would be to use a switched ethernet, with fixed MAC
addressing. This prevents walk-in users from substituting equipement,
and it limits the ability to sniff the network. Only packets destined
for one IP would be visible, and the switch should be able to signal
an alarm if it detects an unauthorized MAC address (as well as refuse
to work). This still allows for NFS, and a higher throughput as well
(each node can use the full bandwidth).
The fourth answer is more likely to be acceptable to management and the users
(the carrot is the higher performance). It doesn't help the reconfiguration
possiblity (booting a floppy with a different OS on a host already authorized
to use the network).
-------------------------------------------------------------------------
Jesse I Pollard, II
Email: pollard@navo.hpc.mil
Any opinions expressed are solely my own.
next prev parent reply other threads:[~2001-09-05 22:12 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-09-05 19:13 [OFFTOPIC] Secure network fileserving Linux <-> Linux Joseph Mathewson
2001-09-05 19:30 ` Fred
2001-09-05 20:17 ` Frank Schneider
2001-09-05 22:12 ` Jesse Pollard [this message]
2001-09-05 22:54 ` Dax Kelson
2001-09-06 1:17 ` John Jasen
2001-09-06 1:54 ` Kain
2001-09-06 3:37 ` Bernd Eckenfels
2001-09-06 12:39 ` Jesse Pollard
2001-09-06 9:20 ` Dominik Kubla
-- strict thread matches above, loose matches on Subject: below --
2001-09-06 12:28 Jesse Pollard
2001-09-06 16:41 ` Mike Fedyk
2001-09-06 12:46 Jesse Pollard
2001-09-07 1:53 ` Jamie Lokier
2001-09-07 15:34 Jesse Pollard
2001-09-07 15:58 ` Jamie Lokier
[not found] <linux.kernel.20010907025336.D7329@kushida.degree2.com>
2001-09-07 15:41 ` Aaron Denney
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200109052212.RAA64901@tomcat.admin.navo.hpc.mil \
--to=pollard@tomcat.admin.navo.hpc.mil \
--cc=joe@mathewson.co.uk \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox