[FIX] PMS leveraged for amplified dDoS attack (SSDP)

Plex Media Server
41

I am attempted to say “yes”, but let’s wait for the results of the internal investigation.

1 Like
43

Plex Media servers are being abused for DDoS attacks | ZDNet

The problem comes when a Plex Media Server discovers a local router that has SSDP support enabled. When this happens, the Plex Media Server will add a NAT forwarding rule to the router, exposing its Plex Media SSDP (PMSSDP) service directly on the internet on UDP port 32414.

Since the SSDP protocol has been known for years to be a perfect vector to amplify the size of a DDoS attack, this makes Plex Media servers a juicy and untapped source of DDoS bots for DDoS-for-hire operations.

Netscout says that attackers only have to scan the internet for devices with this port enabled, and then abuse them to amplify web traffic they send to a DDoS attack victim.

Based on this article it would appear that if your UDP port 32414 is closed, then you should be okay.

…but I’m no expert.

45

The verdict is in:

2 Likes
49

Docker has zero influence on the matter, if your server is running inside a private network (and you haven’t exposed it either via DMZ).
Because the relevant firewall then is in your router. And Docker cannot override this.
Just make sure that your port forwarding rule is only forwarding the main “plex port” to your server machine. And only TCP packets.

If your server is in a data center, with its network port connected to the internet,
or it is indeed an “exposed host” due to DMZ, then you’ll have to investigate further.

I am not a Linux, nor a Docker expert, so I’d like to forward this question to someone knowledgeable. @ChuckPa perhaps.

50

Nearly useless, as your Internet IP is being port scanned multiple times a day by bad actors who can easily find that port. Just make sure you are only forwarding TCP and not UDP as well.

52

As stated by Otto,

  1. TCP-only port forwarding.
  2. TCP-only firewall rules

Additionally:

  1. HTTPS - required connections. (lock it down)

If you have NO ports open to the outside world , use Plex Relay (at most), there is nothing to fear.

Get a good firewall.

You want one which DROPs unsolicited traffic.

DENIED messages still tell them you exist. PfSense is one such example of “drop”.

The goal: Make like a hole in the internet (you don’t exist).

2 Likes
54

Good read. Thank you.

So, where’s the fault?

UFW?
Docker?
Plex?

Am I reading that correctly in that Plex was the victim here because of a combinatorial vulnerability in the Docker+UFW pair?

55

According to this I have no worries as I meet NONE of conditions that would worry me:

Am I affected?

The vast majority of Plex Media Server setups are not exposed or affected by this. It specifically requires that either:

  1. the entire device running Plex Media Server be exposed to the public internet (such as one hosted in a data center or the computer being placed in the public “DMZ” of the network router), or
  2. the server administrator has explicitly forwarded UDP traffic on an applicable port from the public internet to the device running Plex Media Server.

Neither of these configurations are typical for normal users. Only a very small portion of Plex Media Server instances will be potentially affected by this.

Therefore - I am not worried.

59

Where did you get this information?

60

I edited my post to contain this Pinned Forum Announcement:

1 Like
61

That having been said,

  • Presume Plex in docker is vulnerable – IF – UDP is accessible from WAN.
  • Plex does use UDP for discovery on the RFC-1918 subnet the server is on.
  • Whose fault is that for opening up UDP ports and forwarding them?

Where I’m going with this is: Whose responsibility is it for site security?

(Yes, I will get flamed)

3 Likes
62

There will be a greater general understanding and agreement over time that users must become educated about network security and take full responsibility for everything they implement.

This hasn’t even fully penetrated the enterprise space yet, though they’ve come a long way. Home users will take even longer.

1 Like
63

I agree with @ChuckPa’s comment that the admin is responsible for site security.

But I’m curious about your comments here, because your reaction isn’t unique. It seems like naked VPS has become popular despite the risks. (Recommendation: don’t use naked hosting.)

Did you expect the Plex Docker image to behave differently?
Or that Docker would provide network security?
Or that UFW would behave differently?
Or that a network-level firewall was present?

