DHCP fingerprinting is used in conjunction with user roles on the Aruba Mobility Controller. When a user authenticates, their device type is taken into account. Based on that device type, a new role can be assigned to the device, such as restricting access to certain protocols or completely blocking access. Because the system relies on user-defined roles, each organization can develop a system that meets their unique requirements.
Prerequisites
This section describes the prerequisites and dependencies for the ArubaOS DHCP fingerprinting feature.
1. The ArubaOS DHCP fingerprinting feature is available on the mobility controller and mobility access switch platforms running ArubaOS version 6.0.1 or later.
2. The PEFNG license must be present on the platform to assign user roles using the ArubaOS DHCP fingerprinting feature.
3. Clients must be set up to request IP addresses automatically using DHCP.
4. The controller must be in the data path of DHCP exchange, but it does not have to be the DHCP server.
5. There are additional requirements based on the forwarding mode of the AP. Table 2 lists the forwarding mode and platform dependencies.
Table 2 DHCP Fingerprinting Availability by Forwarding Mode and Platform
Product Availability
Table 3 describes the DHCP fingerprint availability by platform.
Table 3 Product Availability
What is a DHCP Fingerprint?
DHCP is a client/server protocol. As shown in Figure 2, the DHCP client exchanges a series of packets with the DHCP server to obtain a unique IP address and other important networking information, such as the default gateway and DNS server.
Figure 2 DHCP protocol Exchange
However, the DHCP protocol is not limited to obtaining basic IP networking information. It includes the flexibility to exchange vendor-specific information about the hardware or operating system of the device. This exchange is done by using DHCP options as defined by RFC 2132 (http://www.ietf.org/rfc/rfc2132.txt). Use of DHCP options is vendor-, device-, and OS-dependent, which creates significant differences in the DHCP packets generated by various devices and thus constitutes a DHCP "fingerprint" Figure 3 is an example of the options included in a DHCP DISCOVER message by an Apple iPad device.
Figure3 Options in a DHCP DISCOVER message
The ArubaOS DHCP fingerprinting feature instructs the stateful firewall to inspect the DHCP packet exchange and identify the device or OS type. Firewall rules can then be used to derive roles for the specific device or OS type.
Identifying a DHCP Fingerprint
Figure 4 Network diagram with an ArubaOS controller in the DHCP data path
ArubaOS DHCP fingerprinting relies on the stateful inspection of DHCP packet exchange, so it is required that the Aruba Mobility Controller is in the data path of the DHCP exchange. However, the mobility controller is not required to be the DHCP server. ArubaOS stateful firewall logs the DHCP options in the DHCP packets along with the MAC address of the client.
To begin the process of examining a DHCP fingerprint, some debugging commands need to be set to make the packets visible. This process can be done either from the web interface or the CLI. We are looking for a value that is unique to a class of device. In cases where more than one DHCP fingerprint is found, any can be used. Typical values of DHCP options are hex: 0c, 37, 3c, or 51. These values correspond to DHCP option numbers: 12, 55, 60, or 81. The goal is to find a value that is unique to that device.
If multiple clients are connecting at the same time, be sure to select the DHCP signature that matches the test device MAC address. Log messages can also be restricted to show output that matches the specific MAC address of the test device. It is a best practice to validate the DHCP signatures using several devices of same type. For a list of validated DHCP signatures developed by the Aruba QA team, see next table: Validated DHCP Fingerprint
Using the WebUI
1. Set the logging level for dhcp sub-category to level debugging. Navigate to Configuration Management Logging Levels.
2. Navigate to Monitoring Debug Process Logs.
3. From the right-side frame, select the Search function and select Filter Criteria: Include and String: Options. Click Display. The logs automatically refresh.
Figure 5 Filter options
4. Ensure that the wireless client is set up for DHCP and connect to the wireless network.
5. Watch the filtered logs section for matching log messages. When the client sends out the DHCP DISCOVER or REQUEST packet, a log message that contains the DHCP option is generated. Figure 6 shows a log message from an Apple iPad device with MAC address a4:d1:d2:1b:40:31.
Figure 6 Using WebUI log filtering to identify a DHCP fingerprint
Using the CLI
1. Ensure that the wireless client is set up for DHCP and connect to the wireless network. Note the wireless client MAC address. From the CLI, enter the “config terminal” context and enable logging level debug for DHCP.
(config)# logging level debugging network
2. Issue the CLI command to show log entries that match the MAC address of the client device being fingerprinted.
(config)#show log network all | include Options
3. Watch the filtered log messages for DHCP options. The output in Figure 7 is for an Apple iPad device with MAC address a4:d1:d2:1b:40:31.
(LC1-Sunnyvale-6000) (config) #show log all | include Options
Sep 7 11:38:08 dhcpdwrap[1829]: <202536> <DBUG> |dhcpdwrap| |dhcp| Datapath vlan900: REQUEST
a4:d1:d2:1b:40:31 reqIP=192.168.200.248 Options 37:0103060f77fc 39:05dc 3d:01a4d1d21b4031
36:c0a8c814 0c:6970616432
Figure 7 Using CLI log filtering to identify a DHCP fingerprint
From the log message output, we find DHCP options 55, 12, 50, and 51 (hex 37, 0C, 32, and 33 respectively). Based on reliable DHCP signatures include DHCP options 12, 55, 60, and 81. We can use any of these options to build a DHCP signature. For example, if we select the option 55 (hex 37), to create a DHCP fingerprint, drop the colon (”:”) and include all the hex numerals before and after the colon. The DHCP fingerprint for device with MAC a4:d1:d2:1b:40:31 is 370103060F77FC.Aruba internal testing, we have found that
User Role Creation
In an Aruba user-centric network, every device is associated with a user role based on login credentials, among other things. This same concept is extended to derive roles based on device type. For detailed configuration steps for roles and policies, refer to ArubaOS 6.1 User Guide, Chapter 12.
In our example, an enterprise has a mobile device access policy for two popular mobile device platforms, Apple iOS and Android, as shown in Table 4. Each class of device has a desired policy as determined by the organization. These policies are implemented by defining rules and applying them to the appropriate device-specific user role.
Table 4 Sample Mobile Device Access Policy for Android and iOS Devices
When devices connect to the WLAN network, they require a minimum set of services such as access to DHCP and DNS services. These services are defined in the Common-Policy and they are common to Apple iOS and Android device roles. Android devices are blocked from accessing the corporate internal network, while Apple iOS devices are allowed access to the internal network only through https. This permission is implemented in the block-internal-access and allow-corporate-https policies respectively. Finally, full access to the Internet is achieved by adding the allow-all policy as the last policy in the role.
Configuration for Common Policies Shared by Android and iOS Devices
ip access-list session common
user any udp 68 deny
any any svc-dhcp permit
any any svc-icmp permit
user alias dns-servers svc-dns permit
Figure 8 Common policies shared by Android devices
Next we will configure the access to internal resources, which will be used for the allow policy for iOS and for the deny policy for Android. For this setup, we will create a network destination alias. Netdestinations allow you to specify blocks of addresses and later make changes to those blocks without rewriting firewall policy.
Internal Corporate Network Destinations
netdestination Internal-Network
network 10.0.0.0 255.0.0.0
network 172.16.0.0 255.255.0.0
network 192.168.0.0 255.255.0.0
Figure 9 Internal corporate network destinations
Next we will create two policies, one that allows corporate resources to be accessed via HTTPS, and one that denies all access to those same resources. First we will configure the iOS policy, then the Android policy.
Configuration for the iOS allow-corporate-https Policy
ip access-list session allow-corporate-https
user alias Internal-Network svc-https permit
user alias Internal-Network any deny
Figure 10 Configuration for the iOS allow-corporate-https policy
Configuration for iOS Device Role
user-role iOS-Device-Role
access-list session common
access-list session allow-corporate-https
access-list session allowall
Figure 11 Policies for iOS device role
Policies for Android Devices
user-role Android-Device-Role
access-list session common
access-list session block-internal-access
access-list session allowall
Figure 12 Policies for Android devices
User Role Derivation
After a DHCP fingerprint has been identified and the device-specific roles have been created, we can now configure the policy for the devices. To get the correct policy assigned, we use “user rules” to change the devices role. Roles that are derived using DHCP fingerprinting take precedence over those derived using other methods, such as server-derived roles or roles derived using an Aruba vendorspecific attribute (VSA). This precedence means that roles derived by the DHCP fingerprint feature prevail even if the RADIUS server is set up to return a role attribute that is different. This functionality allows users to log into a device such as a laptop and receive a normal role via RADIUS, and then use the same credentials on an iPad and receive a different device role.
Roles are derived based on information learned from DHCP exchange, so devices receive this role after successful 802.11 association and Layer 2 authentication. For this reason, a role derived using DHCP fingerprinting is referred as the post-authentication role. It is important to note that while several ways are available for deriving a role in ArubaOS, DHCP fingerprinting is different from all of them.
DHCP fingerprinting operates on attributes that become available after a successful authentication, which extends the role-derivation capability in a powerful way.
DHCP fingerprinting is classified as one of the methods under the user-derived role framework. However, it differs from other methods in an important respect.
DHCP fingerprinting has higher precedence than all other role-derivation methods.
To derive device-specific roles from the WebUI and the CLI, follow these steps.
Using the WebUI
1. Navigate to Configuration Security Authentication.
2. Click User Rules. Click Add to add a user-derived rule.
3. Choose a name for the user-derived rule. See example byod-rules.
4. Click Add to add a new rule set. The screen in Figure 13 is displayed.
Figure 13 Adding rules to derive roles using DHCP Option from WebUI
5. For Set Type, choose Role to derive roles.
6. For Rule Type, choose DHCP-Option.
7. For Condition, choose equals. This rule is set up especially to match DHCP option and its operand values in hex, so equals and starts-with are the only allowed conditions.
8. In the Value field, copy and paste the DHCP fingerprint. Ensure that no colon characters or extra whitespace are included and that only the hex numerals are included.
9. For Roles, choose the device-specific role that was created earlier.
Using the CLI
From the CLI, enter the “config terminal” context and issue the following commands:
aaa derivation-rules user byod-rules
set role condition dhcp-option equals "3C64686370636420342E302E3135" set-value Android-Device-
Role description "Android devices"
set role condition dhcp-option equals "370103060F77FC" set-value iOS-Device-Role description
"iOS devices"
Conclusion
Enterprises and employees are rapidly adopting next-generation smartphones and tablet devices. Wireless is the only way to connect these devices to the network and WLAN is the primary method of connecting to an enterprise network. IT staff require tools that enable them to control the network usage, applications, content, and bandwidth and gain greater visibility into the user and type of devices. ArubaOS delivers a powerful new tool, DHCP fingerprinting, which enables IT staff to create and enforce granular policies per device, per application, and per user. This added functionality is made possible using the same Aruba WLAN infrastructure without adding additional appliances or rearchitecting the network.
No comments:
Post a Comment