Restricting leases

[Patrick Trapp]

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<mailto: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<mailto:dhcp-users-bounces at lists.isc.org> [dhcp-users-bounces at lists.isc.org<mailto:dhcp-users-bounces at lists.isc.org>] on behalf of Jason Gerfen [jason.gerfen at gmail.com<mailto: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<mailto: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<mailto:dhcp-users at lists.isc.org>
https://lists.isc.org/mailman/listinfo/dhcp-users


_______________________________________________
dhcp-users mailing list
dhcp-users at lists.isc.org<mailto: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/7444da8b/attachment.html>