DEV Community: Phaedon V

My Router's Hidden Door for Burglars

Phaedon V — Wed, 14 Oct 2026 17:12:54 +0000

The port I never opened

While poking at my own home network one evening, I found an open door to the internet that I never created. Not a forward I'd set in the router's admin page, not a rule I'd forgotten about — a permanent hole punched straight through my NAT, pointing at the open internet, reachable by any host on the planet, with no authentication and no expiry. And it was aimed at a device that wasn't even powered on at the time.

The culprit was UPnP (Universal Plug and Play) — a convenience feature switched on by default on almost every consumer router shipped in the last fifteen years.

This is a walk-through of how I found it, how I proved it was genuinely reachable from outside my network (every endpoint mine — the only honest way to test this), and what you can do to check for and close the same door on your own network. There's no exotic exploit here. It's the feature working exactly as designed, which is precisely the problem.

Every public IP, MAC address and hostname in this article has been redacted or replaced with documentation-range values. Ironically, leaking those details is exactly the kind of self-own the article is about.

What UPnP actually does

To see why one stray port forward matters, you need the mental model of why your home network is normally safe at all.

Under the hood, your router does NAT (Network Address Translation). Your devices have private addresses (192.168.x.x) that don't exist on the public internet; the router rewrites their traffic to share one public IP. A useful side effect is that unsolicited inbound traffic from the internet has nowhere to go — the router doesn't know which internal device to hand it to, so it drops it. NAT isn't a firewall, but it behaves like one by accident. That's why a random stranger can't reach the laptop in your bedroom.

UPnP exists to poke holes in exactly that protection — on purpose, on demand. Through its IGD (Internet Gateway Device) service, an application on your LAN can ask the router: "forward external port 9308 to me." The router creates the mapping, and now inbound traffic from the internet to that port lands on that device. This is genuinely useful for things that need unsolicited inbound connections: online games, consoles, VoIP, BitTorrent, some smart-home gear.

Here's the whole problem in one sentence:

The router grants these requests to anything on the LAN that asks — no authentication, no prompt to the user, usually no logging.

There's no "are you sure?". There's no password. The router simply trusts that any device on the local network is allowed to open a door to the outside world. Your games console and a compromised IoT bulb have exactly the same privilege. You, the owner, are never asked and often can't even see what was opened without going looking — which is what this whole exercise was.

The small request on top is the whole cause; the internet-facing inbound path on the bottom is the effect — and the device making the request can be anything on your LAN.

The discovery

It started with an ordinary sweep of my own subnet to see what was on the network:

sudo nmap -sn 192.168.0.0/24

Five hosts: the Arris gateway (.1), an LG smart TV (.3), an iPhone (.8), my laptop (.11), and a second Arris interface (.252). All accounted for. A service scan of the gateway showed its web admin UI on lighttpd, and one more thing on port 5000:

PORT     STATE  SERVICE  VERSION
80/tcp   open   http     lighttpd
443/tcp  open   ssl/http lighttpd
5000/tcp open   upnp     MiniUPnPd 1.9 (UPnP 1.1)

That MiniUPnPd 1.9 is the UPnP daemon — and it's a release from around 2014, well over a decade old, baked into the ISP firmware where I can't update it. An old service that any LAN device can command is worth a closer look. So instead of guessing from the web UI, I asked the daemon directly what port forwards it was holding:

sudo apt install -y miniupnpc
upnpc -l

The relevant line in the output:

 i protocol exPort->inAddr:inPort  description              remoteHost leaseTime
 0 UDP  9308->192.168.0.9:9308  '192.168.0.9:9308 to 9308'  ''         0

Decoded, that single line says a lot:

External UDP port 9308 on my public IP is forwarded to 192.168.0.9:9308 on my LAN.
The remoteHost field is empty — the forward accepts connections from any host on the internet, not a specific one.
The lease time is 0 — meaning permanent. It never expires on its own.
The auto-generated description is the format an application produces when it opens its own mapping. Nobody set this by hand; some software on .9 asked for it.

