Router Expert: Building a WLAN proxy server, DHCP services: Part 1

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.

In part one of this article, we looked to using different SSIDs, each with its own IP subnet:

• SSID "Outlan-S" -- Provides HTTP/HTTPS access only using an authenticated proxy server.
• SSID "Outlan-WPA" -- Provides full private network LAN access using Cisco's auth-proxy or IOS VPN client connection.
• SSID "Outlan-Open" -- Provides HTTP only access via a proxy without any authentication.

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 some 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:

1. Open lease policy: Any user that makes a request gets an IP addresses assignment (assuming there are free addresses to hand out).

2. Closed lease policy: Only users with client definitions on the server can get IP address assignments. DHCP supports options for client IP address definitions; 1) MAC address and 2) Option 61 Client-identifier definition that can be either an ASCII string or the host systems MAC address.

3. Hybrid lease policy: Users with and without client definitions are assigned addresses.

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:

• Class 1: Provides full, private network LAN access using Cisco's auth-proxy or IOS VPN client connection: SSID "Outlan-S."

• Class 2: Provides HTTP/HTTPS access only using an authenticated proxy server: SSID "Outlan-WPA."

• Class 3: Provides HTTP only access via a proxy without any authentication: SSID "Outlan-Open."

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."

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};>.

• ddns-update-style none -- ISC DHCPd supports dynamic DNS updates in conjunction with BIND. This option in conjunction with <ddns-updates off> disables DDNS functionality.

• allow unknown-clients -- Configures the server to provide leases to any host that requests one. This option can be used to define the global operation of the server or can be used in conjunction with a declaration statement to define how to handle IP requests.

• deny unknown-clients -- Configures the server to only provide leases to hosts the server has host declarations for. Can be used globally or as part of an address declaration.

• allow known-clients -- Configures the server to only provide leases to hosts the server has host declarations for. Can be used globally or as part of an address declaration.

• authoritative -- Defines the server to function authoratively for each of the sets the DHCP pools defined and ensures that the server maintains the address pools correctly. This command can also be defined on a per pool basis.

• ddns-updates off -- Disables DDNS updates. (See above.)

• ping-check true -- Enables a 1-second ping check before issuing a lease. This prevents most cases of double-leasing and address conflicts where static addresses have been taken from an active pool. It also introduces a 1-second delay in providing users their IP address information.

• deny duplicates -- Configures the server to only allocate one IP address per MAC address.

• one-lease-per-client true -- Configures the server to release any previous leases when it receives a DHCPREQUEST from a host. This command functions adjacently to the deny duplicates parameter.

• deny declines -- Configures the server to reject client generated DHCPDECLINE messages. This is a protective measure against fussy clients and potential DCHPDECLINE message attacks.

• deny bootp -- Configures the server to ignore BOOTP message requests.

• log-facility -- Configures the server to use a specific syslog facility for logging.

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:

• The subnet declaration object is used to define a single IP pool range. The IP network and mask is followed by an IP pool range. In addition to the pool range, DHCP options can be defined within the subnet declaration for default gateway, DNS servers, etc.
  

  subnet x.x.x.x netmask x.x.x.x { <-- required
  range x.x.x.x x.x.x.x; <-- required
  option parameters; <-- optional
  }
  

• The host declaration object is used to define a dedicated IP address lease for a single host. This command is typically used in conjunction with the subnet, shared -network, or group declaration. Each host definition starts with a unique hostname tag, followed by the IP address allocation. The IP address is mapped to the host using the <hardware Ethernet x:x:x:x:x:x>command with the hosts MAC address in standard hex notation. The subnet mask can be derived from the subnet or shared network declaration or specified using DHCP option 1 <subnet-mask x.x.x.x;>. On Mac OS X and *NIX systems DHCP option 61 <option dhcp-client-identifier id string;>.
  

  host 
     
      { <-- required
  fixed-address; <-- required
  hardware Ethernet; <-- required (see above)
  option parameters; <-- optional
  }
     

• The group declaration object is used to define DHCP option parameters for a subset of host declarations within a subnet declaration.
  

  subnet x.x.x.x netmask x.x.x.x { <-- required
  group 
     
       {
  option parameters; <-- optional
  host 
      
        {
  }
  }
  }
  
      
     

