Pre-install MiniUPnPd on OpenWrt by default

Tue Jan 25 07:29:48 PST 2022

I totally understand your concern and having a strict policy by
default it's really a good practice to follow.
I thought about this and IMHO the main problem here is most of the
time that's a question of trade off.

For example I developed a web app and to test OAuth flow I manually
made a forwarding of 80 port from my router to my laptop's 8080.
Finished but forgot to close the forwarding. And when I developed
another app that also listens to the 8080 then it became available to
the whole internet and I didn't even notice it.
UPnP/PCP opens a port only for a specified time that a client must
prolong. In that case this makes it more safe than the manual port
forwarding.
BTW it only allows forwarding for ports higher than 1024. And I can
login and see all the leases in Luci in one place instead of analysing
all firewall rules.

There is a small web server for Chrome
https://chrome.google.com/webstore/detail/web-server-for-chrome/ofhbbkphhbklhfoeikjpcbhemlocgigb
It has 400,000+ users and most of them are not experienced like pupils
who try to host their first home page.
It has support for the exposing port via UPnP. Even if 1% of users use
it that means that 4000 people have to go and manually enable port
forwarding.
I am just afraid of how many people may harm themselves.

Also please note that many users just don't have access to the router
e.g. because it belongs to an ISP or to a hotel.

> any application in your LAN can open ports and poke holes

Even now any application in my LAN can connect to any server and start
uploading and receiving data. Should we block them?
Or any computer in my LAN can connect to any other by default. So my
guest or a hacked teapot can steal photos from my NAS. Should OpenWrt
have an isolated clients policy be default?
But the OpenWrt may have at least pre-configured Guest and IoT
networks with the isolation enabled.
Ideally also it may be a kind of captive portal or a firewall client
app installed on the admin's computer.

Currently any VoIP program uses a TURN server which is basically a
server with a public IP that retransmits data from two peers behind
NAT.
And this opens a door for another attack: the TURN server may
eavesdrop or collect metadata. It may be unexpectedly turned off,
blocked or a huracan broke a line.
Few countries already had a situation when due to protests the
internet was just shut down.
Imagine that you are trying to call your lost child when due to some
disaster or earthquake the internet connectivity was partially broken.
Probably most people want to have such ability even if their
PlayStation may be potentially hacked.

Also in my country there are not so many TURN servers and I feel that
sound quality sometimes is bad even if I call my wife in the nearby
building.

So what is safer and better for privacy: allow peers to call each
other directly or by the strict policy force their VoIP program to use
TURN without even noticing them?
Things become even worse with IoT devices: each vendor has its own
"cloud". Once I couldn't start my vacuum cleaner robot because of
problems with the internet. Disgusting.

That was the whole point of that long discussion about allowing IPv6
connections from outside.
I don't want to touch that topic but my IMHO is that here OpenWrt
tries to save the world which is not possible.
Each app developer must know that it may be accidentally or not be
accessible for the entire internet.
But if an app can explicitly ask for a port forwarding then that at
least means that it's developers are clearly aware about security
risks of this.

As a compromise OpenWrt may allow only a short range of IPv6 ports to
be accessed directly so users of old programs without PCP support may
expose them by simply switching a port.
But that's another question.

Here we have a situation: a Regular User had a router with a UPnP,
installed OpenWrt and now I don't have it and games work slower. That
definitely is not what was expected.
And the user will tell his friends not to install OpenWrt. And those
friends will continue to use a proprietary firmware which is probably
buggy and full of vulnerabilities and backdoors.
What is safier?
A Power User or a sysadmin, as opposed to the Regular User, must know
about UPnP and can disable it and create forwarding manually.

The world is dangerous but we may make it slightly comfortable.

On Tue, 25 Jan 2022 at 15:51, Stijn Segers <foss at volatilesystems.org> wrote:
>
> Hi Sergey,
>
> Op dinsdag 25 januari 2022 om 15u27 schreef Sergey Ponomarev
> <stokito at gmail.com>:
> > Hi,
> >
> > Most routers support port forwarding via UPnP IDG or/and NAT-PMP/PCP.
> > And many vendors use the MiniUPnPd http://miniupnp.free.fr This daemon
> > is kind of standard de-facto.
> > This is necessary for any p2p application but OpenWrt builds don't
> > have it pre-installed and pre-configured. While it's not so difficult
> > to install, this is an additional step and still something that users
> > must know. For example, I didn't know about it for about two years
> > while already using OpenWrt. For many users this makes life after
> > switching to OpenWrt worse than it was before because, for example,
> > now their gaming console works slower. Even if someone will try to
> > install it there is a risk to configure it incorrectly and expose WAN
> > to LAN forwarding.
> >
> > Could you include the MiniUPnPd into OpenWrt?
>
> Given the inherent flaws and threats the concept of UPnP poses, I don't
> think it stands a chance to be included by default. Just the fact that
> any application in your LAN can open ports and poke holes at will in
> your firewall is reason enough to *never* do that.
>
> A lot of people in the community advise users to find out what ports
> they need to open and do that manually, keeping control over what's
> open and what not, instead of relying on an easy (but risky) protocol
> like UPnP.
>
> Of course, that's just my 2 cents.
>
> Cheers
>
> Stijn
>
>
> >
> > There may be few concerns:
> > 1. The UPnP IDG protocol has a very bad reputation. See "Universal Pwn
> > n Play" talk.
> > 2. The MiniUPnPd also had a security issue in 2014 when the WAN to LAN
> > forwarding was enabled for NAT-PMP.
> > 3. A disk space usage: I checked on OpenWrt with WR1043N  (MIPS) and
> > after installing the miniupnpd and it's dependency libcap-ng the disk
> > size usage increased to 72Kb. The binary itself is 98565 bytes, in
> > contrast with uhttpd 46212 and lighttpd 221413. Maybe for Tiny builds
> > this may be too much.
> >
> > To make it smaller and easier for a code audit we may strip the UPnP
> > and leave only NAT-PMP/PCP. See
> > https://github.com/miniupnp/miniupnp/issues/545
> >
> > In July 2014 there was two discussions about IPv6 firewall policy for
> > direct connections:
> > "OpenWRT IPv6 firewall"
> > http://lists.openwrt.org/pipermail/openwrt-devel/2014-July/000763.html
> > "IPv6 firewall and Port Control Protocol"
> > http://lists.openwrt.org/pipermail/openwrt-devel/2014-July/000671.html
> >
> > The MiniUPnPd can solve the problem at least partially.
> >
> > See also: a forum discussion
> > https://forum.openwrt.org/t/port-control-protocol-support/114411
> >
> > Regards,
> > Sergey
> >
> > _______________________________________________
> > openwrt-devel mailing list
> > openwrt-devel at lists.openwrt.org
> > https://lists.openwrt.org/mailman/listinfo/openwrt-devel
>
>

-- 
Sergey Ponomarev,
stokito.com