Plex listening on 54749

server-linux

#1

I'm running Plex Media Server on Ubuntu 18.04. Plex listens on the port 54749, but I cannot find any information about what purpose this port has. The service is functioning fine, and I'm currently blocking the port with iptables.

What does plex use port 54749 for, and is there any place I can find information regarding ports for plex?


#2

Probably one of these two:

forums.plex.tv/discussion/254480/loads-of-upnp-traffic-on-internal-network-with-v1-3-3

forums.plex.tv/discussion/254611/what-is-plex-listening-for-on-udp-port-36004

Cheers.


#3

Logs please ?

Plex does not use / listen on such an odd port unless it's communicating directly with a client (player).

All the ports PMS users are:

https://support.plex.tv/articles/201543147-what-network-ports-do-i-need-to-allow-through-my-firewall/

With addition of 32401 for internal communication only


#4

@ChuckPA said:
Plex does not use / listen on such an odd port unless it's communicating directly with a client (player).

Looks suspiciously like my thread above, which was never really answered.

And even today, there's still something listening on my internet facing IP:

[root@Nethserver ~]# netstat -tupln | grep Plex
tcp        0      0 127.0.0.1:39724         0.0.0.0:*               LISTEN      25673/Plex Plug-in
tcp        0      0 0.0.0.0:32400           0.0.0.0:*               LISTEN      25090/Plex Media Se
tcp        0      0 127.0.0.1:32401         0.0.0.0:*               LISTEN      25090/Plex Media Se
tcp        0      0 0.0.0.0:33400           0.0.0.0:*               LISTEN      25673/Plex Plug-in
tcp        0      0 127.0.0.1:32600         0.0.0.0:*               LISTEN      25172/Plex Tuner Se
tcp        0      0 127.0.0.1:37534         0.0.0.0:*               LISTEN      25109/Plex Plug-in
tcp        0      0 0.0.0.0:33443           0.0.0.0:*               LISTEN      25673/Plex Plug-in
udp        0      0 0.0.0.0:1901            0.0.0.0:*                           25090/Plex Media Se
udp        0      0 0.0.0.0:36598           0.0.0.0:*                           25172/Plex Tuner Se
udp        0      0 76.xxx.194.xxx:38657    0.0.0.0:*                           25090/Plex Media Se
udp        0      0 192.168.0.254:50101     0.0.0.0:*                           25090/Plex Media Se
[root@Nethserver ~]#

Cheers.


#5

Are either of you using Webhooks, e.g Alexia or other device ?


#6

@ChuckPA said:
Are either of you using Webhooks, e.g Alexia or other device ?

Nope.

Cheers.


#7

Plug-ins?

I've searched through the entire source. There is nothing even close.
The only thing I find with those numbers involved are Postal Codes.
Ring a bell perhaps?


#8

Two comments:

This is a UDP socket, so I'm not sure where Webhooks might be involved, as I'm guessing that it would be TCP.

The reason for not finding the port, I'd guess, is that this would be the reply port set up dynamically when sending out a request to a well-know port at the remote end, with the information "please reply here". Just like many other client/server implementations do. Hence my original report using 36004, and now 50101.

Cheers.


#9

Ok.. we did the deep-dive in the code.

We're all seeing the SSDP layer doing its thing. It sends to the Plex multicast group (on the LAN) and listens on the fixed ports. Concurrently, SSDP does its thing. Sends out some random port and awaits UDP replies. If watched long enough, it will change on you. It's nothing more than the SSDP / GDM layers doing their thing.

It looks like they changed a few things in there. We will make some time to wireshark it properly and confirm 100% but at this point, it's nothing nefarious other than Server -> Device discovery waiting for the device to reply back.


#10

Except that the listening port is on the public-facing WAN interface, not on the internal LAN.

Cheers.


#11

Show me the evidence please.

Show me how that port is open on your WAN interface and vulnerable to the world


#12

Wait. Show me where anyone said it was vulnerable. Today it (probably) isn't, but can you put your hand on your heart and say that there will NEVER be a security vulnerability found in that protocol, or indeed any other protocols that are exposed by Plex. It's all about mitigating surface exposure, which actually Plex does a very poor job of:

