Port Control Protocol support

For Developers
1

I was made aware not long ago about the existence of Port Control Protocol; a successor to UPnP & NAT-PMP. I heard qBittorrent is supposed to support it; as anything else making use of libpcp. What is not clear to me, is anything in OpenWRT that does use libpcp to provide an endpoint. This would be useful in an IPv6 environment; as the default firewall for OpenWRT does not permit incoming IPv6 traffic to clients, that wasn't based on a request from software; IPv4-NAT-style port-mapping is a present workaround.

Hope this is of some interest to folks. Thanks!

2 Likes
2

I'm not a network expert but was also interested in the topic and did some investigation.
In devel list was a long discussion IPv6 firewall and Port Control Protocol with a proposition to allow incoming connections for IPv6, at least for non root ports above 1024. But the idea was declined because users may not expect such behavior. Personally I think that any ephemeral port 32768–60999 must be open. Or even it may be some subrange of those ports that will be known to be public.

So a computer from a local network must clearly ask a router to open a port, renew it each 30 minutes and keep watching that it wasn't closed after router's reboot. This makes voip/p2p/gaming software more complicated. But OpenWRT definitely must support this.

To open the port the old solution was a UPNP IDG which is part of Plug-and-Play.
And this is an incredibly terrible protocol: it's kind of HTTP over UDP with SOAP style messages in XML. Specifications are unclear - that is probably the most worst documentation that I ever saw.

I wonder how it was implemented at all. But no wonder that it's very vendor specific and anybody violates spec. Anyway many routers do support it at least somehow. I had one such router but it doesn't worked :slight_smile:

But just because nobody understands it was almost everywhere configured incorrectly and hackers from internet were able to open a hole to local network.
That's why the UPNP was simply removed or disabled by default by many manufactures: they just don't want to fix it :slight_smile:
If you have a spare time there is a great talk Universal Pwn n Play

There is an open source minupnp project and you can install it on OpenWRT and it's even have a Luci app. But it's 140Kb quite too heavy for 4mb devices. And anyway the UPNP client is also too big and need for XML parsing library so it's not so widely used by regular programs.

In 2005 Apple developed their own lightweight protocol NAT-PMP as part of Bonjour. It's second version was renamed to Port Control Protocol because it's not only for NAT anymore.
Basically there is small differences and probably they are backward compatible.
But the PCP is widely used abbreviation so often people saying NAT-PMP/PCP or even just keep calling it in library names as NAT-PMP.
As far I know all Apple products supports it and looks like Juniper routers supports it too. But MikroTik doesn't support and users asking for it.

Looks like Apple never was interested to push this protocol, they just use for themselves with Airport Extreme routers.

Here is a good article that gives a basic understanding of IDG vs NAT-PMP Открываем порты за NAT при помощи NAT-PMP и UPnP IGD.

The NAT-PMP/PCP support was also added by the libpcp authors to the minupnp just because it does a similar thing. So this adds some confusion.
If you do want to use PCP you anyway have to install minupnp. I asked it's authors if it possible to create a PCP only miniupnpd so it can be used in 4mb routers https://github.com/miniupnp/miniupnp/issues/545

For clients there is a libnatpmp library that for example is used by Transmission. The library was developed by the miniupnp author Thomas Bernard.
OpenWRT also has a package for it with 4k size.

The libpcp that you mentioned was developed by two guys from Cisco and as Proof of Concept even tried to use libpcp for Transmission https://www.ietf.org/proceedings/87/slides/slides-87-pcp-12.pdf and submitted a patch #5415 Add PCP support for port forwarding

It's funny because looks like Transmission authors forgot about it

In the issue is also said that the libnatpmp doesn't support IPv6 while the libpcp seems that have a better compliance with protocol.

The miniupnp author also knows about the libpcp and even forked it to play with https://github.com/miniupnp/pcp

It looks for me like there is lack of communication between libpcp, miniupnp and transmission authors.

In the same time the libpcp doesn't have a server part, only it's mock. So the part that actually forwards packets must be implemented.
Also the libpcp client library is not published in Debian/Ubuntu and OpenWRT repos. So basically it seems not so widely used in real life.

