public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Jesse Pollard <pollard@tomcat.admin.navo.hpc.mil>
To: dax@gurulabs.com, Jesse Pollard <pollard@tomcat.admin.navo.hpc.mil>
Cc: "joe@mathewson.co.uk" <joe@mathewson.co.uk>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [OFFTOPIC] Secure network fileserving Linux <-> Linux
Date: Thu, 6 Sep 2001 07:28:59 -0500 (CDT)	[thread overview]
Message-ID: <200109061228.HAA31597@tomcat.admin.navo.hpc.mil> (raw)

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

             reply	other threads:[~2001-09-06 12:29 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-09-06 12:28 Jesse Pollard [this message]
2001-09-06 16:41 ` [OFFTOPIC] Secure network fileserving Linux <-> Linux Mike Fedyk
     [not found] <linux.kernel.20010907025336.D7329@kushida.degree2.com>
2001-09-07 15:41 ` Aaron Denney
  -- strict thread matches above, loose matches on Subject: below --
2001-09-07 15:34 Jesse Pollard
2001-09-07 15:58 ` Jamie Lokier
2001-09-06 12:46 Jesse Pollard
2001-09-07  1:53 ` Jamie Lokier
2001-09-05 19:13 Joseph Mathewson
2001-09-05 19:30 ` Fred
2001-09-05 20:17 ` Frank Schneider
2001-09-05 22:12 ` Jesse Pollard
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

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=200109061228.HAA31597@tomcat.admin.navo.hpc.mil \
    --to=pollard@tomcat.admin.navo.hpc.mil \
    --cc=dax@gurulabs.com \
    --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