-
null
The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.
This chapter contains the following sections:
This section contains the following topics:
The Cisco Unified Wireless Network (UWN) security solution bundles potentially complicated Layer 1, Layer 2, and Layer 3 802.11 Access Point security components into a simple policy manager that customizes system-wide security policies on a per-WLAN basis. The Cisco UWN security solution provides simple, unified, and systematic security management tools.
One of the biggest hurdles to WLAN deployment in the enterprise is WEP encryption, which is a weak standalone encryption method. A newer problem is the availability of low-cost access points, which can be connected to the enterprise network and used to mount man-in-the-middle and denial-of-service attacks.
The Cisco UWN security solution ensures that all clients gain access within a user-set number of attempts. If a client fails to gain access within that limit, it is automatically excluded (blocked from access) until the user-set timer expires. The operating system can also disable SSID broadcasts on a per-WLAN basis.
If a higher level of security and encryption is required, you can also implement industry-standard security solutions such as Extensible Authentication Protocol (EAP), Wi-Fi Protected Access (WPA), and WPA2. The Cisco UWN solution WPA implementation includes AES (Advanced Encryption Standard), TKIP and Michael (temporal key integrity protocol and message integrity code checksum) dynamic keys, or WEP (Wired Equivalent Privacy) static keys. Disabling is also used to automatically block Layer 2 access after a user-set number of failed authentication attempts.
Regardless of the wireless security solution selected, all Layer 2 wired communications between controllers and lightweight access points are secured by passing data through CAPWAP tunnels.
Cisco Aironet client adapter version 4.2 does not authenticate if WPA/WPA2 is used with CCKM as auth key management and a 2 second latency between the controller and AP.
The WEP problem can be further solved using industry-standard Layer 3 security solutions such as passthrough VPNs (virtual private networks).
The Cisco UWN solution supports local and RADIUS MAC (media access control) filtering. This filtering is best suited to smaller client groups with a known list of 802.11 access card MAC addresses.
The Cisco UWN solution supports local and RADIUS user/password authentication. This authentication is best suited to small to medium client groups.
The integrated security solutions are as follows:
This section contains the following topics:
Remote Authentication Dial-In User Service (RADIUS) is a client/server protocol that provides centralized security for users attempting to gain management access to a network. It serves as a backend database similar to local and TACACS+ and provides authentication and accounting services:
Users must enter a valid username and password in order for the controller to authenticate users to the RADIUS server. If multiple databases are configured, you can specify the sequence in which the backend database must be tired.
Whenever a user successfully executes an action, the RADIUS accounting server logs the changed attributes, the user ID of the person who made the change, the remote host where the user is logged in, the date and time when the command was executed, the authorization level of the user, and a description of the action performed and the values provided. If the RADIUS accounting server becomes unreachable, users are able to continue their sessions uninterrupted.
RADIUS uses User Datagram Protocol (UDP) for its transport. It maintains a database and listens on UDP port 1812 for incoming authentication requests and UDP port 1813 for incoming accounting requests. The controller, which requires access control, acts as the client and requests AAA services from the server. The traffic between the controller and the server is encrypted by an algorithm defined in the protocol and a shared secret key configured on both devices.
You can configure multiple RADIUS accounting and authentication servers.For example, you may want to have one central RADIUS authentication server but several RADIUS accounting servers in different regions. If you configure multiple servers of the same type and the first one fails or becomes unreachable, the controller automatically tries the second one, then the third one if necessary, and so on.
Also, the Callback Administrative service type gives the user the lobby ambassador privileges to the controller.
The primary RADIUS server (the server with the lowest server index) is assumed to be the most preferable server for the controller. If the primary server becomes unresponsive, the controller switches to the next active backup server (the server with the next lowest server index). The controller continues to use this backup server, unless you configure the controller to fall back to the primary RADIUS server when it recovers and becomes responsive or to a more preferable server from the available backup servers.
Step 1 Choose Network Configuration on the ACS main page.
Step 2 Choose Add Entry under AAA Clients to add your controller to the server. The Add AAA Client page appears.
Figure 7-1 Add AAA Client Page on CiscoSecure ACS
Step 3 In the AAA Client Hostname text box, enter the name of your controller.
Step 4 In the AAA Client IP Address text box, enter the IP address of your controller.
Step 5 In the Shared Secret text box, enter the shared secret key to be used for authentication between the server and the controller.
Note The shared secret key must be the same on both the server and the controller.
Step 6 From the Authenticate Using drop-down list, choose RADIUS (Cisco Aironet) .
Step 7 Click Submit + Apply to save your changes.
Step 8 Choose Interface Configuration on the ACS main page.
Step 9 Choose RADIUS (Cisco Aironet) . The RADIUS (Cisco Aironet) page appears.
Step 10 Under User Group, select the Cisco-Aironet-Session-Timeout check box.
Step 11 Click Submit to save your changes.
Step 12 On the ACS main page, from the left navigation pane, choose System Configuration.
Step 14 When the Logging Configuration page appears, enable all of the events that you want to be logged and save your changes.
Step 15 On the ACS main page, from the left navigation pane, choose Group Setup .
Step 16 Choose a previously created group from the Group drop-down list.
Note This step assumes that you have already assigned users to groups on the ACS according to the roles to which they will be assigned.
Step 17 Click Edit Settings . The Group Setup page appears.
Step 18 Under Cisco Aironet Attributes , select the Cisco-Aironet-Session-Timeout check box and enter a session timeout value in the edit box.
Step 19 Specify read-only or read-write access to controllers through RADIUS authentication, by setting the Service-Type attribute (006) to Callback NAS Prompt for read-only access or to Administrative for read-write privileges. If you do not set this attribute, the authentication process completes successfully (without an authorization error on the controller), but you might be prompted to authenticate again.
Note If you set the Service-Type attribute on the ACS, make sure to select the Management check box on the RADIUS Authentication Servers page of the controller GUI. See If you are configuring a RADIUS authentication server, select the Management check box to enable management authentication, or unselect it to disable this feature. The default value is selected. If you enable this feature, this entry is considered the RADIUS authentication server for management users, and authentication requests go to the RADIUS server. in the next section for more information.
Note The “RADIUS Authentication Attributes Sent by the Access Point” section lists the RADIUS attributes that are sent by a lightweight access point to a client in access-request and access-accept packets.
Step 20 Click Submit to save your changes.
Step 1 Choose Security > AAA > RADIUS .
Step 2 Perform one of the following:
Note The pages used to configure authentication and accounting contain mostly the same text boxes. Therefore, these instructions walk through the configuration only once, using the Authentication pages as examples. You would follow the same steps to configure multiple services and/or multiple servers.
The RADIUS Authentication (or Accounting) Servers page appears.
Figure 7-2 RADIUS Authentication Servers Page
This page lists any RADIUS servers that have already been configured.
Step 3 From the Call Station ID Type drop-down list, choose IP Address , System MAC Address , or AP MAC Address to specify whether the IP address, system MAC address, or AP MAC address of the originator will be sent to the RADIUS server in the Access-Request message.
Step 4 Enable RADIUS-to-controller key transport using AES key wrap protection by selecting the Use AES Key Wrap check box. The default value is unselected. This feature is required for FIPS customers.
Step 5 Click Apply to commit your changes. Perform one of the following:
Step 6 If you are adding a new server, choose a number from the Server Index (Priority) drop-down list to specify the priority order of this server in relation to any other configured RADIUS servers providing the same service.
Step 7 If you are adding a new server, enter the IP address of the RADIUS server in the Server IP Address text box.
Step 8 From the Shared Secret Format drop-down list, choose ASCII or Hex to specify the format of the shared secret key to be used between the controller and the RADIUS server. The default value is ASCII.
Step 9 In the Shared Secret and Confirm Shared Secret text boxes, enter the shared secret key to be used for authentication between the controller and the server.
Note The shared secret key must be the same on both the server and the controller.
Step 10 If you are configuring a new RADIUS authentication server and want to enable AES key wrap, which makes the shared secret between the controller and the RADIUS server more secure, follow these steps:
Note AES key wrap is designed for Federal Information Processing Standards (FIPS) customers and requires a key-wrap compliant RADIUS authentication server.
a. Select the Key Wrap check box.
b. From the Key Wrap Format drop-down list, choose ASCII or HEX to specify the format of the AES key wrap keys: Key Encryption Key (KEK) and Message Authentication Code Key (MACK).
c. In the Key Encryption Key (KEK) text box, enter the 16-byte KEK.
d. In the Message Authentication Code Key (MACK) text box, enter the 20-byte KEK.
Step 11 If you are adding a new server, enter the RADIUS server’s UDP port number for the interface protocols in the Port Number text box. The valid range is 1 to 65535, and the default value is 1812 for authentication and 1813 for accounting.
Step 12 From the Server Status text box, choose Enabled to enable this RADIUS server or choose Disabled to disable it. The default value is enabled.
Step 13 If you are configuring a new RADIUS authentication server, choose Enabled from the Support for RFC 3576 drop-down list to enable RFC 3576, which is an extension to the RADIUS protocol that allows dynamic changes to a user session, or choose Disabled to disable this feature. The default value is Enabled. RFC 3576 includes support for disconnecting users and changing authorizations applicable to a user session and supports disconnect and change-of-authorization (CoA) messages. Disconnect messages cause a user session to be terminated immediately where CoA messages modify session authorization attributes such as data filters.
Step 14 In the Server Timeout text box, enter the number of seconds between retransmissions. The valid range is 2 to 30 seconds, and the default value is 2 seconds.
Note We recommend that you increase the timeout value if you experience repeated reauthentication attempts or the controller falls back to the backup server when the primary server is active and reachable.
Step 15 Select the Network User check box to enable network user authentication (or accounting), or unselect it to disable this feature. The default value is selected. If you enable this feature, this entry is considered the RADIUS authentication (or accounting) server for network users. If you did not configure a RADIUS server entry on the WLAN, you must enable this option for network users.
Step 16 If you are configuring a RADIUS authentication server, select the Management check box to enable management authentication, or unselect it to disable this feature. The default value is selected. If you enable this feature, this entry is considered the RADIUS authentication server for management users, and authentication requests go to the RADIUS server.
Step 17 Select the IPSec check box to enable the IP security mechanism, or unselect it to disable this feature. The default value is unselected.
Note The IPsec option appears only if a crypto card is installed in the controller.
Step 18 If you enabled IPsec in Select the IPSec check box to enable the IP security mechanism, or unselect it to disable this feature. The default value is unselected. , follow these steps to configure additional IPsec parameters:
a. From the IPSec drop-down list, choose one of the following options as the authentication protocol to be used for IP security: HMAC MD5 or HMAC SHA1 . The default value is HMAC SHA1.
A message authentication code (MAC) is used between two parties that share a secret key to validate information transmitted between them. HMAC (Hash MAC) is based on cryptographic hash functions. It can be used in combination with any iterated cryptographic hash function. HMAC MD5 and HMAC SHA1 are two constructs of the HMAC using the MD5 hash function and the SHA1 hash function. HMAC also uses a secret key for calculation and verification of the message authentication values.
b. From the IPSec Encryption drop-down list, choose one of the following options to specify the IP security encryption mechanism:
c. From the IKE Phase 1 drop-down list, choose one of the following options to specify the Internet Key Exchange (IKE) protocol: Aggressive or Main . The default value is Aggressive.
IKE Phase 1 is used to negotiate how IKE should be protected. Aggressive mode passes more information in fewer packets with the benefit of slightly faster connection establishment at the cost of transmitting the identities of the security gateways in the clear.
d. In the Lifetime text box, enter a value (in seconds) to specify the timeout interval for the session. The valid range is 1800 to 57600 seconds, and the default value is 1800 seconds.
e. From the IKE Diffie Hellman Group drop-down list, choose one of the following options to specify the IKE Diffie Hellman group: Group 1 (768 bits) , Group 2 (1024 bits) , or Group 5 (1536 bits) . The default value is Group 1 (768 bits).
Diffie-Hellman techniques are used by two devices to generate a symmetric key through which they can publicly exchange values and generate the same symmetric key. Although all three groups provide security from conventional attacks, Group 5 is considered more secure because of its larger key size. However, computations involving Group 1 and Group 2 based keys might occur slightly faster because of their smaller prime number size.
Step 19 Click Apply to commit your changes.
Step 20 Click Save Configuration to save your changes.
Step 21 Repeat the previous steps if you want to configure any additional services on the same server or any additional RADIUS servers.
Step 22 Specify the RADIUS server fallback behavior, as follows:
a. Choose Security > AAA > RADIUS > Fallback to open the RADIUS > Fallback Parameters to open the fallback parameters page.
b. From the Fallback Mode drop-down list, choose one of the following options:
c. If you enabled Active fallback mode in From the Fallback Mode drop-down list, choose one of the following options: , enter the name to be sent in the inactive server probes in the Username text box. You can enter up to 16 alphanumeric characters. The default value is “cisco-probe.”
d. If you enabled Active fallback mode in From the Fallback Mode drop-down list, choose one of the following options: , enter the probe interval value (in seconds) in the Interval in Sec text box. The interval serves as inactive time in passive mode and probe interval in active mode. The valid range is 180 to 3600 seconds, and the default value is 300 seconds.
Step 23 Specify the order of authentication when multiple databases are configured by choosing Security > Priority Order > Management User . The Priority Order > Management User page appears.
Step 24 In the Order Used for Authentication text box, specify which servers have priority when the controller attempts to authenticate management users. Use the > and < buttons to move servers between the Not Used and Order Used for Authentication text boxes. After the desired servers appear in the Order Used for Authentication text box, use the Up and Down buttons to move the priority server to the top of the list.
By default, the local database is always queried first. If the username is not found, the controller switches to the RADIUS server if configured for RADIUS or to the TACACS+ server if configured for TACACS+. The default setting is local and then RADIUS.
Step 25 Click Apply to commit your changes.
Step 26 Click Save Configuration to save your changes.
Step 1 Specify whether the IP address, system MAC address, or AP MAC address of the originator will be sent to the RADIUS server in the Access-Request message by entering this command:
config radius callStationIdType { ip_address | mac_address | ap_mac_address | ap_macaddr_ssid }
Note The default is MAC address.
Note Do not use callStation IdType for IPv6-only clients.
Step 2 Specify the delimiter to be used in the MAC addresses that are sent to the RADIUS authentication or accounting server in Access-Request messages by entering this command:
config radius { auth | acct } mac-delimiter { colon | hyphen | single-hyphen | none }
Step 3 Configure a RADIUS authentication server by entering these commands:
– kek specifies the 16-byte Key Encryption Key (KEK).
– mack specifies the 20-byte Message Authentication Code Key (MACK).
– index specifies the index of the RADIUS authentication server on which to configure the AES key wrap.
Step 4 Configure a RADIUS accounting server by entering these commands:
index—Enables or disables a RADIUS accounting server.
Step 5 Configure the RADIUS server fallback behavior by entering this command:
config radius fallback-test mode {off | passive | active}
Step 6 If you enabled Active mode in Configure the RADIUS server fallback behavior by entering this command: , enter these commands to configure additional fallback parameters:
Step 7 Save your changes by entering this command:
Step 8 Configure the order of authentication when multiple databases are configured by entering this command:
config aaa auth mgmt AAA_server_type AAA_server_type
where AAA_server_type is local, radius, or tacacs.
To see the current management authentication server order, enter the show aaa auth command.
Step 9 See RADIUS statistics by entering these commands:
Step 10 See active security associations by entering these commands:
Step 11 Clear the statistics for one or more RADIUS servers by entering this command:
clear stats radius { auth | acct} { index | all }
Step 12 Make sure that the controller can reach the RADIUS server by entering this command:
Table 7-1 through Table 7-5 identify the RADIUS authentication attributes sent by a lightweight access point to a client in access-request and access-accept packets.
Service-Type1 |
|
1.To specify read-only or read-write access to controllers through RADIUS authentication, you must set the Service-Type attribute (6) on the RADIUS server to Callback NAS Prompt for read-only access or to Administrative for read-write privileges. See Specify read-only or read-write access to controllers through RADIUS authentication, by setting the Service-Type attribute (006) to Callback NAS Prompt for read-only access or to Administrative for read-write privileges. If you do not set this attribute, the authentication process completes successfully (without an authorization error on the controller), but you might be prompted to authenticate again. in the “Configuring RADIUS on the ACS” section for more information. |
Note These Cisco-specific attributes are not supported: Auth-Algo-Type and SSID.
Note Message authentication is not supported.
This section contains the following topics:
Terminal Access Controller Access Control System Plus (TACACS+) is a client/server protocol that provides centralized security for users attempting to gain management access to a controller. It serves as a backend database similar to local and RADIUS. However, local and RADIUS provide only authentication support and limited authorization support while TACACS+ provides three services:
Users must enter a valid username and password in order for the controller to authenticate users to the TACACS+ server. The authentication and authorization services are tied to one another. For example, if authentication is performed using the local or RADIUS database, then authorization would use the permissions associated with the user in the local or RADIUS database (which are read-only, read-write, and lobby-admin) and not use TACACS+. Similarly, when authentication is performed using TACACS+, authorization is tied to TACACS+.
Note When multiple databases are configured, you can use the controller GUI or CLI to specify the sequence in which the backend databases should be tried.
For TACACS+, authorization is based on privilege (or role) rather than specific actions. The available roles correspond to the seven menu options on the controller GUI: MONITOR, WLAN, CONTROLLER, WIRELESS, SECURITY, MANAGEMENT, and COMMANDS. An additional role, LOBBY, is available for users who require only lobby ambassador privileges. The roles to which users are assigned are configured on the TACACS+ server. Users can be authorized for one or more roles. The minimum authorization is MONITOR only, and the maximum is ALL, which authorizes the user to execute the functionality associated with all seven menu options. For example, a user who is assigned the role of SECURITY can make changes to any items appearing on the Security menu (or designated as security commands in the case of the CLI). If users are not authorized for a particular role (such as WLAN), they can still access that menu option in read-only mode (or the associated CLI show commands). If the TACACS+ authorization server becomes unreachable or unable to authorize, users are unable to log into the controller.
Note If users attempt to make changes on a controller GUI page that are not permitted for their assigned role, a message appears indicating that they do not have sufficient privilege. If users enter a controller CLI command that is not permitted for their assigned role, a message may appear indicating that the command was successfully executed although it was not. In this case, the following additional message appears to inform users that they lack sufficient privileges to successfully execute the command: “Insufficient Privilege! Cannot execute command!”
Whenever a user successfully executes an action, the TACACS+ accounting server logs the changed attributes, the user ID of the person who made the change, the remote host where the user is logged in, the date and time when the command was executed, the authorization level of the user, and a description of the action performed and the values provided. If the TACACS+ accounting server becomes unreachable, users are able to continue their sessions uninterrupted.
TACACS+ uses Transmission Control Protocol (TCP) for its transport, unlike RADIUS which uses User Datagram Protocol (UDP). It maintains a database and listens on TCP port 49 for incoming requests. The controller, which requires access control, acts as the client and requests AAA services from the server. The traffic between the controller and the server is encrypted by an algorithm defined in the protocol and a shared secret key configured on both devices.
You can configure up to three TACACS+ authentication, authorization, and accounting servers each. For example, you may want to have one central TACACS+ authentication server but several TACACS+ authorization servers in different regions. If you configure multiple servers of the same type and the first one fails or becomes unreachable, the controller automatically tries the second one and then the third one if necessary.
Note If multiple TACACS+ servers are configured for redundancy, the user database must be identical in all the servers for the backup to work properly.
The Internet Engineering Task Force (IETF) draft standard specifies a method for communicating vendor-specific attributes (VSAs) between the network access server and the TACACS+ server. The IETF uses attribute 26. VSAs allow vendors to support their own extended attributes that are not suitable for general use.
The Cisco TACACS+ implementation supports one vendor-specific option using the format recommended in the IETF specification. The Cisco vendor ID is 9, and the supported option is vendor type 1, which is named cisco-av-pair. The value is a string with the following format:
The protocol is a Cisco attribute for a particular type of authorization, the separator is = (equal sign) for mandatory attributes, and * (asterisk) indicates optional attributes.
Step 1 Choose Network Configuration on the ACS main page.
Step 2 Choose Add Entry under AAA Clients to add your controller to the server. The Add AAA Client page appears.
Figure 7-3 Add AAA Client Page on CiscoSecure ACS
Step 3 In the AAA Client Hostname text box, enter the name of your controller.
Step 4 In the AAA Client IP Address text box, enter the IP address of your controller.
Step 5 In the Shared Secret text box, enter the shared secret key to be used for authentication between the server and the controller.
Note The shared secret key must be the same on both the server and the controller.
Step 6 From the Authenticate Using drop-down list, choose TACACS+ (Cisco IOS) .
Step 7 Click Submit + Apply to save your changes.
Step 8 On the ACS main page, in the left navigation pane, choose Interface Configuration .
Step 9 Choose TACACS+ (Cisco IOS) . The TACACS+ (Cisco) page appears.
Step 10 Under TACACS+ Services, select the Shell (exec) check box.
Step 11 Under New Services, select the first check box and enter ciscowlc in the Service text box and common in the Protocol text box.
Step 12 Under Advanced Configuration Options, select the Advanced TACACS+ Features check box.
Step 13 Click Submit to save your changes.
Step 14 On the ACS main page, in the left navigation pane, choose System Configuration .
Step 16 When the Logging Configuration page appears, enable all of the events that you want to be logged and save your changes.
Step 17 On the ACS main page, in the left navigation pane, choose Group Setup.
Step 18 From the Group drop-down list, choose a previously created group.
Note This step assumes that you have already assigned users to groups on the ACS according to the roles to which they will be assigned.
Step 19 Click Edit Settings . The Group Setup page appears.
Step 20 Under TACACS+ Settings , select the ciscowlc common check box.
Step 21 Select the Custom Attributes check box.
Step 22 In the text box below Custom Attributes, specify the roles that you want to assign to this group. The available roles are MONITOR, WLAN, CONTROLLER, WIRELESS, SECURITY, MANAGEMENT, COMMANDS, ALL, and LOBBY. The first seven correspond to the menu options on the controller GUI and allow access to those particular controller features. You can enter one or multiple roles, depending on the group’s needs. Use ALL to specify all seven roles or LOBBY to specify the lobby ambassador role. Enter the roles using this format:
For example, to specify the WLAN, CONTROLLER, and SECURITY roles for a particular user group, you would enter the following text:
To give a user group access to all seven roles, you would enter the following text:
Note Make sure to enter the roles using the format shown above. The roles must be in all uppercase letters, and there can be no spaces within the text.
Note You should not combine the MONITOR role or the LOBBY role with any other roles. If you specify one of these two roles in the Custom Attributes text box, users will have MONITOR or LOBBY privileges only, even if additional roles are specified.
Step 23 Click Submit to save your changes.
Step 1 Choose Security > AAA > TACACS+ .
Step 2 Perform one of the following:
Note The pages used to configure authentication, authorization, and accounting all contain the same text boxes. Therefore, these instructions walk through the configuration only once, using the Authentication pages as examples. You would follow the same steps to configure multiple services and/or multiple servers.
Note For basic management authentication via TACACS+ to succeed, it is required to configure authentication and authorization servers on the WLC. Accounting configuration is optional.
The TACACS+ (Authentication, Authorization, or Accounting) Servers page appears. This page lists any TACACS+ servers that have already been configured.
Step 3 Perform one of the following:
Step 4 If you are adding a new server, choose a number from the Server Index (Priority) drop-down list to specify the priority order of this server in relation to any other configured TACACS+ servers providing the same service. You can configure up to three servers. If the controller cannot reach the first server, it tries the second one in the list and then the third if necessary.
Step 5 If you are adding a new server, enter the IP address of the TACACS+ server in the Server IP Address text box.
Step 6 From the Shared Secret Format drop-down list, choose ASCII or Hex to specify the format of the shared secret key to be used between the controller and the TACACS+ server. The default value is ASCII.
Step 7 In the Shared Secret and Confirm Shared Secret text boxes, enter the shared secret key to be used for authentication between the controller and the server.
Note The shared secret key must be the same on both the server and the controller.
Step 8 If you are adding a new server, enter the TACACS+ server’s TCP port number for the interface protocols in the Port Number text box. The valid range is 1 to 65535, and the default value is 49.
Step 9 In the Server Status text box, choose Enabled to enable this TACACS+ server or choose Disabled to disable it. The default value is Enabled.
Step 10 In the Server Timeout text box, enter the number of seconds between retransmissions. The valid range is 5 to 30 seconds, and the default value is 5 seconds.
Note We recommend that you increase the timeout value if you experience repeated reauthentication attempts or the controller falls back to the backup server when the primary server is active and reachable.
Step 11 Click Apply to commit your changes.
Step 12 Click Save Configuration to save your changes.
Step 13 Repeat the previous steps if you want to configure any additional services on the same server or any additional TACACS+ servers.
Step 14 Specify the order of authentication when multiple databases are configured by choosing Security > Priority Order > Management User . The Priority Order > Management User page appears.
Step 15 In the Order Used for Authentication text box, specify which servers have priority when the controller attempts to authenticate management users. Use the > and < buttons to move servers between the Not Used and Order Used for Authentication text boxes. After the desired servers appear in the Order Used for Authentication text box, use the Up and Down buttons to move the priority server to the top of the list.
By default, the local database is always queried first. If the username is not found, the controller switches to the RADIUS server if configured for RADIUS or to the TACACS+ server if configured for TACACS+. The default setting is local and then RADIUS.
Step 16 Click Apply to commit your changes.
Step 17 Click Save Configuration to save your changes.
– config tacacs auth add index server_ip_address port# { ascii | hex } shared_secret —Adds a TACACS+ authentication server.
– config tacacs auth delete index —Deletes a previously added TACACS+ authentication server.
– config tacacs auth ( enable | disable } index —Enables or disables a TACACS+ authentication server.
– config tacacs auth server-timeout index timeout —Configures the network login retransmission timeout value for a TACACS+ authentication server.
– config tacacs auth mgmt-server-timeout index timeout —Configures the management login retransmission timeout value for a TACACS+ authentication server.
– config tacacs athr add index server_ip_address port# { ascii | hex } shared_secret —Adds a TACACS+ authorization server.
– config tacacs athr delete index —Deletes a previously added TACACS+ authorization server.
– config tacacs athr ( enable | disable } index —Enables or disables a TACACS+ authorization server.
– config tacacs athr server-timeout index timeout —Configures the network login retransmission timeout value for a TACACS+ authorization server.
– config tacacs mgmt-athr server-timeout index timeout —Configures the management login retransmission timeout value for a TACACS+ authorization server.
– config tacacs acct add index server_ip_address port# { ascii | hex } shared_secret —Adds a TACACS+ accounting server.
– config tacacs acct delete index —Deletes a previously added TACACS+ accounting server.
– config tacacs acct ( enable | disable } index —Enables or disables a TACACS+ accounting server.
– config tacacs acct server-timeout index timeout —Configures the retransmission timeout value for a TACACS+ accounting server.
– show tacacs summary —Shows a summary of TACACS+ servers and statistics.
– show tacacs auth stats —Shows the TACACS+ authentication server statistics.
– show tacacs athr stats —Shows the TACACS+ authorization server statistics.
– show tacacs acct stats —Shows the TACACS+ accounting server statistics.
clear stats tacacs [ auth | athr | acct ] { index | all }
config aaa auth mgmt [ radius | tacacs ]
See the current management authentication server order by entering the show aaa auth command.
You must have configured TACACS+ accounting server on the controller.
Step 1 On the ACS main page, in the left navigation pane, choose Reports and Activity.
Step 2 Under Reports, choose TACACS+ Administration .
Step 3 Click the .csv file corresponding to the date of the logs you want to view. The TACACS+ Administration .csv page appears.
Figure 7-4 TACACS+ Administration .csv Page on CiscoSecure ACS
This page displays the following information:
Sometimes a single action (or command) is logged multiple times, once for each parameter in the command. For example, if you enter the snmp community ipaddr ip_address subnet_mask community_name command, the IP address may be logged on one line while the subnet mask and community name are logged as “E.” On another line, the subnet mask maybe logged while the IP address and community name are logged as “E.” See the first and third lines in the example in Figure 7-5.
Figure 7-5 TACACS+ Administration .csv Page on CiscoSecure ACS
This section contains the following topics:
You can configure the controller to specify the maximum number of local database entries used for storing user authentication information. The database entries include local management users (including lobby ambassadors), local network users (including guest users), MAC filter entries, exclusion list entries, and access point authorization list entries. Together, they cannot exceed the configured maximum value.
Step 1 Choose Security > AAA > General to open the General page.
Step 2 In the Maximum Local Database Entries text box, enter a value for the maximum number of entries that can be added to the local database the next time the controller reboots. The currently configured value appears in parentheses to the right of the text box. The valid range is 512 to 2048, and the default setting is 2048.
The Number of Entries, Already Used text box shows the number of entries currently in the database.
Step 3 Click Apply to commit your changes.
Step 4 Click Save Configuration to save your settings.
Step 1 Specify the maximum number of entries that can be added to the local database the next time the controller reboots by entering this command:
config database size max_entries
Step 2 Save your changes by entering this command:
Step 3 View the maximum number of database entries and the current database contents by entering this command:
This section contains the following topics:
You can add local network users to the local user database on the controller. The local user database stores the credentials (username and password) of all the local network users. These credentials are then used to authenticate the users. For example, local EAP may use the local user database as its backend database to retrieve user credentials.
Note The controller passes client information to the RADIUS authentication server first. If the client information does not match a RADIUS database entry, the local user database is polled. Clients located in this database are granted access to network services if the RADIUS authentication fails or does not exist.
Step 1 Choose Security > AAA > Local Net Users to open the Local Net Users page.
Figure 7-7 Local Net Users Page
This page lists any local network users that have already been configured. It also specifies any guest users and the QoS role to which they are assigned (if applicable).
Note If you want to delete an existing user, hover your cursor over the blue drop-down arrow for that user and choose Remove.
Step 2 Perform one of the following:
Step 3 If you are adding a new user, enter a username for the local user in the User Name text box. You can enter up to 24 alphanumeric characters.
Note Local network usernames must be unique because they are all stored in the same database.
Step 4 In the Password and Confirm Password text boxes, enter a password for the local user. You can enter up to 24 alphanumeric characters.
Step 5 If you are adding a new user, select the Guest User check box if you want to limit the amount of time that the user has access to the local network. The default setting is unselected.
Step 6 If you are adding a new user and you selected the Guest User check box, enter the amount of time (in seconds) that the guest user account is to remain active in the Lifetime text box. The valid range is 60 to 2,592,000 seconds (30 days) inclusive, and the default setting is 86,400 seconds.
Step 7 If you are adding a new user, you selected the Guest User check box, and you want to assign a QoS role to this guest user, select the Guest User Role check box. The default setting is unselected.
Note If you do not assign a QoS role to a guest user, the bandwidth contracts for this user are defined in the QoS profile for the WLAN.
Step 8 If you are adding a new user and you selected the Guest User Role check box, choose the QoS role that you want to assign to this guest user from the Role drop-down list.
Step 9 From the WLAN Profile drop-down list, choose the name of the WLAN that is to be accessed by the local user. If you choose Any WLAN , which is the default setting, the user can access any of the configured WLANs.
Step 10 In the Description text box, enter a descriptive title for the local user (such as “User 1”).
Step 11 Click Apply to commit your changes.
Step 12 Click Save Configuration to save your changes.
– config netuser add username password wlan wlan_id userType permanent description description —Adds a permanent user to the local user database on the controller.
– config netuser add username password { wlan | guestlan} { wlan_id | guest_lan_id} userType guestlifetime seconds description description —Adds a guest user on a WLAN or wired guest LAN to the local user database on the controller.
Note Instead of adding a permanent user or a guest user to the local user database from the controller, you can choose to create an entry on the RADIUS server for the user and enable RADIUS authentication for the WLAN on which web authentication is performed.
– config netuser delete username —Deletes a user from the local user database on the controller.
Note Local network usernames must be unique because they are all stored in the same database.
– show netuser detail username —Shows the configuration of a particular user in the local user database.
– show netuser summary —Lists all the users in the local user database.
To know more about configuring local network users, see “Configuring Local EAP” section for more information.
If you want to create a new QoS role, see the “Configuring Quality of Service” section for instructions.
This section contains the following topics:
The password policies allows you to enforce strong password checks on newly created passwords for additional management users of controller and access point. The following are the requirements enforced on the new password:
Step 1 Choose Security > AAA > Password Policies to open the Password Policies page.
Step 2 Select the Password must contain characters from at least 3 different classes check box if you want your password to contain characters from at least three of the following classes: lower case letters, upper case letters, digits, and special characters.
Step 3 Select No character can be repeated more than 3 times consecutively check box if you do not want character in the new password to repeat more than three times consecutively.
Step 4 Select the Password cannot be the default words like cisco, admin check box if you do not want the password to contain words such as Cisco, ocsic, admin, nimda, or any variant obtained by changing the capitalization of letters or by substituting 1, |, or! or substituting 0 for o or substituting $ for s.
Step 5 Select the Password cannot contain username or reverse of username check box if you do not want the password to contain a username or the reverse letters of a username.
Step 6 Click Apply to commit your changes.
Step 7 Click Save Configuration to save your changes.
Step 1 Enable or disable strong password check for AP and WLC by entering this command:
config switchconfig strong-pwd { case-check | consecutive-check | default-check | username-check | all-check } { enable | disable }
Step 2 See the configured options for strong password check by entering this command:
This section explains how to configure a Lightweight Directory Access Protocol (LDAP) server as a backend database, similar to a RADIUS or local user database.
This section contains the following topics:
An LDAP backend database allows the controller to query an LDAP server for the credentials (username and password) of a particular user. These credentials are then used to authenticate the user. For example, local EAP may use an LDAP server as its backend database to retrieve user credentials.
Note The LDAP backend database supports these local EAP methods: EAP-TLS, EAP-FAST/GTC, and PEAPv1/GTC. LEAP, EAP-FAST/MSCHAPv2, and PEAPv0/MSCHAPv2 are also supported but only if the LDAP server is set up to return a clear-text password.
Note Cisco wireless LAN controllers support Local EAP authentication against external LDAP databases such as Microsoft Active Directory and Novell’s eDirectory. For more information about configuring the controller for Local EAP authentication against Novell’s eDirectory, see the Configure Unified Wireless Network for Authentication Against Novell's eDirectory Database whitepaper at http://www.cisco.com/en/US/products/ps6366/products_white_paper09186a0080b4cd24.shtml.
Step 1 Choose Security > AAA > LDAP to open the LDAP Servers page.
This page lists any LDAP servers that have already been configured.
Step 2 Perform one of the following:
Step 3 If you are adding a new server, enter the IP address of the LDAP server in the Server IP Address text box.
Step 4 If you are adding a new server, enter the LDAP server’s TCP port number in the Port Number text box. The valid range is 1 to 65535, and the default value is 389.
Step 5 Select the Enable Server Status check box to enable this LDAP server or unselect it to disable it. The default value is disabled.
Step 6 From the Simple Bind drop-down list, choose Anonymous or Authenticated to specify the local authentication bind method for the LDAP server. The Anonymous method allows anonymous access to the LDAP server. The Authenticated method requires that a username and password be entered to secure access. The default value is Anonymous.
Step 7 If you chose Authenticated in From the Simple Bind drop-down list, choose Anonymous or Authenticated to specify the local authentication bind method for the LDAP server. The Anonymous method allows anonymous access to the LDAP server. The Authenticated method requires that a username and password be entered to secure access. The default value is Anonymous. , follow these steps:
a. In the Bind Username text box, enter a username to be used for local authentication to the LDAP server. The username can contain up to 80 characters.
Note If the username starts with “cn=” (in lowercase letters), the controller assumes that the username includes the entire LDAP database path and does not append the user base DN. This designation allows the authenticated bind user to be outside the user base DN.
b. In the Bind Password and Confirm Bind Password text boxes, enter a password to be used for local authentication to the LDAP server. The password can contain up to 32 characters.
Step 8 In the User Base DN text box, enter the distinguished name (DN) of the subtree in the LDAP server that contains a list of all the users. For example, ou=organizational unit, .ou=next organizational unit, and o=corporation.com. If the tree containing users is the base DN, type o= corporation .com or dc = corporation ,dc=com .
Step 9 In the User Attribute text box, enter the name of the attribute in the user record that contains the username. You can obtain this attribute from your directory server.
Step 10 In the User Object Type text box, enter the value of the LDAP objectType attribute that identifies the record as a user. Often, user records have several values for the objectType attribute, some of which are unique to the user and some of which are shared with other object types.
Step 11 In the Server Timeout text box, enter the number of seconds between retransmissions. The valid range is 2 to 30 seconds, and the default value is 2 seconds.
Step 12 Click Apply to commit your changes.
Step 13 Click Save Configuration to save your changes.
Step 14 Specify LDAP as the priority backend database server for local EAP authentication as follows:
a. Choose Security > Local EAP > Authentication Priority to open the Priority Order > Local-Auth page.
b. Highlight LOCAL and click < to move it to the left User Credentials box.
c. Highlight LDAP and click > to move it to the right User Credentials box. The database that appears at the top of the right User Credentials box is used when retrieving user credentials.
Note If both LDAP and LOCAL appear in the right User Credentials box with LDAP on the top and LOCAL on the bottom, local EAP attempts to authenticate clients using the LDAP backend database and fails over to the local user database if the LDAP servers are not reachable. If the user is not found, the authentication attempt is rejected. If LOCAL is on the top, local EAP attempts to authenticate using only the local user database. It does not fail over to the LDAP backend database.
d. Click Apply to commit your changes.
e. Click Save Configuration to save your changes.
Step 15 (Optional) Assign specific LDAP servers to a WLAN as follows:
a. Choose WLANs to open the WLANs page.
b. Click the ID number of the desired WLAN.
c. When the WLANs > Edit page appears, choose the Security > AAA Servers tabs to open the WLANs > Edit (Security > AAA Servers) page.
d. From the LDAP Servers drop-down lists, choose the LDAP server(s) that you want to use with this WLAN. You can choose up to three LDAP servers, which are tried in priority order.
Note These LDAP servers apply only to WLANs with web authentication enabled. They are not used by local EAP.
e. Click Apply to commit your changes.
f. Click Save Configuration to save your changes.
–
config ldap add
index
server_ip_address port#
user_base user_attr user_type
—
Adds an LDAP server.
– config ldap delete index —Deletes a previously added LDAP server.
– config ldap { enable | disable } index —Enables or disables an LDAP server.
– config ldap simple-bind { anonymous index | authenticated index username username password password }—Specifies the local authentication bind method for the LDAP server. The anonymous method allows anonymous access to the LDAP server whereas the authenticated method requires that a username and password be entered to secure access. The default value is anonymous.
Note The username can contain up to 80 characters.
Note If the username starts with “cn=” (in lowercase letters), the controller assumes that the username includes the entire LDAP database path and does not append the user base DN. This designation allows the authenticated bind user to be outside the user base DN.
– config ldap retransmit-timeout index timeout —Configures the number of seconds between retransmissions for an LDAP server.
config local-auth user-credentials ldap
Note If you enter the config local-auth user-credentials ldap local command, local EAP attempts to authenticate clients using the LDAP backend database and fails over to the local user database if the LDAP servers are not reachable. If the user is not found, the authentication attempt is rejected. If you enter the config local-auth user-credentials local ldap command, local EAP attempts to authenticate using only the local user database. It does not fail over to the LDAP backend database.
– config wlan ldap add wlan_id server_index —Links a configured LDAP server to a WLAN.
Note The LDAP servers specified in this command apply only to WLANs with web authentication enabled. They are not used by local EAP.
– config wlan ldap delete wlan_id { all | index }—Deletes a specific or all configured LDAP server(s) from a WLAN.
– show ldap summary —Shows a summary of the configured LDAP servers.
– show ldap index —Shows detailed LDAP server information. Information similar to following appears:
– show ldap statistics —Shows LDAP server statistics.
– show wlan wlan_id —Shows the LDAP servers that are applied to a WLAN.
For more information about configuring LEAP, see the “Configuring Local EAP” section.
This section contains the following topics:
Local EAP is an authentication method that allows users and wireless clients to be authenticated locally. It is designed for use in remote offices that want to maintain connectivity to wireless clients when the backend system becomes disrupted or the external authentication server goes down. When you enable local EAP, the controller serves as the authentication server and the local user database, which removes dependence on an external authentication server. Local EAP retrieves user credentials from the local user database or the LDAP backend database to authenticate users. Local EAP supports LEAP, EAP-FAST, EAP-TLS, P EAPv0/MSCHAPv2, and PEAPv1/GTC authentication between the controller and wireless clients.
Note The LDAP backend database supports these local EAP methods: EAP-TLS, EAP-FAST/GTC, and PEAPv1/GTC. LEAP, EAP-FAST/MSCHAPv2, and PEAPv0/MSCHAPv2 are also supported but only if the LDAP server is set up to return a clear-text password.
Note Cisco wireless LAN controllers support Local EAP authentication against external LDAP databases such as Microsoft Active Directory and Novell’s eDirectory. For more information about configuring the controller for Local EAP authentication against Novell’s eDirectory, see the Configure Unified Wireless Network for Authentication Against Novell's eDirectory Database whitepaper at http://www.cisco.com/en/US/products/ps6366/products_white_paper09186a0080b4cd24.shtml.
If any RADIUS servers are configured on the controller, the controller tries to authenticate the wireless clients using the RADIUS servers first. Local EAP is attempted only if no RADIUS servers are found, either because the RADIUS servers timed out or no RADIUS servers were configured. If four RADIUS servers are configured, the controller attempts to authenticate the client with the first RADIUS server, then the second RADIUS server, and then local EAP. If the client attempts to then reauthenticate manually, the controller tries the third RADIUS server, then the fourth RADIUS server, and then local EAP. If you never want the controller to try to authenticate clients using an external RADIUS server, enter these CLI commands in this order:
Note EAP-TLS, P EAPv0/MSCHAPv2, and PEAPv1/GTC use certificates for authentication, and EAP-FAST uses either certificates or PACbs. The controller is shipped with Cisco-installed device and Certificate Authority (CA) certificates. However, if you want to use your own vendor-specific certificates, they must be imported on the controller.
Step 1 If you are configuring local EAP to use one of the EAP types listed in the note above, make sure that the appropriate certificates and PACs (if you will use manual PAC provisioning) have been imported on the controller.
Step 2 If you want the controller to retrieve user credentials from the local user database, make sure that you have properly configured the local network users on the controller.
Step 3 If you want the controller to retrieve user credentials from an LDAP backend database, make sure that you have properly configured an LDAP server on the controller.
Step 4 Specify the order in which user credentials are retrieved from the backend database servers as follows:
a. Choose Security > Local EAP > Authentication Priority to open the Priority Order > Local-Auth page.
b. Determine the priority order in which user credentials are to be retrieved from the local and/or LDAP databases. For example, you may want the LDAP database to be given priority over the local user database, or you may not want the LDAP database to be considered at all.
c. When you have decided on a priority order, highlight the desired database. Then use the left and right arrows and the Up and Down buttons to move the desired database to the top of the right User Credentials box.
Note If both LDAP and LOCAL appear in the right User Credentials box with LDAP on the top and LOCAL on the bottom, local EAP attempts to authenticate clients using the LDAP backend database and fails over to the local user database if the LDAP servers are not reachable. If the user is not found, the authentication attempt is rejected. If LOCAL is on the top, local EAP attempts to authenticate using only the local user database. It does not fail over to the LDAP backend database.
d. Click Apply to commit your changes.
Step 5 Specify values for the local EAP timers as follows:
a. Choose Security > Local EAP > General to open the General page.
b. In the Local Auth Active Timeout text box, enter the amount of time (in seconds) in which the controller attempts to authenticate wireless clients using local EAP after any pair of configured RADIUS servers fails. The valid range is 1 to 3600 seconds, and the default setting is 100 seconds.
c. In the Identity Request Timeout text box, enter the amount of time (in seconds) in which the controller attempts to send an EAP identity request to wireless clients using local EAP. The valid range is 1 to 120 seconds, and the default setting is 30 seconds.
d. In the Identity Request Max Retries text box, enter the maximum number of times that the controller attempts to retransmit the EAP identity request to wireless clients using local EAP. The valid range is 1 to 20 retries, and the default setting is 20 retries.
e. In the Dynamic WEP Key Index text box, enter the key index used for dynamic wired equivalent privacy (WEP). The default value is 0, which corresponds to a key index of 1; the valid values are 0 to 3 (key index of 1 to 4).
f. In the Request Timeout text box, enter the amount of time (in seconds) in which the controller attempts to send an EAP request to wireless clients using local EAP. The valid range is 1 to 120 seconds, and the default setting is 30 seconds.
g. In the Request Max Retries text box, enter the maximum number of times that the controller attempts to retransmit the EAP request to wireless clients using local EAP. The valid range is 1 to 120 retries, and the default setting is 20 retries.
h. From the Max-Login Ignore Identity Response drop-down list, choose Enable to limit the number of devices that can be connected to the controller with the same username. You can log in up to eight times from different devices (PDA, laptop, IP phone, and so on) on the same controller. The default value is enabled.
i. In the EAPOL-Key Timeout text box, enter the amount of time (in seconds) in which the controller attempts to send an EAP key over the LAN to wireless clients using local EAP. The valid range is 1 to 5 seconds, and the default setting is 1 second.
Note If the controller and access point are separated by a WAN link, the default timeout of 1 second may not be sufficient.
j. In the EAPOL-Key Max Retries text box, enter the maximum number of times that the controller attempts to send an EAP key over the LAN to wireless clients using local EAP. The valid range is 0 to 4 retries, and the default setting is 2 retries.
k. Click Apply to commit your changes.
Step 6 Create a local EAP profile, which specifies the EAP authentication types that are supported on the wireless clients as follows:
a. Choose Security > Local EAP > Profiles to open the Local EAP Profiles page.
This page lists any local EAP profiles that have already been configured and specifies their EAP types. You can create up to 16 local EAP profiles.
Note If you want to delete an existing profile, hover your cursor over the blue drop-down arrow for that profile and choose Remove.
b. Click New to open the Local EAP Profiles > New page.
c. In the Profile Name text box, enter a name for your new profile and then click Apply .
Note You can enter up to 63 alphanumeric characters for the profile name. Make sure not to include spaces.
d. When the Local EAP Profiles page reappears, click the name of your new profile. The Local EAP Profiles > Edit page appears.
e. Select the LEAP , EAP-FAST , EAP-TLS, and/or PEAP check boxes to specify the EAP type that can be used for local authentication.
Note You can specify more than one EAP type per profile. However, if you choose multiple EAP types that use certificates (such as EAP-FAST with certificates, EAP-TLS, PEAPv0/MSCHAPv2, and PEAPv1/GTC), all of the EAP types must use the same certificate (from either Cisco or another vendor).
Note If you select the PEAP check box, both PEAPv0/MSCHAPv2 or PEAPv1/GTC are enabled on the controller.
f. If you chose EAP-FAST and want the device certificate on the controller to be used for authentication, select the Local Certificate Required check box. If you want to use EAP-FAST with PACs instead of certificates, leave this check box unselected, which is the default setting.
Note This option applies only to EAP-FAST because device certificates are not used with LEAP and are mandatory for EAP-TLS and PEAP.
g. If you chose EAP-FAST and want the wireless clients to send their device certificates to the controller in order to authenticate, select the Client Certificate Required check box. If you want to use EAP-FAST with PACs instead of certificates, leave this check box unselected, which is the default setting.
Note This option applies only to EAP-FAST because client certificates are not used with LEAP or PEAP and are mandatory for EAP-TLS.
h. If you chose EAP-FAST with certificates, EAP-TLS, or PEAP, choose which certificates will be sent to the client, the ones from Cisco or the ones from another Vendor , from the Certificate Issuer drop-down list. The default setting is Cisco.
i. If you chose EAP-FAST with certificates or EAP-TLS and want the incoming certificate from the client to be validated against the CA certificates on the controller, select the Check against CA certificates check box. The default setting is enabled.
j. If you chose EAP-FAST with certificates or EAP-TLS and want the common name (CN) in the incoming certificate to be validated against the CA certificates’ CN on the controller, select the Verify Certificate CN Identity check box. The default setting is disabled.
k. If you chose EAP-FAST with certificates or EAP-TLS and want the controller to verify that the incoming device certificate is still valid and has not expired, select the Check Certificate Date Validity check box. The default setting is enabled.
Note Certificate date validity is checked against the current UTC (GMT) time that is configured on the controller. Timezone offset will be ignored.
l. Click Apply to commit your changes.
Step 7 If you created an EAP-FAST profile, follow these steps to configure the EAP-FAST parameters:
a. Choose Security > Local EAP > EAP-FAST Parameters to open the EAP-FAST Method Parameters page.
b. In the Server Key and Confirm Server Key text boxes, enter the key (in hexadecimal characters) used to encrypt and decrypt PACs.
c. In the Time to Live for the PAC text box, enter the number of days for the PAC to remain viable. The valid range is 1 to 1000 days, and the default setting is 10 days.
d. In the Authority ID text box, enter the authority identifier of the local EAP-FAST server in hexadecimal characters. You can enter up to 32 hexadecimal characters, but you must enter an even number of characters.
e. In the Authority ID Information text box, enter the authority identifier of the local EAP-FAST server in text format.
f. If you want to enable anonymous provisioning, select the Anonymous Provision check box. This feature allows PACs to be sent automatically to clients that do not have one during PAC provisioning. If you disable this feature, PACS must be manually provisioned. The default setting is enabled.
Note If the local and/or client certificates are required and you want to force all EAP-FAST clients to use certificates, unselect the Anonymous Provision check box.
g. Click Apply to commit your changes.
Step 8 Enable local EAP on a WLAN as follows:
a. Choose WLANs to open the WLANs page.
b. Click the ID number of the desired WLAN.
c. When the WLANs > Edit page appears, choose the Security > AAA Servers tabs to open the WLANs > Edit (Security > AAA Servers) page.
d. Select the Local EAP Authentication check box to enable local EAP for this WLAN.
e. From the EAP Profile Name drop-down list, choose the EAP profile that you want to use for this WLAN.
f. If desired, choose the LDAP server that you want to use with local EAP on this WLAN from the LDAP Servers drop-down lists.
g. Click Apply to commit your changes.
Step 9 Click Save Configuration to save your changes.
Note EAP-TLS, P EAPv0/MSCHAPv2, and PEAPv1/GTC use certificates for authentication, and EAP-FAST uses either certificates or PACbs. The controller is shipped with Cisco-installed device and Certificate Authority (CA) certificates. However, if you want to use your own vendor-specific certificates, they must be imported on the controller.
Step 1 If you are configuring local EAP to use one of the EAP types listed in the note above, make sure that the appropriate certificates and PACs (if you will use manual PAC provisioning) have been imported on the controller.
Step 2 If you want the controller to retrieve user credentials from the local user database, make sure that you have properly configured the local network users on the controller.
Step 3 If you want the controller to retrieve user credentials from an LDAP backend database, make sure that you have properly configured an LDAP server on the controller.
Step 4 Specify the order in which user credentials are retrieved from the local and/or LDAP databases by entering this command:
config local-auth user-credentials { local | ldap }
Note If you enter the config local-auth user-credentials ldap local command, local EAP attempts to authenticate clients using the LDAP backend database and fails over to the local user database if the LDAP servers are not reachable. If the user is not found, the authentication attempt is rejected. If you enter the config local-auth user-credentials local ldap command, local EAP attempts to authenticate using only the local user database. It does not fail over to the LDAP backend database.
Step 5 Specify values for the local EAP timers by entering these commands:
Note If the controller and access point are separated by a WAN link, the default timeout of 1 second may not be sufficient.
Step 6 Create a local EAP profile by entering this command:
config local-auth eap-profile add profile_name
Note Do not include spaces within the profile name.
Note To delete a local EAP profile, enter the config local-auth eap-profile delete profile_name command.
Step 7 Add an EAP method to a local EAP profile by entering this command:
config local-auth eap-profile method add method profile_name
The supported methods are leap, fast, tls, and peap.
Note If you choose peap, both P EAPv0/MSCHAPv2 or PEAPv1/GTC are enabled on the controller.
Note You can specify more than one EAP type per profile. However, if you create a profile with multiple EAP types that use certificates (such as EAP-FAST with certificates, EAP-TLS, PEAPv0/MSCHAPv2, and PEAPv1/GTC), all of the EAP types must use the same certificate (from either Cisco or another vendor).
Note To delete an EAP method from a local EAP profile, enter the config local-auth eap-profile method delete method profile_name command:
Step 8 Configure EAP-FAST parameters if you created an EAP-FAST profile by entering this command:
config local-auth method fast ?
where ? is one of the following:
Step 9 Configure certificate parameters per profile by entering these commands:
Note This command applies only to EAP-FAST because device certificates are not used with LEAP and are mandatory for EAP-TLS and PEAP.
Note This command applies only to EAP-FAST because client certificates are not used with LEAP or PEAP and are mandatory for EAP-TLS.
Step 10 Enable local EAP and attach an EAP profile to a WLAN by entering this command:
config wlan local-auth enable profile_name wlan_id
Note To disable local EAP for a WLAN, enter the config wlan local-auth disable wlan_id command.
Step 11 Save your changes by entering this command:
Step 12 View information pertaining to local EAP by entering these commands:
Step 13 (Optional) Troubleshoot local EAP sessions by entering these commands:
Note In these two debug commands, sm is the state machine.
See “Managing Controller Software and Configurations,” for instructions on importing certificates and PACs.
See the “Configuring Local Network Users on the Controller” section for instructions.
See the “Configuring LDAP” section for instructions.
This section contains the following topics:
For the best integration with the Cisco UWN solution, SpectraLink NetLink Telephones require an extra operating system configuration step: enable long preambles . The radio preamble (sometimes called a header) is a section of data at the head of a packet that contains information that wireless devices need when sending and receiving packets. Short preambles improve throughput performance, so they are enabled by default. However, some wireless devices, such as SpectraLink NetLink phones, require long preambles.
Step 1 Choose Wireless > 802.11b/g/n > Network to open the 802.11b/g Global Parameters page.
Step 2 If the Short Preamble check box is selected, continue with this procedure. However, if the Short Preamble check box is unselected (which means that long preambles are enabled), the controller is already optimized for SpectraLink NetLink phones and you do not need to continue this procedure.
Step 3 Unselect the Short Preamble check box to enable long preambles.
Step 4 Click Apply to update the controller configuration.
Note If you do not already have an active CLI session to the controller, we recommend that you start a CLI session to reboot the controller and watch the reboot process. A CLI session is also useful because the GUI loses its connection when the controller reboots.
Step 5 Choose Commands > Reboot > Reboot > Save and Reboot to reboot the controller. Click OK in response to this prompt:
Step 6 Log back into the controller GUI to verify that the controller is properly configured.
Step 7 Choose Wireless > 802.11b/g/n > Network to open the 802.11b/g Global Parameters page. If the Short Preamble check box is unselected, the controller is optimized for SpectraLink NetLink phones.
Step 1 Log on to the controller CLI.
Step 2 Enter the show 802.11b command and select the Short preamble mandatory parameter. If the parameter indicates that short preambles are enabled, continue with this procedure. This example shows that short preambles are enabled:
However, if the parameter shows that short preambles are disabled (which means that long preambles are enabled), the controller is already optimized for SpectraLink NetLink phones and you do not need to continue this procedure.
Step 3 Disable the 802.11b/g network by entering this command:
config 802.11b disable network
You cannot enable long preambles on the 802.11a network.
Step 4 Enable long preambles by entering this command:
Step 5 Reenable the 802.11b/g network by entering this command:
Step 6 Enter the reset system command to reboot the controller. Enter y at the prompt to save the system changes. The controller reboots.
Step 7 Verify that the controller is properly configured by logging back into the CLI and entering the show 802.11b command to view these parameters:
These parameters show that the 802.11b/g network is enabled and that short preambles are disabled.
To configure 802.11 enhanced distributed channel access (EDCA) parameters to support SpectraLink phones, enter this command:
config advanced edca-parameters { svp-voice | wmm-default }
svp-voice enables SpectraLink voice priority (SVP) parameters and wmm-default enables wireless multimedia (WMM) default parameters.
Note To propagate this command to all access points connected to the controller, make sure to disable and then reenable the 802.11b/g network after entering this command.
This section contains the following topics:
The Cisco Identity Services Engine (ISE) is a next-generation, context-based access control solution that provides the functions of Cisco Secure Access Control System (ACS) and Cisco Network Admission Control (NAC) in one integrated platform.
ISE has been introduced in the 7.0.116.0 release of the Cisco Unified Wireless Network. ISE can be used to provide advanced security for your deployed network. It is an authentication server that you can configure on your controller. When a client associates to the controller on a RADIUS NAC–enabled WLAN, the controller forwards the request to the ISE server.
The ISE server validates the user in the database and on successful authentication, the URL and pre-AUTH ACL are sent to the client. The client then moves to the Posture Required state and is redirected to the URL returned by the ISE server. The NAC agent in the client triggers the posture validation process. On successful posture validation by the ISE server, the client is moved to the run state.
To get devices such as tablets or smart phones to be connected to the corporate wireless network, the device must first be registered. The device is registered with the ISE server before being allowed complete access. Device registration occurs in an open WLAN with MAC filtering enabled before it is connected to the corporate network WLAN.
In the case of Central Web Authentication (CWA), the web-authentication occurs on the ISE server. The web portal in the ISE server provides a login page to the client. Once the credentials are verified on the ISE server, the client is provisioned. The client remains in the POSTURE_REQD state until a CoA is reached. The credentials and ACLs are received from the ISE server.
In the case of Local Web Authentication (LWA), the controller provides a web-auth login page against which the username and password are verified. Once the client credentials are verified, the ISE server with the restricted ACL and the URL are sent to the client.
The client remains in POSTURE_REQD state until a change of authorization (CoA) is reached.
Table 7-8 describes the possible combinations in a typical ISE deployment with device registration, CWA, and LWA enabled.
Step 2 Click the WLAN ID of the WLAN for which you want to enable ISE.
The WLANs > Edit page appears.
Step 3 Click the Advanced tab.
Step 4 From the NAC State drop-down list, choose Radius NAC :
Note AAA override is automatically enabled when you use RADIUS NAC on a WLAN.
This section contains the following topics:
The management over wireless feature allows you to monitor and configure local controllers using a wireless client. This feature is supported for all management tasks except uploads to and downloads from (transfers to and from) the controller.
Step 1 Choose Management > Mgmt Via Wireless to open the Management Via Wireless page.
Step 2 Select the Enable Controller Management to be accessible from Wireless Clients check box to enable management over wireless for the WLAN or unselect it to disable this feature. The default value is unselected.
Step 3 Click Apply to commit your changes.
Step 4 Click Save Configuration to save your changes.
Step 1 Verify whether the management over wireless interface is e nabled or d isabled by entering this command:
If disabled, continue with Enable management over wireless by entering this command:. Otherwise, continue with Use a wireless client to associate with an access point connected to the controller that you want to manage..
Step 2 Enable management over wireless by entering this command:
config network mgmt-via-wireless enable
Step 3 Use a wireless client to associate with an access point connected to the controller that you want to manage.
Step 4 Log into the CLI to verify that you can manage the WLAN using a wireless client by entering this command:
telnet controller-ip-address command
This section contains the following topics:
You can access the controller with one of its dynamic interface IP addresses. While wired computers can have only CLI access with the dynamic interface of the WLC, wireless clients have both CLI and GUI access with the dynamic interface.
When the management using dynamic interfaces is disabled, a device can open an SSH connection if the protocol is enabled. However, users are not prompted to log on. Additionally, the management address remains accessible from a dynamic interface VLAN unless a CPU ACL is in place.
config network mgmt-via-dynamic-interface { enable | disable }
Note When the management using dynamic interfaces feature is disabled, ensure that ports 22 and 443 on the dynamic interface are closed. Use the config network ssh disable command to close port 22; and use the config network secureweb disable command to close port 443.
This section contains the following topics:
DHCP option 82 provides additional security when DHCP is used to allocate network addresses. Specifically, it enables the controller to act as a DHCP relay agent to prevent DHCP client requests from untrusted sources. The controller can be configured to add option 82 information to DHCP requests from clients before forwarding the requests to the DHCP server.
The access point forwards all DHCP requests from a client to the controller. The controller adds the DHCP option 82 payload and forwards the request to the DHCP server. The payload can contain the MAC address or the MAC address and SSID of the access point, depending on how you configure this option.
Note Any DHCP packets that already include a relay agent option are dropped at the controller.
DHCP option 82 is not supported for use with auto-anchor mobility, which is described in Chapter15, “Configuring Mobility Groups”
In controller software release 4.0 or later releases, you can configure DHCP option 82 using the controller CLI. In controller software release 6.0 or later releases, you can configure this feature using either the GUI or CLI.
Step 1 Choose Controller > Advanced > DHCP to open the DHCP Parameters page.
Figure 7-11 DHCP Parameters Page
Step 2 Select the Enable DHCP Proxy check box to enable DHCP proxy.
Step 3 Choose one of the following options from the DHCP Option 82 Remote ID text box Format drop-down list to specify the format of the DHCP option 82 payload:
Note If the SSID is associated with a dynamic interface, then the DHCP Option 82 that you configure must be enabled on the dynamic interface.
Step 4 Click Apply to commit your changes.
Step 5 Click Save Configuration to save your changes.
– config dhcp opt-82 remote-id ap_mac
This command adds the MAC address of the access point to the DHCP option 82 payload.
– config dhcp opt-82 remote-id ap_mac:ssid
This command adds the MAC address and SSID of the access point to the DHCP option 82 payload.
– config dhcp opt-82 remote-id ap-ethmac
Adds the Ethernet MAC address of the access point to the DHCP option 82 payload.
config interface dhcp {ap-manager | management} option-82 {disable | en able}
Note In order for DHCP option 82 to operate correctly, DHCP proxy must be enabled. See the “Configuring DHCP Proxy” section for instructions on configuring DHCP proxy.
This section contains the following topics:
An access control list (ACL) is a set of rules used to limit access to a particular interface (for example, if you want to restrict a wireless client from pinging the management interface of the controller). After ACLs are configured on the controller, they can be applied to the management interface, the AP-manager interface, any of the dynamic interfaces, or a WLAN to control data traffic to and from wireless clients or to the controller central processing unit (CPU) to control all traffic destined for the CPU.
You may also want to create a preauthentication ACL for web authentication. Such an ACL could be used to allow certain types of traffic before authentication is complete.
Both IPv4 and IPv6 ACLs are supported. IPv6 ACLs support the same options as IPv4 ACLs including source, destination, source and destination ports.
Note You can enable only IPv4 traffic in your network by blocking IPv6 traffic. That is, you can configure an IPv6 ACL to deny all IPv6 traffic and apply it on specific or all WLANs.
Step 1 Choose Security > Access Control Lists > Access Control Lists to open the Access Control Lists page.
Figure 7-12 Access Control Lists Page
This page lists all of the ACLs and their types (IPv4 or IPv6) that have been configured for this controller.
Note If you want to delete an existing ACL, hover your cursor over the blue drop-down arrow for that ACL and choose Remove.
Step 2 If you want to see if packets are hitting any of the ACLs configured on your controller, select the Enable Counters check box and click Apply . Otherwise, leave the check box unselected, which is the default value. This feature is useful when troubleshooting your system.
Note If you want to clear the counters for an ACL, hover your cursor over the blue drop-down arrow for that ACL and choose Clear Counters.
Step 3 Add a new ACL by clicking New. The Access Control Lists > New page appears.
Step 4 In the Access Control List Name text box, enter a name for the new ACL. You can enter up to 32 alphanumeric characters.
Step 5 Choose the ACL type. There are two ACL types: IPv4 and IPv6.
Step 6 Click Apply. When the Access Control Lists page reappears, click the name of the new ACL.
Step 7 When the Access Control Lists > Edit page appears, click Add New Rule. The Access Control Lists > Rules > New page appears.
Step 8 Configure a rule for this ACL as follows:
a. The controller supports up to 64 rules for each ACL. These rules are listed in order from 1 to 64. In the Sequence text box, enter a value (between 1 and 64) to determine the order of this rule in relation to any other rules defined for this ACL.
Note If rules 1 through 4 are already defined and you add rule 29, it is added as rule 5. If you add or change a sequence number for a rule, the sequence numbers for other rules adjust to maintain a continuous sequence. For instance, if you change a rule’s sequence number from 7 to 5, the rules with sequence numbers 5 and 6 are automatically reassigned as 6 and 7, respectively.
b. From the Source drop-down list, choose one of these options to specify the source of the packets to which this ACL applies:
c. From the Destination drop-down list, choose one of these options to specify the destination of the packets to which this ACL applies:
d. From the Protocol drop-down list, choose the protocol ID of the IP packets to be used for this ACL. These are the protocol options:
Note ICMPv6 is only available for IPv6 ACL.
Note If you choose Other, enter the number of the desired protocol in the Protocol text box. You can find the list of available protocols in the INAI website.
e. If you chose TCP or UDP in the previous step, two additional parameters appear: Source Port and Destination Port. These parameters enable you to choose a specific source port and destination port or port ranges. The port options are used by applications that send and receive data to and from the networking stack. Some ports are designated for certain applications such as Telnet, SSH, HTTP, and so on.
Note Source and Destination ports based on the ACL type.
f. From the DSCP drop-down list, choose one of these options to specify the differentiated services code point (DSCP) value of this ACL. DSCP is an IP header text box that can be used to define the quality of service across the Internet.
g. From the Direction drop-down list, choose one of these options to specify the direction of the traffic to which this ACL applies:
Note If you are planning to apply this ACL to the controller CPU, the packet direction does not have any significance, it is always ‘Any’.
h. From the Action drop-down list, choose Deny to cause this ACL to block packets or Permit to cause this ACL to allow packets. The default value is Deny.
i. Click Apply to commit your changes. The Access Control Lists > Edit page reappears, showing the rules for this ACL.
The Deny Counters fields shows the number of times that packets have matched the explicit deny ACL rule. The Number of Hits field shows the number of times that packets have matched an ACL rule. You must enable ACL counters on the Access Control Lists page to enable these fields.
Note If you want to edit a rule, click the sequence number of the desired rule to open the Access Control Lists > Rules > Edit page. If you want to delete a rule, hover your cursor over the blue drop-down arrow for the desired rule and choose Remove.
j. Repeat this procedure to add any additional rules for this ACL.
Step 9 Click Save Configuration to save your changes.
Step 10 Repeat this procedure to add any additional ACLs.
Step 1 Choose Controller > Interfaces .
Step 2 Click the name of the desired interface. The Interfaces > Edit page for that interface appears.
Figure 7-13 Interfaces > Edit Page
Step 3 From the ACL Name drop-down list, choose the desired ACL and click Apply. The default is None.
Note Only IPv4 ACL are supported as interface ACL, see “Configuring Ports and Interfaces,” for more information on configuring controller interfaces.
Step 4 Click Save Configuration to save your changes.
Step 1 Choose Security > Access Control Lists > CPU Access Control Lists to open the CPU Access Control Lists page.
Step 2 Select the Enable CPU ACL check box to enable a designated ACL to control the traffic to the controller CPU or unselect the check box to disable the CPU ACL feature and remove any ACL that had been applied to the CPU. The default value is unselected.
Step 3 From the ACL Name drop-down list, choose the ACL that will control the traffic to the controller CPU. None is the default value when the CPU ACL feature is disabled. If you choose None while the CPU ACL Enable check box is selected, an error message appears indicating that you must choose an ACL.
Note This parameter is available only if you have selected the CPU ACL Enable check box.
Note When CPU ACL is enabled, it is applicable to both wireless and wired traffic. Only IPv4 ACL are supported as CPU ACL.
Step 4 Click Apply to commit your changes.
Step 5 Click Save Configuration to save your changes.
Step 1 Choose WLANs to open the WLANs page.
Step 2 Click the ID number of the desired WLAN to open the WLANs > Edit page.
Step 3 Choose the Advanced tab to open the WLANs > Edit (Advanced) page.
Figure 7-14 WLANs > Edit (Advanced) Page
Step 4 From the Override Interface ACL drop-down list, choose the IPv4 or IPv6 ACL that you want to apply to this WLAN. The ACL that you choose overrides any ACL that is configured for the interface. None is the default value.
Note To support centralized access control through an AAA server such as ISE or ACS, you must configure the IPv4 and IPv6 ACL on the controller and the WLAN must be configured with AAA override enabled feature.
Note See “Working with WLANs,” for more information on configuring WLANs.
Step 5 Click Apply to commit your changes.
Step 6 Click Save Configuration to save your changes.
Step 1 Choose WLANs to open the WLANs page.
Step 2 Click the ID number of the desired WLAN to open the WLANs > Edit page.
Step 3 Choose the Security and Layer 3 tabs to open the WLANs > Edit (Security > Layer 3) page.
Figure 7-15 WLANs > Edit (Security > Layer 3) Page
Step 4 Select the Web Policy check box.
Step 5 From the Preauthentication ACL drop-down list, choose the desired ACL and click Apply . None is the default value.
Note See “Working with WLANs,” for more information on configuring WLANs.
Step 6 Click Save Configuration to save your changes.
Step 1 See all of the ACLs that are configured on the controller by entering this command:
Information similar to the following appears:
Step 2 See all of the IPv6 ACLs that are configured on the controller by entering this command:
Step 3 See detailed information for a particular ACL by entering this command:
show [ipv6] acl detailed acl_name
Information similar to the following appears:
The Counter text box increments each time a packet matches an ACL rule, and the DenyCounter text box increments each time a packet does not match any of the rules.
Note If a traffic/request is allowed from the controller by a permit rule, then the response to the traffic/request in the opposite direction also is allowed and cannot be blocked by a deny rule in the ACL.
Step 4 Enable or disable ACL counters for your controller by entering this command:
config acl counter { start | stop }
Note If you want to clear the current counters for an ACL, enter the clear acl counters acl_name command.
Note ACL counters are available only on the Cisco 5500 Series Controller, Cisco 4400 Series Controller, Cisco WiSM, and Catalyst 3750G Integrated Wireless LAN Controller Switch.
Step 5 Add a new ACL by entering this command:
config [ipv6] acl create acl_name
You can enter up to 32 alphanumeric characters for the acl_name parameter.
Note When you try to create an interface name with space, the controller CLI does not create an interface. For example, if you want to create an interface name int 3, the CLI will not create this since there is a space between int and 3. If you want to use int 3 as the interface name, you need to enclose within single quotes like ‘int 3’.
Step 6 Add a rule for an ACL by entering this command:
config [ipv6] acl rule add acl_name rule_index
Step 7 Configure an ACL rule by entering this command:
action acl_name rule_index {permit | deny} |
change index acl_name old_index new_index |
destination address acl_name rule_index ip_address netmask |
destination port range acl_name rule_index start_port end_port |
direction acl_name rule_index {in | out | any} |
dscp acl_name rule_index dscp |
protocol acl_name rule_index protocol |
source address acl_name rule_index ip_address netmask |
source address [ipv6] acl_name rule_index prefix |
swap index acl_name index_1 index_2}
See Configure a rule for this ACL as follows: of the “Configuring and Applying Access Control Lists (GUI)” section for explanations of the rule parameters.
Step 8 Save your settings by entering this command:
Note To delete an ACL, enter the config [ipv6] acl delete acl_name command. To delete an ACL rule, enter the config [ipv6] acl rule delete acl_name rule_index command.
Step 1 Perform any of the following:
config interface acl {management | ap-manager | dynamic_interface_name} acl_name
Note To see the ACL that is applied to an interface, enter the show interface detailed {management | ap-manager | dynamic_interface_name} command. To remove an ACL that is applied to an interface, enter the config interface acl
{management | ap-manager | dynamic_interface_name} none command.
See “Configuring Ports and Interfaces,” for more information on configuring controller interfaces.
config acl cpu acl_name {wired | wireless | both}
Note To see the ACL that is applied to the controller CPU, enter the show acl cpu command. To remove the ACL that is applied to the controller CPU, enter the config acl cpu none command.
config wlan acl wlan_id acl_name
Note To see the ACL that is applied to a WLAN, enter the show wlan wlan_id command. To remove the ACL that is applied to a WLAN, enter the config wlan acl wlan_id none command.
config wlan security web-auth acl wlan_id acl_name
See “Working with WLANs,” for more information on configuring WLANs.
Step 2 Save your changes by entering this command:
This chapter contains the following topics:
Management frame protection (MFP) provides security for the otherwise unprotected and unencrypted 802.11 management messages passed between access points and clients. MFP provides both infrastructure and client support.
Specifically, infrastructure MFP protects 802.11 session management functions by adding message integrity check information elements (MIC IEs) to the management frames emitted by access points (and not those emitted by clients), which are then validated by other access points in the network. Infrastructure MFP is passive. It can detect and report intrusions but has no means to stop them.
Specifically, client MFP encrypts management frames are sent between access points and CCXv5 clients so that both the access points and clients can take preventative action by dropping spoofed class 3 management frames (that is, management frames passed between an access point and a client that is authenticated and associated). Client MFP leverages the security mechanisms defined by IEEE 802.11i to protect the following types of class 3 unicast management frames: disassociation, deauthentication, and QoS (WMM) action. Client MFP protects a client-access point session from the most common type of denial-of-service attack. It protects class 3 management frames by using the same encryption method used for the session’s data frames. If a frame received by the access point or client fails decryption, it is dropped, and the event is reported to the controller.
To use client MFP, clients must support CCXv5 MFP and must negotiate WPA2 using either TKIP or AES-CCMP. EAP or PSK may be used to obtain the PMK. CCKM and controller mobility management are used to distribute session keys between access points for Layer 2 and Layer 3 fast roaming.
Note To prevent attacks using broadcast frames, access points supporting CCXv5 will not emit any broadcast class 3 management frames (such as disassociation, deauthentication, or action). CCXv5 clients and access points must discard broadcast class 3 management frames.
Client MFP supplements infrastructure MFP rather than replaces it because infrastructure MFP continues to detect and report invalid unicast frames sent to clients that are not client-MFP capable as well as invalid class 1 and 2 management frames. Infrastructure MFP is applied only to management frames that are not protected by client MFP.
Infrastructure MFP consists of three main components:
Note Client MFP uses the same event reporting mechanisms as infrastructure MFP.
Infrastructure MFP is enabled by default and can be disabled globally. When you upgrade from a previous software release, infrastructure MFP is disabled globally if access point authentication is enabled because the two features are mutually exclusive. Once infrastructure MFP is enabled globally, signature generation (adding MICs to outbound frames) can be disabled for selected WLANs, and validation can be disabled for selected access points.
Client MFP is enabled by default on WLANs that are configured for WPA2. It can be disabled, or it can be made mandatory (in which case, only clients that negotiate MFP are allowed to associate) on selected WLANs.
Step 1 Choose Security > Wireless Protection Policies > AP Authentication/MFP to open the AP Authentication Policy page.
Figure 7-16 AP Authentication Policy Page
Step 2 From the Protection Type drop-down list, enable infrastructure MFP globally for the controller by choosing Management Frame Protection.
Step 3 Click Apply to commit your changes.
Note If more than one controller is included in the mobility group, you must configure a Network Time Protocol (NTP) server on all controllers in the mobility group that are configured for infrastructure MFP.
Step 4 Configure client MFP for a particular WLAN after infrastructure MFP has been enabled globally for the controller as follows:
b. Click the profile name of the desired WLAN. The WLANs > Edit page appears.
c. Choose Advanced . The WLANs > Edit (Advanced) page appears.
Figure 7-17 WLANs > Edit (Advanced) Page
d. From the MFP Client Protection drop-down list choose Disabled , Optional , or Required . The default value is Optional. If you choose Required, clients are allowed to associate only if MFP is negotiated (that is, if WPA2 is configured on the controller and the client supports CCXv5 MFP and is also configured for WPA2).
Note For Cisco OEAP 600, MFP is not supported. It should either be Disabled or Optional.
e. Click Apply to commit your changes.
Step 5 Click Save Configuration to save your settings.
To see the controller’s current global MFP settings, choose Security > Wireless Protection Policies > Management Frame Protection. The Management Frame Protection Settings page appears.
Figure 7-18 Management Frame Protection Settings Page
On this page, you can see the following MFP settings:
config wps mfp infrastructure {enable | disable}
config wlan mfp client {enable | disable} wlan_id [ required ]
If you enable client MFP and use the optional required parameter, clients are allowed to associate only if MFP is negotiated.
Information similar to the following appears:
Information similar to the following appears:
Information similar to the following appears:
Note This report contains no data unless an active attack is in progress. Examples of various error types are shown for illustration only. This table is cleared every 5 minutes when the data is forwarded to any network management stations.
Use this command if you experience any problems with MFP:
where ? is one of the following:
client —Configures debugging for client MFP messages.
capwap —Configures debugging for MFP messages between the controller and access points.
detail —Configures detailed debugging for MFP messages.
report —Configures debugging for MFP reporting.
mm—Configures debugging for MFP mobility (inter-controller) messages.
This section contains the following topics:
Step 1 Choose Security > Wireless Protection Policies > Client Exclusion Policies to open the Client Exclusion Policies page.
Figure 7-19 Client Exclusion Policies Page
Step 2 Select any of these check boxes if you want the controller to exclude clients for the condition specified. The default value for each exclusion policy is enabled.
Step 3 Click Apply to commit your changes.
Step 4 Click Save Configuration to save your changes.
Step 1 Enable or disable the controller to exclude clients on the sixth 802.11 association attempt, after five consecutive failures by entering this command:
config wps client-exclusion 802.11-assoc { enable | disable }
Step 2 Enable or disable the controller to exclude clients on the sixth 802.11 authentication attempt, after five consecutive failures by entering this command:
config wps client-exclusion 802.11-auth { enable | disable }
Step 3 Enable or disable the controller to exclude clients on the fourth 802.1X authentication attempt, after three consecutive failures by entering this command:
config wps client-exclusion 802.1x-auth { enable | disable }
Step 4 Enable or disable the controller to exclude clients if the IP address is already assigned to another device by entering this command:
config wps client-exclusion ip-theft { enable | disable }
Step 5 Enable or disable the controller to exclude clients on the fourth web authentication attempt, after three consecutive failures by entering this command:
config wps client-exclusion web-auth { enable | disable }
Step 6 Enable or disable the controller to exclude clients for all of the above reasons by entering this command:
config wps client-exclusion all { enable | disable }
Step 7 Use the following command to add or delete client exclusion entries.
config exclusionlist { add MAC [ description ] | delete MAC | description MAC [ description ]}
Step 8 Save your changes by entering this command:
Step 9 See a list of clients that have been dynamically excluded, by entering this command:
Information similar to the following appears:
Step 10 See the client exclusion policy configuration settings by entering this command:
Information similar to the following appears:
In most wireless LAN systems, each WLAN has a static policy that applies to all clients associated with an SSID. Although powerful, this method has limitations because it requires clients to associate with different SSIDs to inherit different QoS and security policies.
However, the Cisco Wireless LAN solution supports identity networking, which allows the network to advertise a single SSID but allows specific users to inherit different QoS or security policies based on their user profiles. The specific policies that you can control using identity networking are as follows:
Note The VLAN feature only supports MAC filtering, 802.1X, and WPA. The VLAN feature does not support web authentication or IPsec.
Note When any of the other RADIUS attributes (QoS-Level, ACL-Name, Interface-Name, or VLAN-Tag), which are described later in this section, are returned, the Tunnel Attributes must also be returned.
The operating system’s local MAC filter database has been extended to include the interface name, allowing local MAC filters to specify to which interface the client should be assigned. A separate RADIUS server can also be used, but the RADIUS server must be defined using the Security menus.
This section explains the RADIUS attributes used in identity networking. This section contains the following topics:
This attribute indicates the QoS level to be applied to the mobile client's traffic within the switching fabric, as well as over the air. This example shows a summary of the QoS-Level Attribute format. The text boxes are transmitted from left to right.
This attribute indicates the ACL name to be applied to the client. A summary of the ACL-Name Attribute format is shown below. The text boxes are transmitted from left to right.
This attribute indicates the VLAN Interface a client is to be associated to. A summary of the Interface-Name Attribute format is shown below. The text boxes are transmitted from left to right.
Note This Attribute only works when MAC filtering is enabled or if 802.1X or WPA is used as the security policy.
This attribute indicates the group ID for a particular tunneled session and is also known as the Tunnel-Private-Group-ID attribute.
This attribute might be included in the Access-Request packet if the tunnel initiator can predetermine the group resulting from a particular connection and should be included in the Access-Accept packet if this tunnel session is to be treated as belonging to a particular private group. Private groups may be used to associate a tunneled session with a particular group of users. For example, it may be used to facilitate routing of unregistered IP addresses through a particular interface. It should be included in Accounting-Request packets which contain Acct-Status-Type attributes with values of either Start or Stop and which pertain to a tunneled session.
A summary of the Tunnel-Private-Group-ID Attribute format is shown below. The text boxes are transmitted from left to right.
Note When any of the other RADIUS attributes (QoS-Level, ACL-Name, Interface-Name, or VLAN-Tag) are returned, the Tunnel Attributes must also be returned.
RFC 2868 defines RADIUS tunnel attributes used for authentication and authorization, and RFC2867 defines tunnel attributes used for accounting. Where the IEEE 802.1X authenticator supports tunneling, a compulsory tunnel may be set up for the Supplicant as a result of the authentication.
In particular, it may be desirable to allow a port to be placed into a particular VLAN, defined in IEEE 8021Q, based on the result of the authentication. This configuration can be used, for example, to allow a wireless host to remain on the same VLAN as it moves within a campus network.
The RADIUS server typically indicates the desired VLAN by including tunnel attributes within the Access-Accept. However, the IEEE 802.1X authenticator may also provide a hint as to the VLAN to be assigned to the Supplicant by including Tunnel attributes within the AccessRequest.
For use in VLAN assignment, the following tunnel attributes are used:
The VLAN ID is 12 bits, with a value between 1 and 4094, inclusive. Because the Tunnel-Private-Group-ID is of type String as defined in RFC 2868, for use with IEEE 802.1X, the VLANID integer value is encoded as a string.
When Tunnel attributes are sent, it is necessary to fill in the Tag text box. As noted in RFC 2868, section 3.1:
This section contains the following topics:
The Allow AAA Override option of a WLAN enables you to configure the WLAN for identity networking. It enables you to apply VLAN tagging, QoS, and ACLs to individual clients based on the returned RADIUS attributes from the AAA server.
If you are using a Steel-Belted RADIUS (SBR), FreeRadius, or similar RADIUS server, clients may not obtain the correct QoS values after the AAA override feature is enabled. For these servers, which allow you to edit the dictionary file, you need to update the file to reflect the proper QoS values: Silver is 0, Gold is 1, Platinum is 2, and Bronze is 3. To update the RADIUS server dictionary file, follow these steps:
Note This issue does not apply to the Cisco Secure Access Control Server (ACS).
To update the RADIUS server dictionary file, follow these steps:
Step 1 Stop the SBR service (or other RADIUS service).
Step 2 Save the following text to the Radius_Install_Directory\Service folder as ciscowlan.dct:
Step 3 Open the dictiona.dcm file (in the same directory) and add the line “@ciscowlan.dct.”
Step 4 Save and close the dictiona.dcm file.
Step 5 Open the vendor.ini file (in the same directory) and add the following text:
Step 6 Save and close the vendor.ini file.
Step 7 Start the SBR service (or other RADIUS service).
Step 8 Launch the SBR Administrator (or other RADIUS Administrator).
Step 9 Add a RADIUS client (if not already added). Choose Cisco WLAN Controller from the Make/Model drop-down list.
Step 1 Choose WLANs to open the WLANs page.
Step 2 Click the ID number of the WLAN that you want to configure. The WLANs > Edit page appears.
Step 3 Choose the Advanced tab to open the WLANs > Edit (Advanced) page.
Figure 7-20 WLANs > Edit (Advanced) Page
Step 4 Select the Allow AAA Override check box to enable AAA override or unselect it to disable this feature. The default value is disabled.
Step 5 Click Apply to commit your changes.
Step 6 Click Save Configuration to save your changes.
This section contains the following topics:
Rogue access points can disrupt wireless LAN operations by hijacking legitimate clients and using plain-text or other denial-of-service or man-in-the-middle attacks. That is, a hacker can use a rogue access point to capture sensitive information, such as usernames and passwords. The hacker can then transmit a series of clear-to-send (CTS) frames. This action mimics an access point informing a particular client to transmit and instructing all others to wait, which results in legitimate clients being unable to access network resources. Wireless LAN service providers have a strong interest in banning rogue access points from the air space.
Because rogue access points are inexpensive and readily available, employees sometimes plug unauthorized rogue access points into existing LANs and build ad-hoc wireless networks without IT department knowledge or consent. These rogue access points can be a serious breach of network security because they can be plugged into a network port behind the corporate firewall. Because employees generally do not enable any security settings on the rogue access point, it is easy for unauthorized users to use the access point to intercept network traffic and hijack client sessions. Even more alarming, wireless users frequently publish unsecure access point locations, increasing the odds of having enterprise security breached.
The controller continuously monitors all nearby access points and automatically discovers and collects information on rogue access points and clients. When the controller discovers a rogue access point, it uses the Rogue Location Discovery Protocol (RLDP) to determine if the rogue is attached to your network.
You can configure the controller to use RLDP on all access points or only on access points configured for monitor (listen-only) mode. The latter option facilitates automated rogue access point detection in a crowded RF space, allowing monitoring without creating unnecessary interference and without affecting regular data access point functionality. If you configure the controller to use RLDP on all access points, the controller always chooses the monitor access point for RLDP operation if a monitor access point and a local (data) access point are both nearby. If RLDP determines that the rogue is on your network, you can choose to either manually or automatically contain the detected rogue.
A rogue access point is moved to a contained state either automatically or manually. The controller selects the best available access point for containment and pushes the information to the access point. The access point stores the list of containments per radio. For auto-containment, you can configure the controller to use only monitor mode access point.
The containment operation happens in following two ways:
The individual rogue containment involves sending a sequence of unicast disassociation and deauthentication frames.
WCS software release 5.0 or later releases also support rule-based classification. WCS uses the classification rules configured on the controller. The controller sends traps to WCS after the following events:
Step 1 Make sure that rogue detection is enabled on the desired access points. Rogue detection is enabled by default for all access points joined to the controller (except for OfficeExtend access points). However, in controller software release 6.0 or later releases, you can enable or disable it for individual access points by selecting or unselecting the Rogue Detection check box on the All APs > Details for (Advanced) page.
Step 2 Choose Security > Wireless Protection Policies > Rogue Policies > General to open the Rogue Policies page.
Step 3 From the Rogue Location Discovery Protocol drop-down list, choose one of the following options:
Step 4 In the Expiration Timeout for Rogue AP and Rogue Client Entries text box, enter the number of seconds after which the rogue access point and client entries expire and are removed from the list. The valid range is 240 to 3600 seconds, and the default value is 1200 seconds.
Note If a rogue access point or client entry times out, it is removed from the controller only if its rogue state is Alert or Threat for any classification type.
Step 5 If desired, select the Validate Rogue Clients Against AAA check box to use the AAA server or local database to validate if rogue clients are valid clients. The default value is unselected.
Step 6 If desired, select the Detect and Report Ad-Hoc Networks check box to enable ad-hoc rogue detection and reporting. The default value is selected.
Step 7 In the Rogue Detection Report Interval text box, enter the time interval in seconds at which APs should send rogue detection report to the controller. The valid range is from 10 seconds to 300 seconds, and the default value is 10 seconds.
Note This feature is applicable to APs that are in monitor mode only.
Step 8 In the Rogue Detection Minimum RSSI text box, enter the minimum RSSI value that a rogue should have for APs to detect and for a rogue entry to be created in the controller. The valid range is from –128 dBm to 0 dBm, and the default value is 0 dBm.
Note This feature is applicable to all the AP modes.
There can be many rogues with very weak RSSI values that do not provide any valuable information in rogue analysis. Therefore, you can use this option to filter rogues by specifying the minimum RSSI value at which APs should detect rogues.
Step 9 In the Rogue Detection Transient Interval text box, enter the time interval at which a rogue has to be scanned for by the AP after the first time that the rogue is scanned. After the rogue is scanned, updates are sent periodically to the controller. The APs filter transient rogues, which are active for a very short period and are then silent. The valid range is from 120 seconds to 1800 seconds, and the default value is 0.
Note This feature is applicable to APs that are in monitor mode only.
This feature has the following advantages:
Step 10 If you want the controller to automatically contain certain rogue devices, select the following check boxes. Otherwise, leave the check boxes unselected, which is the default value.
Step 11 Click Apply to commit your changes.
Step 12 Click Save Configuration to save your changes.
Step 1 Make sure that rogue detection is enabled on the desired access points. Rogue detection is enabled by default for all access points joined to the controller (except for OfficeExtend access points). However, in controller software release 6.0 or later releases, you can enable or disable it for individual access points by entering the config rogue detection { enable | disable } Cisco_AP command.
Note To see the current rogue detection configuration for a specific access point, enter the show ap config general Cisco_AP command.
Note Rogue detection is disabled by default for OfficeExtend access points because these access points, which are deployed in a home environment, are likely to detect a large number of rogue devices.
Step 2 Enable, disable, or initiate RLDP by entering these commands:
Step 3 Specify the number of seconds after which the rogue access point and client entries expire and are removed from the list by entering this command:
config rogue ap timeout seconds
The valid range for the seconds parameter is 240 to 3600 seconds (inclusive), and the default value is 1200 seconds.
Note If a rogue access point or client entry times out, it is removed from the controller only if its rogue state is Alert or Threat for any classification type.
Step 4 Enable or disable ad-hoc rogue detection and reporting by entering this command:
config rogue adhoc { enable | disable }
Step 5 Enable or disable the AAA server or local database to validate if rogue clients are valid clients by entering this command:
config rogue client aaa { enable | disable }
Step 6 Specify the time interval in seconds at which APs should send rogue detection report to the controller by entering the following command:
config rogue detection monitor-ap report-interval time in sec
Valid range for the time in sec parameter is 10 seconds to 300 seconds, and the default value is 10 seconds.
Note This feature is applicable to APs that are in monitor mode only.
Step 7 Specify the minimum RSSI value that rogues should have for APs to detect and for rogue entry to be created in the controller by entering the following command:
config rogue detection min-rssi rssi in dBm
Valid range for the rssi in dBm parameter is –128 dBm to 0 dBm, and the default value is 0 dBm.
Note This feature is applicable to all the AP modes.
There can be many rogues with very weak RSSI values that do not provide any valuable information in rogue analysis. Therefore, you can use this option to filter rogues by specifying the minimum RSSI value at which APs should detect rogues.
Step 8 Specify the time interval at which rogues have to be consistently scanned for by APs after the first time the rogues are scanned for by entering the following command:
config rogue detection monitor-ap transient-rogue-interval time in sec
Valid range for the time in sec parameter is 120 seconds to 1800 seconds, and the default value is 0.
Note This feature is applicable to APs that are in monitor mode only
Using the transient interval values, you can control the time interval at which APs should scan for rogues. APs can also filter the rogues based on their transient interval values.
This feature has the following advantages:
Step 9 If you want the controller to automatically contain certain rogue devices, enter these commands:
Note If you want the controller to only generate an alarm when such a rogue is detected, enter the config rogue ap ssid alarm command.
Note If you want the controller to only generate an alarm when such a rogue is detected, enter the config rogue ap valid-client alarm command.
Note If you want the controller to only generate an alarm when such a network is detected, enter the config rogue adhoc alert command.
Step 10 Configure RLDP scheduling by entering this command:
config rogue ap rldp schedule add mon 22:00:00 23:00:00
Note When you configure RLDP scheduling, it is assumed that the scheduling would occur in the future, that is, after the configuration is saved.
Step 11 Save your changes by entering this command:
This section contains the following topics:
The controller software now enables you to create rules that can organize and display rogue access points as Friendly, Malicious, or Unclassified.
By default, none of the classification rules are enabled. Therefore, all unknown access points are categorized as Unclassified. When you create a rule, configure conditions for it, and enable the rule, the unclassified access points are reclassified. Whenever you change a rule, it is applied to all access points (friendly, malicious, and unclassified) in the Alert state only.
Note Rule-based rogue classification does not apply to ad-hoc rogues and rogue clients.
Note You can configure up to 64 rogue classification rules per controller.
When the controller receives a rogue report from one of its managed access points, it responds as follows:
1. The controller verifies that the unknown access point is in the friendly MAC address list. If it is, the controller classifies the access point as Friendly.
2. If the unknown access point is not in the friendly MAC address list, the controller starts applying rogue classification rules.
3. If the rogue is already classified as Malicious, Alert or Friendly, Internal or External, the controller does not reclassify it automatically. If the rogue is classified differently, the controller reclassifies it automatically only if the rogue is in the Alert state.
4. The controller applies the first rule based on priority. If the rogue access point matches the criteria specified by the rule, the controller classifies the rogue according to the classification type configured for the rule.
5. If the rogue access point does not match any of the configured rules, the controller classifies the rogue as Unclassified.
6. The controller repeats the previous steps for all rogue access points.
7. If RLDP determines that the rogue access point is on the network, the controller marks the rogue state as Threat and classifies it as Malicious automatically, even if no rules are configured. You can then manually contain the rogue (unless you have configured RLDP to automatically contain the rogue), which would change the rogue state to Contained. If the rogue access point is not on the network, the controller marks the rogue state as Alert, and you can manually contain the rogue.
8. If desired, you can manually move the access point to a different classification type and rogue state.
If you upgrade to controller software release 5.0 or later releases, the classification and state of the rogue access points are reconfigured as follows:
As mentioned previously, the controller can automatically change the classification type and rogue state of an unknown access point based on user-defined rules, or you can manually move the unknown access point to a different classification type and rogue state.
If the rogue state is Contained, you have to uncontain the rogue access point before you can change the classification type. If you want to move a rogue access point from Malicious to Unclassified, you must delete the access point and allow the controller to reclassify it.
Step 1 Choose Security > Wireless Protection Policies > Rogue Policies > Rogue Rules to open the Rogue Rules page.
Any rules that have already been created are listed in priority order. The name, type, and status of each rule is provided.
Note If you ever want to delete a rule, hover your cursor over the blue drop-down arrow for that rule and click Remove.
Step 2 Create a new rule as follows:
a. Click Add Rule . An Add Rule section appears at the top of the page.
b. In the Rule Name text box, enter a name for the new rule. Make sure that the name does not contain any spaces.
c. From the Rule Type drop-down list, choose Friendly or Malicious to classify rogue access points matching this rule as friendly or malicious.
d. Click Add to add this rule to the list of existing rules, or click Cancel to discard this new rule.
Step 3 Edit a rule as follows:
a. Click the name of the rule that you want to edit. The Rogue Rule > Edit page appears.
Figure 7-22 Rogue Rule > Edit Page
b. From the Type drop-down list, choose Friendly or Malicious to classify rogue access points matching this rule as friendly or malicious.
c. From the Match Operation text box, choose one of the following:
d. To enable this rule, select the Enable Rule check box. The default value is unselected.
e. From the Add Condition drop-down list, choose one or more of the following conditions that the rogue access point must meet and click Add Condition .
Note To delete an SSID, highlight the SSID and click Remove.
Note WCS refers to this option as “Open Authentication.”
Note The SSID and Managed SSID conditions cannot be used with the Match All operation because these two SSID lists are mutually exclusive. If you define a rule with Match All and have these two conditions configured, the rogue access points are never classified as friendly or malicious because one of the conditions can never be met.
You can add up to six conditions per rule. When you add a condition, it appears under the Conditions section.
Note If you ever want to delete a condition from this rule, hover your cursor over the blue drop-down arrow for that condition and click Remove.
f. Click Apply to commit your changes.
Step 4 Click Save Configuration to save your changes.
Step 5 If you want to change the order in which rogue classification rules are applied, follow these steps:
a. Click Back to return to the Rogue Rules page.
b. Click Change Priority to access the Rogue Rules > Priority page.
The rogue rules are listed in priority order in the Change Rules Priority text box.
c. Highlight the rule for which you want to change the priority, and click Up to raise its priority in the list or Down to lower its priority in the list.
d. Continue to move the rules up or down until the rules are in the desired order.
e. Click Apply to commit your changes.
Step 6 Classify any rogue access points as friendly and add them to the friendly MAC address list as follows:
a. Choose Security > Wireless Protection Policies > Rogue Policies > Friendly Rogue to open the Friendly Rogue > Create page.
b. In the MAC Address text box, enter the MAC address of the friendly rogue access point.
c. Click Apply to commit your changes.
d. Click Save Configuration to save your changes. This access point is added to the controller’s list of friendly access points and should now appear on the Friendly Rogue APs page.
Step 1 Choose Monitor > Rogues .
Step 2 Choose the following options to view the different types of rogue access points detected by the controller:
The Friendly Rogue APs page, Malicious Rogue APs page, and Unclassified Rogue APs page provide the following information: the MAC address and SSID of the rogue access point, Channel Number, the number of clients connected to the rogue access point, the number of radios that detected the rogue access point, and the current status of the rogue access point.
Note To remove acknowledged rogues from the database, go to the WLC UI and change the rogue state to Alert Unknown and click Save Configuration. If the rogue is no longer present, it will disappear from the database in 20 minutes.
Note If you ever want to delete a rogue access point from one of these pages, hover your cursor over the blue drop-down arrow and click Remove. To delete multiple rogue access points, check the check box corresponding to the row you want to delete and click Remove Selected.
Step 3 Obtain more details about a rogue access point by clicking the MAC address of the access point. The Rogue AP Detail page appears.
This page provides the following information: the MAC address of the rogue device, the type of rogue device (such as an access point), whether the rogue device is on the wired network, the dates and times when the rogue device was first and last reported, and the current status of the device.
The Class Type text box shows the current classification for this rogue access point:
Note Once an access point is classified as Malicious, you cannot apply rules to it in the future, and it cannot be moved to another classification type. If you want to move a malicious access point to the Unclassified classification type, you must delete the access point and allow the controller to reclassify it.
Step 4 If you want to change the classification of this device, choose a different classification from the Class Type drop-down list.
Note A rogue access point cannot be moved to another class if its current state is Contain.
Step 5 From the Update Status drop-down list, choose one of the following options to specify how the controller should respond to this rogue access point:
The bottom of the page provides information on both the access points that detected this rogue access point and any clients that are associated to it. To see more details for any of the clients, click Edit to open the Rogue Client Detail page.
Step 6 Click Apply to commit your changes.
Step 7 Click Save Configuration to save your changes.
Step 8 View any rogue clients that are connected to the controller by choosing Rogue Clients . The Rogue Clients page appears. This page shows the following information: the MAC address of the rogue client, the MAC address of the access point to which the rogue client is associated, the SSID of the rogue client, the number of radios that detected the rogue client, the date and time when the rogue client was last reported, and the current status of the rogue client.
Step 9 Obtain more details about a rogue client by clicking the MAC address of the client. The Rogue Client Detail page appears.
This page provides the following information: the MAC address of the rogue client, the MAC address of the rogue access point to which this client is associated, the SSID and IP address of the rogue client, the dates and times when the rogue client was first and last reported, and the current status of the rogue client.
Step 10 From the Update Status drop-down list, choose one of the following options to specify how the controller should respond to this rogue client:
The bottom of the page provides information on the access points that detected this rogue client.
Step 11 Click Apply to commit your changes.
Step 12 If desired, you can test the controller’s connection to this client by clicking Ping .
Step 13 Click Save Configuration to save your changes.
Step 14 See any ad-hoc rogues detected by the controller by choosing Adhoc Rogues . The Adhoc Rogues page appears.
This page shows the following information: the MAC address, BSSID, and SSID of the ad-hoc rogue, the number of radios that detected the ad-hoc rogue, and the current status of the ad-hoc rogue.
Step 15 Obtain more details about an ad-hoc rogue by clicking the MAC address of the rogue. The Adhoc Rogue Detail page appears.
This page provides the following information: the MAC address and BSSID of the ad-hoc rogue, the dates and times when the rogue was first and last reported, and the current status of the rogue.
Step 16 From the Update Status drop-down list, choose one of the following options to specify how the controller should respond to this ad-hoc rogue:
Step 17 From the Maximum Number of APs to Contain the Rogue drop-down list, choose one of the following options to specify the maximum number of access points used to contain this ad-hoc rogue: 1 , 2 , 3 , or 4.
The bottom of the page provides information on the access points that detected this ad-hoc rogue.
Step 18 Click Apply to commit your changes.
Step 19 Click Save Configuration to save your changes.
Step 20 View any access points that have been configured to be ignored by choosing Rogue AP Ignore-List . The Rogue AP Ignore-List page appears.
This page shows the MAC addresses of any access points that are configured to be ignored. The rogue-ignore list contains a list of any autonomous access points that have been manually added to WCS maps by WCS users. The controller regards these autonomous access points as rogues even though WCS is managing them. The rogue-ignore list allows the controller to ignore these access points. The list is updated as follows:
Step 1 Create a rule by entering this command:
config rogue rule add ap priority priority classify { friendly | malicious } rule_name
Note If you later want to change the priority of this rule and shift others in the list accordingly, enter the config rogue rule priority priority rule_name command. If you later want to change the classification of this rule, enter the config rogue rule classify {friendly | malicious} rule_name command.
Note If you ever want to delete all of the rogue classification rules or a specific rule, enter the config rogue rule delete {all | rule_name} command.
Step 2 Disable all rules or a specific rule by entering this command:
config rogue rule disable { all | rule_name }
Note A rule must be disabled before you can modify its attributes.
Step 3 Add conditions to a rule that the rogue access point must meet by entering this command:
config rogue rule condition ap set condition_type condition_value rule_name
where condition_type is one of the following:
Note If you ever want to delete all of the SSIDs or a specific SSID from the user-configured SSID list, enter the config rogue rule condition ap delete ssid {all | ssid} rule_name command.
Note You can add up to six conditions per rule. If you ever want to delete all of the conditions or a specific condition from a rule, enter the config rogue rule condition ap delete {all | condition_type} condition_value rule_name command.
Step 4 Specify whether a detected rogue access point must meet all or any of the conditions specified by the rule in order for the rule to be matched and the rogue access point to adopt the classification type of the rule by entering this command:
config rogue rule match { all | any } rule_name
Step 5 Enable all rules or a specific rule by entering this command:
config rogue rule enable { all | rule_name }
Note For your changes to become effective, you must enable the rule.
Step 6 Add a new friendly access point entry to the friendly MAC address list or delete an existing friendly access point entry from the list by entering this command:
config rogue ap friendly { add | delete } ap_mac_address
Step 7 Save your changes by entering this command:
Step 8 View the rogue classification rules that are configured on the controller by entering this command:
Information similar to the following appears:
Step 9 View detailed information for a specific rogue classification rule by entering this command:
show rogue rule detailed rule_name
Information similar to the following appears:
Information similar to the following appears:
show rogue ap friendly summary
Information similar to the following appears:
show rogue ap malicious summary
Information similar to the following appears:
show rogue ap unclassified summary
Information similar to the following appears:
show rogue ap detailed ap_mac_address
Information similar to the following appears:
show ap auto-rf 802.11a Cisco_AP
Information similar to the following appears:
show rogue ap clients ap_mac_address
Information similar to the following appears:
Information similar to the following appears:
show rogue client detailed client_mac_address
Information similar to the following appears:
Information similar to the following appears:
show rogue adhoc detailed rogue_mac_address
Information similar to the following appears:
Information similar to the following appears:
Note See View any access points that have been configured to be ignored by choosing Rogue AP Ignore-List. The Rogue AP Ignore-List page appears. of the “Viewing and Classifying Rogue Devices (GUI)” section for more information on the rogue-ignore access point list.
config rogue ap classify friendly state { internal | external } ap_mac_address
Note A rogue access point cannot be moved to the Friendly class if its current state is Contain.
config rogue ap classify malicious state { alert | contain } ap_mac_address
Note A rogue access point cannot be moved to the Malicious class if its current state is Contain.
config rogue ap classify unclassified state { alert | contain } ap_mac_address
Note A rogue access point cannot be moved to the Unclassified class if its current state is Contain.
This section contains the following topics:
Cisco TrustSec (CTS) enables organizations to secure their networks and services through identity-based access control to anyone, anywhere, anytime. The solution also offers data integrity and confidentiality services, policy-based governance, and centralized monitoring, troubleshooting, and reporting services. CTS can be combined with personalized, professional service offerings to simplify solution deployment and management and is a foundational security component to Cisco Borderless Networks.
The CTS architecture establishes domains of trusted network devices. Each device in the domain is authenticated by its peers. Communication on the links between devices in the domain is secured with a combination of encryption, message integrity checks, and data-path replay protection mechanisms. CTS uses the device and user credentials acquired during authentication for classifying the packets by security groups (SGs) as they enter the network. This packet classification is maintained by tagging packets on ingress to the CTS network so that they can be correctly identified to apply security and other policy criteria along the data path. The tag, called the security group tag (SGT), allows the network to enforce the access control policy by enabling the endpoint device to act upon the SGT to filter traffic.
One of the components of the CTS architecture is the security group-based access control. Access policies in the Cisco TrustSec domain are topology-independent, based on the roles (as indicated by security group number) of source and destination devices rather than on network addresses. Individual packets are tagged with the security group number of the source.
Cisco devices use the SGT Exchange Protocol (SXP) to propagate SGTs across network devices that do not have hardware support for Cisco TrustSec. SXP is the software solution to avoid CTS hardware upgrade on all switches. WLC will be supporting SXP as part of the CTS architecture. The SXP sends SGT information to the CTS-enabled switches so that appropriate role-based access control lists (RBACLs) can be activated depending on the role information represented by the SGT. By default, the controller always works in the Speaker mode. To implement the SXP on a network, only the egress distribution switch needs to be CTS-enabled, and all the other switches can be non-CTS-capable switches.
The SXP runs between any access layer and distribution switch or between two distribution switches. The SXP uses TCP as the transport layer. CTS authentication is performed for any host (client) that joins the network on the access layer switch similar to an access switch with CTS–enabled hardware. The access layer switch is not CTS hardware enabled. Data traffic is not encrypted or cryptographically authenticated when it passes through the access layer switch. The SXP is used to pass the IP address of the authenticated device (that is a wireless client) and the corresponding SGT up to the distribution switch. If the distribution switch is CTS–hardware enabled, the switch inserts the SGT into the packet on behalf of the access layer switch. If the distribution switch is not CTS-hardware enabled, the SXP on the distribution switch passes the IP-SGT mapping to all the distribution switches that have CTS hardware. On the egress side, the enforcement of the RBACL occurs at the egress Layer 3 interface on the distribution switch.
For more information about CTS, see http://www.cisco.com/en/US/netsol/ns1051/index.html .
– MAC Filtering using RADIUS servers
– Web authentication using RADIUS servers for user authentication
Step 1 Choose SECURITY > TrustSec SXP to open the SXP Configuration page.
Figure 7-24 SXP Configuration Page
This page lists the following SXP configuration details:
This page also displays the following information about SXP connections:
Step 2 To enable CTS SXP, from the SXP State drop-down list, choose Enabled .
Step 3 Enter the default password that should be used to make an SXP connection. We recommend that the password contain a minimum of 6 characters.
Step 4 In the Retry Period text box, enter the time in seconds that determines how often the Cisco TrustSec software retries for an SXP connection.
Step 5 Click Apply to commit your changes.
Step 1 Choose SECURITY > TrustSec SXP and click New to open the SXP Connection > New page.
Step 2 In the Peer IP Address text box, enter the IP address of the next hop switch to which the controller is connected.
config cts sxp { enable | disable }
config cts sxp default password password
config cts sxp retry period time-in-seconds
config cts sxp connection peer ip-address
config cts sxp connection delete ip-address
This section contains the following topics:
The Cisco Intrusion Detection System/Intrusion Prevention System (CIDS/CIPS) instructs controllers to block certain clients from accessing the wireless network when attacks involving these clients are detected at Layer 3 through Layer 7. This system offers significant network protection by helping to detect, classify, and stop threats including worms, spyware/adware, network viruses, and application abuse. Two methods are available to detect potential attacks:
You can configure IDS sensors to detect various types of IP-level attacks in your network. When the sensors identify an attack, they can alert the controller to shun the offending client. When you add a new IDS sensor, you register the controller with that IDS sensor so that the controller can query the sensor to get the list of shunned clients.
When an IDS sensor detects a suspicious client, it alerts the controller to shun this client. The shun entry is distributed to all controllers within the same mobility group. If the client to be shunned is currently joined to a controller in this mobility group, the anchor controller adds this client to the dynamic exclusion list, and the foreign controller removes the client. The next time that the client tries to connect to a controller, the anchor controller rejects the handoff and informs the foreign controller that the client is being excluded.
The Cisco wireless intrusion prevention system (wIPS) is also supported on the controller through WCS. See the “Configuring wIPS” section for more information.
See “Configuring Mobility Groups,” for more information on mobility groups.
Step 1 Choose Security > Advanced > CIDs > Sensors to open the CIDS Sensors List page.
Figure 7-25 CIDS Sensors List Page
This page lists all of the IDS sensors that have been configured for this controller.
Note If you want to delete an existing sensor, hover your cursor over the blue drop-down arrow for that sensor and choose Remove.
Step 2 Add an IDS sensor to the list by clicking New. The CIDS Sensor Add page appears.
Step 3 The controller supports up to five IDS sensors. From the Index drop-down list, choose a number (between 1 and 5) to determine the sequence in which the controller consults the IDS sensors. For example, if you choose 1, the controller consults this IDS sensor first.
Step 4 In the Server Address text box, enter the IP address of your IDS server.
Step 5 The Port text box contains the number of the HTTPS port through which the controller is to communicate with the IDS sensor. We recommend that you set this parameter to 443 because the sensor uses this value to communicate by default.
The default value is 443 and the range is 1 to 65535.
Step 6 In the Username text box, enter the name that the controller uses to authenticate to the IDS sensor.
Note This username must be configured on the IDS sensor and have at least a read-only privilege.
Step 7 In the Password and Confirm Password text boxes, enter the password that the controller uses to authenticate to the IDS sensor.
Step 8 In the Query Interval text box, enter the time (in seconds) for how often the controller should query the IDS server for IDS events.
The default is 60 seconds and the range is 10 to 3600 seconds.
Step 9 Select the State check box to register the controller with this IDS sensor or unselected this check box to disable registration. The default value is disabled.
Step 10 In the Fingerprint text box, enter a 40-hexadecimal-character security key. This key is used to verify the validity of the sensor and is used to prevent security attacks.
Note Make sure you include colons that appear between every two bytes within the key. For example, enter AA:BB:CC:DD.
Step 11 Click Apply. Your new IDS sensor appears in the list of sensors on the CIDS Sensors List page.
Step 12 Click Save Configuration to save your changes.
Step 1 Choose Security > Advanced > CIDS > Shunned Clients to open the CIDS Shun List page.
Figure 7-26 CIDS Shun List Page
This page shows the IP address and MAC address of each shunned client, the length of time that the client’s data packets should be blocked by the controller as requested by the IDS sensor, and the IP address of the IDS sensor that discovered the client.
Step 2 Click Re-sync to purge and reset the list as desired.
Step 1 Add an IDS sensor by entering this command:
config wps cids-sensor add index ids_ip_address username password
The index parameter determines the sequence in which the controller consults the IDS sensors. The controller supports up to five IDS sensors. Enter a number (between 1 and 5) to determine the priority of this sensor. For example, if you enter 1, the controller consults this IDS sensor first.
Note The username must be configured on the IDS sensor and have at least a read-only privilege.
Step 2 (Optional) Specify the number of the HTTPS port through which the controller is to communicate with the IDS sensor by entering this command:
config wps cids-sensor port index port_number
For the port-number parameter, you can enter a value between 1 and 65535. The default value is 443. This step is optional because we recommend that you use the default value of 443. The sensor uses this value to communicate by default.
Step 3 Specify how often the controller should query the IDS server for IDS events by entering this command:
config wps cids-sensor interval index interval
For the interval parameter, you can enter a value between 10 and 3600 seconds. The default value is 60 seconds.
Step 4 Enter a 40-hexadecimal-character security key used to verify the validity of the sensor by entering this command:
config wps cids-sensor fingerprint index sha1 fingerprint
You can get the value of the fingerprint by entering show tls fingerprint on the sensor’s console.
Note Make sure to include the colons that appear between every two bytes within the key (for example, AA:BB:CC:DD).
Step 5 Enable or disable this controller’s registration with an IDS sensor by entering this command:
config wps cids-sensor { enable | disable } index
Step 6 Enable or disable protection from DoS attacks by entering this command:
config wps auto-immune { enable | disable }
The default value is disabled.
Note A potential attacker can use specially crafted packets to mislead the IDS into treating a legitimate client as an attacker. It causes the controller to wrongly disconnect this legitimate client and launches a DoS attack. The auto-immune feature, when enabled, is designed to protect against such attacks. However, conversations using Cisco 792x phones might be interrupted intermittently when the auto-immune feature is enabled. If you experience frequent disruptions when using 792x phones, you might want to disable this feature.
Step 7 Save your settings by entering this command:
Step 8 See the IDS sensor configuration by entering one of these commands:
The second command provides more information than the first.
Step 9 See the auto-immune configuration setting by entering this command:
Information similar to the following appears:
Step 10 Obtain debug information regarding IDS sensor configuration by entering this command:
Note If you ever want to delete or change the configuration of a sensor, you must first disable it by entering the config wps cids-sensor disable index command. To delete the sensor, enter the config wps cids-sensor delete index command.
This section contains the following topics:
You can configure IDS signatures, or bit-pattern matching rules used to identify various types of attacks in incoming 802.11 packets, on the controller. When the signatures are enabled, the access points joined to the controller perform signature analysis on the received 802.11 data or management frames and report any discrepancies to the controller. If an attack is detected, appropriate mitigation is initiated.
Cisco supports 17 standard signatures on the controller as shown on the Standard Signatures page.
Figure 7-27 Standard Signatures Page
These signatures are divided into six main groups. The first four groups contain management signatures, and the last two groups contain data signatures.
– NULL probe resp 1 (precedence 2)
– NULL probe resp 2 (precedence 3)
When a management frame flood signature is used to detect such an attack, the access point identifies management frames matching the entire characteristic of the signature. If the frequency of these frames is greater than the value of the frequency set in the signature, an access point that hears these frames triggers an alarm. The controller generates a trap and forwards it to WCS.
The management frame flood signatures are as follows:
– Reassoc flood (precedence 6)
– Broadcast probe flood (precedence 7)
– Disassoc flood (precedence 8)
– Reserved mgmt 7 (precedence 10)
– Reserved mgmt F (precedence 11)
The reserved management frame signatures 7 and F are reserved for future use.
When a NetStumbler signature is used to detect such an attack, the access point identifies the offending device and alerts the controller. The NetStumbler signatures are as follows:
– NetStumbler 3.2.0 (precedence 13)
– NetStumbler 3.2.3 (precedence 14)
– NetStumbler 3.3.0 (precedence 15)
– NetStumbler generic (precedence 16)
A standard signature file exists on the controller by default. You can upload this signature file from the controller, or you can create a custom signature file and download it to the controller or modify the standard signature file to create a custom signature.
Step 1 If desired, create your own custom signature file.
Step 2 Make sure that you have a Trivial File Transfer Protocol (TFTP) server available. Follow these guidelines when setting up a TFTP server:
Step 3 If you are downloading a custom signature file (*.sig), copy it to the default directory on your TFTP server.
Step 4 Choose Commands to open the Download File to Controller page.
Figure 7-28 Download File to Controller Page
Step 5 Perform one of the following:
Step 6 From the Transfer Mode drop-down list, choose TFTP or FTP .
Step 7 In the IP Address text box, enter the IP address of the TFTP or FTP server.
Step 8 If you are downloading the signature file using a TFTP server, enter the maximum number of times that the controller should attempt to download the signature file in the Maximum retries text box.
The range is 1 to 254 and the default value is 10.
Step 9 If you are downloading the signature file using a TFTP server, enter the amount of time in seconds before the controller times out while attempting to download the signature file in the Timeout text box.
The range is 1 to 254 seconds and the default is 6 seconds.
Step 10 In the File Path text box, enter the path of the signature file to be downloaded or uploaded. The default value is “/.”
Step 11 In the File Name text box, enter the name of the signature file to be downloaded or uploaded.
Note When uploading signatures, the controller uses the filename that you specify as a base name and then adds “_std.sig” and “_custom.sig” to it in order to upload both standard and custom signature files to the TFTP server. For example, if you upload a signature file called “ids1,” the controller automatically generates and uploads both ids1_std.sig and ids1_custom.sig to the TFTP server. If desired, you can then modify ids1_custom.sig on the TFTP server (making sure to set “Revision = custom”) and download it by itself.
Step 12 If you are using an FTP server, follow these steps:
a. In the Server Login Username text box, enter the username to log into the FTP server.
b. In the Server Login Password text box, enter the password to log into the FTP server.
c. In the Server Port Number text box, enter the port number on the FTP server through which the download occurs. The default value is 21.
Step 13 Choose Download to download the signature file to the controller or Upload to upload the signature file from the controller.
Step 1 Choose Security > Wireless Protection Policies > Standard Signatures or Custom Signatures to open the Standard Signatures page or the Custom Signatures page.
Figure 7-29 Standard Signatures Page
The Standard Signatures page shows the list of Cisco-supplied signatures that are currently on the controller. The Custom Signatures page shows the list of customer-supplied signatures that are currently on the controller. This page shows the following information for each signature:
Step 2 Perform one of the following:
Step 3 Click Apply to commit your changes.
Step 4 Click the precedence number of the desired signature to enable or disable an individual signature. The Standard Signature (or Custom Signature) > Detail page appears.
This page shows much of the same information as the Standard Signatures and Custom Signatures pages but provides these additional details:
– Per Signature—Signature analysis and pattern matching are tracked and reported on a per-signature and per-channel basis.
– Per MAC—Signature analysis and pattern matching are tracked and reported separately for individual client MAC addresses on a per-channel basis.
– Per Signature and MAC—Signature analysis and pattern matching are tracked and reported on a per-signature and per-channel basis as well as on a per-MAC-address and per-channel basis.
Step 5 In the Measurement Interval text box, enter the number of seconds that must elapse before the signature frequency threshold is reached within the configured interval. The range is 1 to 3600 seconds, and the default value varies per signature.
Step 6 In the Signature Frequency text box, enter the number of matching packets per interval that must be identified at the individual access point level before an attack is detected. The range is 1 to 32,000 packets per interval, and the default value varies per signature.
Step 7 In the Signature MAC Frequency text box, enter the number of matching packets per interval that must be identified per client per access point before an attack is detected. The range is 1 to 32,000 packets per interval, and the default value varies per signature.
Step 8 In the Quiet Time text box, enter the length of time (in seconds) after which no attacks have been detected at the individual access point level and the alarm can stop. The range is 60 to 32,000 seconds, and the default value varies per signature.
Step 9 Select the State check box to enable this signature to detect security attacks or unselect it to disable this signature. The default value is enabled (or selected).
Step 10 Click Apply to commit your changes. The Standard Signatures or Custom Signatures page reflects the signature’s updated state.
Step 11 Click Save Configuration to save your changes.
Step 1 Choose Security > Wireless Protection Policies > Signature Events Summary to open the Signature Events Summary page.
Figure 7-30 Signature Events Summary Page
This page shows the number of attacks detected by the enabled signatures.
Step 2 Click the signature type link for that signature to see more information on the attacks detected by a particular signature. The Signature Events Detail page appears.
This page shows the following information:
Step 3 Click the Detail link for that attack to see more information for a particular attack. The Signature Events Track Detail page appears.
Figure 7-31 Signature Events Track Detail Page
This page shows the following information:
Step 1 If desired, create your own custom signature file.
Step 2 Make sure that you have a TFTP server available. See the guidelines for setting up a TFTP server in Step 2 of the “Uploading or Downloading IDS Signatures” section.
Step 3 Copy the custom signature file (*.sig) to the default directory on your TFTP server.
Step 4 Specify the download or upload mode by entering the transfer {download | upload} mode tftp command.
Step 5 Specify the type of file to be downloaded or uploaded by entering the transfer {download | upload} datatype signature command.
Step 6 Specify the IP address of the TFTP server by entering the transfer {download | upload} serverip tftp-server-ip-address command.
Note Some TFTP servers require only a forward slash (/) as the TFTP server IP address, and the TFTP server automatically determines the path to the correct directory.
Step 7 Specify the download or upload path by entering the transfer {download | upload} path absolute-tftp-server-path-to-file command.
Step 8 Specify the file to be downloaded or uploaded by entering the transfer {download | upload} filename filename.sig command.
Note When uploading signatures, the controller uses the filename you specify as a base name and then adds “_std.sig” and “_custom.sig” to it in order to upload both standard and custom signature files to the TFTP server. For example, if you upload a signature file called “ids1,” the controller automatically generates and uploads both ids1_std.sig and ids1_custom.sig to the TFTP server. If desired, you can then modify ids1_custom.sig on the TFTP server (making sure to set “Revision = custom”) and download it by itself.
Step 9 Enter the transfer { download | upload } start command and answer y to the prompt to confirm the current settings and start the download or upload.
Step 10 Specify the number of seconds that must elapse before the signature frequency threshold is reached within the configured interval by entering this command:
config wps signature interval signature_id interval
where signature_id is a number used to uniquely identify a signature. The range is 1 to 3600 seconds, and the default value varies per signature.
Step 11 Specify the number of matching packets per interval that must be identified at the individual access point level before an attack is detected by entering this command:
config wps signature frequency signature_id frequency
The range is 1 to 32,000 packets per interval, and the default value varies per signature.
Step 12 Specify the number of matching packets per interval that must be identified per client per access point before an attack is detected by entering this command:
config wps signature mac-frequency signature_id mac_frequency
The range is 1 to 32,000 packets per interval, and the default value varies per signature.
Step 13 Specify the length of time (in seconds) after which no attacks have been detected at the individual access point level and the alarm can stop by entering by entering this command:
config wps signature quiet-time signature_id quiet_time
The range is 60 to 32,000 seconds, and the default value varies per signature.
Step 14 Perform one of the following:
config wps signature {standard | custom} state signature_id {enable | disable}
config wps signature {enable | disable}
Note If IDS signature processing is disabled, all signatures are disabled, regardless of the state configured for individual signatures.
Step 15 Save your changes by entering this command:
Step 16 If desired, you can reset a specific signature or all signatures to default values. To do so, enter this command:
config wps signature reset { signature_id | all }
Note You can reset signatures to default values only through the controller CLI.
Information similar to the following appears:
Note If IDS signature processing is disabled, all signatures are disabled, regardless of the state configured for individual signatures.
Information similar to the following appears:
show wps signature events summary
Information similar to the following appears:
show wps signature events {standard | custom} precedence# summary
Information similar to the following appears:
show wps signature events {standard | custom} precedence# detailed per-signature source_mac
show wps signature events {standard | custom} precedence# detailed per-mac source_mac
This section contains the following topics:
The Cisco Adaptive wireless intrusion prevention system (wIPS) is an advanced approach to wireless threat detection and performance management. It combines network traffic analysis, network device and topology information, signature-based techniques, and anomaly detection to deliver highly accurate and complete wireless threat prevention. With a fully infrastructure-integrated solution, you can continually monitor wireless traffic on both the wired and wireless networks and use that network intelligence to analyze attacks from many sources to more accurately pinpoint and proactively prevent attacks rather than waiting until damage or exposure has occurred.
The Cisco Adaptive wIPS is enabled by the Cisco 3300 Series Mobility Services Engine (MSE), which centralizes the processing of intelligence collected by the continuous monitoring of Cisco Aironet access points. With Cisco Adaptive wIPS functionalities and WCS integration into the MSE, the wIPS service can configure, monitor, and report wIPS policies and alarms.
Note If your wIPS deployment consists of a controller, access point, and MSE, you must set all the three entities to the UTC time zone.
The Cisco Adaptive wIPS is not configured on the controller. Instead, WCS forwards the profile configuration to the wIPS service, which forwards the profile to the controller. The profile is stored in flash memory on the controller and sent to access points when they join the controller. When an access point disassociates and joins another controller, it receives the wIPS profile from the new controller.
Local mode or FlexConnect mode access points with a subset of wIPS capabilities is referred to as Enhanced Local Mode access point or just ELM AP. You can configure an access point to work in wIPS mode if the access point is in any of the following modes:
wIPS ELM has limited capability of detecting off-channel alarms. The access point periodically goes off-channel, and monitors the non-serving channels for a short duration, and triggers alarms if any attack is detected on the channel. But the off-channel alarm detection is best effort and it takes longer time to detect attacks and trigger alarms, which might cause the ELM AP intermittently detect an alarm and clear it because it is not visible. Access points in any of the above modes can periodically send alarms based on the policy profile to the wIPS service through the controller. The wIPS service stores and processes the alarms and generates SNMP traps. WCS configures its IP address as a trap destination to receive SNMP traps from the MSE.
Table 7-11 lists all the SNMP trap controls and their respective traps. When a trap control is enabled, all the traps of the trap control are also enabled.
The following are the trap description for the traps mentioned in the Table 7-11 above:
– SNMP Authentication—The SNMPv2 entity has received a protocol message that is not properly authenticated.
Note When a user who is configured in SNMP V3 mode tries to access the controller with an incorrect password, the authentication fails and a failure message is displayed. However, no trap logs are generated for the authentication failure.
– Link (Port) Up/Down—Link changes status from up or down.
– Multiple Users—Two users login with the same login ID.
– Spanning Tree—Spanning Tree traps. See the STP specifications for descriptions of individual parameters.
– Rogue AP—Whenever a rogue access point is detected this trap will be sent with its MAC Address; When a rogue access point that was detected earlier and it no longer exists this trap is sent.
– Config Save—Notification sent when the controller configuration is modified.
– AP Register—Notification sent when an access point associates or disassociates with the controller.
– AP Interface Up/Down—Notification sent when access point interface (802.11a or 802.11b/g) status goes up or down.
– 802.11 Association—The associate notification is sent when the client sends an association frame.
– 802.11 Disassociation—The disassociate notification is sent when the client sends a disassociation frame.
– 802.11 Deauthentication—The deauthenticate notification is sent when the client sends a deauthentication frame.
– 802.11 Failed Authentication—The authenticate failure notification is sent when the client sends an authentication frame with a status code other than 'successful'.
– 802.11 Failed Association—The associate failure notification is sent when the client sends an association frame with a status code other than 'successful'.
– Exclusion—The associate failure notification is sent when a client is excluded.
– User Auth Failure—This trap is to inform that a client RADIUS Authentication failure has occurred.
– RADIUS Server No Response—This trap is to indicate that no RADIUS server(s) are responding to authentication requests sent by the RADIUS client.
– WEP Decrypt Error—Notification sent when the controller detects a WEP decrypting error.
– Rouge AP—Whenever a rogue access point is detected this trap will be sent with its MAC Address; When a rogue access point that was detected earlier and it no longer exists this trap is sent.
– SNMP Authentication—The SNMPv2 entity has received a protocol message that is not properly authenticated.
Note When a user who is configured in SNMP V3 mode tries to access the controller with an incorrect password, the authentication fails and a failure message is displayed. However, no trap logs are generated for the authentication failure.
– Multiple Users—Two users login with the same login ID.
– Load Profile—Notification sent when Load Profile state changes between PASS and FAIL.
– Noise Profile—Notification sent when Noise Profile state changes between PASS and FAIL.
– Interference Profile—Notification sent when Interference Profile state changes between PASS and FAIL.
– Coverage Profile—Notification sent when Coverage Profile state changes between PASS and FAIL.
– Channel Update—Notification sent when access point dynamic channel algorithm is updated.
– Tx Power Update—Notification sent when access point dynamic transmit power algorithm is updated.
– Child Excluded Parent—Notification send when a defined number of failed association to the controller occurs through a parent mesh node.
– Notification sent when child mesh node exceeds threshold limit of number of discovery response timeouts. The child mesh node will not try to associate excluded parent mesh node for the interval defined. The child mesh node will remember the excluded parent MAC address and when it joins the network it will inform the controller.
– Parent Change—Notification is sent by the agent when a child mesh node changes its parent. The Child mesh node remembers its previous parent and it will inform the controller about the change of its parent when it joins back the network.
– Child Moved—Notification sent when a parent mesh node loses connection with its child mesh node.
– Excessive Parent Change—Notification sent when child mesh node changes its parent frequently. Each mesh node keeps count of number of parent changes in fixed time. If it exceeds the defined threshold then child mesh node informs the controller.
– Excessive Children—Notification sent when the child count exceeds for a RAP and MAP.
– Poor SNR—Notification sent when child mesh node detects lower SNR on backhaul link. For the other trap, a notification is sent to clear a notification when child mesh node detects SNR on backhaul link is higher then the object defined by 'clMeshSNRThresholdAbate'.
– Console Login—Notification is sent by the agent when login on MAP console is successful or failure after three attempts.
– Default Bridge Group Name—Notification sent when MAP mesh node joins parent using 'default' bridge group name.
Note The remaining traps do not have trap controls. These are traps, which are not generated too frequently and thus do not require any trap control. Thus, any other trap generated by the Controller cannot be turned off.
Note In all of the above cases, the controller functions solely as a forwarding device.
Note To download the MIBs, click on http://www.cisco.com/cisco/software/release.html?mdfid=282600534&flowid=7012&softwareid=280775088&release=7.3&relind=AVAILABLE&rellifecycle=&reltype=latest.
For more information on the Cisco Adaptive wIPS, see the Cisco Wireless Control System Configuration Guide, Release 7.0.172.0 and the Cisco 3300 Series Mobility Services Engine Configuration Guide, Release 7.0 .201.0.
Step 1 Choose Wireless > Access Points > All APs > access point name .
Step 2 Set the AP Mode parameter. To configure an access point for wIPS, you must choose one of the following modes from the AP Mode drop-down list:
Step 3 Set the AP Sub Mode to wIPS by choosing wIPS from the AP Sub Mode drop-down list.
Step 1 Configure an access point for monitor mode by entering this command:
config ap mode {monitor | local | flexconnect} Cisco_AP
Note To configure an access point for wIPS, the access point must be in monitor, local, or flexconnect modes.
Step 2 Enter Y when you see the message that the access point will be rebooted if you want to continue.
Step 3 Save your changes by entering this command:
Step 4 Disable the access point radio by entering this command:
config {802.11a | 802.11b} disable Cisco_AP
Step 5 Configure the wIPS submode on the access point by entering this command:
config ap mode ap_mode submode wips Cisco_AP
Note To disable wIPS on the access point, enter the config ap mode ap_mode submode none Cisco_AP command.
Step 6 Enable wIPS optimized channel scanning for the access point by entering this command:
config ap monitor-mode wips-optimized Cisco_AP
The access point scans each channel for 250 milliseconds. It derives the list of channels to be scanned from the monitor configuration. You can choose one of these options:
The 802.11a or 802.11b Monitor Channels text box in the output of the show advanced { 802.11a | 802.11b} monitor command shows the monitor configuration channel set:
Step 7 Reenable the access point radio by entering this command:
config { 802.11a | 802.11b} enable Cisco_AP
Step 8 Save your changes by entering this command:
Note You can also view the access point submode from the controller GUI. To do so, choose Wireless > Access Points > All APs > the access point name > the Advanced tab. The AP Sub Mode text box shows wIPS if the access point in is monitor mode and the wIPS submode is configured on the access point or None if the access point is not in monitor mode or the access point is in monitor mode but the wIPS submode is not configured.
show ap config general Cisco_AP
Information similar to the following appears:
Information similar to the following appears:
Information similar to the following appears:
This section contains the following topics:
Devices that are Wi-Fi Direct capable can connect directly to each other quickly and conveniently to do tasks such as printing, synchronization, and sharing of data. Wi-Fi Direct devices can associate with multiple peer-to-peer (P2P) devices and with infrastructure wireless LANs (WLANs) concurrently. You can use the controller to configure the Wi-Fi Direct Client Policy, on a per WLAN basis, where you can allow or disallow association of Wi-Fi devices with infrastructure WLANs or disable Wi-Fi Direct Client Policy altogether for WLANs.
Wi-Fi Direct Client Policy is applicable to WLANs that have APs in local mode only.
Step 1 Choose WLANs to open the WLANs page.
Step 2 Click the WLAN ID of the WLAN for which you want to configure the Wi-Fi Direct Client Policy. The WLANs > Edit page appears.
Step 3 Click the Advanced tab.
Step 4 From the Wi-Fi Direct Clients Policy drop-down list, choose one of the following options:
Step 5 Click Apply to commit your configuration.
Step 1 To configure the Wi-Fi Direct Client Policy on WLANs, enter this command:
config wlan wifidirect { allow | disable | not-allow } wlan-id
The syntax of the command is as follows:
Step 2 Save your configuration by entering this command:
This section contains the following topics:
This feature enables clients that have a manual web proxy enabled in the browser to facilitate authentication with the controller. If the user's browser is configured with manual proxy settings with a configured port number as 8080 or 3128 and if the client requests any URL, the controller responds with a web page prompting the user to change the Internet proxy settings to automatically detect the proxy settings so that the browser’s manual proxy settings information does not get lost. After enabling this settings, the user can get access to the network through the web authentication policy. This functionality is given for port 8080 and 3128 because these are the most commonly used ports for the web proxy server.
Note Webauth proxy redirect ports are not blocked via CPU ACL. If a CPU ACL is configured to block the port 8080, 3128, and one random port as part of webauth proxy configuration, then those ports are not blocked because the webauth rules take higher precedence than the CPU ACL rules, until the client is in webauth_req state.
A web browser has three types of Internet settings that can be configured by the user:
In a manual proxy server configuration, the browser uses a proxy server's IP address and a port. If this configuration is enabled on the browser, the wireless client communicates with the destination proxy server's IP on the configured port. In a Web-Auth scenario, the controller does not listen to such proxy ports and the client would not able to establish a TCP connection with the controller. In effect, the user is unable to get any login page to authentication and get access to the network.
When a wireless client enters a web authenticated WLAN network, it tries to access a URL. If a manual proxy configuration is configured on the client's browser, all web traffic going out from the client will be destined to the proxy IP and port configured on the browser.
Note For external clients, the controller sends the login page as is (with or without JavaScipt).
Note When you configure FIPS mode with secure web authentication, we recommend that you use Mozilla Firefox as your browser.
Step 1 Choose Controller > General to open the Controller > General page.
Step 2 From the WebAuth Proxy Redirection Mode, select Enabled .
Step 3 In the WebAuth Proxy Redirection Port text box, enter the port number of the web auth proxy.
This text box consists of the port numbers on which the controller listens to for web authentication proxy redirection. By default, the three ports 80, 8080, and 3128 are assumed. If you configured the web authentication redirection port to any port other than these values, you must specify that value.
The default secure web (https) authentication for clients is enabled.
Note If you configure to disallow secure web (https) authentication for clients using the config network web-auth secureweb disable command, then you must reboot the Cisco WLC to implement the change.
This parameter specifies the port numbers on which the controller listens to for web authentication proxy redirection. By default, the three ports 80, 8080, and 3128 are assumed. If you configured the web authentication redirection port to any port other than these values, you must specify that value.
The controller supports three active exploit alarms that serve as notifications of potential threats. They are enabled by default and therefore require no configuration on the controller.