There are many options available out there however, if the decision is to
implement DHCP to MAC addresses, a few considerations need to be taken into
account:
1. Is the environment controlled? IE: does the IT department know what is
happening on the network and can anyone place a system on the network?
2. Does management accept the overhead of implementing this strategy? Either
a physical inventory will need to be done or a login script will have to be
written. There is a cost involved with man power.
3. Has the DHCP server architecture being decided on? Windows NT, 2000, XP,
UNIX, or Linux/FreeBSD? Windows is the easiest although I prefer Solaris.
4. Who will be responsible for the server? Support, Networks, Security or
all. One group must take overall responsibility and the associated
accountability!
5. DRP/Continuity planning must be done. A lease that is too long does not
cater for the functionality that DHCP offers (a lease of 99 days in a fluid
network does not work, be realistic). If the server goes down before the
lease is renegotiated or it fails entirely, duplicate IP addresses could
restrict system availability.
6. LAST but not least, how will the system be maintained? Find an automated
system. Windows NT, 2000, and XP has tools in the resource pack that allow
you to populate the DHCP Server with a DOS command file. Writing a perl
script to read from a flat file or any DB to do this will work 100% (tried
and tested). On Unix, the awk or shell script/perl will do the same.
When all this is done, implement and enjoy. REMEMBER, it is better to change
the router/gateway address while implementing this to ensure that 'unknown'
systems are captured and prevent future problems.
With regards to restricting IP addresses to certain MACs, implement the full
hog. If it is on a another segment, only allow certain MAC addresses through
the router/switch if you have enabled forwarding to a central DHCP server.
This is a management nightmare solution and in my opinion totally overboard
and management intensive unless you want to work 25 hours a day 7 days a
week.
Remember the function of DHCP, if it asks for one, give it one if one is
available.
As a note, this strategy only works well in a large network if the
environment is formalised and has Change Control and Configuration
Management.
Regards,
Gavin Ferreiro (CISSP)
Project Manager, Security and Service Management Consultant
Mobile: +27 (83) 341 7907
Work: +27 (11) 794 4017
Fax: +27 (11) 794 4017
This e-mail may contain confidential Information and may be legally
privileged and is intended only for the person to whom it is addressed. If
you are not the intended recipient, you are notified that you may not use,
distribute or copy this document in any manner whatsoever. Kindly also
notify the sender immediately by e-mail, and delete the e-mail. When
addressed to clients of the company from where this e-mail originates ("the
sending company") any opinion or advice contained in this e-mail is subject
to the terms and conditions expressed in any applicable terms of business or
client engagement letter . The sending company does not accept liability
for any damage, loss or expense arising from this e-mail and/or from the
accessing of any files attached to this e-mail.
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: 15 May 2002 16:04
To: [EMAIL PROTECTED]
Subject: Restricting DHCP addresses to known MAC's via Win2K DHCP server
There's been periodic discussion on this list about
restricting DHCP leases by MAC address and the relative
merits of doing so. My question is once the decision is
made to do it, how is it being done? Does anyone know how
to do it in a Win2K server environment? (Win2K DHCP
services...) If not possible, is there a typical strategy
people are using to restrict granting of DHCP addresses to
known MAC's?