From my multi-interface server. One interface to the internet, the other my internal LAN:

netstat -tupln | grep Plex
tcp        0      0 127.0.0.1:43463         0.0.0.0:*               LISTEN      29985/Plex Plug-in
tcp        0      0 127.0.0.1:45520         0.0.0.0:*               LISTEN      30080/Plex Plug-in
tcp        0      0 0.0.0.0:32400           0.0.0.0:*               LISTEN      29199/Plex Media Se
tcp        0      0 127.0.0.1:32401         0.0.0.0:*               LISTEN      29199/Plex Media Se
tcp        0      0 0.0.0.0:33400           0.0.0.0:*               LISTEN      30010/Plex Plug-in
tcp        0      0 127.0.0.1:32600         0.0.0.0:*               LISTEN      29280/Plex Tuner Se
tcp        0      0 127.0.0.1:40569         0.0.0.0:*               LISTEN      30144/Plex Plug-in
tcp        0      0 127.0.0.1:34394         0.0.0.0:*               LISTEN      30010/Plex Plug-in
tcp        0      0 127.0.0.1:39706         0.0.0.0:*               LISTEN      30077/Plex Plug-in
tcp        0      0 127.0.0.1:39835         0.0.0.0:*               LISTEN      29219/Plex Plug-in
tcp        0      0 127.0.0.1:46719         0.0.0.0:*               LISTEN      30121/Plex Plug-in
tcp        0      0 0.0.0.0:33443           0.0.0.0:*               LISTEN      30010/Plex Plug-in
tcp        0      0 127.0.0.1:34820         0.0.0.0:*               LISTEN      30038/Plex Plug-in
udp        0      0 0.0.0.0:1901            0.0.0.0:*                           29199/Plex Media Se
udp        0      0 76.xx.194.xxx:43435     0.0.0.0:*                           29199/Plex Media Se
udp        0      0 192.168.0.254:37895     0.0.0.0:*                           29199/Plex Media Se
udp        0      0 0.0.0.0:39442           0.0.0.0:*                           29280/Plex Tuner Se

See how many of those listening ports are exposed to the external interface. I count 6. 1 of them is a non-Plex provided plug-in, which leaves 5 possible exposures from the base product. 1 explicitly, which cannot hear any responses that would be sent to it, because it's listening on the wrong interface, and 4 implicitly, of which only 1 should be listening to the outside world. The count is so low, because I have shut down as many of the services within Plex that I can, but it still causes the other systems in my LAN to bombard it back with thousands of UPnP responses. Otherwise that number would be closer to 9.

OK, most people are running some sort of firewall that should be blocking any attempt to connect to those ports, but that's no reason for Plex to ignore the fact that they should be limiting the exposure that the product has and not assuming that all it's users are tech savvy enough to do so.

Cheers.


#13

I'm not trying to be adversarial in any way. I am trying to make and then prove what is happening.
What we do here is what Engineering will require I prove to them. (Steps To Reproduce )

Does this occur immediately after startup? If it does, (important) with the system not playing any media to anyone,

  1. Let it come up and sit there.
  2. When you see the ports open, capture this output again as above -and-
  3. Get the Full set of debug logs. (ZIP) file and attach (or PM to me with a link to this thread for my sanity sake :) )

Also please include any lan configuration information: vlan? multiple subnet? DMZ ? VPN? etc.

This is a 'Get the Smoking Gun' type thing we need to do.


#14

Snapshot taken 10 seconds after Plex was started:

