Thin Client solutions

[David Wolfskill]

On Mon, Oct 24, 2005 at 06:52:06PM -0700, Brian Street wrote:
> ...
> 
> Your points are valid and we've been thinking about them all. What I
> am considering is a firewalled network for code development that only
> allows connections from specific thin clients (I should be able to
> allow only specific mac addresses to connect just like a wireless
> node, no?).

The phrase "just like" is well-used here, since that MAC address
filtering may range anywhere from "adequate" to "about as effective
as tissue paper."

My knowledge of the Microsoft Windows world is, bluntly, negligible, so
it's possible that folks using such a platform would find such filtering
effective.

But running FreeBSD, I know -- because I've done it -- that one may
change the MAC address of certain NICs.

Indeed, MAC address filtering is one of the techniques I use on my home
wireless net.  So to verify that it was acting as I expected it to, I
established a connection between my laptop and an access point ("AP")
using a Cisco 340 (802.11b) card.  I then used the "ifconfig" command to
change the MAC address -- and noted with some satisfaction that this
disrupted the connection quite effectively.

I then changed the MAC address back, and the connection was restored.

Maybe you won't be dealing with folks who would (be able to) do such
things; I don't know.  And not all NICs necessarily have "programmable"
MAC addresses.  MAC address filtering can be of use, but you should know
its limitations before going too far with plans to deploy it.

> We are also considering a separate desktop for the users
> to check email, internet access, etc. but what prevents them from
> just taking the time to copy the data from the isolated network to
> the other network. At some point you have to trust that your source
> code is safe with your new employees, but I think that might be too
> cautious of an approach.

What happens if one of them has a cell phone with a camera?  How about
an  employee with an eidetic memory (referring to the "between the ears"
type of memory here, not semiconductors)?
 
> We'd like to limit the access to the code and try like heck to keep it
> from getting out....which is a huge task and probably not possible.

Think "risk mitigation."  :-}

Peace,
david
-- 
David H. Wolfskill				david at catwhisker.org
Prediction is difficult, especially if it involves the future. -- Niels Bohr

See http://www.catwhisker.org/~david/publickey.gpg for public key.