Unifi Cloud Key traffic blocked by AC as ULTASRF?

[junglechuck]

Hi everyone,
I've been fighting with my UBNT cloud keys pretty much all year. I know there were bugs in the 6.x firmware released about a year ago, but I dug a little deeper today when only one of my cloud keys went "offline". The CK was actually just find, but since Ubiquiti changed the authentication to run their their servers, I noticed that my NGFW AC was blocking the traffic and labeling it as ULTRSRF (which I had tarpited so that other users can't easily use that proxy). Creating rules to allow the CK local IP and server list to be "allowed" didn't solve anything. The only solution was to disable the "tarpit" rule in the AC for ULTRSRF in general. Anyone else seeing this issue? Seems similar to the thread(s) a few months+ ago that saw IDS/IP blocking cloud keys. Thanks

[sky-knight]

Application Control, and Intrusion Prevention both go nuts over Unifi's controller, and for good reason! The nature of how it enables cloud functionality is a standards violation, and is bypassing appropriate security protocols.

As such, you need to use your policy rules to direct traffic sourced from, or destined do your cloud key into a policy with a curated list of modules that doesn't do anything that causes a problem.

In short your Cloud Key should be influenced by a different Application Control instance than your main network. As a hosted service, this falls into my general advice of ensuring you use a curated policy for that. Fail to do this at your own peril... as you have discovered.

[junglechuck]

Application Control, and Intrusion Prevention both go nuts over Unifi's controller, and for good reason! The nature of how it enables cloud functionality is a standards violation, and is bypassing appropriate security protocols.

As such, you need to use your policy rules to direct traffic sourced from, or destined do your cloud key into a policy with a curated list of modules that doesn't do anything that causes a problem.

In short your Cloud Key should be influenced by a different Application Control instance than your main network. As a hosted service, this falls into my general advice of ensuring you use a curated policy for that. Fail to do this at your own peril... as you have discovered.

Thanks @sky-knight, I've been observing these little issues for awhile. I would actually like to be able to "safely" allow outside unifi devices to communicate with the cloud key that's beind NGFW. I've been considering using client MAC address restrictions, but as I'm guessing you had a solid handle on this . . . any thoughts? Brillant to put the CK on it's own policy.

[sky-knight]

MAC addresses do not persist past the first router, this method doesn't work over the Internet.

There is no way to differentiate device types over the Internet at large. Publicly exposed services must defend themselves, if you don't trust the controller to do so you have no choice but to wrap it in a VPN.

This is what mTLS was designed to mitigate... but Ubiquity needs to update their junk to use it... everything should be mTLS in this space by now... but it isn't.

[junglechuck]

MAC addresses do not persist past the first router, this method doesn't work over the Internet.

There is no way to differentiate device types over the Internet at large. Publicly exposed services must defend themselves, if you don't trust the controller to do so you have no choice but to wrap it in a VPN.

@sky-knight,
Thanks. Very helpful education. Thanks for your contribution to this form. As for trusting the cloud key . . . after this year of unifi 6.x firmware- no way. I'll install physical cloud keys at all the other sites instead. Much cheaper than allowing a breach.

[sky-knight]

@sky-knight,
Thanks. Very helpful education. Thanks for your contribution to this form. As for trusting the cloud key . . . after this year of unifi 6.x firmware- no way. I'll install physical cloud keys at all the other sites instead. Much cheaper than allowing a breach.

That's one of the reasons why I like Unifi so much... you can still do a local controller, keep it offline, VPN to the network and work from there.

As for the breaches, I just rotate my ui.com account's password and TOTP token quarterly. I haven't had any problems with cloud access.

Of course if you have anything on VLAN1 other than your Unifi gear itself... you're not really any safer, because a BOT on a workstation can get at the controller anyway.