uPnP snitch? Is there any way to "see" pnp requests?

Hi. I try not to use uPnP but sometimes a client might be failing because of a closed port and it is annoying to figure it out.

So i was wondering... is there something that do nothing but listen and logs uPnP requests? So if anything is not working properly, i just look at the logs and immediately know what to open up?

...not to mention getting to know if there's something malicious running on the clients trying to open things it is not supposed to.

Please post output of

ubus call system board
1 Like

LuCI shows ports opened by uPnP in "Services -> uPnP". From the same screen you can enable additional logging.

why that would help? I'm looking for a generic service (also have several modems i want this for)

all modems are on "23.05.3" though, on ARMv8 cpus.

That is only available after you install a full blown uPnP service. which I do not want as it is a blatant security hole.

Please post output of

ubus call system board

And explain how upnp is a security hole?

1 Like

upnp is indeed considered a security risk. The wikipedia article has several mentions of flaws and vulnerabilities.

There are two major issues with the standard from a security standpoint (not counting any general implementation flaws):

  1. The first generation of the standard could request ports be opened/forwarded to any host on the network by any other host. This means that an infected PC could, for example, poke holes in the firewall aimed at another PC, thus allowing remote exploitation of other vulnerabilities in a given OS. This was fixed in the subsequent revisions (OpenWrt has a "secure" or "strict" mode or something like that) such that a host can only ask for ports forwarded to itself.
  2. Even notwithstanding the issue above, there is no user/admin notification of or control over the ports being opened/forwarded. Therefore, a bit of malware could open ports on the local machine, and in that case it could have specifically started services for whatever purpose it wants.
5 Likes

Got it, other nat traversal does not traverse nat

If you are worried about unauthorized network traffic on LAN, you have bigger issues than uPnP.
Sadly it's the only option for things like multiple Xboxes playing p2p networked games.

I think miniupnpd is not automatically enabled after install, and you could even create the config to have it disabled before installing it, if you are truly worried about a LAN device opening a port the very second you install uPnP.

1 Like

If you used openwrt and tried to enable nat-pmp solution was kind of at the end of page.

If you are worried about unauthorized network traffic on LAN, you have bigger issues than uPnP.

that's very reductionist.

for starters, there's very little one can do to restrict network access to untrusted VMs and such. We try to route all the VM traffic to a special vnet, but that depends on devs "doing the right thing" which hardly works. In the end, VM traffic is the same as workstation traffic.

Then there's the problem of bugs on both the uPnP and the routing/firewall. And abuses of things like ICMP and L2 handling of addresses. There are several instances where external actors could trick either the router itself of the clients in the network to bounce a malicious request. Everyone in this day and age agrees that source address is not authentication. Let alone authorization. Yet, there is uPnP.

Then there's the necessity of poking holes in NAT. We do need holes, but uPnP is the worst way to do it. Why would I want a badly documented DSL with full root access to my firewall rules? You cannot look critically at uPnP and ever think it is a sane idea.

btw, that's like trying to support win xp (same igd v1 client implementation code). i'd place them on a isolated wired vlan. Besides being broken to the point of not working with v2 which was supposed to be backward compatible, i also have some old dead bookmarks on remote code execution bugs on those)

Weird one does not see all log checkboxes in luci miniupnpd and the access list

1 Like

(sorry, missed this message when replying other earlier)

If you used openwrt and tried to enable nat-pmp solution was kind of at the end of page.

Isn't it just a thin-api-layer translating bounjour to uPnP? After you have uPnP IGDCP enabled via miniupnp?

I'm not sure how compatible is nat-pmp with clients... will do some research. But that will only mean i have to look for a nat-pmp snitcher as well :slight_smile: as it isn't any better than uPnP IGDCP (well, maybe in implementation choices, but the auth part is also non-existent)

Your outright refusal to provide

ubus call system board

means you run some vendor SDK with leftover OpenWRT strings all over place and actually your problem is unfixable here.

FWIW, NAT-PMP is more or less the same as upnp, and it is still considered a security risk.

1 Like

Yeah, nat-pmp opens doors and changes tv channels. it is just like upnp.

some vendor SDK with leftover OpenWRT strings all over

very thankful for your help on the forum... but i don't even...

Yeah, nat-pmp opens doors and changes tv channels. it is just like upnp.

:slight_smile: I do like your humor though.

...Anyway, following from the talk from Daniel Garcia (all the way back to defcon19) where I was hopping i could re-purpose the thing he demoed to write my own hacky uPnP log-only daemon (I failed to find anything. but it's a called umap.py if anyone have better googlefu or want to write to him) ...i ended up finding something better: someone at akamai already made one in golang and opensourced it in 2021.

will try it out and report back. cheers.

Here's an alternative that's more sane in my opinion.

Install luci-app-upnp, this also installs, but does not yet enable miniupnpd. Visit the uPnP section in LuCI, view the ACLs and make sure that only the "Default deny" remains.
Tick the "Start UPnP and NAT-PMP service" and make sure uPnP and NAT-PMP functionality are also ticked.

Any device trying to map a port, will result in a log message, no need to tick "Enable additional logging"

Tue Jul  2 11:08:06 2024 daemon.err miniupnpd[17003]: No allowed eport for NAT-PMP 50035 tcp->192.168.1.123:50035
3 Likes

That requires OpenWRT ....