is this someone trying to inflate their importance by reporting old news?
I agree with this entire post. If itās easy, people will use it.
Itās not like a car, handgun, or nuclear bomb. It doesnāt need to be licensed or dumbed down.
As much as possible, itās nice to have clear safety indicators. Make it easier to use correctly than incorrectly.
But mostly, caveat emptor. Tools can sometimes cut you.
Docker should be licensed. āDocker training class / driving test ā PASSEDā
1 Like
Thatās what I get for taking a few minutes to myself 
Iām back now
I support your comments that this has been out in the wild for a long time. Iām personally comfortable with immediate disclosure for this type of amplification issue - it can be perfectly mitigated by correct firewall rules, and doesnāt require waiting for updated software.
I donāt think thereās any reason to believe this statement from that article:
ā¦ since Plex has stated that a fixed version is still to-be-forthcoming.
That sounds like a misunderstanding/guess/bad assumption in the article, to me.
Agreed on the bad guess / doesnāt understand the subject / faux epert
1 Like
Sorry folks. I wasnāt quick enough. Iāve addressed the issue.
2 Likes
As far as Iām concerned, after ChuckPA worked with me for weeks getting the music scanner upgraded to contend with MASSIVE music libraries, he can do no wrong regardless of the topic. 
1 Like
I think what I was trying to state yesterday got somewhat misconstrued with the back and forth.
My $0.02, even though UFW is ineffective in restricting Docker opened ports, with a few minor modifications to the docker config, it should be easy to strict what ports are publicly exposed using Docker, for those running a Plex Media Server via Docker at a data center.
I.e., Restricting all of the ports except 32400 to the localhost using a bridged Docker config.
docker run \
-d \
--name plex \
-p 32400:32400/tcp \
-p 127.0.0.1:3005:3005/tcp \
-p 127.0.0.1:8324:8324/tcp \
-p 127.0.0.1:32469:32469/tcp \
-p 127.0.0.1:1900:1900/udp \
-p 127.0.0.1:32410:32410/udp \
-p 127.0.0.1:32412:32412/udp \
-p 127.0.0.1:32413:32413/udp \
-p 127.0.0.1:32414:32414/udp \
-e TZ="<timezone>" \
-e PLEX_CLAIM="<claimToken>" \
-e ADVERTISE_IP="http://<hostIPAddress>:32400/" \
-h <HOSTNAME> \
-v <path/to/plex/database>:/config \
-v <path/to/transcode/temp>:/transcode \
-v <path/to/media>:/data \
plexinc/pms-docker
Or using docker-compose bridged networking yml, with all ports except 32400 restricted to the localhost.
version: '2'
services:
plex:
container_name: plex
image: plexinc/pms-docker
restart: unless-stopped
ports:
- 32400:32400/tcp
- 127.0.0.1:3005:3005/tcp
- 127.0.0.1:8324:8324/tcp
- 127.0.0.1:32469:32469/tcp
- 127.0.0.1:1900:1900/udp
- 127.0.0.1:32410:32410/udp
- 127.0.0.1:32412:32412/udp
- 127.0.0.1:32413:32413/udp
- 127.0.0.1:32414:32414/udp
environment:
- TZ=<timezone>
- PLEX_CLAIM=<claimToken>
- ADVERTISE_IP=http://<hostIPAddress>:32400/
hostname: <hostname>
volumes:
- <path/to/plex/database>:/config
- <path/to/transcode/temp>:/transcode
- <path/to/media>:/data
In my personal opinion, this info should be in either the readme or at least as a secondary template in the Plex Server Docker repo. For anyone using Docker bridged networking at a data center, these config changes would mitigate the current vulnerability and limit exposure to additional vulnerabilities in the future.
In the described ānakedā Docker hosting scenario, I donāt think itās necessary to publish those other ports to localhost at all.
A simpler option is to not publish them at all, if itās not a LAN deployment.
A simpler option is to not publish them at all, if itās not a LAN deployment.
No disagreement here, on a base level. The way I first learned of the issue of the unexpected behavior of UFW when using Docker was when I was trying to reverse proxy a website front end and route it through Cloudflare. Only later did I learn that the website I thought was secured/hidden via Cloudflare and UFW restricting connection to only Cloudflare IPs was still publicly exposed to the internet on the serverās public IP and Docker port.
The solution of binding all Docker ports to the host is a solution that can also restrict port 32400 traffic to the host for those using Cloudflare, Incapsula, or even just a host reverse proxy to prevent direct access to port 32400.
I posted one āsolutionā that could be used generically, instead of going through different scenarios, allowing the server admin to decide which ports should be exposed outside of the machine running Plex.
1 Like
This is not completly true though, some clients like the android tv client wont go local unless plex is configured to accept inauthenticated traffic from your local ip subnet.
I have a pihole and unifi network and if i take out that setting in plex the tv will go over the plex.tv route instead of locally it is visable in plex dashbord then as wel that the client sony barvia android tv is vooming in over the remote bandwith instead of the local one.
My plex server is on an esxi host server vm with w10 witch is connted to a unifi 8 port poe switch witch is connected to a 3p usg and all managed to a unifi controller running on my internal network the local lan is set to use the inifi controller as 1st dns second is the usg witch has the wan line
Which setting are you referring to?
There are 2 setting in the network settingings where you can list networks for LAN
LAN Networks
And
List of IPAdesses without authentication
Sorry i am on a dutch system so it shows those options in dutch.
These settings donāt have any connection with the topic of this thread.
i meerly pointed out that its wasnt trough that all clients go local automaticly and gave the resolution to that with the pointing.
i know there is a fix for this issue keeping pms updated to newest and indeed not setting things trough UPNP will help allot.
If your server is not connected directly to the open internet, there is 0 need for a fix. Even the UPnP request of Plex doesnāt create a forwarding of the UDP port in question.
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.