• The shared-network declaration object is used to define multiple IP subnets on the same physical network. The shared-network statement is commonly used with DHCP options that help designate which users are assigned to specific IP networks. Without this designation the server will treat the networks as a common pool and assign IP addresses from the pool(s) as requests come in.
  

  shared-network 
     
       {
  parameters ;
  pool {
  range x.x.x.x x.x.x.x; <-- required
  option parameters ; <-- optional
  }
  }
  
     

• The pool declaration object is used to define DHCP option parameters for a range of IP addresses. The pool declaration is used in conjunction with the subnet or shared-network declaration.
  

  pool {
  range x.x.x.x x.x.x.x; <-- required
  option parameters ; <-- optional
  }
  

ISC also supports class and subclass declarations that can be used in conjunction with the subnet and shared-network declarations. The use of classes and match and match if expressions allow the administrator to configure qualifier's leases out of different address pools. A common use of classes is to define "known" and "unknown" user class and have the different classes of users get assigned leases out of different IP address pools. If anything, ISC is very flexible making it an ideal tool for implementing network access control.

In addition to IP address information DHCP can provide a wide array of information on not only how the host should configure its network interface, but on how to utilize a variety of network services. There are over 150+ DHCP options. The "classic" DHCP options were defined in RFC 1497 and RFC 1533. The current standard is RFC2132. ISC also supports the ability to support RFC draft "options" by configuring an option definition. There is one thing you need to keep in mind when configuring definitions. Although there is a wide array of DHCP standard and experiential options, the majority of DHCP clients only support a small subset making the real limitation of our DHCP server's functionality the DHCP clients (which we have little control over) rather than the server. Here is a list of the most commonly supported options, with their option codes (#):

• option <new-option-name> code <DHCP option code> = definition -- Provides the ability to define new or experimental options. There are eight definition types:

• <Boolean>
• <unsigned or signed integer {8, 16, or 32}>
• <ip-address>
• <text>
• <string>
• <encapsulate>
• <array <of any of the definition types listed above>
• <record <sequence of the definition types listed above>
• option host-name <"name" > -- (12) Sets the clients local host name. This option in combination with the domain name option (15) will set the fully qualified domain name for the client.
• option dhcp-client-identifier <value> -- (61) Used by the server (and client) to define a unique client identifier in a host declaration. The identifier can be the host's Media Access Control (MAC) address prepended with HEX 01:xx.xx.xx.xx.xx.xx or an ASCII string. In some cases, the ASCII string may need to be prepended with none, one "\0" or three "\000" zeros; this all depends on what client you are supporting. By experimenting with the ASCII option, your clients are a must if you decide to implement option 61. You should also know that the Windows XP/2000 DHCP client does not support ASCII component of option 61.
• option domain-name-servers <x.x.x.x, x.x.x.x> -- (6) Provides domain name servers the host can use for DNS resolution. The servers should be listed in order of preference.
• option routers <x.x.x.x> -- (3) Provides the default gateway or list of gateways the host can use to forward packets off of the subnet. The routers should be listed in order of preference.
• option domain-name <domain.com> -- (15) This option sets the domain name the host should use when resolving domain name quires.
• option subnet-mask <x.x.x.x> -- (1) This option sets the hosts subnet mask. If this option is not set the server will glean the subnet mask value from the Subnet declaration.
• option netbios-name-servers <x.x.x.x> -- (44) This option provides a list of NetBIOS name resolution servers. The servers should be listed in order of preference.
• option netbios-node-type <integer> -- (46) This option defines how the host should resolve NetBIOS name quires.

• 1 = B-Node (No Wins) Broadcast
• 2 = P-Node (Wins Only) Peer
• 4 = M-Node (Broadcast, Wins) Mixed
• 8 = H-Node (Wins, then Broadcast) Hybrid
• Option dhcp-lease-time <in seconds> -- There are a number of timer values that inform the client how to manage its DHCP lease. Some of these timers are variables that are part of a Subnet or Pool definition. Others are traditional options:

  subnet x.x.x.x netmask x.x.x.x { 
  range x.x.x.x x.x.x.x; 
  default-lease-time 
     
      ;
  max-lease-time 
      
       ;
  min-lease-time 
       
        ; 
  }
  
       
      
     

