Selfhosted
A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don't control.
Rules:
-
Be civil: we're here to support and learn from one another. Insults won't be tolerated. Flame wars are frowned upon.
-
No spam posting.
-
Posts have to be centered around self-hosting. There are other communities for discussing hardware or home computing. If it's not obvious why your post topic revolves around selfhosting, please include details to make it clear.
-
Don't duplicate the full text of your blog or github here. Just post the link for folks to click.
-
Submission headline should match the article title (don’t cherry-pick information from the title to fit your agenda).
-
No trolling.
-
No low-effort posts. This is subjective and will largely be determined by the community member reports.
Resources:
- selfh.st Newsletter and index of selfhosted software and apps
- awesome-selfhosted software
- awesome-sysadmin resources
- Self-Hosted Podcast from Jupiter Broadcasting
Any issues on the community? Report it using the report flag.
Questions? DM the mods!
view the rest of the comments
Port forward, filter ips, take reasonable precautions on the trust of networks.
It's not rocket science, as you mentioned in your other vitriol.
I think you don't understand the nature of the exploit.
Anybody who can see the Jellyfin login page can use the Jellyfin server's permissions to play media directly from your media library.
Port forwarding doesn't matter. Jellyfin hosts on port 80/443 which you have to allow for the service to function. Most clients are on dynamic IPs or CGNATs so unless you're going to manually change the IP filter for every single user every few days, IP filters are not a reasonable solution.
'Take reasonable precautions on the trust of networks' doesn't even make sense. Your Jellyfin server is either available to the Internet or not available to the Internet. If you choose not to trust the Internet (the actual mitigation) then you obtain access to your Jellyfin server through a VPN.
No, I understand the nature of the unencrypted transport. I understand that the credentials are exchanged unencrypted (although the passwd isnt in plaintext, even on jellyfin). I also understand what is on the trusted network, my kid's subnet.
The mitigations are the following:
Correct, that's the idea and that's why the IP is filtered. When my kid's IP changes, his PC posts a notice to me about it, and I change the the fw rule. This happens once a year on average.
Also correct, it is available to the internet, which from jellyfin's point of view is one single /32.
There is a body of suggested action to take in the interest of security that is repeated here and in other self-hosted spaces, and what you're saying is valid and sound advice. I want to acknowledge that I don't take your comment as wrong, it's very prudent for someone just getting into managing their own stuff.
However, security is my job, and I do take it seriously. And there are more ways than one to get it done.
I keep my data back ends on encrypted channels, backups on another, and I control very tightly what has access to everything else. The model I use is something like "zero trust", where I assume the clients even on my own network are malicious. In that context, extending my lan to a single remote lan on a single port isn't really much different than allowing an iot device I don't trust on my actual lan; it sees no other hosts but a gateway and whatever my acls allow it to.
So in the end, what can a device do at large on the internet to my jellyfin "network"? Nothing. What can a pwned device do on my kid's network with jellyfin? It can watch TV and movies, because the api calls from jellyfin clients to jellyfin front end are nondestructive.
I work in security as well.
If you only have a single user that accesses via a single static IP then it isn't much of an issue to manually maintain an IP whitelist.
Allowing access to multiple users across many different networks, means that you're going to have to deal with their IP changing frequently often multiple times per day. You'd have to be available full-time to update your whitelist if done manually.
If you're going to run software on those machines to check for their public IP and report it to you (or a script you run) in order to update your firewall's whitelist then you could just as easily (or, I'd argue, more easily) run a Tailscale client on their machine and only give them access to Jellyfin via Tailscale's ACL.
I just mean that you can't simply put Jellyfin behind a reverse proxy and alter some port forwarding rules to protect against the argument injection vulnerability, since it executes the ffmpeg command as the Jellyfin's service account so it would have access to any file that that account could access (which should be limited to the container, but some people run it bare metal still).
Using a VPN is just easier to deal with, to me, than trying to allow any access from Internet IPs. The firewall can simply block everything from the Internet that isn't VPN traffic. This is especially true if you control all of the devices that will be connecting to your network.
All of my traffic, even LAN traffic, is on one VPN or another. Everything is done 'locally' on the VPNs regardless of where the device is located.
I think we're arguing two sides of the same coin.
What? How is port forwarding adding anything to security? How does blocking IP ranges help prevent attacks on the unsecured backend?