Restricting leases

[Jason Gerfen]

Arptables comes to mind but can also be circumvented using MAC spoofing.

> On Jan 29, 2015, at 1:45 PM, Patrick Trapp <ptrapp at nex-tech.com> wrote:
> 
> Yeah, the initial focus is to prevent accidental connections. I'm sure what you suggest here is a future discussion.
> 
> From: dhcp-users-bounces at lists.isc.org [dhcp-users-bounces at lists.isc.org] on behalf of Jason Gerfen [jason.gerfen at gmail.com]
> Sent: Thursday, January 29, 2015 10:53 AM
> To: Users of ISC DHCP
> Subject: Re: Restricting leases
> 
> No problem. Also so you are aware, if you want security on said subnet/network segment the previous use of hardware matching with classing assigned to each/any subnet you wish to implement this white list of devices with would be further enhanced through the use authenticated MAC services as this feature within a dhcpd.conf configuration will only prevent known/unknown devices from automatically obtaining a set of configuration options (hostname, ip, gateway, bootp/pxe services) for the given lease.
> 
> A user with some information of the network segment may simply assign these values and then utilize the network.
> 
> 
>> On Thu, Jan 29, 2015 at 9:40 AM, Patrick Trapp <ptrapp at nex-tech.com> wrote:
>> Thanks, Jason. I'm off to educate myself enough to have an intelligent question when I return. ;-)
>> 
>> Have a great day!
>> 
>> From: dhcp-users-bounces at lists.isc.org [dhcp-users-bounces at lists.isc.org] on behalf of Jason Gerfen [jason.gerfen at gmail.com]
>> Sent: Thursday, January 29, 2015 10:26 AM
>> To: Users of ISC DHCP
>> Subject: Re: Restricting leases
>> 
>> Good morning Patrick,
>> 
>> While the typical RTFM is always encouraged I believe the option(s) that will benefit you the most regarding a wildcard whitelist of nodes per network segment would be the section within the dhcpd.conf titled 'client classing' & 'subclasses'.
>> 
>> The examples provided should give you some insight into allowing devices based on the hardware identifier or other unique device identifiers. More information on these can be obtained in RFC-2132 (https://www.ietf.org/rfc/rfc2131.txt) table 3 (fields and options in a DHCP message).
>> 
>> Hope this helps
>> 
>>> On Thu, Jan 29, 2015 at 9:12 AM, Patrick Trapp <ptrapp at nex-tech.com> wrote:
>>> First, an apology - I'm not even sure how to ask this question, so my pre-post research really got me nowhere. So I'm really looking for a direction as much as an answer - I hate wasting people's time asking a question when I don't really know enough to ask the question well.
>>> 
>>> Second, the question(s) - Can we/how can we/should we limit the devices that the DHCP server provides addresses to? For example, legitimate devices on this network are 80% produced by two specific manufacturers. There should be virtually no workstations on this network - legitimate workstations accessing this network will do so via another network and get their addresses from a different DHCP system. The only reason a workstation should be on this network is if a technician is troubleshooting. 
>>> 
>>> So I am looking at the viability of allowing devices from the known manufacturers and whitelisting the specific devices carried by our technicians and not providing addresses for unexpected devices.
>>> 
>>> I fully expect and deserve an RTFM - I'm hoping someone can give me some ideas where I should be looking and what key words will get me where I need to go.
>>> 
>>> Thanks for reading,
>>> Patrick
>>> 
>>> _______________________________________________
>>> dhcp-users mailing list
>>> dhcp-users at lists.isc.org
>>> https://lists.isc.org/mailman/listinfo/dhcp-users
>> 
>> 
>> _______________________________________________
>> dhcp-users mailing list
>> dhcp-users at lists.isc.org
>> https://lists.isc.org/mailman/listinfo/dhcp-users
> 
> _______________________________________________
> dhcp-users mailing list
> dhcp-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/dhcp-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/dhcp-users/attachments/20150129/799c6b66/attachment.html>