WLC MGMT Interface Access Control

[aavnet89]

Hello, Cisco Community,

With the recent announcement of multiple vulnerabilities in Cisco IOS XE Software Web UI Feature, CVE-2023-20198 and CVE-2023-20273 respectfully. I have taken to closing any holes that afflict our environment. My concern (however not addressed in the advisory: Multiple Vulnerabilities in Cisco IOS XE Software Web UI Feature) is for our AirOS Infrastructure, with varying WLC(s) globally, and the secure-server feature being present, I could not / cannot identify if the 3500 series product line is impacted. I would assume not, given the lack of communication relating to AirOS in the advisory statement.

Through my remediation, I have identified that network management over HTTPS to our Wireless LAN Controllers is not suitably limited through access control(s), open to administrative connection via HTTPS from any internal source that isn't currently policed through ISE. i.e. server VLANs etc. To combat to this, I wish to enforce Access Control through ACLs, VACLs, or perhaps a policy map within ISE itself.

The Controllers supply an option to apply a local ACL to the MGMT interface, processed in software, my concern given the age of the hardware and expected traffic over this interface is degradation in performance, resulting in packet loss. This lead me to look at applying a ACL, PACL, VACL on the directly connected switch of the Controller(s). Traffic control is then closer to the source, utilising specific hardware allocated, specifically for VACLs. My understanding is all packets bridged and entering the VLAN are checked against the VACL. With significant traffic and varying usage, making Access Control cumbersome to manage, and potentially introducing a bottleneck, given the extensive VACL Map that would be required to govern the Virutal LAN.

Also considered CBAC, unfortunately the associated switching infrastructure does not support this feature, thus not applicable in this situation.

My question: Given the scenario above, and that the Controllers are not public facing, what access control type would best suit the requirement? And where would the access control be placed?

My thanks in advance.

[marce1000]

                >..., and that the Controllers are not public facing, 
 - In my opinion that would be sufficient to mitigate this vulnerability , 
 
 M.

[aavnet89]

Thanks, Marce1000,

The vulnerability isn't the focus point, simply back-fill to provide detail where possible. My question relates more to restricting access to the MGMT interface of a WLC without impacting services and or the production environment, and where based on the scenario access control should be placed.

[marce1000 · Accepted solution]

                       >...cannot identify if the 3500 series product line is impacted. 
            - It isn't because the aireos based controllers do not run IOS-XE  (where the vulnerability takes place)

          >... and where based on the scenario access control should be placed.
 - For the AireOS models best on the controller itself with so called 'CPU ACL(s)' : good document here : 
                       https://mrncciew.com/2013/03/15/wlc-access-control-list-acl/

 M.

[Scott Fella]

Like Marce mentioned, the CPU ACL is what you need to use.  Be careful or else you will lock yourself out.  You should read u on it from various sources and hopefully you have a spare/lab controller you can build out your CPU ACL.

[aavnet89]

Thanks, Scott,

The CPU ACL looks to certainly be what I need. In terms of transport services, I will perform an invisible port-scan to identify open TCP services.

Thanks again to you all.

[marce1000]

  - Yeah , the CPU ACL is what you need indeed for AireOS based controllers , but  you need to be carefully with it , to not lock yourself out. Ideally it would be done on initial controller configuration without APs connected or clients served.  You may try it (e.g.) without saving the configuration immediately , in case of trouble , (or have a spare controller for testing)

 M.

[Rich R]

Yes we use CPU ACL.
Just remember all the other things you might need to allow:
https://www.cisco.com/c/en/us/support/docs/wireless/5500-series-wireless-controllers/113344-cuwn-ppm.html
Ideally your WLC management should be behind a firewall too.
Like others have warned - make sure you have console access to disable the CPU ACL in case you lock yourself out.