As the world is gradually moving towards IPv6, home users find themselves behind an IPv6 firewall (as opposed to a NAT router in the old IPv4 world). To make Plex servers inside the LAN accessible from clients outside, a port needs to be opened in the firewall. This can be done in the web interface of most routers, but this requires manual action, and ports opened that way then stay open even if the Plex server is not running. If the router supports PCP (Port Control Protocol), the Plex server application would instruct the router to open the appropriate port.
https://tools.ietf.org/html/rfc6887
This is analogous to how Plex currently does NAT-PMP in IPv4 - PCP is its successor.
I like it, I’ve no free votes though (stupid limits).
It was a bad idea in PMP, and it’s still a bad idea in PCP. A single compromised endpoint could conceivable turn your firewall into swiss cheese. If you build this functionality into the Plex stack, then you are still putting your entire firewall security model into the hands of the Plex developers. There are still other controls you would need to have in place and segmentation/isolation of hosts, and that level of segmentation will likely not be included in consumer level routers, even if PCP is adopted.
This is what I never understood with all the criticism of PMP/PCP - a compromised endpoint can already set up an outgoing connection, act as a relay inside the LAN, etc - why would it need to open a (much easier to detect btw) port for incoming traffic?
And the whole nature of a server in a TCP/IP network requires that it is routable from the outside. The only way to avoid something like PMP/PCP is to either rely on third party man-in-the-middle services so both server and client can use an outgoing connection (thats how Teamviewer does it) which has even worse security implications, or alternatively requires millions of know-nothing users go into their router/firewall webinterface and map (NAT) or open (firewall) ports manually, which leads to an even worse static situation - for one, the port will remain mapped/opened long after Plex is uninstalled unless the user reminds himself to go back to close it.
Because I DO know about security and networking, I know what ports I have open and forwarded on my firewall. I don’t need a piece of software controlling my firewall automatically and without permission. The issue is that, based on the RFC, one machine can control ports and forwards for other machines. So, you could potentially have a machine controlling access to and from other machines. I do believe PCP can be hardened and may even be safer that I anticipate if enterprises pick it up and build on it. However, consumer hardware will be a train wreck and I don’t think enterprises will want or need this. That is why they hire network and security staff.
If you port is left open and forwarded, after you have removed plex, it really only becomes a huge issue if a) you have another process on the same IP that is using port 32400 or b) you have a lower level protocol vulnerability on the far end and an attacker might cause a DoS on that IP. But, if nothing is listening on that IP on that port, the communication will fail. I agree - it needs to be cleaned up, but it is unlikely to cause an issue here. I see a lot more risk in applications that don’t need to have access (maybe you don’t use that functionality, whatever) opening network ports that you don’t know about. Then that application has a vulnerability but you don’t know it. All of the sudden a new vulnerability, exposed unknowingly to the internet, on your machine. That is the real issue to me.
The point for this request is, currently Plex Media Server has implemented UPNP and NAT-PMP for the old IPv4 world of NAT traversal, and it works well. Plex will probably have some stats how many server instances make use of it, but I’m willing to bet the majority of IPv4 servers use it.
With the transition to an IPv6 world (either in the form of DS-Lite or Dual Stack) well under way, Plex needs to implement PCP if it wants to retain the same functionality once most consumer connections have no IPv4 address of their own anymore. If the Plex devs deem PMP safe enough for the current server, then where is the argument against PCP (which, from a security point of view, is exactly the same)?
I understand your wish that Plex should not have either PMP or PCP implemented, and all should be set up manually in the router interface. But this is not possible for all: take for example the case of users who do not have password access to the router interface but still need the option to punch a hole in the firewall for themselves.
Offtopic: I think this concept of your own safe walled off LAN and the evil wide wide WAN is going to be a thing of the past very soon for everyone, enterprise or consumer. With IoT devices everywhere running god knows what, every server need to treat LAN and WAN devices with the same suspicion. Whether an badly written application is able to open a port or not in the firewall is irrelevant, if it’s vulnerable it’s dead meat either way. It’s a lot quicker to portscan from within the LAN anyway with its nice UDP device discovery protocols than for attackers from the WAN to trawl through the whole IPv6 address space.
I don’t care whether they implement it or not so long as if it is disabled it is completely disabled. Ideally, the user could decide whether to even have the libraries loaded to support it, but that is probably a bridge too far.
Zero trust networking has been discussed for a dozen years or more, but it still isn’t here. I don’t see that changing in the next 5-10 years, but there have been some gains made with NSX and other microsegmentation products. That is definitely where I would like to head, and do on my own network at home, but that is far too difficult to expect most of my friends or family to deal with.
The vulnerable server is the point, but I don’t want one badly written software to impact the overall security of the rest of the environment…
Understood, but if you’re concerned about the security implications of running a server behind your firewall, maybe Plex isn’t really the thing you should be running in the first place (apart from the obvious route of renting a VPS, or putting your Plex server on a VM in a separate DMZ).
Which is precisely what I am doing, running externally reachable services in a DMZ. Anyone running something open to the internet should be a little concerned about running those services. But I think we are running out of productive runway here. Should vendors start to implement PCP in security gear, I am sure they will tighten it up. Enterprise customers will not accept otherwise.
it seems lots of people dont really know how hole punching works. The argument that you give out control to a software that makes swiss cheese of your firewall is just stupid. As certuna pointed out, you usually have your firewall setup like this, that all connections from the LAN can open ports on the WAN anyway. The main advantage with hole punching is, that connections from your LAN to WAN will only be opened to a specific public IP of a client (like a smartphone) in order for it to access the Plex services in your LAN. This is much more secure than creating a manual rule that allows essentially the whole world to access something on your network on port 32400. So essentially you have to trust, that the plex server sort of “connects” clients with your login, to your server. If you say you do not trust plex with this, then just use another software in general for your streaming.
This is much more secure than creating a manual rule that allows essentially the whole world to access something on your network on port 32400.
This is not how most firewalls one residential CPE routers are implemented though, with manual settings you generally only open one port to one IP address, not one port to all.
But yes, your main point stands - it is extremely unlikely that malware inside the LAN will go through the trouble of opening a port to itself to receive incoming connections (which is super easy to detect) rather than just set up an outgoing connection to its control server, which will just blend in with the thousands of other outgoing connections by the dozens of processes on the machine. I don’t think there’s ever been any example in the wild of malware that does that, in 20-plus years of NAT-PMP/PCP.
Then again, I think there’s no direct need for Plex to implement PCP very quickly, as few home routers support it yet for IPv6. It’s just that it’s a logical extension of Plex’s current IPv4 NAT-PMP feature, and will make it ready for single stack IPv6+NAT64 networks.
Well you are talking about the LAN IP. You map a port to one LAN IP, correct. But you do not limit the public source IP that is allowed to access this port on the WAN side. So you open up this port on your public IP to everyone on the Internet, and this is what makes it unsecure.
It’s unclear to me what your issue is here - this is the same for all methods to open or map a port, either manual or via NAT-PMP/PCP, on IPv4 or IPv6.
Unless you specifically add (blacklist/whitelist) source IP address/range filtering to your firewall, you won’t have this functionality. Plex relies on authorization, not IP filtering.
Whitelisting is difficult since your Plex clients might connect from anywhere (at work, mobile network, from home, on holiday), and blacklisting large chunks of the internet (say, blocking all of China/Russia/US) is useless since brute force attackers these days are smart enough to use local botnets or relays.
Of course with IPv6 you make brute forcing a lot harder than with IPv4, since an attacker has to guess which one of the millions of possible IPv6 addresses in your prefix * 64k ports is the one where your Plex server is listening, versus IPv4 where there’s one public IPv4 address with 64k possible mapped ports.
