Re: [OFFTOPIC] Secure network fileserving Linux <-> Linux

Re: [OFFTOPIC] Secure network fileserving Linux <-> Linux

[Jesse Pollard]

> On Wed, 5 Sep 2001, Jesse Pollard wrote:
> 
> > 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).
> 
> Both your Third and Fouth answer depend on MAC addresses locked down on
> the switch.  This is fatally flawed since (as the orginal poster pointed
> out), changing your MAC address to match the expected MAC is quite easy.
> 
> # ifconfig eth0 ether A0:B1:C2:D3:E4:F4
> 
> How can you get the expected MAC address?
> 
> 1. Walk up to an allowed computer, unplug computer from wall jack.  Plug
> cross over cable from allowed computer into laptop.  Sniff MAC address
> from frames generated by allowed computer.

or plug in a small hub and sniff valid traffic.

> 	- Reconfigure your eth0 with allowed MAC, plug into network
> 
> 2. Walk up to an allowed computer, unplug computer from wall jack.  Plug
> into wall jack and sniff destination MAC address on frames sent by switch.
> 
> 	- Reconfigure your eth0 with allowed MAC
> 
> 
> One solution is to require layer 2 authentication from the switch, before
> it fowards frames on that port.  Before DHCP.  This process could be
> repeated every time link is lost.  The switch uses RADIUS off of some
> authentication server.

Good point. I didn't think of that one - my environment doesn't require it
(physical security is good here).

> The 802.11x standard(s) implement this for wireless networks, it can also
> be used on wired networks (the specs allow it at least).

I wouldn't want to use 802.11 for much of anything where security is important.
It's just too easy to crack. You also need good physical and OS security
to implement VPNs over wireless.

-------------------------------------------------------------------------
Jesse I Pollard, II
Email: pollard@navo.hpc.mil

Any opinions expressed are solely my own.

Re: [OFFTOPIC] Secure network fileserving Linux <-> Linux

[Mike Fedyk]

On Thu, Sep 06, 2001 at 07:28:59AM -0500, Jesse Pollard wrote:
> > The 802.11x standard(s) implement this for wireless networks, it can also
> > be used on wired networks (the specs allow it at least).
> 
> I wouldn't want to use 802.11 for much of anything where security is important.
> It's just too easy to crack. You also need good physical and OS security
> to implement VPNs over wireless.

That would be 802.11 over a wired network, not wireless....

Re: [OFFTOPIC] Secure network fileserving Linux <-> Linux

[Aaron Denney]

Jamie Lokier <lk@tantalophile.demon.co.uk> wrote:
> Jesse Pollard wrote:
> > > 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.
> > 
> > I disagree! First of all you can always use NFS over TCP, so much for
> > "every thing else uses filehandles/UDP". (No that this improves security,
> > but it can improve reliability!)
> 
> It can improve security if you use NFS over TCP over SSL...
> 
> That may be easier to configure than IPSec in some environments.

take a look at sfs: http://www.fs.net/


-- 
Aaron Denney
-><-

Re: [OFFTOPIC] Secure network fileserving Linux <-> Linux

[Jesse Pollard]

Jamie Lokier <lk@tantalophile.demon.co.uk>:
> Jesse Pollard wrote:
> > > 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.
> > 
> > I disagree! First of all you can always use NFS over TCP, so much for
> > "every thing else uses filehandles/UDP". (No that this improves security,
> > but it can improve reliability!)
> 
> It can improve security if you use NFS over TCP over SSL...
> 
> That may be easier to configure than IPSec in some environments.

I've never seen that used. I assume the procedure is something like:

1. login on client (requires home directory be local)
2. ssh to server (local window for password)
3. user mode mount to another directory (assuming not mounting working
   directory - marked busy, though that might be allowed)
4. use another window for local usage.

	mountd port has to be redirected
	nfsd port(s) have to be redirected (I think, might not apply to server)
	biod port(s) have to be redirected
	lockd port(s) have to be redirected (unless nolocking)
	statd port(s) have to be redirected (not sure)

And only a single user per host (not unreasonable).

Would it also work for windows/Macs?

-------------------------------------------------------------------------
Jesse I Pollard, II
Email: pollard@navo.hpc.mil

Any opinions expressed are solely my own.

Re: [OFFTOPIC] Secure network fileserving Linux <-> Linux

[Jamie Lokier]

Jesse Pollard wrote:
> > It can improve security if you use NFS over TCP over SSL...
> > That may be easier to configure than IPSec in some environments.
> 
> I've never seen that used. I assume the procedure is something like:
> 
> 1. login on client (requires home directory be local)
> 2. ssh to server (local window for password)

