UniFi Dream Machine Security Hardening Guide

EnthusiastXYZ

Limp Gawd
Joined
Jun 26, 2020
Messages
221
This is a small guide of what you can do to strengthen your UniFi Dream Machine (UDM) security with settings not found in UDM GUI. You need to know how to login to UDM via SSH and understand basic SSH commands. I suggest using either PuTTY or KiTTY for for SSH commands and WinSCP to manage files. My tweaks are open to criticism and you're welcome to add corrections, list your tweaks, and or provide related advice.

1. Download Boost Chicken's UDM-Utilities because UDM is not nearly as flexible as Ubiquiti Security Gateway (USG) and cannot be configured with config.gateway.json file. Many USG SSH commands do not work on UDM and those that do cannot survive reboot without UDM-Utilities . Bootscript is what you need for my guide and it is very easy to setup. Simply log into SSH and run (or copy/paste) these commands:
unifi-os shell
curl -L https://github.com/boostchicken/udm...n-boot-script/packages/udm-boot_1.0.5_all.deb -o udm-boot_1.0.5_all.deb
dpkg -i udm-boot_1.0.5_all.deb
exit

2. Apply custom IPTables by making iptables.sh file with #!/bin/sh as top line, then use WinSCP to copy/paste that file to into /mnt/data/on_boot.d directory and assign that file 0755 permission. Don't forget to finalize WinSCP copy/paste process or else the file doesn't stay in that directory. You can do that by editing the file within WinSCP itself and re-saving the file within WinSCP. You can create separate files for IPv4 and IPv6 rules. Do NOT set general INPUT and/or FORWARD policies to DROP. In other words, do not use "iptables -P INPUT DROP" and "iptables -P FORWARD DROP" or it will lock you out of your router because such commands would apply DROP policies to not just WAN, but router's internal interface.
Why create your own IPTables for UDM?
A. UDM GUI firewall rules do not apply to communication between router's internal interface and WAN. For example, a UDM GUI rule to drop all inbound/outbound WAN ICMP packets does not prevent it from sending outbound ICMP to WAN to test internet connection reliability. The same applies IGMP and some other protocols.
B. UDM sends out Device Discovery packets (IP 255.255.255.255) via UDP port 10001 to all interfaces, including WAN. UDM GUI rules can't stop it. My communication with Ubiquiti confirms that this bug exists and is on their "to do" patch list. Custom IPTables (to drop outbound IP 255.255.255.255 and/or outbound UDP port 10001 packets) is a simple way to stop these packets from being sent.
C. SSH (iptables -v -n -L) doesn't show you the exact syntax for rules set via UDM GUI and it is unknown whether UDM applies some commonly-used security rules to prevent ACK scans, drop empty, and/or fragmented packets:
-f -j DROP
-p tcp --tcp-flags ALL ALL -j DROP
-p tcp --tcp-flags ALL NONE -j DROP
-p tcp --tcp-flags ALL FIN,PSH,URG -j DROP
-p tcp ! --syn -m conntrack --ctstate NEW -j DROP
D. Prevent Ubiquiti or bad actors from accessing your router through remote management. UDM registration requires a cloud account with username and password that can always be used to log into your router, even if you create a separate local access account. UDM non-Pro owners can disable remote management, but UDM Pro owners cannot. As I mention earlier, UDM GUI firewall rules do not apply to communication between router's internal interface and WAN. IPTables rules are needed to fully drop access on Ubiquti ports used for remote management.

3. Apply custom EBTables (ebtables.sh, same format, directory, file permissions as iptables.sh) to further filter traffic. IPTables apply only to Layer 3 (packets) while EBTables apply to Layer 2 (frames). You can find EtherTypes here - https://en.wikipedia.org/wiki/EtherType . EBTables is a great way to drop IPv6, multicast, WoL, VLAN and other types of frames.

