[TriLUG] Diskless Clients and Security - Followup Questions

[Aaron S. Joyner]

Roy Vestal wrote:

> I have a over 150 machines at the moment that will in some way have to 
> be booted diskless. Currently, we are using boot CD's but I want to 
> move away from the CD's so that the management of the environments is 
> centralized and the OS projects are consistant. However, not all of 
> these machines are going to be online at one time so I would like to 
> use a set of 100 IPs and have them randomly assigned when a machine is 
> brought online.  Make sense?
>
> This is a development lab and these machines are used mostly for 
> development and/or testing and are not online for long periods of time 
> (i.e days/weeks, not necessarily months). We now have 3 different 
> OS/env scenarios that we use where PXE would let us minimize 
> maintenance and more closely control the versions of the enviroments 
> used. However we "share" the network in question (with me being the 
> DHCP/DNS server admin <evil grin!> ) so we need to be able to secure 
> it from other groups outside our lab. And we are constantly adding new 
> machines and removing old machines from dev/testing pool so I want to 
> be able to manage these simply. Just adding/removing the mac's will be 
> painful enough.
>
> In a nutshell, I need to overcommit my range by almost 100% to an 
> everchanging pool of machines/mac's.


If I may be so bold, I would suggest that what you're doing is going 
about it the wrong way.  "Securing" your IP addresses by limiting what 
your DHCP server hands out is only marginally useful for a myriad of 
reasons.  First off, if you have users plugging in computers and 
attempting to use this network segment, then they're going to try to get 
an IP address.  This means that either your DHCP server will assign them 
one, another DHCP server will assign them one, or they'll have to make 
one up on their own.  If you give them an address, at least you can be 
reasonably assured that it won't conflict with another machine.  You 
might run *out* of addresses, but that's a whole different problem.  Not 
giving out an address won't prevent you from running out, it just causes 
the user to try to make one up, which is the same as the last option.  
In that case, the user (especially as the range gets full) is likely to 
choose an address that is in use, or will be in a few moments when that 
test machine in the corner with the lease for it finishes rebooting.  
Bad karma.

In the scenario above I haven't touched on yet, where you're sharing a 
broadcast domain or have a dhcp relay to another dhcp server from your 
network segment, then you're in a simple race condition.  Your DHCP 
clients that you *want* to have addresses, *might* get an address from 
your server, or they *might* get an address from the other DHCP server.  
I don't think I need to explain why that's bad.  Trusting to the latency 
of the closer DHCP server is also a very bad mistake.  You should 
basically never have two DHCP servers with an overlapping scope that 
aren't a fail over pair.

So, tackle this problem by segmenting your broadcast domain.  Ie. put 
your test machines on another subnet, which either no one wants to be 
on, or is allowed to be on, or physically can get on.  This solves the 
problem of wayward users connecting to the network.  As for *how* to 
segment yourself, consider turning off unused ports on managed switches, 
using 802.1x authentication, simply changing your network addressing 
scheme and installing a NAT router at the border back to the regular 
network with the rest of the users - what ever you need to do to change 
the network topology.

So you may say you can't do that for a myriad of reasons.  Those reasons 
are the real problem here.  Find solutions to those problems, and you'll 
be moving in the right direction to a better life through better 
networking.  Or maybe I'm just really naive and you have a complex and 
unique problem.  In that case, feel free to ignore the above ramblings.

Aaron S. Joyner