To summarize:

  1. It's not clear which one is better libpcp or libnatpmp. I think, ideally the libpcp must be just merged into libnatpmp because it's already used in production and can be easily upgraded by existing distribution channels. https://github.com/libpcp/pcp/issues/22
  2. For new routers with a big storage OpenWRT may just include by default the miniupnpd and luci-app-upnp but it must be pre-configured carefully.
  3. As an alternative we may try to develop a PCP only daemon or even just extend OpenWRT firewall. That pcpd will be small, easy to audit and configure and can be backported for tiny 4mb devices.

P.S.: some ISP may open a port for you with UPnP. So for example you may access your router from internet even without a static IP. This opens a door for next discussion about cascade PCP configurations.

3 Likes
3

Hi again, a short update on this.
I gathered a list of all PCP/NAT-PMP libraries and daemons https://en.wikipedia.org/wiki/Port_Control_Protocol#Implementations
It turned out that there is also available two daemons https://github.com/tedjp/stallone and http://savannah.nongnu.org/projects/natpmp/ which was written by a student but looks working. They are both outdated but still they are smaller than miniupnpd.

Also the https://github.com/miniupnp/libnatpmp now has an open issues. Hope this will improve it's usage and adoption.

I also found that some libraries authors are not excited about the PCP:

IIRC the spec had various extensions in review at the time, and there were talks of carrier-grade NATs supporting PCP. NATPMP was a simple protocol. PCP, if you include all of the extra stuff, didn't seem like a simple protocol.

When it comes to UPnP, its the ancient routers that you need to be worried about. More modern routers are all probably fine. Some routers may also have security features that won't let your software just open whatever ports it wants (user intervention may be required).

Another one author decided not to support the PCP at all:

PCP is a neat protocol, but it's significantly larger in scope than NAT-PNP. PCP is upwards compatible with NAT-PNP at the network packet layer, but I think a good Golang API for PCP would look different than the current go-nat-pmp API. I think it would be better to have a separate go-PCP library with a PCP-centered API.

4

I sent a letter to devlist http://lists.openwrt.org/pipermail/openwrt-devel/2022-January/037719.html

5

@stokito thanks for looking into all of this. It looks like it's a complicated situation, but there appears to be a working path on it per your ideas.

1 Like
6

I asked in dev chat http://lists.openwrt.org/pipermail/openwrt-devel/2022-January/037749.html

So the PCP wont be supported by OpenWrt out of the box and developers of p2p apps must provide instructions to users about enabling it manually.

1 Like
7

Fair enough. With my local home-network administrator hat on, I can understand the position voiced in that chat, control over which ports are open or closed should be with the admin not with any application that feels like it.

"So even given that NAT-PMP would be safer than manual port forwarding
and allows the use of safer and more reliable programs the OpenWrt is
intended only for advanced users that at the same time don't want to
use the Internet."

This is IMHO not an objective summary of the IRC discussion. And also dependent on a very optimistic assessment on which application will use NAT-PMP and whether they will do so with asking the users informed consent or not. Mind you, I am happy to believe that your application will behave exemplary well, but who will make sure all other NAT-PMP capable applications will behave similarly well?

Now, personally, I have made peace with the realization that my router's firewall is not going to be the end-all of all home network security, as most devices are reasonably mobile and hence require their own firewalls anyway, but I still think that enabling NAT-PMP is something that a network's admin needs to be in control of.

Is poking "holes" though firewalls annoying? Yes, a bit, but then it does not need to be done that often anyways....

And I do sympathize with your challenge in guiding inexperienced users to configure their networks such that your application works as designed; how about you take this as a teaching moment and add to your documentation instructions how to achieve that manually?

2 Likes
8