I don’t think Plex should provide a security primer in the Docker image README, but sometimes Beware, dragons! is a nice warning.

1 Like
64

Not true at all. It was a small percentage of hackers that knew this existed. Now they all know it exists and how easy it is to exploit. I can do it and I’m not THAT competent.
They could’ve given PLEX a heads up. It’s the correct procedure. No warning at all? Garbage.

3 Likes
65

I agree with @ChuckPa’s sentiment as well; the server admin is ultimately responsible for its security.

With regard to the Docker/bridged network/naked hosting case, the problematic traffic can be dropped with an appropriate iptables rule. Appropriate here means inserted into the FORWARD chain before the Docker rules. Something like the following works:
iptables -I FORWARD 1 -p udp --dport 32414 -j DROP

[Edit to add]
Even better, add the rules to the DOCKER-USER chain.
iptables -A DOCKER_USER -p udp --dport 32414 -j DROP

1 Like
66

My thoughts on a VPS:

  1. If one is going to purchase one, one must understand (as in – REALLY UNDERSTAND) the security requirements associated with successfully operating what has been leased from the provider. Be fully aware of the tools provided by the vendor in their product offering – BUYER BEWARE!

  2. Folks get Linux “because it’s faster” but don’t have the slightest clue how to effectively & properly administer the OS. (ref: Look at how many threads are here in the forum trying to set things up on the home LANs)

  3. When folks lease that Public-facing VPS, without any protection other than those which are innate to the OS itself and possibly apps loaded by the vendor, their lack of basic TCP/IP networking and firewall fundamentals, is what creates the risk. The OS itself is fundamentally secure and can be further tightened down. Look at the Enterprise world. Is that Linux kernel any different than what anyone else uses?

  4. It makes NO DIFFERENCE whether you have the native PMS app or Docker loaded in HOST / BRIDGE mode – Both forms of PMS are 100% dependent on the host… The container is nothing more than a chroot() abstraction at this point. When used in NAT mode, it does nothing more than abstract the network stack one layer (which is impractical for PMS use without "port forwarding through the Docker NAT layer … :thinking: )

Per the question of what do I expect?

Remember the stacking: PMS → Docker container → UFW → Linux network stack → Kernel.

  1. Docker is the container mechanism. It has NO business, nor would I ever expect it to address security in ANY FORM. (does your dentist change your car oil?)

  2. PMS on Linux host versus in a container (LXC -or-Docker) , I expect no change.

  3. I expect the additional layer as “one more thing” which can go wrong and be misconfigured ( Complexity invites oversights & vulnerabilities )

  4. UFW should be doing its job – without fail – at the HOST network stack level. IMHO, This issue demonstrates some fundamental issues:
    a. UFW is (qualified) vulnerable as it pertains to protecting Docker containers.
    b. Users do not understand what they’re doing .
    c. “Youtube Experts” provide base knowledge / how-to’s but those are not 100% guaranteed for all uses and, as such “BUYER BEWARE”. IE: What works for them is not likely to work for you unlesss your home LAN and operational topology is a 100% match in all regards (hardware, software, net config, gateway devices, etc).

Now, if I may share my personal thoughts?

  1. Folks loaded linux. – conscious decision. Linux isn’t the default OS on any machines

  2. Linux has a steep learning curve. (it took me 10 years before becoming really comfortable with all of it and I still learn new things because it’s contantly changing)

  3. (My most sincere apologies as I’m about to offend) Folks were uninformed / uneducated / foolish and , in most cases, just went and and “opened the barn door”. What where they expecting?

  4. Everyone here will hopefully know how much I’m willing to educate & help by now. I will always make the time to help with this type thing if/when asked.

6 Likes
67

LOL Damn ChuckPA this issue got to you. :face_with_raised_eyebrow:

68

No. Not at all. I thought a “from the heart” was requested, so I gave one.

If not, I will gladly remove.

:man_facepalming: :gun:

:rofl:

4 Likes
69

I think you are spot on, please leave it :slight_smile:

70

Thanks, Nice to know 40 years of doing this in far more security-demanding environments than Plex didn’t go to waste

3 Likes