WLC 5508 WebAuth - CPU ACL/ACL

[maissiat]

Dear All,

We just performed a PenTest from our Guest wireless network. The result showed that from this Guest network , the virtual IP (1.1.1.1) and the ip of the Guest network dynamic interface were reachable from a Guest wireless client.

The client can reach the HTTPS webAuth page .

In our setup, we do not use webAuth , we use Cisco ISE Self guest registration portal , it means that our WLC setup , for the Guest wlan is like this :
- Layer 3 Security is set to none and we configured the AAA servers part only with an ACL that allow traffic to our Cisco ISE servers.

As we do not use WLC webAuth , Is there a way to disable webAuth feature or block access to the WebAuth page with an ACL ?
I thought maybe I could assign an ACL that deny traffic to the IPs mentionned before to the Guest WLAN dynamic interface

Any help is welcome

Thank you 

Best regards 

Marc 

[Haydn Andrews]

I am taking it your using central web auth not local web auth with ISE doing the splash page.

This deployment guide shows the Pre-auth ACL you need:

https://www.cisco.com/c/en/us/support/docs/security/identity-services-engine/115732-central-web-auth-00.html#anc5

Noticed that you are using the virtual interface of 1.1.1.1. The IP of 1.1.1.1 is now a registered public IP address as 1.0.0.0/8 have been assigned to the public space.

https://www.cisco.com/c/en/us/support/docs/wireless-mobility/wireless-lan-wlan/213535-wlc-virtual-ip-address-1-1-1-1.html

That being said the Virtual interface is also used for other things, so blocking access to it could cause issues, if you were going to block it via an ACL then only do it to http/https.

Are the users accessing the virtual interface before they have entered the RUN state or whilst still in WEBAUTH_REQD or POSTURE_REQD? And have you confirmed that the virtual IP is not routable?

[Jurgens L]

You can also try the CPU ACL of the WLC, that will definitely give you the ability to block anything you don’t want to reach the WLC. Use with care though as you might lock yourself out of you don’t apply your ACL rules correctly. I would recommend you first test on a non-production WLC.

Haydn have some good question, when you did the pen test was this during the webauth state or after you successfully authenticated via the guest portal.


<<< Please help the community by marking useful posts helpful, or accept as a solution if it resolved your issue >>>

[maissiat]

Thanks for your feedback, I will try with CPU ACL to limit http/https traffic

[Mooseloose]

Hi there. I have the same issue as you where a pen test highlighted this vulnerability. 

Did the CPU ACL work for you as expected?

Thanks,

Jim.

[maissiat]

Hi, 

Thanks for your feedbacks . Yes we do Central Web Auth , I had a look at the deployement guide URL and it's exactly what we have done. 

To this question : Are the users accessing the virtual interface before they have entered the RUN state or whilst still in WEBAUTH_REQD or POSTURE_REQD? And have you confirmed that the virtual IP is not routable?

The pen test has beed done after the user was  authentified/authorized in ISE 

1.1.1.1 is not routable on our network . 

So I think I will try to limit access to HTTP/HTTPS with CPU ACL . 

Thanks a lot 

Marc

[patoberli]

Also change this IP address to a valid private one, or you might run into weird troubles in the future.

[Jurgens L]

---

1.1.1.1 is not routable on our network . 

So I think I will try to limit access to HTTP/HTTPS with CPU ACL . 

Don't forget telnet and SSH access as well, recommend virtual IP address to use is 192.0.2.x (reload on the wlc will be required)

<<< Please help the community by marking useful posts helpful, or accept as a solution if it resolved your issue >>>