Results 1 to 6 of 6
  1. #1
    Untangler
    Join Date
    Jul 2019
    Posts
    53

    Default Unifi Cloud Key traffic blocked by AC as ULTASRF?

    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

    Screen Shot 2021-09-19 at 8.03.54 PM.png

  2. #2
    Untangle Ninja sky-knight's Avatar
    Join Date
    Apr 2008
    Location
    Phoenix, AZ
    Posts
    26,163

    Default

    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.
    Rob Sandling, BS:SWE, MCP
    NexgenAppliances.com
    Phone: 866-794-8879 x201
    Email: support@nexgenappliances.com

  3. #3
    Untangler
    Join Date
    Jul 2019
    Posts
    53

    Default

    Quote Originally Posted by sky-knight View Post
    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.

  4. #4
    Untangle Ninja sky-knight's Avatar
    Join Date
    Apr 2008
    Location
    Phoenix, AZ
    Posts
    26,163

    Default

    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.
    Rob Sandling, BS:SWE, MCP
    NexgenAppliances.com
    Phone: 866-794-8879 x201
    Email: support@nexgenappliances.com

  5. #5
    Untangler
    Join Date
    Jul 2019
    Posts
    53

    Default

    Quote Originally Posted by sky-knight View Post
    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.

  6. #6
    Untangle Ninja sky-knight's Avatar
    Join Date
    Apr 2008
    Location
    Phoenix, AZ
    Posts
    26,163

    Default

    Quote Originally Posted by junglechuck View Post
    @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.
    Rob Sandling, BS:SWE, MCP
    NexgenAppliances.com
    Phone: 866-794-8879 x201
    Email: support@nexgenappliances.com

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  

SEO by vBSEO 3.6.0 PL2