4. Apply IFConfig tweaks (ifconfig.sh, same format, directory, file permissions as iptables.sh/ebtables.sh) to disable promiscuous mode and multicast that are enabled by default for some interfaces (WLAN and switch). In example below X needs to be replaced with whichever interlace you wish to edit and you can view available interfaces via ifconfig command in SSH:
ifconfig X -multicast
ifconfig X -allmulti
ifconfig X -promisc
You can also disable unused tunnel/VPN interfaces:
fconfig dummy0 down
ifconfig sit0 down
ifconfig gre0 down
ifconfig ip_vti0 down

5. Apply custom SysCTL and Kernel tweaks (sysctl.sh, same format, directory, file permissions as iptables.sh/ebtables.sh/ifconfig.sh) to enable reverse path filtering, disable ICMP redirection, fully disable IPv6, and apply other common SysCTL tweaks. In example below X needs to be replaced with whichever interlace you wish to edit and you can view available interfaces via ifconfig command in SSH. You can use all and default instead of X if you want tweaks to apply to all interfaces:
echo 0 > /proc/sys/net/ipv4/conf/all/accept_redirects
echo 0 > /proc/sys/net/ipv4/conf/X/accept_redirects
echo 0 > /proc/sys/net/ipv4/conf/default/accept_redirects
echo 0 > /proc/sys/net/ipv4/conf/all/send_redirects
echo 0 > /proc/sys/net/ipv4/conf/X/send_redirects
echo 0 > /proc/sys/net/ipv4/conf/default/send_redirects
echo 0 > /proc/sys/net/ipv4/conf/all/secure_redirects
echo 0 > /proc/sys/net/ipv4/conf/X/secure_redirects
echo 0 > /proc/sys/net/ipv4/conf/default/secure_redirects
echo 0 > /proc/sys/net/ipv4/conf/all/accept_source_route
echo 0 > /proc/sys/net/ipv4/conf/X/accept_source_route
echo 0 > /proc/sys/net/ipv4/conf/default/accept_source_route
echo 0 > /proc/sys/net/ipv4/conf/all/shared_media
echo 0 > /proc/sys/net/ipv4/conf/X/shared_media
echo 0 > /proc/sys/net/ipv4/conf/default/shared_media
echo 1 > /proc/sys/net/ipv4/conf/all/rp_filter
echo 1 > /proc/sys/net/ipv4/conf/X/rp_filter
echo 1 > /proc/sys/net/ipv4/conf/default/rp_filter
echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_all
echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts
echo 1 > /proc/sys/net/ipv4/icmp_ignore_bogus_error_responses
To fully disable IPv6, you can use the following entries in ifconfig.sh file:
echo 0 > /proc/sys/net/ipv6/conf/all/forwarding
echo 0 > /proc/sys/net/ipv6/conf/X/forwarding
echo 0 > /proc/sys/net/ipv6/conf/default/forwarding
echo 0 > /proc/sys/net/ipv6/conf/all/accept_ra
echo 0 > /proc/sys/net/ipv6/conf/X/accept_ra
echo 0 > /proc/sys/net/ipv6/conf/default/accept_ra
echo 0 > /proc/sys/net/ipv6/conf/all/accept_source_route
echo 0 > /proc/sys/net/ipv6/conf/X/accept_source_route
echo 0 > /proc/sys/net/ipv6/conf/default/accept_source_route
echo 1 > /proc/sys/net/ipv6/conf/all/disable_ipv6
echo 1 > /proc/sys/net/ipv6/conf/X/disable_ipv6
echo 1 > /proc/sys/net/ipv6/conf/default/disable_ipv6

6. Run your own local DNS server to filter client and UDM traffic. Pi-Hole and AdGuard Home are the best options for that. Use your local DNS server's IP address for WAN DNS IP address to have Pi-Hole/AdGuard Home filter UDM analytics, metrics, and telemetry connections by blocking connections to "trace.svc.ui.com" domain. That domain is black-listed in Seven Black hosts and OISD hosts. All you need is a $20 Raspberry Pi (for a small network) to run such a server, but setting up and running such a local DNS server is beyond the scope of this guide. I will only provide some DNS-over-HTTPS (DoH) tips for those who already run their own Pi-Hole/AdGuard Home local DNS servers:
- Most DoH DNS servers still use UDP port 53 to establish unencrypted plaintext "bootstrap" connection to their DoH addresses. You need to use the right IP-based DoH addresses (or SDNS stamp addresses) to avoid such plaintext "bootstrap" connections. For example, AdGuard's "https://dns.adguard.com/dns-query" DoH address requires UDP port 53 to be open before DoH connection can happen, but their "https://94.140.14.14/dns-query" address does not and uses only encrypted TCP port 443 connections.
- Block outbound WAN UDP port 53 completely if you use DoH server addresses that don't require "bootstrap" over UDP port 53.