Thank you for the detailed response. This is a really some topic that seems like a holy war and many people just don't want to touch it. Even if it seems clear that NAT holes are evil when digging into the topic it opens many other aspects.
The most horrible thing is that in fact our beliefs just don't matter simply because...

  1. Almost all routers anyway have the NAT holes enabled. Even Apple routers. Personally I didn't hear that this was used for an attack. 8 years passed since the last security hole in MiniUPnPd and even that was just a misconfiguration from vendors. I'm pretty sure that OpenWrt users always had a good preset. So at least we know that it's resistant to external attacks.

  2. Literally almost all routers still have a default username and password. So any worm may simply do whatever it wants and create as many forwardings as it wants. Hopefully most OpenWrt users change the default password.

  3. Any malicious programs have their own servers so they easily create tunnels. Sure UPnP will simplify their dirty job but at the price of exposing users to another attack by using centralised servers.

The concern about the inability to use p2p programs is really big. This is very dangerous for many people not only because of oppression but also because of nature disasters.
I partially explained it in my answer http://lists.openwrt.org/pipermail/openwrt-devel/2022-January/037721.html.

We had a big discussion about choosing a source code hosting and problems with blocking. But that's only source code and discussions which are not private and may be anywhere. And at the same time billions of users have to use totally unprivate software for messaging and calls. Even if you have encrypted messages then there still are not so many servers that have a motivation to retransmit them. Without good p2p connectivity it's not possible to create good programs and improve quality of life.

From this perspective for paranoiacs it even looks suspicious that OpenWrt limits direct connections.

BTW I'm also not sure if it's really so not safe. An attacker has to scan 65535-1024=64511 ports to at least find some listening program, then it must somehow guess what exactly is the program and which version and then somehow send an exploit. It's not so easy. Now imagine that an attacker has to scan many IPv6 addresses.

Of course, most OpenWrt users are more experienced. And many of them even use Linux or antivirus and are less exposed to worms. But not all of them know about UPnP. I didn't know.
Now I know and risks seem fine for me. Even if my vacuum cleaner robot will be hacked somehow, that's not a big deal because my Linux PC won't be harmed for sure.

Even if some advanced users know that UPnP may help them they may be too lazy to install the MiniUPnPd or just simply don't know which one to install. Here just having it pre-installed but not enabled may help. If the server will be small (i.e. NAT-PMP only) then it won't be a problem to preinstall it disabled.
But even 72k should be fine for 8mb routers.
Ideally OpenWrt needs a configuration guide in which it may just ask to enable UPnP, guest WiFi and other most important things.

how about you take this as a teaching moment and add to your documentation instructions how to achieve that manually?

Sure, that's the only option left. Still I installed OpenWrt to my parents and my wife's parents and I literally can't control what's happening there and manually forward a port each time.

9

I do not think this to e a matter of "believe", but of assessment of risk which ideally is fact-based.

A) I do not have any reliable statistics for default settings of "all routers" and I invite you to share your sources that made you come to that conclusion.
B) As far as I can tell Apple stopped making routers years ago, so how are they relevant (and it is not that Apple does not have its own share of security issues, including not reliably fixing known bugs in older but apparently still supported OS versions)?
C) My argument is that NAT-PMP in itself is a security problem, so I do not require any bugs in its implementation to consider it clearly something a networks admin needs to opt-in explicitly (as compared to be active by default). Yes, MiniUPnP, can be made reasonably secure, by only allowing specific internal IP addresses to remap ports, but the default seems to be to allow any internal addresses to re-map ports > 1024.... So IMHO even reasonable MiniUPnP use will require admin intervention, so having the admin run opkg update ; opkg install luci-app-upnp before doing the adjustment of internal IP addresses allowed to use that service does not look to onerous to me.

I do not believe that this is still true, I have seen individualized default passwords on a BT HomeHub5A as well as on a FritzBox (not sure which), and OpenWrt by default has no password set but requires a wired connection (wifi is disabled) and pokes the user to set a password... Have you actually set up an OpenWrt router from scratch recently?

Yes, security is always only relative and comes in layers, and there is always a conflict between security and convenience. The question hence is less "is this security decision in itself sufficient to eradicate a certain class of attacks completely" and more "is the gain in relative convenience worth the loss in relative security (by making certain attacks easier)". There are clearly different possible answers to that question. None inherently a-priori better or worse. In this specific case, I personally would like to be in control as the admin of my network and hence do not see how a default configuration could allow that?

