Round Two: Can I manage to set up Jellyfin correctly this time?
from compostgoblin@lemmy.blahaj.zone to selfhosted@lemmy.world on 12 Aug 20:03
https://lemmy.blahaj.zone/post/30248098
from compostgoblin@lemmy.blahaj.zone to selfhosted@lemmy.world on 12 Aug 20:03
https://lemmy.blahaj.zone/post/30248098
Hi y’all, thanks for the help with my question yesterday. I did a bit of homework, and I think I’ve got things figured out. Here’s my revised plan:
-
configure a cron job to update DuckDNS with my IP address every 5 minutes
-
use ufw to block all incoming traffic, except to ports 80 and 443, to allow incoming traffic to reach Caddy
-
configure the Caddyfile to direct traffic from my DuckDNS subdomain to Jellyfin’s port
Does this seem right this time? Am I missing anything, or unnecessarily adding steps? Thanks in advance, I’ll get the hang of all this someday!
#selfhosted
threaded - newest
If it’s for your personal use and no one else is going to connect, why don’t you just configure a wireguard tunnel to remotely connect to your server as if you were in LAN without exposing anything?
I’d like to be able to share it with friends and family
Tailscale allows you to do the same except you can create keys with limited access to only certain ports (just in case you don’t want them peeking around your server).
Tailscale has the Funnel feature too, which puts the endpoint on Tailscale’s servers.
You could do both - Funnel for people who you don’t want to walk through setting up a client, and use the client for those who you’re willing to put the effort into.
My preference would be to avoid Tailscale, but I’ll check it out. Thanks!
I second this for the funnel feature
It made my whole issue with ports easy since it forwards only one open port
I still don’t recommend putting jellyfin on the Internet. It’s not designed for it. There are some API endpoints you can access without authentication, not to mention potential authentication bypass vulnerabilities.
5 minutes is also probably too frequent. Leases are usually significantly longer. You might hit a rate limit and get blocked.
Thanks for the tip! I’ll back the refresh rate off to be safe.
I’m not sure I entirely understand your concern about putting Jellyfin on the internet. A large part of my interest in selfhosting is being able host my own music library, my own cloud storage, etc, and access it as an alternative to Spotify or Google Drive. Doesn’t that inherently mean that they need to be on the internet, if I want to be able to access them when I’m away from home?
My goal has been to find a way to do that safely, but if that’s not possible, that’s good to know too, so I don’t keep trying to do the impossible.
Wireguard or tailscale are much better ways of accessing jellyfin from outside your network.
What if I want a bunch of people to be able to log into my library via Finamp?
You use plex instead, or you accept the massive security vulnerabilities.
Provide them with VPN access. If that’s too much for them, then they don’t get access. Tough. On the scale of security vs convenience, that’s nothing.
If you really really want, you should at least see if you can put a WAF in front, and put the server itself somewhere it doesn’t have access to the rest of your network (a DMZ) so that if and when it gets hacked, it doesn’t compromise the entire network.
I highly recommend Tailscale, you can share machines/services with unlimited friends on the free tier, and all of the actual auth stuff is handled by someone who isn’t me.
I use Nginx Proxy Manager and whitelist my remote users. They all have static IPs though, so its a workable solution for me.
Before I used a whitelist I would go through the access logs, and could never find any attempts to exploit the endpoints - only some random bots trying to find some admin page assuming it was another service. Not saying you shouldn’t take it seriously, but you are likely not subject to these attacks the moment you expose it.
That said, there is a discussion about these endpoints on their repo. At some point they will be fixed (my impression is that they are hampered by legacy Emby code). When they do, you could do this more securely.
It’s honestly just a matter of how much risk you are comfortable with for using jellyfin on the open internet.
(If i remember correctly:) The unauthenticated routes thing can only be used for streaming your content without a login (if you can guess the contents ids on your server I believe).
In my opinion, it’s not worth the hassle of using a vpn because I don’t think this risk is worth mitigating with one.
But everyone has their own personal risk assesment of course.
P.s. Easier than a VPN, at least for logging in other users, would be to use some type of proxy authentication like Authelia. I believe jellyfin has a plugin you can use. It can be complicated to setup, but it’s an option. I believe it should protect all routes exposed by jellyfin so that solves the unauthenticated streaming issue. (I still dont think this is necessary but more choice for the risk-adverse!).
github.com/authelia/authelia
Yes, those are the known vulnerabilities. We don’t know how many unknown vulnerabilities could be discovered in the future.
Unfortunately no software exists that is fully perfect in this regard (any program could have multiple bugs just waiting to be found), but jellyfin being open source puts it in a better situation for finding vulnerabilities sooner.
At least we are more likely to hear about them than we would for PMS. Quickest way to find vulnerabilities is to have as many eyes as possible on it, if you only let the 20 devs you employ look a lot can be missed. Just my opinion though.
Yet everyone in here tells everyone to switch from Plex, which is designed for it, to jellyfin lol
I prefer security vulnerabilities I can manage to privacy ones I cannot.
What privacy vulnerabilities are you talking about exactly?
Assuming you’ve forwarded ports 80 & 443 on your router, that’ll do just fine.
Speaking as a hacker and SWE, the cringelords telling you that exposing Jellyfin is some major liability are LARPers who don’t know what they’re talking about.
Meh, I won’t expose ports anymore - last time I did I had someone hammering on it hard enough to slow my consumer router.
I closed the port and would still have someone hammer it occasionally for months, hoping the port was still open.
Just for my own education, if you don’t mind - how were you able to tell someone was hammering on the port if it was closed? Would fail2ban have been an option to stop them?
Firewalls can log dropped packets.
Yeah, fair point — I was only talking RCE.
That’s a real risk if you get hit by a lazy stuffing script, and I personally SSH tunnel my self-hosted to a public VPS to avoid that sorta thing.
@Op, if you do notice slowdowns for your whole network & suspicious noise in your Jellyfin logs, the easy move is to configure fail2ban and ask your ISP to rotate your router’s IP for you.
Haha okay, thanks! And I’d just forward ports 80 and 443 from the router to ports 80 and 443 on the Pi’s internal IP address in the router settings, right?
Yeah, you’ll probably want to give your Pi a static internal IP too, but the details for that will depend on the specifics of your router and network.
If it doesn’t have to be exposed, then it shouldn’t be exposed. A Webserver should be exposed: Nginx and co are working on it for decades. Jellyfin on the other hand is a much smaller project, and chances for security issues are significantly higher.
Did you read the thread body? Op is using Caddy to reverse proxy, as they should be.
The smoothbrain top comment is claiming that Jellyfin “wasn’t designed to be exposed to the internet” AT ALL, reverse proxy or not. I agree that you want a reverse proxy in this situation — but you’re poking at a strawman of your own invention here, and putting words in my mouth that I didn’t say.
How does reverse proxy help with security? Reverse proxy is mostly there for the convenience.
Sorry, I assumed you were intelligent and sanewashed your comment.
I assumed you were talking about the fact that internal web servers that services like Jellyfin run are often DoSable without a proxy.
Jellyfin is quite literally a web app and perfectly safe to host on the web. Wanna prove me wrong? I’ll happily spin up an instance and throw a $500 bounty on there for you.
What the fuck is your problem 😂😂
Rt, my bad for the personal attack; I was trying to be saucy with that opener and missed the mark.
That being said, your opinion is still hot garbage. It’s not hard at all to host dynamic services publicly with minimal risk if you know what you’re doing, and Jellyfin is pretty damn low risk.
The argument you’re making is comparable to going on a car forum and saying no one should ever drive on a public road because you might crash, and there are drivers doing things you can’t control. It’s factually true that you mitigate all risk by doing so, but misses the fact the people can and do drive on public roads all the time without much hurrah.
Umm… Not sure if you are serious but knowledge is meant to be shared so… A reverse proxy isn’t really for convenience, it sits between two networks and proxies traffic according to specific rules. It also has the benefit of masking the origin server a bit (like its IP) and in a lot of cases can be used as a way to ensure traffic going to a server or service that doesn’t support transport encryption actually transverses the internet within a secure tunnel.
Yes, that’s why I said mostly. In this context reverse proxy is being used to access different ports via 80/443 from outside. That is not necessarily the use case you’re mentioning.
You don’t need to hard update your IP every 5 minutes. The typical DNS updaters (just use ddclient) can simply check if your IP is up to date and only update if it isn’t.
It’s perfectly fine to host jellyfin online. Use a proxy server to enable TLS and do not use default ports 80/443. Use letsencrypt for free certificates. No need for VPN to access here either. Do not expose any other ports such as SSH on default ports. Lock down your jellyfin server and any other related services behind a VPN service and block access to Internet through other interfaces (except for port forwards on your ISP for jelly). Go high on port ranges since they typically aren’t scanned or blocked. Go dual stack for best results and don’t use your router address for IPv6 more than likely you have your own /64 choose a different address for port forwards. Do not assign this address to your internal servers. Use a reserved unrouted IPv6 range internally and do NAT6. Do not allow any raw IPv6 internet access
In my opinion, you’d be fine using default ports. Guess there’s no harm in using other ports though, other than the pain of having the remember which port to use if you ever forget when adding a new device, etc.
Edit: I should add that im speaking of only ports 80/443 here. If you must expose ssh over the internet (probably shouldnt) for example, then yes, use a non-standard port (I use non standard ports for pretty much all apps except http/s).
Do not expose Jellyfin. It has unauthenticated endpoints that will be exploited by bots
I forgot duckdns still exists to be fair