Picking up where we left off last month (see DHCP services for WLANs), we have two big tasks ahead in order to get DHCPD up and running: building the dhcpd.conf file, then setting up process management and monitoring.
Considering the number of different elements needed to implement a secure WLAN solution, it would seem that configuring the DHCP service would be pretty straightforward. And, for the most part, it is. But DHCP, like all networking components, tends to become as complicated as the solution it's supporting. If the networking environment is simple, so is the configuration. If the networking environment is complex -- well, you can do the math. Secure computing environments are all grounded on the notion of permitted service access. Not all users are equal; some have more access than others. How this access is regulated is the problem the network administrator must solve. The hardy administrator has a few tactics available to follow when implementing a secure network solution. The first is to use application layer authentication, i.e., proxy gateway or VPN. The second is to implement some kind of network access control, i.e., a NAC or firewall filter. The third is to implement both. In part one of this article, we looked at implementing a security model following the "application layer" approach using three IP network segments to provide three network service access models.
[IMAGE]
In part one of this article, we looked to using different SSIDs, each with its own IP subnet:
While there is nothing insecure about this approach, it relies solely on the "application" layer security. In the event this is breached, the network environment is vulnerable. As it turns out, this environment can be strengthened by more fully utilizing DHCP to do more than just dole out IP addresses. The DHCP environment can be crafted to take on the additional roll of network access enforcement. This added security does come with so
To continue reading for free, register below or login
To read more you must become a member of SearchNetworking.com
me added overhead but that is the cost of a secure network. This month we will dive a little deeper into DHCP implementation options and the configurations to support the three SSID network models and an alternative DHCP configuration that utilizes only a single SSID.
The DHCP network access control for all of us
When designing a DHCP environment, administrators have three lease assignment models they can use:
Of course once you go beyond the open lease policy, user/admin interaction is now required. But this same interaction is required for implementing WPA or WEP where keys must be provided to the user. The same holds true for implementing VPN client access or authenticated proxy access. Clients, configuration information and user credentials need to be distributed to the user. There is no short-cut to security. Adding DHCP NAC)only enhances your other security measures. Now let's translate our multi-SSID scheme into a hybrid DHCP policy where each SSID is a different user class:
It's at this point that we need to look at what DHCP NAC opens up for us -- what I like to call Option 2.
One of the limitations of the multi-SSID solution is bandwidth. 802.11 wireless is a shared bandwidth network medium. The result being that performance degrades as more users join the SSID. The WLAN example above addresses this by utilizing three different access-points. 802.11 wireless also has a limitation in the number of access-points that can be located within the same physical space due to space limitations in the RF spectrum it utilizes. No more than three access-points can be supported within the same broadcast range without carrier signal issues. The WLAN solution above addresses bandwidth limitations of 802.11 by using a dedicated access-point for each user class. This approach works great if each user community has the same population. However, it is more than likely that the majority of the user population will be Class 2 or Class 3 users in most WLAN scenarios.
A more performance-friendly alternative (while still being secure) is to utilize an overlay IP network running on the same "physical segment."
[IMAGE]
By using the overlay IP network in conjunction with a hybrid DHCP model, we can leverage the available bandwidth of all three access-points and still maintain a segmented network structure. Class 1 and Class 2 users have IP address assignments allocated using a closed DHCP lease policy using a host's MAC address or an administrator assigned "Client-Id" (Mac OS X and *NIX only support the client-id option) for identification while Class 3 user allocations are provided using an open DHCP lease policy.
dhcpd.conf Command syntax
The ISC dhcp.conf has three components: global parameters, address declarations and DHCP option parameters. The global parameters define how the server will operate. Here is a list of most commonly used parameters. Global parameters are typically listed at the top of the configuration file, one command per line. The syntax for parameter settings is <command {option};>.
The complete list of global parameters can be found in the dhcpd.conf main page. Once the server parameters have been defined, the next step is configuring the pool declarations. Pool declarations and their accompanying options can be configured as standalone or nested sets. There are five commonly used pool declarations:
Once again this is not a definitive list of all of the available DHCP options, just ones that are commonly supported by most of the DHCP clients you will run into. These options are also used in the example dhcpd.conf configuration files we're now going to review.
DHCP server configuration for a multi-SSID environment
The first DHCP configurations we're going to look at are the more traditional of the two. It utilizes a hybrid DHCP lease model where some of the subnets are open and the others are closed. It consists of three subnet objects, one for each network segment. Here is a diagram of the network that depicts the three SSID segments:
[IMAGE]
One key configuration element to note is the requirement to set up DHCP relay services on the router that connects the Outlan-WPA and Outlan-Open network segments. Here is what the router interface configuration for the 71.1 link looks like to operate as a DHCP relay:
Now let's take a look at the configuration, starting with the global parameters:
We want to provide the clients with a domain search list (defined in RFC 3397), for resolving DNS short-names. This option is not part of the standard ISC configuration so it needs to be defined:
The first Subnet object supports the "open" http access. Any host can join the network segment to maintain wireless performance pool size of only 20 IP addresses is configured. When a user joins the subnet (if supported) she is greeted with a "Welcome to Outlan Open!" message.
The second and third Subnet objects provide IP addressing for "Outlan-S" and "Outlan-WPA" SSID's. IP address assignments for these subnets allocated use a closed lease policy. This requires that each host needs to have a host identifier (either a MAC address or ASCII id string) configured, before they can get a lease assignment. When setting up closed subnets, administrators can either collect the users MAC addresses and manage the entries or "pre-configure" ASCII identifiers. While these subnets are closed, creating a small pool to fish for MAC addresses makes configuring the MAC leases far easier than getting users to provide the information. These addresses of course should be blocked from forwarding packets off of the subnet. This is where the option comes in handy for informing users how to gain proper access. Here are two different approaches to configure this access. The subnet configuration for the 172.30.41.0 segment uses two pool declarations to manage the "fishing" address range and the user address range:
The first pool defines the fishing addresses, open to any user:
The second pool provides addresses for "known" users:
The subnet configuration for the 172.30.71.0 segment uses the default range to define the "fishing pool." A short lease time is defined for the fishing pool to make sure the address recycled quickly.
Since this network segment is especially for a class of users that would require permanent access, static host definitions make far more sense than a random lease pool. Here a definition object is used to define lease parameters for these users.
About the author:
Michael J. Martin has been working in the information technology field as a network and Unix system admin for more than 10 years. What's his biggest strength as an expert? He says it's his "broad base of experience in working in the ISP/carrier and enterprise spaces as both a systems and a network engineer." His background in designing, implementing, and supporting MIS infrastructures for research and ISPs gives him a unique perspective on large-scale internetworking and security architecture. Michael shares his wealth of knowledge in his monthly Router Expert series and in frequent Live Expert Webcasts.
