Cisco WiSM Config Practice Opens SVI Vulnerability
Cisco’s recommend WiSM configuration practice will make you vulnerable – by George Stefanick
I was asked, “The WiSM Config Practice has been out for years, how did you find this ?” The devil is in the details....
WiSM Configuration Practice
The initial steps in configuring a Cisco WiSM is what I like to call a “configure-and-forget” step. This is because once the WiSM is configured and married to the backplane of the Sup720 via the “service port” its rare one would need to revisit this procedure again.
There are a number of Cisco WiSM Configuration guides available at cisco.com explaining this process. We will get into these in a bit…
What is the WiSM “service port”?
First lets understand what the service port interface is and the purpose of the service port. The WiSM service port is one of many ports on a Cisco WiSM. They include the management, ap manager, virtual, service and the operator dynamic interfaces.
- Management interface (pre-defined and mandatory)
- AP-Manager interface (pre-defined and mandatory)
- Virtual interface (pre-defined and mandatory)
- Service-port interface (pre-defined and mandatory)
- Operator-defined interface (user-defined)
Cisco’s 4400 and 5500 model controller’s service port is used for out-of-bandwidth management. The service port is a physical port supported on these models, whereby allowing you physical access with a console / null modem cable.
Contrary to the service port on the 4400 and 5500’s models. The WiSM service port is NOT used for out-of-bandwidth management. Rather it is used to synchronize the supervisor engine (720) and the WiSM.
How does the “service port” on the Cisco WiSM connect to the Sup720?
Once the WiSM is installed, you enter the Sup720 and create a local vlan for the purpose of communications between both the WiSM and the Sup720. Cisco references vlan 192 in their WiSM config documents, but of course any vlan number can be used.
Cisco’s WiSM Configuration documentation goes a step further and states to create an SVI interface. An SVI interface is a gateway to bridge traffic. (Here in lies the problem. I will cover in more detail in the next section.)
(See below reference and links to Cisco WiSM configuration Guides, note the SVI interface recommendations and the lack of an ACL)
The Vulnerability
The Cisco WiSM Configuration Guides detail the creation of an SVI interface for the purpose of the service port interface. For example;
Sup720(config)# interface Vlan 192
Sup720(config-if)# ip address 192.168.10.1 255.255.255.0
Sup720(config-if)# no shutdown
Sup720(config-if)# exit
The Cisco WiSM Guides makes no reference to an ACL which would restrict traffic access to the service port SVI interface. By creating the SVI interface you have a “connected route” from users who terminate to the 6500 to reach the SVI interface. This would include wired and wireless users. Essentially, inside users have access to the WiSM service port. This would also include wireless guest!
Lets follow the packet:
1) Wireless client pings 192.168.10.1
2) The packet egresses the wireless client and 802.11 headers are applied
3) The packet travels via RF
4) Packet reaches Access Point
5) Access points encapsulates the packet in a LWAPP/CAPWAP headers
6) The packet is then sent to the Cisco WiSM / Controller
7) The WiSM removes the LWAPP/CAPWAP encapsulation and adds 802.3 headers
8) The WiSM places the packet on the wired
9) The packet transverses the router to the connected 192.168.10.1 SVI interface
I’m positive this is an oversight by Cisco. Recent conversations with Cisco SE’s, Cisco TAC and other peers agree this is an issue on many levels.
Engineers and Admins who configure the WiSM for the first time or perhaps engineers who have little knowledge would follow the Cisco WiSM Configuration Guide step by step. Not understanding that an ACL needs to be applied to the SVI interface for the WiSM service port.
Real World Examples:
Lets cover why this is an issue with some real world examples:
Example#1 –
Your inside networks are 10.x.x.x and 172.x.x.x. Your service port on the WiSM is configured for 192.168.10.x network. Users who terminated to the cat / Sup 720 that houses the WiSM has access to the SVI interface 192.168.10.x. Why, because it is a connected route. The traffic will bridge over from 10 / 172 to the 192 network.
Example#2 –
Suppose you don’t have a Cisco WLC to anchor guest traffic. Your wireless guest traffic terminates to the cat / Sup720 that houses the WiSM. Let suppose you ACL your "GUEST" SVI interface denying your known inside networks. You think you are done and call it a day.
DENY 10.0.0.0 (inside network)
But did you remember to deny 192.168.10.x? If you didn’t your wireless guest now have access to your service port
How to Fix it:
If you configured an SVI interface. Simply ACL the SVI not to allow ANY network access to this SVI interface.
Conclusion:
I admit this isn’t a five-alarm hole. You don’t have to drop everything you are doing. But it is one that needs to be addressed if you followed Cisco WiSM Configuration Guides.
Cisco links to WiSM Config
http://www.cisco.com/en/US/docs/wireless/technology/wism/technical/reference/appnote.html
! - Create a vlan in the Supervisor 720, this vlan is local to the chassis and is used for
communication between Cisco WiSM and Catalyst Supervisor 720 over a Gigabit interface on
the Supervisor and service-port in the Cisco WiSM.
Sup720(config)# vlan 192
! -- Assign an appropriate IP address and subnet mask for VLAN 192
Sup720(config)# interface Vlan 192
Sup720(config-if)# ip address 192.168.10.1 255.255.255.0
Sup720(config-if)# no shutdown
Sup720(config-if)# exit
http://www.cisco.com/en/US/products/hw/modules/ps2706/products_tech_note09186a00808330a9.shtml
Create the WiSM Service Port Gateway and assign the IP address.
Create a VLAN in the Supervisor 720. This VLAN is local to the chassis and is used for communication between Cisco WiSM and Catalyst Supervisor 720 over a Gigabit Interface on the Supervisor and a service port in the Cisco WiSM.
interface Vlan192
Description WiSM Service Port Gateway or Management Interface on CAT6K
ip address 192.168.10.1 255.255.255.0
Reader Comments (4)
After I read your blog post I VPNd into our network. I was able to ping the SVI interface of our WiSM. I guess I know what I'll be doing first thing tomorrow. Love the site!
You can't SSH to the service port. It doesn't respond to ping either. A quick NMAP scan shows no open ports. What exactly is the security risk?
Hi Jason, thanks for your reply. You are correct about the service port, however we aren't talking about the service port on the WISM. We are talking about the SVI interface. If you follow Cisco WiSM guide you create an SVI interface. This SVI interface is a connected route @ the SUP. Folks that are security minded but more so folks that dump their guest traffic off at the SUP720 need to ACL this SVI interface. The SVI can be reached, because it is a connected route. Like I mentioned this is not a 5 alarm fire here. But folks should know this interface can be reached if not properly ACLd. And since WISMs are "install and forget" devices this becomes a concern for so. Thanks for your response...
We don't have a guest anchor controller and we egress the wireless traffic from the distribution. I'm working late this evening on projects. I just connected to our guest wireless and sure enough I can ping and access the SVI interface from our guest network. In fact the contractor who setup the WiSMs apparently used the same IP address from the WiSM guide. Thanks for the heads up.