Notes:
- You must re-apply IFConfig and SysCTL tweaks every time you change certain WiFi settings (channel width, channel) within UDM GUI.
I think UDM-Utilities developer is working on an update to have custom scripts seamlessly re-apply themselves after whichever interval.
- EBTables can't stop UDM from sending out Link Layer Discovery Protocol (LLDP) packets on all interfaces (every 30 seconds), including WAN. LLDP is a Layer 2 protocol that uses EtherType 0x88CC, but EBTables "-p 0x88cc -j DROP" command doesn't work on it and neither does EBTables command to drop LLDP MAC address packets. LLDP-Med can be disabled in UDM GUI switch port settings, but plain LLDP is permanently enabled. It can be disabled in Ubiquiti Security Gateway via config.gateway.json, but UDM does not support that. Ubiquiti admits that such is the case, but does not consider LLDP packets over WAN to be a security risk. I do and I hope someone figures out how to fully disable it on UDM.
- Here's an incomplete list of domains to which UDM connects, but all of them can be blocked without losing local router functions:
  • static.ui.com (has the highest number of connections/connection attempts and may be necessary for Device Fingerprinting icon retrieval)
  • static.ubnt.com (may be necessary for Device Fingerprinting icon retrieval)
  • ping.ui.com
  • ping.ubnt.com
  • ips1.unifi-ai.com (needed for IDS/IPS, sends out encrypted information about your IP, alerts, and possible attacks to Ubiquiti, which then uses that information to improve Ubiquiti IDS/IPS, more info here -https://community.ui.com/questions/Thats-a-lot-of-traffic-to-ips1-unfi-ai-com/0c9b48d8-52b1-4c14-b5e0-e8ba7bb714fe)
  • assets.unifi-ai.com (possibly related to IDS/IPS)
  • trace.svc.ui.com (depending on options selected in UDM GUI, used to send either non-anonymized or anonymized telemetry information to Ubiquity, considered to be a spyware domain by many ad blockers)
  • crash-report-service.svc.ui.com (crash reporting, includes non-anonymized and/or anonymized telemetry)
  • api.ipify.org (verifies public IP, domain used for tracking)
  • icanhazip.com
  • config.ubnt.com
  • apt-beta.artifacts.ui.com
  • apt.artifacts.ui.com
  • security.debian.org
  • _http._tcp.deb.debian.org
  • deb.debian.org
  • _http._tcp.security.debian.org
  • fw-update.ubnt.com (needed for firmware update)
  • fw-download.ubnt.com (needed for firmware update)
  • dl.ui.com (needed for firmware update)
  • deb.nodesource.com
  • www.ubnt.com
  • *.test (uses a set of numbers instead of * to test internet connectivity)
  • 0.ubnt.pool.ntp.org (SNTP, used along with user-defined NTP servers)
  • 1.ubnt.pool.ntp.org (SNTP, used along with user-defined NTP servers)
  • debian.map.fastlydns.net (needed for UDM GeoLocation map)
  • api.tiles.mapbox.com (needed for UDM GeoLocation map)
  • net-fe-static-assets.network-controller.svc.ui.com (used while in UDM GUI)
There are likely other domains to which UDM connects depending on the situation, but you're not in control of those connections if you use public address for WAN DNS. You can easily block all the domains if you run your own local DNS server (Pi-Hole/AdGuard Home) and specify your local server's IP address for WAN DNS address.
 
Last edited:
That's a great start to hardening those Dream Machine devices. A while back, I recommended one to a friend, but looking at what you found, I am reluctant to recommend it again...

Also, it would be helpful to separate out the hardening sysctl values from the IPv6 disable values....
 
That's a great start to hardening those Dream Machine devices. A while back, I recommended one to a friend, but looking at what you found, I am reluctant to recommend it again...

Also, it would be helpful to separate out the hardening sysctl values from the IPv6 disable values....

Thanks! I separated IPv6 entries.
 
Here's an incomplete list of domains to which UDM connects, but all of them can be blocked without losing local router functions:
  • static.ui.com (has the highest number of connections/connection attempts and may be necessary for Device Fingerprinting icon retrieval)
  • static.ubnt.com (may be necessary for Device Fingerprinting icon retrieval)
  • ping.ui.com
  • ping.ubnt.com
  • ips1.unifi-ai.com (needed for IDS/IPS, sends out encrypted information about your IP, alerts, and possible attacks to Ubiquiti, which then uses that information to improve Ubiquiti IDS/IPS, more info here -https://community.ui.com/questions/Thats-a-lot-of-traffic-to-ips1-unfi-ai-com/0c9b48d8-52b1-4c14-b5e0-e8ba7bb714fe)
  • assets.unifi-ai.com (possibly related to IDS/IPS)
  • trace.svc.ui.com (depending on options selected in UDM GUI, used to send either non-anonymized or anonymized telemetry information to Ubiquity, considered to be a spyware domain by many ad blockers)
  • crash-report-service.svc.ui.com (crash reporting, includes non-anonymized and/or anonymized telemetry)
  • api.ipify.org (verifies public IP, domain used for tracking)
  • icanhazip.com
  • config.ubnt.com
  • apt-beta.artifacts.ui.com
  • apt.artifacts.ui.com
  • security.debian.org
  • _http._tcp.deb.debian.org
  • deb.debian.org
  • _http._tcp.security.debian.org
  • fw-update.ubnt.com (needed for firmware update)
  • fw-download.ubnt.com (needed for firmware update)
  • dl.ui.com (needed for firmware update)
  • deb.nodesource.com
  • www.ubnt.com
  • *.test (uses a set of numbers instead of * to test internet connectivity)
  • 0.ubnt.pool.ntp.org (SNTP, used along with user-defined NTP servers)
  • 1.ubnt.pool.ntp.org (SNTP, used along with user-defined NTP servers)
  • debian.map.fastlydns.net (needed for UDM GeoLocation map)
  • api.tiles.mapbox.com (needed for UDM GeoLocation map)
  • net-fe-static-assets.network-controller.svc.ui.com (used while in UDM GUI)
There are likely other domains to which UDM connects depending on the situation, but you're not in control of those connections if you use public address for WAN DNS. You can easily block all the domains if you run your own local DNS server (Pi-Hole/AdGuard Home) and specify your local server's IP address for WAN DNS address.
 
Just a few notes about UDM WiFi SSID management WPA3 that is now available for UDM (Non-Pro) if you update to the latest UDM Beta firmware and to the latest Network Application firmware:
- Do not use WPA3 Transitional mode that allows devices to connect via either WPA2 or WPA3 to the same SSID because of downgrade vulnerability. For WPA3 devices, create WPA3-only SSID's, and for WPA2 devices create WPA2-only SSID's.
- To create Non-Portal Guest WiFi SSID's, you must use the old UI because the new UI allows only Portal-based Guest HotSpots and Non-Portal SSID's created in old UI show up as "No Authentication" in new UI, but that is incorrect.
- To manage Non-Portal Guest WPA3 SSID's, you must use old UI because WPA3 settings exist only for trusted (Non-Guest) LAN and do not exist for Non-Portal and Portal Guest SSID's
- To manage Non-Portal Guest WPA2 SSID's, you must use the new UI because the old UI locks up during setting application if you have a mix of WPA2 and WPA3 SSID's.

Having 2 UI's that offer different settings is one of the dumbest decisions Ubiquiti ever made.
 
BTW, you can now create local-only account for UDM during initial setup without any need to have a Ubiquiti cloud account.
 
Back
Top