• Default-lease-time <sec> -- (51) Used if client does not ask for a specific lease time of 12 hours.
• Max-lease-time <sec> -- Sets the longest lease the server can issue; time is assigned if the client's lease request is longer the MAX lease time. Twenty-four hours is the default.
• Min-lease-time <sec> -- Forces client to take a lease longer than the one it has requested. Zero seconds is the default.
• option dhcp-renewal-time <sec> -- (58) Set the time in seconds when the client starts to renew the lease sending a unicast DHCPREQUEST. If no time is specified, the client will use half of the asigned lease time.
• option dhcp-rebinding-time <sec> -- (59) Client looks for a new server to renew the address sending a broadcast DHCPREQUEST. If no time is specified the client will use seven-eighths of the negioated lease time.
• option dhcp-message <"text"> -- (56) This option is available to the server and client to provide error or event messages. How these messages are handled widely varies depending on the client. Some clients can display the messages to the user, others send the message to logging, and others simply ignore them. Like option 61, some experimentation is needed to see how your client environments respond.
• option dhcp-server-identifier <x.x.x.x>-- (54) This option is defined as part of the server's global declarations to inform clients of the servers "resolvable" IP address when the DHCP server has multiple IP addresses.

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:

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:

!
service dhcp
!
!
interface Fast Ethernet 0/0
ip address 172.30.71.1 255.255.255.0
ip helper address 172.30.40.254

Now let's take a look at the configuration, starting with the global parameters:

ddns-update-style none
authoritative; 
ddns-updates off; 
ping-check true; 
one-lease-per-client true; 
deny declines; 
deny bootp; 
deny duplicates; 
log-facility local5; 
option dhcp-server-identifier 172.30.40.2;

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:

option domain-search code 119 = string;

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.

subnet 172.30.40.0 netmask 255.255.255.0 {
range 172.30.40.20 172.30.71.41;
allow unknown clients;
option dhcp-message "Welcome to Outlan Open!";
option routers 172.30.40.1;
option domain-search "outlan.net,usr.outlan.net";
option domain-name "open.outlan.net";
option domain-name-servers 172.30.40.101;
option broadcast-address 172.30.80.255;
default-lease-time 28800; 
max-lease-time 28800;
min-lease-time 3800;
option dhcp-renewal-time 14400;
option dhcp-rebinding-time 26000;

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:

subnet 172.30.41.0 netmask 255.255.255.0 {
option routers 172.30.41.1;
option domain-name-servers 172.30.80.101;
option subnet-mask 255.255.255.0;

The first pool defines the fishing addresses, open to any user:

pool {
range 172.30.41.190 172.30.41.191;
max-lease-time 30;
default-lease-time 30;
option dhcp-message "You are an unknown client please contact adminstration 

@ ext 4090 for network access.";
} <- End Of Pool Statement

The second pool provides addresses for "known" users:

pool {
deny unknown clients;
range 172.30.41.160 172.30.41.170;
option dhcp-message "Welcome to Outlan-S";

host trinity {
hardware ethernet 00:17:f2:40:97:6e;
} <- End Of host Statement

} <- End Of Pool Statement

} <- End Of Subnet Statement

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.

subnet 172.30.71.0 netmask 255.255.255.0 {
range 172.30.71.99 172.30.71.99;
option routers 172.30.71.1;
option domain-name "usr.outlan.net";
option domain-name-servers 172.30.80.101;
option dhcp-message "You have been assigned the learning address 

for outlan-wpa. 
Please contact the administration team @ ext 4090";
allow unknown-clients;
max-lease-time 30;
 default-lease-time 30;

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.

group user {
option dhcp-message "You have entered outlan-wpa";

host zuse.outlan.net {
fixed-address 172.30.71.150;
hardware ethernet 00:17:f2:40:97:6e;
option subnet-mask 255.255.255.0;
option domain-name "usr.outlan.net";
option host-name "zuse";
}

host trinity.outlan.net {
fixed-address 172.30.71.151;
option dhcp-client-identifier "\000trinity";
option subnet-mask 255.255.255.0; 
option domain-name "usr.outlan.net";
option host-name "trinity";
}

} <- End Of Group Statement

} <- End Of Subnet Statement

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.