And the kicker: 192.168.0.9 wasn't in my host sweep. The device that opened this hole was offline — but because the lease is permanent, its internet-facing forward outlived it. A classic orphaned mapping, sitting open, pointing at a device that comes and goes (a phone, a console, an IoT gadget), and reachable from the whole internet the entire time.

Proving the door is real

Listing a mapping only tells you the router intends to forward a port. It doesn't prove the outside world can actually reach in — ISP-level filtering or carrier-grade NAT can quietly make an "open" forward a dead end. The only honest test is to open a port to a listener I control and connect to it from a device that is genuinely off my network.

Every endpoint in this test is mine: my router, my laptop, my public IP, my phone. That's what keeps it a legitimate security test rather than an attack. Do not do this against infrastructure you don't own.

First, a listener on my laptop (LAN .11), so an incoming probe hits something instead of a closed port:

nc -lvnp 8099

Then, using the same UPnP mechanism an app would, I opened a forward to it — with a one-hour lease so it auto-expires if I forget it:

upnpc -a 192.168.0.11 8099 8099 TCP 3600
upnpc -l

The mapping now showed up in the list alongside the mystery one:

 1 TCP  8099->192.168.0.11:8099  'libminiupnpc'  ''  3597

Now the real test, from my phone on mobile data with Wi-Fi off — a connection coming from the public internet, nowhere near my LAN:

nc -vn <YOUR-PUBLIC-IP> 8099

And it connected:

