Secure WLAN Management Configuration Guidelines

This section discusses the configuration commands for secure management best practices, as outlined in Chapter 10.

By default, Telnet access is enabled on the APs. It is recommended that you disable Telnet access and enable SSH access to the APs. Example 12-24 illustrates the configuration required to disable Telnet access on the AP.

Example 12-24. Commands to Disable Telnet Access to the AP

access-list 111 permit tcp any any neq telnet

line vty 0 4

 access-class 111 in

line vty 5 15

 access-class 111 in

!

Example 12-25 shows commands required to enable SSH access and disable HTTP access on the IOS-enabled APs or the bridges. By default, HTTP access is enabled on the APs for management. It is recommended that you disable HTTP access or restrict HTTP access to the AP (management traffic only).

Example 12-25. Commands to Enable SSH Access on the AP/Bridge

! Commands to enable SSH version 1.5 on the APs/Bridges

! Domain-name is simply used as a seed to generate the RSA keys for the SSH sessions

TMELAB-AP1(config)#ip domain-name tmelab.cisco.com

TMELAB-AP1(config)#crypto key generate rsa general-keys modulus 1024

! Command to disable HTTP access to the AP

TMELAB-AP1(config)#no ip http server

Administrator authentication is locally enabled on the APs. If desired, RADIUS or TACACS+ can be used for administrator authentication. You can use the commands shown in Example 12-26 on a standalone AP or on the WDS client AP to enable TACACS authentication.

Example 12-26. TACACS Configuration Required for Administrator Authentication

!

TMELAB-AP1(config)#aaa new-model

! Specify TACACS+ server information

TMELAB-AP1(config)#tacacs-server host 10.10.10.5 key tmelab1

TMELAB-AP1(config)#aaa group server tacacs+ tac-admin

TMELAB-AP1(config-sg-tacacs+)#server 10.10.10.5

TMELAB-AP1(config-sg-tacacs+)#exit

! Remove default user account

TMELAB-AP1(config)#no Username Cisco

! Configure to check the local user database first and then the TACACS server for user

authentication and authorization

TMELAB-AP1(config)#aaa authentication login default local group tac-admin

TMELAB-AP1(config)#aaa authorization exec default local group tac-admin

! If desired, enable http authentication/authorization via TACACS

TMELAB-AP1(config)#ip http authentication aaa

Along with the preceding configuration on the AP/bridge, you must add the AP/bridge as "TACACS+(IOS)" AAA client on the AAA server. Also, make sure to create the appropriate user accounts on the AAA server and to provide the appropriate level of access for each user. For example, when using Cisco Secure ACS server, user or user-group settings for the "TACACS(IOS)" privilege level parameter can be specified from level 1 to 15 for the administrative user (1 = read only, whereas 15 = read and write permissions).

A hacker can potentially spoof the default gateway MAC address for a guest VLAN or in a hotspot scenario to carry out man-in-the-middle (MitM) attacks. It is recommended that you lock down the default gateway MAC address to prevent these attacks in a hotspot or guest VLAN deployment scenario. Example 12-27 prevents the hacker from using the default gateway (10.10.10.1) MAC address to carry out MitM attacks. As shown in Example 12-27, the MAC address of the default gateway (DG) is added to the association access list. This prevents anyone from using the DG MAC address and associating to the AP. (That is, it prevents DG MAC address spoofing.)

Example 12-27. Black Listing the Default Gateway MAC Address on the AP

! Black listing the default gateway mac-address to prevent MitM attacks in a hot-spot/

guest access scenario

TMELAB-AP1#sh arp

Protocol  Address          Age (min)  Hardware Addr   Type   Interface

Internet  10.10.10.1              0   0004.dd82.29c0  ARPA   BVI1

Internet  10.10.10.27             0   0009.6b50.bd45  ARPA   BVI1

Internet  10.10.10.24            33   000c.850f.256a  ARPA   BVI1

Internet  10.10.10.22            34   000c.30e9.0711  ARPA   BVI1

Internet  10.10.10.21             -   000c.8500.0156  ARPA   BVI1

! Create an association access list to deny client(s) from using the DG mac-address

dot11 association mac-list 700

access-list 700 deny   0004.dd82.29c0   0000.0000.0000

access-list 700 permit 0000.0000.0000   ffff.ffff.ffff

Public Secure Packet Forwarding (PSPF) prevents a client that is associated to an AP from communicating with other clients on the same WLAN cell. This feature should be enabled on guest VLANs and on hotspot deployments to prevent hacker attempts to compromise WLAN user devices. As shown in Example 12-28, PSPF can be enabled on the radio interface and on the radio subinterface(s).

Example 12-28. Port Security (PSPF) Configuration Commands

! Enabling PSPF (port security) on the Radio interface

TMELAB-AP1#conf t

TMELAB-AP1(config)#int dot11Radio 0

TMELAB-AP1(config-if)#bridge-group 1 port-protected

It is a recommended practice to restrict management traffic to the AP/bridge. If VLANs are enabled on the AP/bridge, management traffic can be separated from the user traffic, and ACLs can be applied on the management VLAN. You can implement the following best practices to secure management traffic between the AP/bridge and the management servers (WLSE, AAA, and so on):

• Restrict network management and radio management traffic between APs and the WLSE:

  - Allow SNMP traffic between the APs and the WLSE.

  - Allow WLCCP traffic (UDP, 2887) between the APs and the WDS.

  - Allow WLCCP traffic (UDP, 2887) between the WDS and the WLSE.

  - Allow SSH (TCP, port 22) and HTTP traffic between management servers and the APs.

  - Allow TFTP traffic between the APs and the WLSE.

• Restrict RADIUS traffic between APs and the RADIUS server:

  - Allow authentication traffic: UDP, port 1812 or 1645.

  - Allow accounting traffic: UDP, port 1813 or 1646.

• Restrict other traffic types:

  - Allow DHCP traffic between APs and the DHCP server.

• Deny all other traffic to the APs.