UPnP Security Warning: A Real Case of NAS Auto-Exposing SSH Ports to the Public Internet
How a re-enabled UPnP setting caused a UGREEN NAS to silently expose SSH to the internet and attract brute-force attacks.
A homelab user discovered his UGREEN NAS had autonomously exposed SSH (port 22), HTTP, and HTTPS to the public internet via UPnP — a setting he had re-enabled while troubleshooting Tailscale. The exposed SSH port immediately attracted automated brute-force attacks, and the resulting DoS flood caused his router to disconnect the WAN as a self-defense measure. The incident highlights how internal devices can undermine even well-designed external security architectures.
A Real Homelab Security Scare
For newcomers to the homelab scene, network security is often framed as "defending against external attacks" — setting strong passwords, disabling unnecessary port forwarding, deploying a VPN. But a firsthand account shared by a Reddit user reveals an easy-to-overlook risk: a device on your local network can silently open a door to the outside world without you ever knowing.
It started innocuously enough. While waiting for dinner, he was browsing Reddit when pages stopped loading. He initially suspected his self-hosted Pi-hole + Unbound recursive DNS setup, but investigation showed DNS was working fine.
Pi-hole and DNS-Layer Security: Pi-hole is widely known as an ad blocker, but at its core it's a network-level DNS filtering system that intercepts resolution requests for specific domains across the entire LAN. Paired with Unbound as a recursive resolver, Pi-hole can bypass upstream ISP DNS servers entirely and query root nameservers directly, eliminating DNS hijacking and DNS leak risks. In a homelab context, this combination serves dual roles — privacy protection and security monitoring. All DNS queries from every device on the LAN pass through it, making it often the first place anomalous outbound behavior leaves a trace.
That's when he noticed something odd: his UGREEN NAS was making several STUN requests. STUN (Session Traversal Utilities for NAT) is a protocol specifically designed to help devices behind NAT discover their public IP address — WebRTC, VoIP, and tools like Tailscale rely heavily on it to establish direct peer-to-peer connections. NAS vendors using STUN for "remote access keepalive" means the device continuously reports its network status to vendor servers to prepare for cloud-relayed connections, even if the user has disabled the relevant features in the UI. Having vaguely encountered STUN while configuring Tailscale, he didn't think much of it at the time.
From "Network Dropping" to "SSH Being Scanned"
What really set off alarms was the router log. It showed "Internet disconnected" entries during the outage period, even though the physical connection was completely intact. Rebooting the router restored connectivity, but the anomaly nagged at him.
Digging deeper into the router logs, he found some troubling records:
- WAN remote access requests from unfamiliar IPs
- Most critically — remote access attempts targeting port 22 (SSH) on the NAS's local IP
He immediately SSH'd into the NAS and checked the system logs, where he found clear signs of attack:
Invalid user
error: key_exchange_identification: client sent invalid protocol identifier "GET / HTTP/1.1"
banner exchange invalid format
These entries are classic signatures of automated scanning bots and brute-force attacks. Automated scans targeting SSH port 22 happen in near real-time across the internet — data from security research platform Shodan shows that a newly exposed SSH service typically receives its first scan probe within minutes. The Invalid user entries indicate attackers were using dictionary attacks to enumerate common usernames (root, admin, ubuntu, etc.); the key_exchange_identification errors show that some scanners don't even follow the SSH handshake protocol and instead send raw HTTP requests to probe what service is behind the port. These attacks are fully automated by botnets capable of targeting thousands of hosts per second — the moment a port is exposed, the attacks follow. All attacking source IPs traced back to data centers in California, Texas, and China, many associated with VPN hosting services.
The Culprit: UPnP That Got Re-Enabled
After searching community discussions for similar cases, he identified the root cause: UPnP (Universal Plug and Play).
What UPnP Actually Does
UPnP was developed under Microsoft's leadership in 1999, designed to let home network devices discover and interact with each other with "zero configuration." For port mapping specifically, UPnP uses the IGD (Internet Gateway Device) protocol subset, which allows any device on the LAN to send a request to the router and automatically claim a port mapping — no human intervention required. This mechanism completely bypasses user authorization — the router cannot distinguish whether a request comes from a "trusted gaming console" or a "device compromised by malware." Security research firm Rapid7 scanned in 2013 and found over 80 million devices globally exposing UPnP services, with a large number containing directly exploitable vulnerabilities. While UPnP was designed to simplify connections for gaming consoles and P2P apps, the core danger is this: devices can autonomously decide which ports to expose to the public internet, entirely without the user's knowledge.
This user had previously followed the standard security advice of "disable UPnP," but a month earlier, while troubleshooting a Tailscale connectivity issue, he had re-enabled it hoping to get more stable P2P connections. That single action caused the UGREEN NAS to independently expose HTTP, HTTPS, and SSH (port 22) to the public internet.
On Tailscale and UPnP: Tailscale is built on the WireGuard protocol and implements the core principles of zero-trust network access. Its most important security property is that users don't need to open any inbound ports on their router — nodes complete NAT traversal via outbound connections, appearing completely "invisible" to external scans. In practice, Tailscale can establish direct connections in most NAT environments without UPnP. Re-enabling UPnP to "optimize" Tailscale is a security trade-off that gives up far more than it gains.
Even more concerning: even after he had disabled the remote access feature in the UGREEN NAS interface, the NAS continued making requests to STUN servers, attempting to establish P2P connections. This demonstrates that certain "keepalive" behaviors on these devices are not fully controlled by UI toggle switches.
Why the Network Dropped: The Router's Self-Defense Mechanism
Continuing to filter through the router logs, he found the direct cause of the outage — DoS attack alerts:
ICMP FloodFW.WANATTACK
DoS (Denial of Service) attacks overwhelm a target by flooding it with massive volumes of packets, exhausting its processing capacity or bandwidth. ICMP Flood is one of the most classic forms, where attackers send large numbers of ICMP Echo Requests (ping packets), forcing the target to continuously respond. Modern consumer routers commonly include basic DoS protection modules that can detect abnormal traffic patterns and trigger protective actions — including dropping anomalous packets, rate limiting, and even actively disconnecting the WAN connection to protect the internal network. This explains the "mysterious outage" in this case: the router wasn't malfunctioning; it was executing its self-protection logic.
Because NTP time synchronization wasn't configured, the router log timestamps were scrambled, making post-incident analysis considerably more difficult — a reminder that accurate time synchronization is a fundamental prerequisite for security log analysis. NTP isn't just about log readability; in security mechanisms like certificate validation and Kerberos authentication, clock skew exceeding the allowed threshold causes authentication to fail outright. Accurate time sync is the hidden foundation of the entire security infrastructure.
His Original Security Architecture Was Actually Quite Solid
The irony is that this user's network security design was genuinely thoughtful:
- No port forwarding of any kind except Tailscale's peer relay port, which only responds to legitimate connections from his own tailnet and appears as a "dead port" to external scans
- All services accessed via Tailscale VPN — VPN when away, LAN direct connection at home
- Caddy reverse proxy combined with Pi-hole local DNS records (CNAME mappings) to resolve local domain names to the corresponding NAS ports
- Minecraft server long since migrated to the tailnet, no longer exposing public-facing ports
In other words, he had sealed off every "external entry point" he could think of. What he didn't anticipate was that the threat could come from inside — a NAS that could open the door itself.
NAS Security: Key Lessons and Action Items
This incident is a wake-up call for all homelab users. The core lesson: security thinking can't only focus on the external attack surface — you also need to defend against autonomous behavior by devices inside your network.
1. Immediately Check and Disable UPnP on Your Router
This is the most direct line of defense. With UPnP disabled, no device can independently open ports without authorization. If a specific application genuinely requires it, manually configure precise port forwarding rules so you have explicit control over every external-facing opening. Almost every security guide recommends disabling UPnP by default on home routers — its convenience simply cannot offset the security risk of "devices can autonomously expose services."
2. Be Wary of "Keepalive" Background Behavior on NAS Devices
Even after disabling remote access in the UI, devices may continue making outbound connections to vendor STUN or relay servers. In this case, the user ultimately blocked ugnas.com and all its subdomains at the Pi-hole level, completely severing these covert connections. The principle behind this "DNS-layer blocking" strategy: even if the NAS firmware contains hardcoded outbound logic, if DNS resolution is intercepted, the device can't locate the vendor's servers. One blind spot to be aware of: if a device uses hardcoded IPs rather than domain names, you'll need to supplement this with outbound firewall rules on the router.
3. Regularly Review Router and Device Logs
WAN access records, SSH login logs, and DoS alerts are all critical clues for detecting anomalies. Always configure NTP time synchronization — scrambled log timestamps make post-incident analysis extremely difficult. It's also worth monitoring DNS query logs — anomalous outbound domains recorded by tools like Pi-hole are often the earliest warning that a device is behaving outside its intended boundaries.
4. Use VPN Instead of Exposing Public-Facing Ports
Zero-trust access solutions based on WireGuard, such as Tailscale, allow you to securely access internal services without opening any inbound public-facing ports — this is the recommended security paradigm for homelabs. Consolidating all remote access into VPN tunnels dramatically reduces your attack surface. From an external scanning perspective, a properly configured Tailscale node is completely "invisible" on the public internet with no detectable listening ports.
Closing Thoughts
This user openly admitted he's a homelab newcomer who thought his security measures were comprehensive enough. This incident proved that even the most thorough external defenses can be pierced by a single inconspicuous internal configuration setting. Behind UPnP's convenience lies the very real risk of "devices autonomously exposing services"; NAS vendors' "keepalive" mechanisms continuously attempt to punch through your network perimeter without the user's knowledge.
If you're running a NAS or home server, go check your router settings right now — if UPnP is enabled, disable it immediately. What you may be relying on at this moment is nothing more than a "strong enough" password — and that's nowhere near sufficient.
Key Takeaways
- UPnP allows LAN devices to autonomously open inbound ports on your router without user authorization
- NAS devices may continue background outbound activity (STUN, cloud relay) even after "remote access" is disabled in the UI
- Tailscale does not require UPnP — re-enabling UPnP to optimize Tailscale is an unnecessary security trade-off
- Pi-hole DNS-layer blocking can cut off vendor keepalive connections at the domain level
- Router DoS protection can trigger automatic WAN disconnection — a "mysterious outage" may actually be your router protecting you
- Accurate NTP time synchronization is foundational to reliable security log analysis
- Closing every external entry point means nothing if an internal device can open its own door
Related articles
Go Microservices in Practice: Detailed Architecture for E-Commerce, AI Agent, and IM System Integration
Deep dive into integrating e-commerce, AI Agent, and IM systems under Go microservices architecture, covering unified auth, gRPC, componentized Agent engines, and group chat bots.
X Platform's Recommendation Algorithm Caught Filtering Brazilian Election Content, Reigniting Algorithm Transparency Debate
X (formerly Twitter) was found filtering Brazilian election content in its For You feed, sparking debate over algorithm transparency and free speech.
Poison-Resistant Concept Anchoring: A New Approach to Defending Against AI Data Poisoning
Deep dive into Poison-Resistant Concept Anchoring, defending against data poisoning via signed anchors and bounded updates. Experiments show 62% poison isolation with 0% false rejection rate.