Connection to 198.51.100.23 8099 port [tcp/*] succeeded!

That line is the whole proof. A TCP handshake completed from a device out on the internet, through my public IP, through the UPnP forward, to a listener on my laptop. Typing into the phone showed the text arriving live in the listener window back on the laptop — a full, unauthenticated, bidirectional channel from the open internet into my machine, opened by nothing more than a LAN-side request.

From a phone on mobile data, off the home network: the connection to the public IP on the forwarded port completes. The IP is redacted.

The listener confirmed the inbound connection from an off-network address:

Ncat: Listening on 0.0.0.0:8099
Ncat: Connection from 198.51.100.200.
Ncat: Connection from 198.51.100.200:56732.

Typed on the phone, landing live on the laptop — a two-way channel straight from the open internet into the machine.

The instant the demo was done, I tore the hole down — which is the one step you must never skip:

upnpc -d 8099 TCP

Why this is genuinely dangerous

The demo above is harmless — I opened a door and closed it. But the same mechanism, outside your control, is where the risk lives.

Malware self-exposure. This is the big one. A compromised device — a PC, a phone, an IoT gadget — can open its own inbound forward and hand an attacker a direct line back in, bypassing NAT entirely. NAT would have blocked that unsolicited inbound traffic; UPnP opens the door from the inside, on the malware's request. The victim does nothing and sees nothing.

Exposing a vulnerable service you never meant to publish. A forward leads to a service on the internal device. If that service has a known flaw — an old admin panel, a debug port, a torrent client with an RCE, an IP camera with hardcoded credentials — it's now reachable from anywhere on earth instead of just your living room. The mapping itself is harmless; what sits behind it may not be.

Open to the whole world, forever. Remember that mystery mapping: remoteHost empty (any source IP) and lease 0 (permanent). That combination produces holes that outlive the device that made them — orphaned forwards nobody is tracking, exactly like the one I found pointing at an offline device.

Attacks on the UPnP daemon itself. This is where an old MiniUPnPd matters. Historically, badly configured routers exposed their UPnP control interface to the WAN side, letting remote attackers add mappings from across the internet — research years ago found tens of millions of such devices. There's also CallStranger (CVE-2020-12695), which abuses the UPnP event-subscription mechanism for DDoS reflection, data exfiltration and internal port scanning. A decade-old daemon is more likely to carry that kind of baggage.

A fair word of calibration: UPnP is not inherently a breach. It ships on by default, and millions of people run it for years without incident — a legitimate app opening a legitimate port is the normal case. The real cost is loss of visibility and control. You don't get to approve what opens, so a bad actor or a sloppy device inherits the same power your games console has. Put bluntly: UPnP converts "an attacker must breach the perimeter" into "an attacker must breach any single device on the LAN, and the perimeter opens itself."

The other layer: getting onto the LAN in the first place

Everything above assumes an attacker is already on your network. On this same router, getting there took about a minute.

The gateway had WPS still enabled (WPS 2.0), and WPS is the weak link in most home WiFi. Using an AC1200 USB adapter (Realtek RTL8812AU) with the wifite3 toolkit, the WPS PIN fell in roughly a minute — a Pixie Dust attack recovered it offline, and the PIN handed over the WiFi passphrase directly. No wordlist, no waiting. WPS is sold as convenience; in practice it's a side door that sidesteps even a strong WPA2 password.

The run end to end: PMF disabled, WPS 2.0 enabled, the WPS PIN recovered and the WPA2 passphrase with it. Network name, addresses, PIN and password redacted.

Two things made it worse:

PMF (Protected Management Frames) was disabled — that's what lets an attacker deauthenticate a client and capture the WPA handshake to begin with.
A strong WiFi password is no help while WPS is on, because the PIN is a parallel route straight to the passphrase.

Now connect the two halves. Someone only has to be in WiFi range once — a neighbour, a car parked outside. WiFi gets them onto the LAN; from the inside, UPnP lets them open a permanent internet-facing door to anything that stays online — the router’s own admin page, a NAS, an IP camera, or a backdoor dropped on an always-on device. They then walk away with remote access from anywhere, and the forward survives reboots and outlives their visit. That’s why “nobody’s on my WiFi” isn’t the reassurance it sounds like: a weak wireless door plus UPnP isn’t two small problems — it’s a chain that turns one brief moment of proximity into lasting remote access.

Check and shut it down on your own network

Fifteen minutes on your own gear. All of this is read-and-remediate on hardware you own.

List what UPnP is currently holding open. This is the single most revealing command — it prints your external IP and every active forward:

sudo apt install -y miniupnpc   # or: dnf install miniupnpc
upnpc -l

Read the mappings carefully. For each one, ask: do I recognise the internal device, did I mean to expose it, and why is the lease permanent? A clean list is fine. Anything you can't explain is your finding.

Identify every device on the network, so nothing behind a forward is a mystery. The vendor from the MAC address usually names it instantly:

sudo nmap -sn 192.168.0.0/24

Delete any stale or unwanted mapping. It takes effect immediately:

upnpc -d <externalPort> <TCP|UDP>

Turn UPnP off at the router unless you specifically rely on it. This is the real fix — deleting a mapping without disabling UPnP just lets whatever opened it punch the hole again. It's in the gateway's admin page, usually under Advanced, Firewall, or NAT settings. On an old daemon, disabling UPnP entirely is the cleaner call.

Change the router admin password while you're in there. A weak or default gateway password is still the single most common way home routers get taken over — it outranks UPnP by a wide margin.

Disable WPS. If your router offers WPS — PIN mode especially — turn it off. A WPS PIN can be recovered in minutes (Pixie Dust, or a straight brute force) no matter how strong your WiFi password is. Where the router supports it, switch WiFi to WPA3 and enable PMF, which also closes the handshake-capture path.

Verify from the outside. Everything above is the inside view. What actually matters is what the internet sees, and your LAN can't tell you that. Scan your own public IP from off the network — a phone on mobile data, a cheap VPS, or an external port-check service — to confirm nothing is exposed that shouldn't be. (If your router's WAN IP is in the 100.64.x.x–100.127.x.x range, you're behind carrier-grade NAT and inbound forwards won't work from outside anyway — worth knowing before you test.)

The one rule, and the takeaways

Everything here was done on my own network, against my own devices, from my own phone. That line is not optional. Capturing, scanning or opening ports against networks and devices you don't own is illegal in most places, full stop. The entire value of this exercise is understanding your own exposure — keep it there, or take it to a lab you control end to end.

The things worth carrying away:

NAT is not a firewall. It blocks unsolicited inbound traffic as a side effect, and UPnP exists specifically to undo that, on request, with no authentication.
UPnP trades control for convenience. You can't approve what gets opened, so every device on your LAN — trusted or compromised — holds the same power to expose you.
The perimeter is only as strong as your weakest device. With UPnP on, breaching any single LAN device is enough; the perimeter then opens itself.
Visibility beats assumptions. upnpc -l took seconds and showed me a permanent, internet-facing hole I never knew existed. You can't defend what you can't see.

My own loose end from all this: a stale forward to a device that's currently offline, which I'll identify from the router's DHCP list before deciding whether to kill the mapping and switch UPnP off for good. If you run upnpc -l on your own network after reading this, I'd genuinely like to know what you find.

That SSH bot rotating IPs in your logs? Ban the whole subnet, then let the ban expire

Phaedon V — Fri, 02 Oct 2026 09:39:38 +0000

It started with an SSH alert I've seen a thousand times:

sshd: Invalid user taow from 203.0.113.239 port 50612

Then again. And again. Dozens of times, from a different IP almost every time, but always inside the same /24.

Was it dangerous? No. That server only accepts SSH keys, and I double-checked from another box:

$ ssh user@server
user@server: Permission denied (publickey).

No password prompt, nothing to guess. The bot was trying usernames against a door that doesn't have a keyhole.

But it was still noise: alerts piling up in the SIEM, auth logs filling up, and CPU spent rejecting the same junk over and over. When the real alert eventually arrives, I want to see it, not dig for it under 500 copies of Invalid user oracle.

Why the usual quick fixes didn't feel right

Banning single IPs is pointless against a bot that rotates through a whole range.

ufw deny from 203.0.113.0/24 looks right but often does nothing. UFW appends the rule after your existing allow 22, so the allow matches first and the deny never fires. You need ufw insert 1 ..., and you have to remember that every time.

A raw iptables -I rule works, but then it lives there forever. Six months later, someone finds a mystery DROP rule with no comment, no date and no owner, and nobody dares delete it.

What I actually wanted:

ban a whole subnet, not an IP
have it expire by itself (most of these bots move on after a day or two)
optionally make it permanent when a range keeps coming back
not touch the existing firewall setup (UFW, firewalld, whatever's there)
leave a readable trail for the next admin

So I wrote a small tool for it: netban.

phaedonv / netban

netban is a single Bash script for blocking whole networks (for example a /24) on a Linux host, either for a fixed time or permanently.

Manual IPv4 network bans for Linux, built on nftables.
Temporary bans that expire on their own. Permanent bans that survive reboots

netban is a single Bash script for blocking whole networks (for example a /24) on a Linux host, either for a fixed time or permanently. It's meant as a manual fallback next to automated defences such as Wazuh active response, Suricata, fail2ban or CrowdSec: you use it when those miss something or when you need to stop traffic right now without editing firewall configs.

$ netban 203.0.113.57/24
banned 203.0.113.0/24 for 24h

Why

A typical case: a server exposes SSH with key-only auth, and a bot keeps hammering it from a rotating pool of IPs inside one subnet:

sshd: Invalid user taow from 203.0.113.239 port 50612
sshd: Invalid user admin from 203.0.113.12 port 41877
sshd: Invalid user oracle from 203.0.113.190 port 39020

It isn't a real threat, because passwords…

View on GitHub

What it looks like

$ netban 203.0.113.239/24
banned 203.0.113.0/24 for 24h

You can paste the IP straight from the alert with /24 on the end. The host bits get masked, so it bans the network.

Need a different duration, or a permanent ban with a note for future you?

netban 203.0.113.0/24 6h
netban 198.51.100.0/24 perm "returns daily, ssh user enum"

Or run it with no arguments for an interactive prompt, which is handy when you're triaging a few ranges at once:

$ netban
netban> 203.0.113.0/24
banned 203.0.113.0/24 for 24h
netban> 198.51.100.7/24 2d
banned 198.51.100.0/24 for 2d
netban> list
netban> quit

And to check it's actually doing something:

$ netban -l
--- temporary ---
    elements = { 203.0.113.0/24 timeout 1d expires 23h41m12s }
--- permanent (live) ---
    elements = { 198.51.100.0/24 }
--- permanent (/etc/netban/permanent.list) ---
198.51.100.0/24  # added 2026-10-01 - returns daily, ssh user enum
--- drops ---
@perm counter packets 1843 bytes 110580
@temp counter packets 212 bytes 12720

The counters climb, the log goes quiet, and the SIEM stops shouting.

How it works (it's mostly nftables doing the work)

The whole trick is that nftables already supports sets with per-element timeouts. netban just wraps that in something you can type at 2am without looking anything up.

table inet netban
 ├─ set perm   (interval)            permanent networks
 ├─ set temp   (interval, timeout)   temporary networks, auto-expire
 └─ chain input  hook input priority -10
      ip saddr @perm counter drop
      ip saddr @temp counter drop

A few design choices that matter:

Its own table. netban never edits UFW, firewalld or /etc/nftables.conf. Everything lives in inet netban, so removing it is one command and can't break anything else.

Priority -10. UFW and firewalld hook input at priority 0. netban's chain runs before them, so a banned range is dropped no matter what allow rules sit further down. That fixes the "my deny never matched" problem.

The kernel handles expiry. A temporary ban is just a set element with timeout 24h. There's no cron job, no cleanup script and no state to forget about. When the timer runs out, it's gone.

Permanent bans are plain text. They go into /etc/netban/permanent.list with a date and your note, and a small systemd oneshot (netban.service) reloads them at boot. It's also PartOf=nftables.service, so if someone restarts nftables and flushes the ruleset, the permanent bans come straight back.

The core of a temporary ban is really just this:

nft add element inet netban temp '{ 203.0.113.0/24 timeout 24h }'

Everything else is input validation, CIDR masking, and making it pleasant to use.

Install

It's a single Bash script. You need Linux with nft, Bash 4+ and sudo.

curl -fsSLO https://raw.githubusercontent.com/phaedonv/netban/main/netban
sudo bash netban --install

That puts netban in /usr/local/bin, creates /etc/netban/permanent.list, and enables the boot service. Re-running --install updates in place.

What it is not

I want to be upfront about this, because it's a small tool and I'd rather you know its limits:

It's not automatic. It doesn't watch logs. For automatic per-IP banning, use fail2ban, CrowdSec or Wazuh active response. netban is the manual fallback for when those miss something or you need to act right now.
It's not real protection on its own. The actual SSH defence is key-only auth (PasswordAuthentication no) and limiting who can reach port 22. netban reduces noise and load.
It's IPv4 only. For now.
It's host-level. If you control the edge router or cloud firewall, blocking there saves bandwidth for every machine behind it.

Where it fits in a typical layered defence:

Layer	Scope	When
SIEM / IDS / fail2ban / CrowdSec	automatic, per IP	first line, reacts to alerts
Geo blocking (optional)	automatic, per country	broad rotation across many ranges
netban	manual, per network, temp or perm	fallback when the above miss it

Try it, break it, tell me

netban is MIT-licensed and lives here: github.com/phaedonv/netban. It was written at Catalink as part of a growing set of small blue-team tools we use day to day.

If you try it, I'd love to hear:

How do you handle subnet-rotating bots today? fail2ban with a custom action, CrowdSec, edge firewall, or just ignore them?
IPv6 support: worth adding, or do you mostly see this noise over v4?
Anything that broke on your distro. Issues and PRs are very welcome.

If it saved you a few minutes of log-scrolling, a ⭐ on the repo helps other admins find it.

The tool and this post were written with help from an AI assistant. The problem, the servers and the decisions are mine.