Thin Client solutions

Tue Oct 25 12:04:50 PDT 2005

>From Previous Post:

>
> 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?). 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.
>
> 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.
>
> Brian.
>
>
[ warning : long post ]

Mac addresses can be cloned, so mac address filtering is pretty pointless.
Google the internet for articles about getting into wifi access points and
you will see notes about Mac address cloning.

Your best bet would be to have a VPN setup on your network. The coders are
on one VPN and the public access terminals for email/etc are on a seperate
VPN. That way, the only way anyone is able to do anything on your network is
if they are authenticated against one of the VPNs. Just plugging a
computer/laptop into your network won't get them anywhere. This will prevent
code from walking.

Note: The developer VPN should have its own email server for internal only
emails. That way, the developers can email one another code and notes, but
the email has no chance of ever entering the public networks/internet. Same
for word processing, printing, etc.

One way to do this is:

Setup your various VPN networks so that developers are isolated from the
rest of the world, since theft of IP seems to be a concern. Have a VMware
ACE setup to create limited access images of Windows for developers to use.
Have development data on a central server, not on the images. All changes to
the thinclient images are undone when the system is rebooted or the user
logs out. USB, PCMCIA, FW, CDROM, SOUND, etc are disabled on the thinclient
machine image. The Image contains the VPN software to authenticate against
the Developer network, but requires a developer to login.

Instead of ACE, you can also use a stripped down and hardened PXE-booted
Linux to run VMware player. Use that to run restricted VMware images served
by your central server. The Linux image can have the USB, CDROM, PCMCIA, etc
modules unloaded or not compile in so that the developer/user won't have
access to it from Linux or VMware/Windows.

Ultimately, if your developers are looking to steal your info, they can
always bring in a digicam to photograph snippets of code/etc. They could
bridge the private and public networks to copy data. They could work with
someone who manages to the networks to bridge the networks physically. They
could steal a backup tape. Depending on the code they are developing, they
could even embed the source code into the compiled application for redumping
later.

They could even bridge the desktop and the thin client with a serial cable
or parallel port cable to do a system-to-system copy. I mean... they are
developers, it isn't hard to write a simple utility or download a public one
to do a serial/parallel cable transfer. With a custom LED/photo-diode
device, you could, in theory, use the monitor to export data serially or
parallel. (Might be a nice hobby project, actually.)

If the thinclient needs to be secure, then it should store NO information
and have no means to input/output other than the screen and the
keyboard/mouse. The system should stop working if it is unplugged from the
network and require re-authentication to prevent cached data from being
copied to another computer(thinclient+ramdrive => laptop via cross-over
cable). Ie, if the thinclient's OS detects it isn't in contact with the
central server, it should wipe it's local ramdisk and shutdown.

The desktop/workstation should similarly be restricted and limited, but via
a different network and different central server. "Maybe" have USB/CDROM
access since it is for normal office work, but it should definitely not have
any means to connect with the thin client in any way.

Assume that the BIOS can be compromised. Passwords can be reset. So a normal
machine plugged into your network will get nothing except the PXE-boot/dhcp
information to load a highly restricted image which will not access the hard
drive, cdrom, usb, flash, pcmcia, serial, parallel, infrared, bluetooth,
wifi, or sound ports.

Regarding the "thinpathsystems.com <http://thinpathsystems.com>" X terminal
product, it makes use of the local hard disk. So once you have installed it
once, there is very little to prevent it from being compromised to allow
copying data to another machine from hooking up to it and copying data from
it.

Seriously, virtualize the OS. This allows you to lock down the hardware at 2
levels: the host OS(Linux) can disable drivers to the various hardware
ports, so that even if the system HAD a hard drive in it, it won't be used,
and the GUEST OS ala VMware Player(Windows), where it has no access to the
HOST OS's devices, which aren't available, and the VMware instance is
further disabled.

If they manage to hack the Windows Guest OS, the Linux underlying OS won't
let them write to anything or transmit anywhere. If they manage to hack the
underlying Linux OS, there is nowhere to write programs to since the system
isn't compiled with support for local storage or local buses.
VMware Player can even limit which shared folders are available.

If they disconnect the network, you can encode the Linux distro to basically
wipe the ram drive on the thinclient via a heartbeat with a central server.
No return beats in say 5 seconds and the ethernet link is down? We've been
disconnected, wipe it and shutdown. Mitigated risk to cached data theft.
Since the saved data is stored on a NFS/CIFS/CVS central server, no data
loss. Since the OS is booting from a remote image, no OS corruption.

It might be a bit more involved than a straightforward
firewall/VPN/segmented network approach or an X11 thinclient approach, but
you get alot more control while being able to provide a "full" OS to the
developers to work on. You can also maintain different revisions of
workstation images,should someone need to work on a particular OS revision
or a different set of development tools.

The VMware ACE route has a higher price tag, but is a single bundled
package.
The Linux+VmwarePlayer+VMwareWorkstation route is cheaper, but requires a
little more admin experience/knowledge.

But both options will mitigate the risk of developers walking off with
information on their laptops, portable media, etc... when properly
configured.

How much protection you need depends on what the requirements are for the
project.

Wing.

--
Wing Wong
wingedpower at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.baylisa.org/pipermail/baylisa/attachments/20051025/8e4664eb/attachment-0001.html>