- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
11-08-2023 01:09 AM
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.
Solved! Go to Solution.
- Labels:
-
Other NAC
Accepted Solutions
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
11-08-2023 04:23 AM
>...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.
-- Each morning when I wake up and look into the mirror I always say ' Why am I so brilliant ? '
When the mirror will then always repond to me with ' The only thing that exceeds your brilliance is your beauty! '
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
11-08-2023 03:18 AM
>..., and that the Controllers are not public facing,
- In my opinion that would be sufficient to mitigate this vulnerability ,
M.
-- Each morning when I wake up and look into the mirror I always say ' Why am I so brilliant ? '
When the mirror will then always repond to me with ' The only thing that exceeds your brilliance is your beauty! '
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
11-08-2023 03:37 AM
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
11-08-2023 04:23 AM
>...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.
-- Each morning when I wake up and look into the mirror I always say ' Why am I so brilliant ? '
When the mirror will then always repond to me with ' The only thing that exceeds your brilliance is your beauty! '
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
11-08-2023 08:01 AM
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.
*** Please rate helpful posts ***
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
11-09-2023 04:18 AM
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
11-09-2023 04:44 AM
- 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.
-- Each morning when I wake up and look into the mirror I always say ' Why am I so brilliant ? '
When the mirror will then always repond to me with ' The only thing that exceeds your brilliance is your beauty! '
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
11-09-2023 05:39 AM
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.
Please click Helpful if this post helped you and Select as Solution (drop down menu at top right of this reply) if this answered your query.
------------------------------
TAC recommended codes for AireOS WLC's and TAC recommended codes for 9800 WLC's
Best Practices for AireOS WLC's, Best Practices for 9800 WLC's and Cisco Wireless compatibility matrix
Check your 9800 WLC config with Wireless Config Analyzer using "show tech wireless" output or "config paging disable" then "show run-config" output on AireOS and use Wireless Debug Analyzer to analyze your WLC client debugs
Field Notice: FN63942 APs and WLCs Fail to Create CAPWAP Connections Due to Certificate Expiration
Field Notice: FN72424 Later Versions of WiFi 6 APs Fail to Join WLC - Software Upgrade Required
Field Notice: FN72524 IOS APs stuck in downloading state after 4 Dec 2022 due to Certificate Expired
- Fixed in 8.10.196.0, latest 9800 releases, 8.5.182.12 (8.5.182.13 for 3504) and 8.5.182.109 (IRCM, 8.5.182.111 for 3504)
Field Notice: FN70479 AP Fails to Join or Joins with 1 Radio due to Country Mismatch, RMA needed
How to avoid boot loop due to corrupted image on Wave 2 and Catalyst 11ax Access Points (CSCvx32806)
Field Notice: FN74035 - Wave2 APs DFS May Not Detect Radar After Channel Availability Check Time
Leo's list of bugs affecting 2800/3800/4800/1560 APs
Default AP console baud rate from 17.12.x is 115200 - introduced by CSCwe88390
