Summary

The article discusses the challenges faced in configuring firewall rules for a Ubiquiti Dream Machine Pro (UDM Pro) due to the use of CloudFront and changing IP addresses, and provides insights on improving the setup process with a more secure and user-friendly approach.

Abstract

The author of the article is attempting to set up a UDM Pro and encounters difficulties due to extensive and changing IP ranges required for the setup. The use of CloudFront by Ubiquiti complicates the firewall configuration because pfSense cannot resolve the constantly changing CloudFront subdomains to their respective IP addresses. This results in blocked traffic during the setup process. The author suggests a better approach for Ubiquiti, recommending the use of a fixed contiguous IP range and a service fronted by a domain with specific load balancer fixed IPs in a cloud environment. This would simplify the firewall configuration for customers to a single rule. The article also touches on the security concerns related to the current setup, including the potential for cleartext password transmission and the need for integrity checks to prevent scenarios like the Solar Winds breach. Despite the challenges, the author is hopeful that the WiFi performance of the UDM Pro will be superior to other access points.

Opinions

The author is frustrated with the complexity and dynamic nature of IP ranges and domains used during the UDM Pro setup, which are exacerbated by CloudFront's practices.
There is a clear opinion that Ubiquiti's current approach to IP addressing and domain resolution for device setup is inadequate and poses security risks.
The author believes that Ubiquiti should implement a more secure and stable system using a fixed IP range and a dedicated load balancer to facilitate easier and safer firewall configurations for end-users.
The author is critical of the current security posture of the UDM Pro setup process, particularly the potential for sensitive data exposure and the lack of robust integrity checks.
Despite the criticisms, the author remains optimistic about the potential performance improvements the UDM Pro could offer once properly configured.

Firewall Rules for UDM Pro Setup

Why. So. Many. IP. Ranges? And domains don’t resolve.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

⚙️ Check out my series on Automating Cybersecurity Metrics. The Code.

🔒 Related Stories: Unifi | Dream Machine Pro | Ubiquiti | Network Security

💻 Free Content on Jobs in Cybersecurity | ✉️ Sign up for the Email List

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

In another post I went through extensive measures to figure out all the domain names I needed to get through the UDM Pro setup process. It appears those domain names may have changed. I’m trying to set up the UDM Pro from factory default again and it’s not working.

The first thing I see is a ton of traffic on port 5060.

SIP??

https://community.ui.com/questions/UDM-Pro-generating-SIP-traffic-out-its-WAN-interface/a64c1ac8-c97a-4d61-9163-2fd3fd57833e

I’m not using that plus is it really supposed to be going out over the Internet? I’ll have to turn that off once I can actually get into the UDM Pro. Apparently you cannot do that until after you register which requires Internet access — hence all the trials and tribulations of my prior posts.

But I’m close I think.

CloudFront — UGH.

So here’s the reason I can’t use domains in my firewall configuration. Ubiquiti is using CloudFront.

I’ve written about problems with CloudFront before (and other CDNs).

CDN Security Wishlist

One way content delivery networks make security harder

medium.com

Here’s the problem. I put config.ubnt.com in my list of UDM domains in a pfSense alias. I wrote about aliases in one of my other pfSense posts.

But pfSense can’t make the following translation from config.ubnt.com to [gobbledegook randomly changing subdomain].cloudfront.net which resolves to the IP address 65.8.178.97 in this case.

So the traffic is blocked.

Is this a pfSense bug because when I dig the config.ubnt.com domain I get back the right IP addresses:

Hmm. The only solution I can see besides trying to keep up with randomly changing CloudFront IPs is to allow a much bigger block for setup only and then remove the rule when I’m done with the setup.

So I enter that IP range and it’s no longer blocked. Next up I’m getting a password error. Honestly it’s late and I think I typed my password wrong, but I reset it anyway.

Now I’m seeing different IP addresses — sending traffic over port 80. Those aren’t sending my password in clear text are they??

Well I ran packet capture on port 80 on pfSense after hitting the login button and I didn’t see anything. Finally I just started over at the primary IP address and started the login process over and it worked.

The device wants to run a bunch of speed tests on port 80 to weird IP addresses and there’s some traffic on port 8081. I decline.

Finally, after all that, I am setting up the device!

But will it work…or more blocked traffic?

I unblocked another Amazon IP range.

I did NOT unblock traffic to port 1900, 5353, or 48000. What IS all this stuff? Also IGMP and port 81. These things should be off unless someone explicitly configures it — and I think some of this should not be hitting the pfSense firewall logs.

OK so by refreshing and adding IP ranges and from my past research into domain names the UDP setup uses the following, all on port 443. This does not include all the weird speed test IP addresses.

This *may* include some traffic from my laptop unrelated to the UDM setup but who knows. I can’t see the sending IP until I get in and look at the logs in the UDM as explained in prior posts.

There is a much better way to do this.

Create a service fronted by a domain that points to specific load balancer fixed IPs in a cloud environment. And pick one. AWS would be my preferred but pick one because you don’t want to load balance traffic over to Google I don’t think. Unless you had some way to set up a connection in a data center that has super fast low latency access to both cloud environments.

Anyway set up that load balancer and a fixed contiguous IP range so it’s easy for customers to create ONE firewall rule for setup. Do not use port 80. Then have that firewall dish off the traffic to the appropriate service behind it when it comes in. Do NOT use CloudFront for updates.

Make sure all the services are behind the load balancer on a private network, and especially whatever software you are sending to customers so you can do an integrity check on the way out the door and prevent Solar Winds type scenarios.

This is the kind of thing I help customers with on IANS Research calls. Let me help you design a secure system — not a bunch of random IP addresses like this for a firewall setup.

Well anyway, my Dream Machine Pro which is not so dreamy so far has been restarting for like 15 minutes. Wish me luck.

I hope the WiFi is dreamier than the other access points I’ve tried — and that’s not a high bar. Crossing fingers.

🤞

Follow for updates.

About Teri Radichel:
~~~~~~~~~~~~~~~~~~~~
⭐️ Author: Cybersecurity Books
⭐️ Presentations: Presentations by Teri Radichel
⭐️ Recognition: SANS Award, AWS Security Hero, IANS Faculty
⭐️ Certifications: SANS ~ GSE 240
⭐️ Education: BA Business, Master of Software Engineering, Master of Infosec
⭐️ Company: Penetration Tests, Assessments, Phone Consulting ~ 2nd Sight Lab

Need Help With Cybersecurity, Cloud, or Application Security?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
🔒 Request a penetration test or security assessment
🔒 Schedule a consulting call
🔒 Cybersecurity Speaker for Presentation

Follow for more stories like this:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 
❤️ Sign Up my Medium Email List
❤️ Twitter: @teriradichel
❤️ LinkedIn: https://www.linkedin.com/in/teriradichel
❤️ Mastodon: @teriradichel@infosec.exchange
❤️ Facebook: 2nd Sight Lab
❤️ YouTube: @2ndsightlab