Restrict SSH to WLC from untrusted subnets

[DAVID]

We are trying to be more prudent on what subnets have access to our WLC for PCI compliance.  We have created a deny ACL  on the management ACL of the wireless controller but I can still ssh from a subnet we have denied access to. What gives?   We obviously do not want to block CAPWAP traffic to and from the access points and controllers but we do no want to have unrestricted management access from all the remote subnets.

[Scott Fella]

Why not just create an acl on the layer 3 svi and not on the WLC. 

-Scott 

*** Please rate helpful posts *** 

[DAVID]

that would be an option if I had it.  I'm trying to appease management who insists that the ACL is not correct.  Here is a brief background.  I have two 5520's in HA.  The active node is what is accessible to the AP's and general management. While the deny tcp any any has been created on the management ACL I can still SSH to the backup node but not the active node.  Trying to understand as to why?  I do realize that only one node will be active at a time and any ACL obliviously only deals with the active node.  Just making sure that I am not missing something.

[Tymofii Dmytrenko]

@Scott Fella does it mean there's no way to apply management ACL on the WLC? That's a bit of disappointment. We also have a requirement to restrict management access to WLCs in the trusted network (such as only DC/jump boxes) can manage it. Applying this ACL to management SVI on a switch is not really an option because apart from WLCs we have tens of other devices in management VLAN and some have different requirements. This will also make ACL IP-address specific, while if applied to WLC it can be based around standard sets of source IP address (jump box) with ANY as destination - hence unified across all WLCs.

I can't believe Cisco hasn't created management ACLs...  we've just finished applying this to our routers and switches securing both SSH and HTTPS, but of course... you can't do this on WLCs :)

[Scott Fella]

You can create a CPU ACL to restrict access to management. We just rather restrict it from the L3 as it’s easier to apply from a few devices than all. 

[Tymofii Dmytrenko]

Yeah... I am looking at CPU ACLs now.

Applied basic ACL with one DENY (specific) and ONE PERMIT ALL statement. It does look like it does the job, but I am not sure if anything else can be broken potentially.

Also tried a reverse rule - PERMIT from 2 subnets from where management traffic is expected and DENIED everything else - still ok. Apparently in 8.x code this ACL does not affect service protocols, such as CAPWAP and Mobility (all my APs are still up, clients can still connect and consume wireless services).

I will leave it for couple days before signing off....  Thanks !

[Tymofii Dmytrenko]

Oh... it affects RADIUS communication :( and TACACS+

So, ACL must include service subnets too... or protocols. Crap.

That's not what we wanted as it can become way too complicated.

[Scott Fella]

It’s trocky because you have to understand if you use any, inbounds or outboud. I have just used source subnet permit like https and ssh inbound then deny any any inbound for https and ssh inbound then permit any any.

So you might want to try to permit what you want first using inbound then deny the same protocols then have a permit any any in the end.

[Tymofii Dmytrenko]

Thanks Scott

Yeah, it's tricky, indeed

Just tried what you've suggested and it works

So I permit HTTPS/SSH by source (two rules per source), then DENY HTTPS/SSH from ANY and permit other protocols ANY ANY.

I believe CPU ACL ignores the direction, rules needs to be as if you apply TOWARDS CPU (seen it somewhere).

It works