That is a straw-man, no? We are not talking about making your application impossible, all we require is that a networks admin makes an informed decision about the risk involved.

No you misunderstand, the attacker puts malicious code into a smartphone app, and will be able to operate its own P2P exploit network without centralized C&C servers making it harder to detect and squish. My point is not about taking over my network from the outside (as I said I do not consider my own home network non-hostile) but making it harder to base a nefarious operation from inside my home network. And yes, this is relative security not absolute.

Yes and that is fine, as I said each networks operator should make this decision, but if the default is upnp installed and active than the decision is party taken out of the admins hand. If upnp would work in a way where a mapping request would result in a query to the admin (let's ignore the technically how to get to the admin in realtime) with an easy way to accept/reject temporarily/time-limited such a request for the requesting internal IP address that would be a different case to argue, but that is not the case right now.

Yes, but in that case I would argue that they are really not interested in that service and hence not installing it might be the right decision...

Again requiring the admin to install the app does not seem to onerous to me, given that it needs to be competently configured anyway (even the decision to unconditionally enable it for all internal hosts sgoud be made consciously).

Have a look at the wiki if something like that does not exist already, if yes see whether it needs refinements if no, have a go at it.

As I said, if you (assuming your the networks' admin) decide that enabling upnp is an acceptable trade-off just install and enable it unconditionally. But accept that others might not want to do so.
But honestly, how often do you actually need to open new holes?

3 Likes
10

do not have any reliable statistics for default settings of "all routers"

https://192-168-1-1ip.mobi/default-router-passwords-list/
That may really vary from country to country and by ISP. Here in Ukraine the ISP market is really big and highly competitive. That makes the internet here one of the best in the world in terms of quality/cost. In my building I have at least three ISP but maybe it's even five. And some of them prefer to give their own router, some have strict security measures but some are just pure garbage and customers use their own routers with fabric defaults. One of the biggest ISP uses the same password on all it's routes (kyivstar). I wish to be wrong that default passwords are widely used. I can tell that at least five times I was able to login into a router with default credentials.

The FritzBox! as far as I know it is used only in Germany. It's really great that they customise passwords.

OpenWrt can also include a generated pwd during a download. The image is compressed with LZMA and it supports concatenate streams and the last stream may be just uncompressed and we may write a password there. The same password may be added into the downloaded file name so the user may see it even if left the OpenWrt site.
We may discuss this as a separate topic.

OpenWrt requires a wired connection (wifi is disabled)

It's good that you mentioned this. I had a situation when I rented an apartment for a week and the WiFi router had default credentials and probably had vulnerabilities in the original firmware. I asked an owner if she is fine if I'll set another credential or even install OpenWrt. She said that totally trusts me and previous visitors also complained about WiFi stability. But I didn't install OpenWrt because it has a turned WiFi for a security reason but I hadn't any cable. So due to security precautions of OpenWrt I just wasn't able to use it left unprotected (sorry for dramatising :slight_smile:
Today with WPA3 the radio sniffing is not a big issue so maybe it's time to make Wifi enabled by default?

As far as I can tell Apple stopped making routers years ago

Thank you, I didn't know. That is good news because Apple is jailing their devices :slight_smile:

malicious code will be able to operate its own P2P exploit network without centralized C&C servers making it harder to detect and squish

That's a good point. I think that if the worm creates a port forwarding then it expects to receive packets/commands from outside. So it still needs a central tracker server which may be detected. At least cyber police still have a tail to pull.
At the same time a central server may be bought in the cyber crime forum or just hack someone's wifi. Ironically, it seems that for hackers it's easier to get a central server with many resources than for a good app developer.

Maybe even OpenWrt should have some kind of Dynamic Firewall like Turris Omnia have https://docs.turris.cz/basics/sentinel/threat-detection/
But who knows that one day the block list firewall wont begin to block you? Or should it also block what the government said? It should be optional for sure.

It comes to mind to me that some applications while being leggit are doing dubious things. The recent story when Norton Antivirus began to mine a crypto. Or MS tracking servers. Even Chrome may be threatened as a spying software. Many questions appear here.

so having the admin run opkg update ; opkg install luci-app-upnp

That's easy to do for us and still for many inexperienced users this may be additional obstacles:

  1. You must know about UPnP and that it may solve your problems. I didn't know for example.

  2. You must be sure if this is safe or not. Googling UPnP shows many old articles about vulnerabilities which are not actual anymore. This may unnecessarily scarry users.

  3. You must know how to use Luci packages and that you must press the Update button before searching for a package.

  4. Which package should I install? By searching for upnp it shows dozens of them. Or I may install miniupnpd but not install luci-app-upnp and don't enable it.

That's why I thought that it should be pre-installed, properly configured and enabled by default. For me it was obvious that it should be done like that because benefits are much bigger than potential impact.

Now when OpenWrt devs explained that they don't want to have even that small additional attack vector I agree with them. There is still some superstition about how dangerous it is and we lack some common understanding of the threat model.
Even if core devs will say "hey a RandomUknownDudeFromInternet, you are right! Let's enable it" it will cause many objections from users.

As a good compromise OpenWrt may have it pre-installed but not enabled by default. At least users will see UPnP in Luci and may think if they want to enable it.
Or, a better solution would be to have a user friendly configuration wizard. The Turris Omnia has its own admin dashboard and there is a short list of additional packages that users may want to install. There are things like OpenVPN, Tor, NextCloud, AdBlock and UPnP (which is in fact the miniupnpd+luci-app-upnp). This is very user friendly.
OpenWrt definitely must have something similar. If I can give a simple instruction to my users to go into their router and just make a single click this will make life much easier.

11

Yikes.. So you took apparently non-technical people, gave them a FOSS Embedded OS Firmware for their networking devices, and then expect to say "Good luck!"? You did this - twice..

When you want to be the person, you have to be the person. If you want to play network admin, do it properly. If you need remote access to a network, you setup an inbound VPN (which OpenWrt has provisions for, both OpenVPN and WireGuard).

Beyond that, you have the option of being the "on-call" tech by showing them how to use built-in apps like "Quick Assist", which is available to anyone with Win10 (1903+, I believe, but you may have to confirm) which gives them the ability to let you remote into their PC securely, from which you can do what you need to do on the network from that particular beachhead. How crazy do you want to get with it and how patience and love your parents and in-laws actually have for your shenanigans (which is how they'll ultimately see it the first time the network doesn't work the way they think it should).

OEM Firmware has these "conveniences" built in and enabled because they don't really care about the security of the devices they put out and they don't want to deal with the support calls about "how their Xbox/Playstation's Online chat won't work right and the FAQ says to open the ports and now I'm asking you because your name is on the box and I paid $60 because the cable guy said it was better and YOU BETTER FIX IT"... Hense, UPNP, WPS, etc.

If you want "easy" and "security", you better be ready to hand over serious cash. Whether it's complex-but-great-UX UI (rarely) or simply hiring the expert to make what you have do what you want (very easy as far as you are concerned, pricey though).

Also, I believe you came to the IRC asking about MiniUPNP being defaulted to being included and active because you were developing a "P2P Project", no? You can't expect anyone to use your project to have UPNP or NAT-PMP, so you're going to have to provision for it not being there anyway. And, if your software runs with those tools, and you are expecting some kind of privacy, you're kidding yourself. If your app can drill out, whatever else is on that machine can do it as well, leaking whatever data it wants to about it's connections (including the one over your application). P2P Devs should be the first one cheering security. People are telling you how to do it correctly, not easy.. They are rarely the same (look at Log4J having dependency trees up to NINE deep!!) if you need a dev example

1 Like
12

You did this - twice..

I did it five times :slight_smile: Also I gave two of my old routers with OpenWr to relatives and bought a Turris Omnia for myself, which is also based on OpenWrt. Oh wait, I also have a Kankun SP3 smart socket, two FWall Wap-v1.0 repeaters and one I also gave to my relative, and GL.Inet Mango and all of them have stock firmware based on OpenWrt. My vacuum cleaner robot has Ubuntu based firmware. BTW new robots now use OpenWrt. You see, the FOSS Embedded is not as bad as we used to think :slight_smile:

If you want "easy" and "security", you better be ready to hand over serious cash

The whole point is that NAT holes are more secure. They are temporary, auditable from UI, less prone to make a configuration error, clearly shows that a program supports it and aware of risks, allows secure traffic by using direct connection instead of centralised spying servers. Maybe I missed something but I didn't remember that someone challenged this.
The only two attack vectors that I see is a DDoS, sending an exploit or that a program doesn't have a good intruders protection like a weak password. But this is the same as we have now.
Right now if a user wants to play on Xbox it will either: open port itself (and potentially do it wrong) or install upnp which leads us to the same issues.

I do agree that we may minimise risk by hardening the nat hole daemon.
We may strip off that UPnP and leave only PCP. If a program uses PCP then it's definitely newer and probably is better protected.
The PCP is a small protocol and easier to audit. It's a binary protocol while the UPnP uses XML and it's parsing is a big attack vector.

We may allow only IPv6 ip addresses which are harder to guess and again shows that the program is newer.
Also I am going to raise a question in MiniUPnPd about open ports by default. Currently defaults are 1024-65535 but I think that only ephemeral ports 49152–60999 must be allowed.
I need to check if it is possible that a program opens a port that it doesn't own. It should send an open port request from the same port as it wan't to use.
Ideally would be to extend PCP and to allow users to use a password or some OAuth dance with a router. Then the NAT hole daemon may send a notification when the port opens. But for now we can't do this. Still this is possible to add in future.

Also an end device OS may ask a user for confirmation to open a port. Like in Android you must confirm an access to photos.

13

Ah, sorry I was not clear, my question is what fraction odf routers in the wild are still using the default passwords (secure or insecure).

That should probably brought up as an issue with that ISP's security team... but that is outside of the scope of this list :wink:

Not sure, I believe they also sell abroad, but I really brought them up as an example for a commercial router manufacturer.

This is completely out of scope IMHO. Let's skip going down that tangent, please.

I am sure the next tie you will come prepared... over here most routers come with >= 1 ethernet cable in the box... but that might different in other places.

I am just an OpenWrt user, so I am not the right party to address such proposals towards, but personally I really really like the current design, where there is zero chance of rooting one's router over the air, while those with physical access can do everything.

It is also slightly bad news as it implies that your facts might not be as recent/up-to-date as desirable :wink:

??? All you need is a VPS with either a fixed IP address and/or sufficient flexible (dynamic)-DNS, as I see this this is a question of $$$ more than on whether side of the "law" you operate, no?

Well, but we talking about this in the context of a new application/service you develop and that users need to "know about" in some way or the other, so maybe adding how to deal with firewalls in different levels of restrictiveness to the place users finds out about how to use your application would solve this conundrum?

Again, my argument is that even a bug-free, working as designed upnp might be considered an unacceptable security compromise, independent to the fact that software rarely is bug-free even after years of use and debugging (hopefully the un-handled corner-cases get rarer over time though).

Yes, the onus is on those trying to deploy apps/services that require changes to the default configuration, but once you accept that pressing one button in a GUI more does sound manageable to me, no?

I have no idea, in your case I would propose you test the different ones and simply describe how to configure those to cooperate with your application. Bonus points for explicitly spelling out the security<->convenience trade-off this entails, so that users can make an informed decision.

Yes, and I fully accept that from your perspective this seems a reasonable trade-off. I do question however if that assessment generalizes to all existing or potential OpenWrt users.

For sure, as you seem to only look at the part where an upnp system might be exploitable by working out of spec, while ignoring the concerns that upnp even according to spec can be considered a security problem.

Maybe, maybe not, but without consent from the core developers (to be clear, that is not me, I am merely a normal user) this whole thing is not going to go far...

IMHO that would be an argument against installing it by default if it might cause people to casually enable it without researching the issue sufficiently to be able to make an informed decision about the involved trade-off.

Go wild, develop and offer something ;). Feature request, make it so that the network admin needs to grant any request (either forever of for 24 hours) and make such grants as restrictive as possible (linking to MAC address?)....

Well ATM it will be:
1: click on update sources
2: type in luci-app-upnp
3: click install
that seems not that much harder, no?

Not sure this would be any worse than commercial router interfaces... (but I tend to only help install OpenWrt for users that explicitly ask for it).

Maybe you spould have put the rest of the family on omnia's/mox's as well, as turris OS aims to being a secure by default OpenWrt-based distribution that caters to non-expert users.... (disclaimer, happy turris omnia user myself, still running TOS, since the automatic updates were the main attraction and these require TOS).

Compare to disabling a stateful firewall completely? Yes, compared to not allowing holes? No. Compared to manually poked holes? Debatable.

You are missing the point, all applications on the allow-list or even on all internal hosts can now poke arbitrary holes into the firewall, all in that name of convenience...

No, in the first case there is only one limited hole and an mischievous application on the same host will have to search and find that before abusing it, in the second case all it needs to do is ask nicely...

Engineering by wishful thinking? This does nothing for the case of malevolent internal application abusing the capability.

Except that the whole functionality is an attack vector.

Except it is the network admin that needs to be asked here... by all means implement that functionality and then ask for it to be installed and enabled....

2 Likes
14

I checked and looks like Cisco routeres have the upnp and it's enabled by default https://www.cisco.com/c/en/us/support/docs/smb/unified-communications/cisco-small-business-voice-gateways-and-atas/smb3983-upnp-settings-on-the-wrp400.html

Such routers aren't the cheapest SOHO routers. As we saw, libpcp was also developed by Cisco.

I didn't hear that their users were harmed by upnp.

Any worm that opens a port still has to use some additional server with a public IP to notify about the victim IP and the opened port number. But if it has a public server then it may build a tunnel. The only benefit is that with the open port worms may talk with each other and receive data faster.

That is really questionable if they even need this.

So in fact avoiding upnp is effectively the same as just speed limiting.

Another attack is to send an exploit to a program. But the same is for a program that uses a manually forwarded port.

There is a possibility that some program with a vulnerability opened a port itself. And again the same as for a worm: it must anyway interact with its public server. The tracker server may say: "hey, your version is old, you must upgrade. I won't tell you anyone elses IP to connect". So this attack risk is really unlikely.

The upnp also allows the use of a random port each time which also extremely improves security.

We say that "OpenWrt is secure by default". But this is definitely not the case for UPnP.

The current situation is that users are being exposed to many attacks because they are using centralized relays even without knowing about it. IPv6 is just useless because it doesn't serve the initial purpose.

Even compromise solutions to use PCP are rejected just because "UPnP is bad mmmkay?".

Instead of being a good modern router OpenWrt tries to be an obsolete poor firewall.

15

Could be, but hand on your heart, you seem to be researching this from the angle that upnp/pcp are harmless and a trying to find corroborating evidence for that position...

Yes, as I said security is always at a trade-off with convenience, but what is more convenient for your application is also more convenient for more nefarious applications. So this boils down to a question of policy, that IMHO every network's administrator will need to decide on.

That works the other way around as well, having users install and enable it before using your application, assuming you have easy to read and follow step-by-step instructions, is also only a minor speed-bump.

Yes, but I do not consider that to be a relevant threat in our discussion.

Why? Scanning all IPv4 address space is not impossible or unheard of, and if one can rely on a mostly stable port number things get even easier. If you accept a little longer exploration phase at start-up to find other nodes in the P2P botnet, you can do away with the need of more centralized C&C infrastructure...

How does this stop our "worm" from requesting specific ports or from repeating its requests until it got assigned a port it is happy with?

I am not saying that, because absolute security is not really an option, I would say OpenWrt comes with a reasonable sets of defaults that seem to prefer security over convenience to some degree.

You obviously have every right to form your own opinions and assessments, but I am not fully convinced that you are looking at the issue at hand from an objective enough perspective.
For what it is worth, I am quite happy with OpenWrt as router and am mostly using defaults and only a few additional packages. And the best thing is, if you are not happy with the defaults you can:
a) change them on your local installation
b) build and distribute your own firmwares including your preferred packets and configurations for your "customers"
c) distribute instructions for how to ads all the prerequisites your application might require from a firewall/router, so that it is usable for the few OpenWrt users....
d) change OpenWrt's defaults to suit your needs, but ATM it looks like you should reconsider your arguments if you want to continue on that road... (again, I am a mere user, whether you convince me or not does not matter one iota, you would need to win the heart and minds of the real developers)....

