allow Firewall Hole Punching to increase security!

Feature Suggestions
1

Plex devs, PLEASE add the option for PlexPass users (or all) to be able to utilize TCP/UDP Firewall Hole punching. So that we dont have to open port 32400 (nor any ports) to the entire internet / expose plex to the entire internet (and thus allow access for any known/unknown exploits or vulnerabilities that may exist).
**
This is a really important security gap that needs to be closed (ie the need to expose plex server to the internet is NOT REALLY required). **

Obviously the cloud infrastructure to initiate the 1st connection is already in place (ie my plex )

for a full explanation / background on how this technique works, please see my long post in this thread (or wikipedia TCP hole punching):

https://forums.plex.tv/discussion/76336/plex-security-how-to-avoid-opening-public-port/p2?

(im aware that you can, and SHOULD, change the default 32400 port to something random)

Thank you!
(please vote up, this is important!)

2

So you would trade something you can control and monitor (a single port open) to a third party that can completely control (by compromising software by the same company that you are worried about) your outbound traffic flow???

If this were set up, then the server infrastructure would be a great target for attacks. As a security professional, I would be far more concerned about that reality than exposing my plex port. I know not everyone can, but proper network segmentation is really a good thing.

3

I got news for you… they can already DO THIS… your plex server already maintains a constant connection to Plex Cloud and can respond to commands from plex cloud (how do you think you are able to login to your server from plex.tv). What im proposing would not descrease security in anyway.

You are missing my point entirely. (also exactly what im describing is how Skype, Facetime , CCTV DVRs and many other devices get around NAT wo requiriing users to open ports)

Also what you are describing is nothing compared to the threats posed by having an open port 24/7 , to an actual service that is closed source and responds to any IP that accesses it.

(also i was asking for this to be an optional feature, users can enable if they wish) although it would be better for it to be in use by default.

4

Ok. Whatever, you are right, IoT devices never have security issues, Skype and Facetime have never had issues, and any open port is just a invitation to have your system turned inside out. I’ll just bow out here and feel free to do whatever makes you sleep better at night. Good luck.

5

I do wish plex would respond to this, or add this feature/functionality , at some point soon… It really is a security risk / security issue that should be addressed or at a minimum discussed further here. While drinehart does bring up some points of discussion / thought- im hopeful others will discuss this issue, and further options as well (or add some more points of view).

There arent many scenarios in 2017/2018 where use of a “home-type” of service/app (that is still under active development) requires users to add public facing, open ports. Plex is one of those, so further discussion/thought (and possible better methods to accomplish the same goal) are important and worth having.

In light of the concerns / points drinehart brings up, i still feel, for Plex Server, the use of (by default) OR the additional option of, TCP/UDP hole punching, would be a much more secure method of allowing home server access , than the current method of requiring a port open to the public internet.

(btw, the IP addrss restriction that plex server offers is a good feature, but to be clear it does not address nor mitigate the security threats im referencing, as even if a non plexServer-whitelisted IP address, attempts to access your server IP:port- they still have access to the Server (and can attempt any potential exploits). As the Plex Server side IP whitelist only affects ability to authenticate. Another way of saying this is the plex server IP whitelist is not like a separate firewall IP ACL, ie even a plex-server blacklisted IP address still gets the web “welcome to plex server, enter your login/pass, please” interface").

Some Further replies to drienhart’s points:
1- while a Hole-punch type architecture/setup could make Plex’s server more attractive as a “prize” for hackers looking to leverage services for dDOS types of attacks:

A- Plex would be a much worse type of target for this compared to devices/cloud servers such as; Google Nest, or Dahua CCTV DVRs. As Both of those physical devices + Services use hole punching, but have MANY more end points / potential attack devices. (in drienhart’s example, MANY more devices from which to maliciously “cloud instruct” to send dDOS type attacks FROM. ie # of nest thermostats “in the wild” VS # of plex servers “in the wild”). Also i feel that home users would be much quicker to notice that their plex server was sending out dDOS attacks , versus their Nest thermostat (or other “cloud insturcted” IOT type device in the home)

B- Plex would now be able to respond to any security issues, on their “cloud” end (as it would be an attack on their cloud server , which they can easily monitor and patch). Versus the current model/current scenario of: IF an exploit/vuln IS EVEN disclosed to the public, THEN it is now up to each and every user to update their Plex servers- and in any mean time of not applying update, each and every user is still vulnerable, and easily able to be located ( ie via port scan/masscan 0.0.0.0/0 tcp32400 )

Those points aside (and no disrespect to drienharts) , i really dont feel the issues/threats he brings up are good “reasons against” a hole-punch type system vs the current “client open-port type system.” However there may be good reasons aginst my suggested hole-punch type system, which i why i hope others w sec. backgrounds will discuss here.

Thanks

6

So basically what you’re saying is that it is better to have a single big juicy target that someone can hack into that if penetrated would give them a way into EVERYONE’S networks, versus having a port open and MAYBE you have an unpatched system on the default port that they happen to scan. right.

7

This isn’t ideal but this may be a good alternative:
https://www.zerotier.com/

It’s a p2p vpn that uses udp hole punching and is open source. You can use the bridge feature to accomplish this.

8

I read some of the wiki stuff and don’t fully understand it BUT if it’s like @drinehart comment then heck no. I’m not in favor of this. I am so mad that the companies are responsible for leaking our credit card numbers and personal information.

It really erks me that companies keep such information about us. It’s total BS. What do they say it’s for… “Better Service”? Doesn’t sound that way to me.

9

I kinda can get down with that as you would have to trust their relay servers

10

It’s a bit frustrating that people just say “hell no” without actually knowing how TCP/IP networks actually work, and what firewall hole punching does.

But yes, with consumer internet connections rapidly transitioning from IPv4 -behind-NAT to IPv6-behind-firewall (DS-Lite, etc) we will need firewall holepunching sooner or later, just like we needed NAT portforwarding for current IPv4 setups.

Probably through PCP (Port Control Protocol), but this depends on what protocol your firewall supports.

By the way this request is probably a duplicate of this: Support for PCP (Port Control Protocol, RFC6887) - firewall hole punching