> 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.
-
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/
This archive was generated by hypermail 2b29 : Fri Sep 07 2001 - 21:00:34 EST