I have a hunch we reached the point were we might want to just agree to disagree, no?

1 Like
16

Cisco Routers also require a base level of knowledge, even for their low end stuff..

Yeah.. Tell me again how this is the "easy way"? These are pretty standard for the "Cisco" brand (unless you actually were referring to Linksys?) . Those who care/know better do not make it "easier"..

2 Likes
17

Interesting that in the instruction Cisco allows to be < 1024 ports to be forwarded with UPnP. Limiting by a service also looks interesting. We have two usage scenarios:

  1. Some well-known service like 80 http is forwarded. E.g. email.
  2. Some p2p program need for a random ephemeral port. It then must send it to tracker server or directly to the peer.
    The first is questionable and definitely must be allowed manually but for p2p case this doesn't need to be pre-configured.
18

How does this stop our "worm" from requesting specific ports

The port randomness helps against port scanning from outside. It's not related to the worm from inside.

Scanning all IPv4 address space is not impossible

Still it definitely a more complicated task. An attacker must scan all servers and all ephemeral ports and without being noticed. Even if it found something interesting on the next restart a program will use another port.

19

Could you please explain exactly why you care so much about the default? I think OpenWRT's design philosophy of choosing security over convenience is the right choice. But I do understand the defaults are not right for everyone's situation / desire as you already explained.

