[PLUG] Thin Client Security

Cooper Stevenson cooper at linux-enterprise.net
Wed Dec 11 00:04:46 UTC 2002


Matt,

What you prescribed below is an *outstanding* idea! This way, access
control is greatly increased as one would now need to gain access to the
server room to fake a server. Great idea!!


-Cooper

On Tue, 2002-12-10 at 15:59, Matt Alexander wrote:
> I just thought of something else I could do...
> I could setup VLANs on the switch that only allow each client port to talk
> to the port with the LTSP server.  Then it wouldn't matter if someone
> plugged in another server.
> ~M
> 
> 
> 
> On Tue, 10 Dec 2002, Matt Alexander wrote:
> 
> > I agree with Brian...
> > You're referring to the potential insecurity of DHCP, and not the K12LTSP
> > project in particular.  Most companies run DHCP servers for their internal
> > clients and they could be susceptible to the same type of network
> > foulplay, regardless of the chosen operating system.  It would be
> > considerably easier to be a fake DHCP server for a non-LTSP client,
> > however, because the LTSP server does so much more than just DHCP in order
> > for clients to actually work.  In a Windows network, for example, I could
> > plug in a DHCP server that has everything configured the same as the real
> > DHCP server, except I set your gateway to go through me instead and then
> > forward the traffic onto the real gateway while I watch everything going
> > by.
> >
> > I use LTSP for about 35 users at my company.  The clients lack hard disks,
> > floppy drives, and CD drives.  These users plug into a switch which then
> > plugs directly into the LTSP server.  Each port is connected to the switch
> > only if there's a client computer plugged in at their desk (there are no
> > empty cubes with live data jacks).  It would be possible, although rather
> > unlikely, for someone to unplug their current desktop, plug in a fully
> > configured LTSP server which uses the real LTSP server as a gateway and
> > answers DHCP requests.  It still would have to answer DHCP requests faster
> > than the real server and it wouldn't have the user's correct password for
> > them to login anyway (unless you were clever and configured things so any
> > entered password would be accepted).
> > ~M
> >
> >
> > On 10 Dec 2002, Cooper Stevenson wrote:
> >
> > > Brian,
> > >
> > > It is an issue primarily because of the way the communication between
> > > between the server and the client is carried out.
> > >
> > > Are there easier ways to gain access to internal account information?
> > > Certainly. I can think of two ways just writing this sentence that make
> > > the internal subnet easy prey (hint: think ``wireless audit for
> > > prevention).
> > >
> > > This case is a little different than your normal communication. Again,
> > > please see above: it would be really difficult in practice to fake a
> > > server for long in practice. Having said that, though it an be done
> > > (think: last night's backup tape).
> > >
> > > Here, the client is not asking for _a_ server, it's asking for _any_
> > > server (X Windows client/server nomenclature not withstanding).
> > >
> > > It's just one of those things we need to think about when we evaluate a
> > > new system, ``is this an acceptable risk?''
> > >
> > > Again, I totally agree with you here. I mean, if an attacker can manage
> > > to sneak a machine on the internal subnet to sniff packets, for example,
> > > then the Administrator had better brush up on his/her SSL, etc. skills
> > > real fast.
> > >
> > > Better yet he should have done that before hand.
> > >
> > >
> > > -Cooper
> > >
> > > On Tue, 2002-12-10 at 14:39, Brian Hoag wrote:
> > > > Isn't this true of all network types?  If you compromise the security of
> > > > the network, why does it matter what client type you use.  If you
> > > > already have access to the server, you could easily get password and
> > > > user info.  Maybe I do not understand the question here, but in my
> > > > opinion, this shouldn't be considered a liability of the K12LTSP
> > > > project.  Correct me if I'm wrong please.
> > > >
> > > > --Brian
> > > >
> > > >
> > > > -----Original Message-----
> > > > From: plug-admin at lists.pdxlinux.org
> > > > [mailto:plug-admin at lists.pdxlinux.org] On Behalf Of Cooper Stevenson
> > > > Sent: Tuesday, December 10, 2002 10:27 AM
> > > > To: lug at peak.org
> > > > Cc: PLUG Mailing List
> > > > Subject: [PLUG] Thin Client Security
> > > >
> > > > All,
> > > >
> > > > When discussing the K12LTSP project yesterday and it's benefits, I was
> > > > asked about the server side security.
> > > >
> > > > Specifically, is there a mechanism in place to prevent an attacker from
> > > > putting a ``fake'' server on the subnet that the clients look for?
> > > >
> > > > In other words, let's say that a thin client sends a Bootp broadcast on
> > > > the network. What's to stop a hacker from plugging in a false server and
> > > > intercepting client requests?
> > > >
> > > > Of course the attacker would have had to have compromised a `real'
> > > > server to gain login information, etc. to make this work and it would
> > > > likely be discovered very quickly, but still...
> > > >
> > > >
> > > > -Cooper
> > > >
> > > >
> > > >
> > > >
> > > > _______________________________________________
> > > > PLUG mailing list
> > > > PLUG at lists.pdxlinux.org
> > > > http://lists.pdxlinux.org/mailman/listinfo/plug
> > > >
> > > >
> > > > _______________________________________________
> > > > PLUG mailing list
> > > > PLUG at lists.pdxlinux.org
> > > > http://lists.pdxlinux.org/mailman/listinfo/plug
> > > >
> > >
> > >
> > >
> > > _______________________________________________
> > > PLUG mailing list
> > > PLUG at lists.pdxlinux.org
> > > http://lists.pdxlinux.org/mailman/listinfo/plug
> > >
> >
> >
> 
> 
> _______________________________________________
> PLUG mailing list
> PLUG at lists.pdxlinux.org
> http://lists.pdxlinux.org/mailman/listinfo/plug
> 






More information about the PLUG mailing list