Hello,
I’m looking for some help understanding how an apparently unauthorized user is able to stream content from my publicly available plex media server. I’m not sure which forum is the correct forum for support related questions…
The details are as follows:
-plex media server is publicly available
-windows PMS build 1.1.4.2757 (admittedly and out of date build, but I don’t like the interface changes introduced soon after this version)
-the only network allowed to login without auth is manually set to 127.0.0.1
-I have reset account passwords, but the unauthorized user jumps back on the same account instantly
-I have manually deleted the connecting device(s) in question (always a Roku Express) but the user reconnects instantly
-whenever I manually block the user’s IP via my network gear, they simply change IP’s
-I’ve even logged them allegedly connecting via 127.0.0.1 once when I started blocking entire subnets
-I’ve removed the accounts in question and they simply move to another account
Has anyone seen this? This has been going on for ~2 years off and on. I’ve searched extensively on the forums for a similar issue and have troubleshooted based off any somewhat similar issues I’ve seen here. I’ve never found the exact issue listed however.
Are you using a custom domain name for your plex server?
Did you set up a reverse proxy?
I surmise the above two will for sure play a role in your issue.
Update your server software!
Server updates don’t only contain interface changes, but also from time to time security-relevant fixes.
The minimum required and supported server version is 1.5.1
Indeed I am using a custom domain name. I am not using a reverse proxy for PMS - although I do use a reverse proxy for other sites running on the same windows server. For PMS however, I enabled SSL connections only and setup a redirect on TCP ports 80 and 443 straight to PMS on TCP 32400.
I absolutely understand the requirement for updates and will update. I just really don’t like the newer interface (like, really dislike it a lot). If I could find some documentation of the issue at hand and see that a fix is applied I guess that would outweigh my dislike of the new interface. Currently though I’m a little hesitant to upgrade and find that the issue persists.
I suspect there is a setting that I either mis-configured or was not properly hardened by default. I was hoping someone would be familiar with this issue already.
@“justin@tokyothunder.com” said:
For PMS however, I enabled SSL connections only and setup a redirect on TCP ports 80 and 443 straight to PMS on TCP 32400.
Why 2 ports? Plex uses only 1.
Currently though I’m a little hesitant to upgrade and find that the issue persists.
How about setting up a VM and doing a test-installation?
It gives the freedom to tinker before doing the big upgrade.
Why 2 ports? Plex uses only 1.
Because end users need to be able to just enter the raw “www.domain.com” into the browser, which is a call to TCP 80 (http), AND end users need to be able to enter “https://www.domain.com” into the browser, which is a call to TCP 443 (https). No matter how the end user enters the domain into their browser they end up at the same place.
How about setting up a VM and doing a test-installation?
It gives the freedom to tinker before doing the big upgrade.
That’s fine, and I’ve already done that to test the latest versions many times. The problem is I need to make it live for the unauthorized user(s) to connect.
Are you asking me to share the details with you or just offering the logs as a place for myself to start?
I do have the logs of several occurrences, albeit with verbose enabled. I’ve disabled verbose and will grab the log the next time it occurs, probably later today or tomorrow. This is how I was able to begin understanding the issue in the first place, including the time I saw them connect via 127.0.0.1.
It seems to me they are simply spoofing bogus IP’s because when it started their IP’s were in Bulgaria or something. After I started blocking entire countries they eventually began selecting IP’s geographically closer and closer to my server culminating in apparently spoofing 127.0.0.1 itself. Funny thing is, they have excellent taste in media!
I spent a long time last night reviewing PMS changelogs and I just can’t get onboard with either Plex Web 3.0+ or many of the PMS 1.5+ changes. I understand this means I am unsupported so I won’t push the issue further. I just hoped someone already knew of an issue like this and could instruct me how to investigate further or reference a changelog that demonstrates a known issue and resolution–and maybe that’s what you’ve done with the security-related fix above. I’ll review it.
Thanks again.
@“justin@tokyothunder.com” said:
Are you asking me to share the details with you or just offering the logs as a place for myself to start?
I was merely giving you a hint where to start looking.
But apparently you have done that already.
It seems to me they are simply spoofing bogus IP’s because when it started their IP’s were in Bulgaria or something. After I started blocking entire countries they eventually began selecting IP’s geographically closer and closer to my server culminating in apparently spoofing 127.0.0.1 itself. Funny thing is, they have excellent taste in media!
And you are sure this was not one of your sharees, utilizing a Relay connection?
It could also be that one of your sharees has leaked one of his authentication tokens, for instance by using a compromised computer/wifi hotspot or by publicly posting a full URL from a plex web page.
I don’t find either scenario likely given that the user seems to effortlessly move across different users. I have verified at the time of the unauthorized connections that the users in question were not streaming anything and I know they didn’t share the passwords with anyone because the unauthorized access continued after I changed their passwords without telling them.
Changing passwords will not necessarily invalidate tokens which have already been created.
For this to happen, there is this checkbox to tick during the password change:
(but doing so will of course also require all client devices to get re-linked with the account)