But what exactly is preventing you from changing those defaults? I understand that installing & enabling upnp isn't as easy as we make it out to be, but OpenWRT needs to be installed as well, which is far from easy for the average Joe as well. I am assuming you are doing the installation for your relatives?

  1. What is preventing you from installing & enabling upnp after installing OpenWRT for your relatives?
  2. In case your relatives do install OpenWRT themselves, what is preventing you from providing them with an image-builder image which includes upnp and has it enabled by default?

To be honest, all I am hearing is that having it on by default makes sense for YOUR particular situation. But as the others already tried to explain, the protocol itself has security implications, so it will never be enabled by default for OpenWRT (thankfully so!). Some people prefer to have it enabled, some prefer to have it disabled. You cannot please both crowds. But in that case, security simply triumphs convenience.

As for the discussion regarding the security implications: If upnp is implemented well (and that's already the first if!), the security implications for malicious software is rather small. A well implemented upnp implementation prevents applications from opening ports for other devices. Yes, a malicious program could open a port to be controlled from outside. But at the same time, if your computer is infected by malicious software, it can just as easily contact a command & control server with a connection initiated from inside the network, so the ability to open ports isn't strictly needed.

However, the security implications ARE there for non-malicious software. When manually port forwarding an application, you trust the application, and you made sure that it's using a sane configuration. For example and depending on application, a strong password, bruteforce protection, secure protocols, etc. However, if ANY application can open a port at will, it means that applications you might not trust to be open to the big bad internet can open their port. Maybe even with a weak default configuration. Port forwarding is explicit, which means you have to think about what you're doing. Automatic port forwarding is implicit, and you might end up with an application open to the whole wide world with shitty and insecure defaults. We CANNOT control every single application that will ever be used within a network to be secure. We CAN, however, minimize the risk that they pose to a network by not automatically opening ports on request.

As for port scanning, have you ever enabled detailed logging for the firewall? You'd be surprised how often scans happen. Seeing literally thousands of requests per day is totally normal.

3 Likes
20

There are even services specifically for it..
shodan.io

1 Like