Davy Davidson wrote:
> Hi,
> I have a little problem and seek for ur thoughts, let's assume I'm in
> a very open environment where everyone can very easily try to get
> his/her laptop on the network and IP addresses are assigned by a DHCP
> server and we are in a domain environment, how do I prevent machines
> that are not part of our domain to be assigned an IP address?
As has been indicated in previous responses to your question, there are
a couple of approaches to this problem.

The most basic is to do what you ask - use MAC addresses to prevent
machines that aren't registered from getting IPs leased. The downsides
to this method are that it is expensive to administer (since you need
mac registrations for every workstation on your lan), and only provides
a trivial level of security, since it is very trivial to get the MAC
address of a machine which is registered (or just assign yourself a
static address). This approach doesn't stop your rogue clients from
connecting to other clients, but merely doesn't give them the
information they normally need to do so.

There are some "Secure DHCP" products, but I haven't yet seen any that
actually solve the problem (and some of them seem simply to use
MAC-based assignment but with a slightly less clunky interface than the
microsoft DHCP mmc), so I'd be very wary of them and the promises they make.

MAC Filtering, port locking, or any of the other names by which it's
referred to use MAC addresses again - but at the switch level. This is a
good deal more clumsy, since you generally have no centralised database
to maintain and frequently your MAC registrations will be done on a
port-by-port basis, but has the slight advantage that - at least in
theory - *no* traffic will be allowed by the switch for the wrong mac
address. The benefit of this approach is that it should be marginally
harder to get a legitimate MAC to use (you need *precisely* the right
one for the given port and your opportunities for sniffing are limited),
but stealing an existing workstation's network socket and reading the
MAC address from the label on the back of the unit really isn't that
hard. Effort required, significant.. ease of bypass, minimal.

Moving up a level, then, what you really want to do is accept that DHCP
is insecure and design your network such that it assumes this to be the
case. Most basically, with a well-segmented network that's kept up to
date, you may decide this is an acceptable risk. Assuming that you've
crossed this bridge and decided it isn't (no, I don't think I really
think so either), we move on to what else we can do.

There are two basic methodologies you can apply to do this. The first
method is to use authentication at the switch level, using 802.1x,
designed for just this purpose. Using 802.1x, your workstations
authenticate through the switch to a radius server (IAS, steel-belted
radius, freeradius, whatever..) before they are allowed any
connectivity. This authentication can use X.509 certificates, computer
account credentials from AD, or whatever else you'd normally configure
radius to authenticate with (these are the big two). Windows has a
built-in 802.1x supplicant, and (in XP, at least) it's enabled by
default, so assuming you allow connections from computer accounts, this
can be an entirely server/switch-side implementation if you have XP (and
probably 2k) clients - workstations should "just work" with the new
system. (Disclaimer: Testing, controlled environment, etc etc.)

Depending upon your equipment (to avoid much pain this approach will
*require* decent managed switches from the likes of 3com, cisco, nortel,
HP, et al), you may also be able to do fun stuff like allocate different
machines different vlans, so all clients in your Engineering OU get
dropped into the engineering vlan (and consequently the engineering
broadcast domain/subnet) irrespective of where onsite they plug in.
This, to my mind, as well as the ability to arbitrarily chop machines
network access off at the switch fairly quickly right from AD (depending
upon the interval you configure for radius re-authentication) is a
really nice advantage of implementing this solution. Once you have it
up, there's lots more you can do with it.

Many higher-end access points such as the cisco aironet units and the HP
Procurve access points (which have the slight benefit of having a
lifetime warranty - hurrah!) also do similar for wireless using
WPA-radius or WPA2-radius, either with multiple SSIDs (engineering SSID,
development SSID, all from one physical unit, each connecting to a
different vlan), or using radius authentication and data stored in AD to
dictate which VLAN a given account is tied to. This will require a
hotfix on XP clients to support WPA2 (KB893357).

Authentication in this manner is great, but may cause problems with
older machines without a supplicant for 802.1x (or, if you configure
WPA2, machines whose wireless drivers don't support it), and support for
radius authentication requires expensive equipment. Getting radius
working properly and reliably with wireless equipment can also be
slightly painful at times. There's dynamic WEP too, but WPA2-Radius is
so much nicer it's worth buying new network cards.

The second method in this respect is to use something like IPSec (which
is what NAC/NAQC use) to effectively enforce a host-based firewalling
policy across groups of machines. In this manner, you can force your
domain clients *only* to communicate to other domain clients that also
have IPSec configured. Microsoft call this "Server and Domain Isolation"
using IPSec, and if you google for that term, you will find some great
support material from technet that goes through how this works. The same
applies to the preceding method regarding wireless & radius, if you
search for "securing wireless lans" - the first two hits are the PEAP
and Passwords documentation and the Certificate-based documentation from
technet. They're great - worth a read even if you don't intend to
implement it (or if you're just interested in IAS).

Last but not least, there are the most expensive options - options like
cisco NAP (Network Access Protection) which integrate centralized
authentication with policy enforced using a supplicant on the host.
These are probably overkill based on your requirements, since you
probably don't need to enforce antivirus policies &c on your clients
before granting them access to particular portions of the network. These
options will probably require similar (or larger) amounts of
infrastructure to that put in place for a radius solution (which is free
if you have windows licenses - IAS, the microsoft AD-integrated radius
server is a windows component), in addition to server infrastructure for
your chosen solution, on top of compliant network hardware at any tier
of your network you need to enforce this protection on.

Overall, I think the IPSec methodology is probably your best bet if you
don't have all-managed switches. It doesn't protect against Denial of
Service against your clients or network stack-based attacks, but it
should stop clients from connecting to network resources (even with
credentials), unless your intruders have some fairly high-level
technical skills and administrative access to workstations or servers to
see how your solution is configured and steal/copy credentials or
certificates. At that point we're entering the realms in which a
determined intruder would be just as well using an authorized
workstation for nefariousness anyhow.

Why was DHCP never retrofitted with authentication, you say? Well,
actually, it sort of was - RFC 3118 sets out Authentication for DHCP -
it's just that no-one has ever bothered implementing it! (And if they
had, it still wouldn't solve the static assignment issue raised at the
beginning of my e-mail).

Hope that helps. Not to plug it too much, but if you're interested, I
wrote a paper on why DHCP is insecure (and why it deserves more love).
It, and a set of presentation slides on the same topic, are online at
http://jeremiad.org/download.shtml