Question about dhcp-client-identifier
Tim Peiffer
peiffer at umn.edu
Wed Aug 22 15:32:07 UTC 2007
I don't think it is possible as you suggest - ignore the UID. According
to the man page for dhcpd.conf, there is the option of ignoring
duplicates, only allowing a MAC to hold only one lease. I don't know
how one would look a duplicate MAC's in different subnets though.
> The duplicates flag tells the DHCP server that if a request
> is received from a client that matches the MAC address of a host
> declaration, any other leases matching that MAC address should be
> discarded by the server, even if the UID is not the same. This
> is a violation of the DHCP protocol, but can prevent clients
> whose client identifiers change regularly from holding many leases
> at the same time. By default, duplicates are allowed.
I would echo Glenn's sentiments. I think your efforts are better spent
on tracking ip to hardware to physical port down to jack per unit of
time. Have something else provide the access controls and leave to
DHCPD the job of providing addressing and network parameters. If you
mandate that everyone 'must' get their address from the DHCP server and
enforce through realtime dhcp packet snooping on the switch (I know that
vendor C will do it), then there are little chances of 'hiding'.
Besides, you get bonus points from law enforcement if you can show
positive session information to within a few minutes of start/stop
activity, regardless of whether the address was assigned by the DHCP server.
Alternatively require the users to 'log in to the network' through
effective use of proxy firewalls or deployment of 802.1X.
Duplicate MAC addresses are a fact of life, regardless of whether
someone choses to administratively re-assign the MAC. Programmable Array
Logic and Gate Array Logic used to encode station addresses blow bits
periodically. Sometimes vendors accidentally duplicate through bad QA,
etc.. It is also sometimes different to tell the difference between
hardware failure and malice just purely on MAC.
The point is that if you leave access controls to DHCPD, you will find
your self chasing your tail more often than you care to admit.
Regards,
Tim Peiffer
Network Support Engineer
Networking and Telecommunications Services
University of Minnesota/Northern Lights GigaPOP
Darren wrote:
>> Ok, so let's try and understand this. Joe User with a certain mac
>> address is happily working away. A Bad Guy tracks his connection
>> somehow and borrows his mac address, then connects to the same network
>> but a different subnet. You want him to be denied an IP address by
>> dhcp. All that shows up in the logs is that a particular mac address
>> turned up on another subnet. Happens a lot if you have roving laptops.
>>
>>
> We are aware that this is a problem for roving laptops. We can handle
> that on the support/administrative end of things.
>
>> What happens if the Bad Guy manually assigns himself an IP address that
>> is valid for the subnet? Instant access...
>>
>>
> We have other methods in place for making it impossible for a user to
> statically assign himself an IP.
>
>
>> What about the same scene, but on the same subnet? The new device can
>> steal all the connections that Joe User had. This is one way to do ARP
>> cache poisoning. There are others that don't require the use of a
>> duplicated mac address.
>>
>>
> We aren't particularly concerned about a user causing another user
> problems, we will deal with that on the administrative/support side. We
> ARE concerned about a user being able to "hide".
>
>
>> As has been said many times on this list, DHCP is not a security
>> enforcement service. By its very nature it happily hands out IP
>> addresses to unauthenticated devices on the network.
>>
>>
> Understood - we would never use it as a security device. We merely
> would like to be able to make the data from DHCP more useful.
>
>
>> regards,
>> -glenn
>>
>>
>
>
>
More information about the dhcp-users
mailing list