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.
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).
! 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.
! 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.)
! 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).
! 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.