Or you can use the `openssl' program.

> 3. user mode mount to another directory (assuming not mounting working
>    directory - marked busy, though that might be allowed)
> 4. use another window for local usage.
> 
> 	mountd port has to be redirected
> 	nfsd port(s) have to be redirected (I think, might not apply to server)

Really, the only critical one if you're worried about people
reading/writing your data is nfsd.  mountd is second most important, but
not really if you're using the user-space NFS server.

> 	biod port(s) have to be redirected

No need for biod.

> 	lockd port(s) have to be redirected (unless nolocking)
> 	statd port(s) have to be redirected (not sure)

I'm not sure about statd either.  It would be safest to run this over SSL.

> And only a single user per host (not unreasonable).

You could have multiple users per host, with appropriate funky mounts so
each user can only access their own secure mounts.  Either mount in a
subdirectory of a user-private directory, or use the Plan9-style
per-user mount trees (experimental patches from Al Viro).

> Would it also work for windows/Macs?

If you put a Linux box in between to implement the SSL part :-)

It's pretty complicated, but then even a simple port-based firewall is
rather complicated with NFS.

Now, if somebody were to fix the portmapper and RPC libraries to use
sensible fixed ports, so we could sensibly firewall RPC services, they
might be tempted to implement automatic SSL tunnelling while they're
there...

-- Jamie

Re: [OFFTOPIC] Secure network fileserving Linux <-> Linux

[Jesse Pollard]

Dominik Kubla <kubla@sciobyte.de>:
On Wed, Sep 05, 2001 at 05:12:48PM -0500, Jesse Pollard wrote:
> 
> 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.

I disagree! First of all you can always use NFS over TCP, so much for
"every thing else uses filehandles/UDP". (No that this improves security,
but it can improve reliability!)

Yes - but it won't work in the environment. As you pointed out, it works
under Solaris. No MACs, No Linux, and no MS windows (which would likely be
present in a lab).

Second, without physical security you can't protect the access keys - hence
no kerberos.

-------------------------------------------------------------------------
Jesse I Pollard, II
Email: pollard@navo.hpc.mil

Any opinions expressed are solely my own.

Re: [OFFTOPIC] Secure network fileserving Linux <-> Linux

[Jamie Lokier]

Jesse Pollard wrote:
> > 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.
> 
> I disagree! First of all you can always use NFS over TCP, so much for
> "every thing else uses filehandles/UDP". (No that this improves security,
> but it can improve reliability!)

It can improve security if you use NFS over TCP over SSL...

That may be easier to configure than IPSec in some environments.

-- Jamie

[OFFTOPIC] Secure network fileserving Linux <-> Linux

[Joseph Mathewson]

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.)

Joe.

+-------------------------------------------------+
| Joseph Mathewson <joe@mathewson.co.uk>          |
+-------------------------------------------------+

Re: [OFFTOPIC] Secure network fileserving Linux <-> Linux

[Fred]

One possible solution might be samba, but I'd be lying if I asserted anything 
about its security, I do know that it can be configured to operate entirely 
over SSL though.

Fred

__________________________________________________ 
On Wednesday 05 September 2001 02:13 pm, Joseph Mathewson wrote:
> 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.)
>
> Joe.
>
> +-------------------------------------------------+
>
> | Joseph Mathewson <joe@mathewson.co.uk>          |
>
> +-------------------------------------------------+
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

Re: [OFFTOPIC] Secure network fileserving Linux <-> Linux

[Frank Schneider]

Joseph Mathewson schrieb:
> 
> 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.)

Hello...

What about switching to IPSec ?

Should work between Linuxboxes....or why shouldn't it ?

Solong...
Frank.

--
Frank Schneider, <SPATZ1@T-ONLINE.DE>.                           
Microsoft isn't the answer.
Microsoft is the question, and the answer is NO.
... -.-

Re: [OFFTOPIC] Secure network fileserving Linux <-> Linux

[Jesse Pollard]

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.

Re: [OFFTOPIC] Secure network fileserving Linux <-> Linux

[Dax Kelson]

On Wed, 5 Sep 2001, Jesse Pollard wrote:

> 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).

Both your Third and Fouth answer depend on MAC addresses locked down on
the switch.  This is fatally flawed since (as the orginal poster pointed
out), changing your MAC address to match the expected MAC is quite easy.

# ifconfig eth0 ether A0:B1:C2:D3:E4:F4

How can you get the expected MAC address?

1. Walk up to an allowed computer, unplug computer from wall jack.  Plug
cross over cable from allowed computer into laptop.  Sniff MAC address
from frames generated by allowed computer.

	- Reconfigure your eth0 with allowed MAC, plug into network

2. Walk up to an allowed computer, unplug computer from wall jack.  Plug
into wall jack and sniff destination MAC address on frames sent by switch.

	- Reconfigure your eth0 with allowed MAC


One solution is to require layer 2 authentication from the switch, before
it fowards frames on that port.  Before DHCP.  This process could be
repeated every time link is lost.  The switch uses RADIUS off of some
authentication server.

The 802.11x standard(s) implement this for wireless networks, it can also
be used on wired networks (the specs allow it at least).

Dax

Re: [OFFTOPIC] Secure network fileserving Linux <-> Linux

[John Jasen]

On Wed, 5 Sep 2001, Jesse Pollard wrote:

> 	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).

Did you consider AFS?

Might be overkill for his environment, but it does do ACLs.

--
-- John E. Jasen (jjasen1@umbc.edu)
-- In theory, theory and practise are the same. In practise, they aren't.

Re: [OFFTOPIC] Secure network fileserving Linux <-> Linux

[Kain]

[-- Attachment #1: Type: text/plain, Size: 405 bytes --]

On Wed, Sep 05, 2001 at 09:17:11PM -0400, John Jasen wrote:
> Did you consider AFS?

There is also Coda, which I have had good luck with.  It also supports volume replication, ACLs, and disconnectecd operation, to boot.
-- 
When you look into the abyss,the abyss also looks into you.
	- Friedrich Nietzche
**
Penguin Sympathizer
Bryon Roche, Kain <kain@imperativesoultions.com>
<kain@kain.org>

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

Re: [OFFTOPIC] Secure network fileserving Linux <-> Linux

[Bernd Eckenfels]

In article <Pine.SGI.4.31L.02.0109052116010.3586235-100000@irix2.gl.umbc.edu> you wrote:
> Did you consider AFS?

> Might be overkill for his environment, but it does do ACLs.

Does it do data encryption? I think you may need to run IPSec, which does
not fit too well into the required environemnt.

Greetings
Bernd

Re: [OFFTOPIC] Secure network fileserving Linux <-> Linux

[Jesse Pollard]

Bernd Eckenfels <ecki@lina.inka.de>:
> In article <Pine.SGI.4.31L.02.0109052116010.3586235-100000@irix2.gl.umbc.edu> you wrote:
> > Did you consider AFS?
> 
> > Might be overkill for his environment, but it does do ACLs.
> 
> Does it do data encryption? I think you may need to run IPSec, which does
> not fit too well into the required environemnt.

I thought of AFS, but was not sure clients existed for all systems that
would likely be in a lab. I should have listed it as a possiblility though.

-------------------------------------------------------------------------
Jesse I Pollard, II
Email: pollard@navo.hpc.mil

Any opinions expressed are solely my own.

Re: [OFFTOPIC] Secure network fileserving Linux <-> Linux

[Dominik Kubla]

On Wed, Sep 05, 2001 at 05:12:48PM -0500, Jesse Pollard wrote:
> 
> 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.

I disagree! First of all you can always use NFS over TCP, so much for
"every thing else uses filehandles/UDP". (No that this improves security,
but it can improve reliability!)

True: krb5 only authenticates the mount, but krb5i also computes a
MD5-based message authentication code on every RPC request to the server
and every RPC reply to the client, thus providing integrity protection.
krb5p uses DES encryption to provide privacy.  Unfortunately only Solaris
with SEAM and SEAS (or AdminPack for Solaris 8) seems to implement this.
I would love to see a Linux implementation of this!

I would like to recommend "Managing NFS and NIS" (2nd ed) from O'Reilly,
especially chapter 12 "Network Security".  That chapter discusses the
mechanismns described above as well as performance and relation to IPsec
(for the impatient: using AH+ESP will give you HOST-based security, while
using krb5+krb5i+krb5p will give you USER-based security)

As for encryption slowing down the network: security does not come for free.
It is the task of the System Administrator to evalute his security requirements
against the required performance of the installation and take the appropriate
measures. Nobody ever said that was easy. It if was every MCSE could do it!

The author of "Managing NFS and NIS" (2nd ed) gave some figures on performance
degradation using krb5 (using two Ultra 5 w Solaris 8, using NFS over TCP):

	Auth	Throughput	Degradation	CPU util.
                 (MB/sec)	rel. to "sys"

	sys	5.4		-		69%
	krb5	5.26		2.6%		70%
	krb5i	4.44		17.7%		77%
	krb5p	1.45		73.1%		99%

(Test involved writing a 200MB file to the tmpfs of the server using the
mkfile utility. I am sure one could run better tests, but...)

Now i would be more concerned with the increas in CPU utilisation than
the throughput degradation. Why? If i truly need to protect sensitive
information with encryption, i can wait for the data. But making the
server unusable for the duration of the data transfer is in most cases
not acceptable.

Dominik Kubla
-- 
ScioByte GmbH, Zum Schiersteiner Grund 2, 55127 Mainz (Germany)
Phone: +49 6131 550 117  Fax: +49 6131 610 99 16

GnuPG: 717F16BB / A384 F5F1 F566 5716 5485  27EF 3B00 C007 717F 16BB