[root@Nethserver ~]# netstat -tupln | grep Plex
tcp        2      0 0.0.0.0:32400           0.0.0.0:*               LISTEN      28815/Plex Media Se
tcp        0      0 127.0.0.1:32401         0.0.0.0:*               LISTEN      28815/Plex Media Se
tcp        0      0 127.0.0.1:32600         0.0.0.0:*               LISTEN      28914/Plex Tuner Se
tcp        0      0 127.0.0.1:45476         0.0.0.0:*               LISTEN      28836/Plex Plug-in
udp        0      0 0.0.0.0:42401           0.0.0.0:*                           28914/Plex Tuner Se
udp        0      0 0.0.0.0:34629           0.0.0.0:*                           28914/Plex Tuner Se
udp        0      0 0.0.0.0:1901            0.0.0.0:*                           28815/Plex Media Se
udp        0      0 0.0.0.0:59525           0.0.0.0:*                           28914/Plex Tuner Se
udp        0      0 0.0.0.0:35094           0.0.0.0:*                           28815/Plex Media Se
udp        0      0 0.0.0.0:53822           0.0.0.0:*                           28914/Plex Tuner Se
udp        0      0 76.xx.194.xxx:37857     0.0.0.0:*                           28815/Plex Media Se
udp        0      0 0.0.0.0:54900           0.0.0.0:*                           28815/Plex Media Se
udp        0      0 0.0.0.0:56723           0.0.0.0:*                           28914/Plex Tuner Se
udp        0      0 192.168.0.254:57168     0.0.0.0:*                           28815/Plex Media Se
udp        0      0 0.0.0.0:33140           0.0.0.0:*                           28914/Plex Tuner Se
[root@Nethserver ~]#

Also attached the logs.

Looking at them, it's this UPnP traffic that's being listened for, as it looks like it starts a listener on each interface it finds. How do I shut this off on all interfaces.

Cheers.


#15

1 You have en0 configured directly on a WAN address

May 09, 2018 11:09:56.514 [0x7fec07bff700] DEBUG - NetworkInterface: Watching for changes on the interfaces.
May 09, 2018 11:09:56.514 [0x7fec25c58840] DEBUG - Network interfaces:
May 09, 2018 11:09:56.514 [0x7fec25c58840] DEBUG - * 1 lo (127.0.0.1) (loopback: 1)
May 09, 2018 11:09:56.514 [0x7fec25c58840] DEBUG - * 3 eno1 (7X.XX.XXX.242) (loopback: 0)
May 09, 2018 11:09:56.515 [0x7fec25c58840] DEBUG - * 4 br0 (192.168.0.254) (loopback: 0)
May 09, 2018 11:09:56.515 [0x7fec25c58840] DEBUG - Creating NetworkServices singleton.

2 Settings - Server - Network - Turn off GDM (Discovery)

If this machine is in a DataCenter, A. UDP won't get past the routers B. There are no firewall ports open (unless your firewall is disabled, even if you leave discovery ON.

If it's at home, I suggest you reconfigure the network and put WAN on the other side of a NAT device. Again, UDP does not pass due to the router functions in a NAT device.


#16

Point 1: Correct, as it’s my internet gateway.

Point 2: It’s already off:

So how do I stop the listeners being created and having to keep updating an internal firewall rule to stop it logging thousands of replies generated in my internal network replying back to Plex.

My concern isn’t about the UPnP broadcast looking for devices, as you point out, that isn’t routable. However, a port scan, inbound would find an open port (if it wasn’t blocked by a firewall). Well, actually would find 6 open ports, which at some point in the future could be found to have security vulnerabilities. Like I said, it’s all about reducing exposure and having ports open on all interfaces. Which goes back to a long standing request from many, many, folks on this forum. Provide a way to say which interfaces, in a multi-interface machine, are used by Plex for which functions. There should be a definitive separation between the services which are internal to the LAN and which have a legitimate need to connect to the WAN.

Cheers.


#17

Respectfully, You put your PMS as your network gateway. What do you expect?
If the firewall is running, portscans are immaterial


#18

@ChuckPA said:
Respectfully, You put your PMS as your network gateway. What do you expect?
If the firewall is running, portscans are immaterial

That's sidestepping the issue.

Why are those ports still open when GDM is off.

And equally respectfully, can you point me at the FAQ or article that warns people running Windows ICS on a machine connected directly to the internet that they should NOT run Plex. >:)

Cheers.


#19

Do you want me to say that PMS is intended for home use, behind a NAT router where the LAN is generally open and the NATPMP/UPnP listeners can safely sit there without security concern? Then Yes. that's how it's implemented.


#20

Do you really want to know how I loosely interpret that last comment:

It's the users responsibility to protect themselves from the security holes we may have in our product.

</sarcasm>

Have you ever been through a full network security audit.

</EOM>

Cheers.