Introduction
Protecting access to the management interfaces of your network devices is a must but you have to think twice before implementing this kind of security on a Cisco WLAN Controller. By using a CPU ACL (access control list) you can lock down which IP networks or IP addresses are allowed to communicate to the WLC CPU which is where you would have to go to make changes to the configuration, get SNMP data, and much more.
However, it isn't as simple as that. Unlike switches where you can configure an ACL to protect the vty lines which are where Telnet/SSH connections would appear, protecting the management interface of a WLC is a bit trickier.
If you dive into Cisco's documentation on the matter you will find that there are a lot of different takes on how the CPU ACL actually works. Some claim it's only for management access, some claim it could block communication with RADIUS/TACACS-servers and even deny access points from connecting to the WLC. There seem to be a lot of changes between the different software versions.
To test what the WLC CPU ACL actually does we will use a WLC 2504 running version 8.3.102.0 and a WLC 5508 running version 8.4.100.0.
What the WLC CPU ACL can't block:
CAPWAP traffic to and from access points.
Traffic to and from other WLCs in Mobility Group.
Traffic to and from RADIUS/TACACS servers.
Traffic to and from LDAP servers.
Traffic to and from DHCP servers.
That means that even if you lock down your WLC with an ACL containing only "deny ip any any", all of these services will still work. In one of the Cisco documents regarding CPU ACL, there was a statement saying that "traffic initiated by the WLC CPU itself will never be blocked" and this seems to be true. If you are wondering why DHCP-server is included here that is because the WLC can act as a DHCP Proxy (enabled by default, it's essentially the WLC's version of a router's ip helper-address command), and then the traffic is considered to be initiated by the WLC itself and not the client.
What the WLC CPU ACL will block:
HTTP/HTTPS traffic towards the WLC management IP address.
SSH/Telnet traffic towards the WLC management IP address.
SNMP traffic towards the WLC management IP address.
FTP/TFTP/SFTP traffic towards the WLC management IP address.
ICMP traffic (like ping) towards the WLC management IP address and all dynamic interfaces (client interfaces).
What you should manually permit:
Management IP networks (probably your IT department).
Whatever IP network you have assigned to the WLC's Service Port for Out-of-Band management.
Traffic from backup tools such as Cisco Prime, NetMRI, Rancid, and so on.
Traffic from monitoring tools like OP5, Solarwinds, etc.
Final Notes
You can use the command show rules to see what the WLC itself has decided to permit to communicate with the CPU. The output looks like a huge ACL where the WLC will automatically add the IP addresses and network ports of every RADIUS-server, DHCP-server, TACACS-server, and more as "Allowed" services. If you for example add a RADIUS authentication server, the IP address of the server and quite a few important ports like 1812 and 1700 (Change-of-Authorization, CoA) will be added without you having to think about it.
You cannot make changes to the WLC CPU ACL while it is in effect. You have to disable the CPU ACL feature to modify the ACL.
Even if you permit one of the "unblockable" services like the CAPWAP ports (UDP 5246/5247) in your ACL, the hit counter for them will never increase. The same goes for RADIUS/TACACS/LDAP and Mobility Group traffic.
For my testing, I locked down the WLC CPU down to IP-address/port level but I think you'd be fine going with just permit at IP level to keep it simple. Do whatever feels best (or whatever your company's policy decides...).