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:
Any issues on the community? Report it using the report flag.
Questions? DM the mods!
As long as your jellyfin server is properly configured behind a reverse proxy, letting it be accessible publicly on the internet is fine.
Obviously everyone has their own threat model, but it's not that big of a threat in this case (personally I don't care).
This. People are overly paranoid nowadays.
I have had SSH open directly to my main PC for 15 years and never had any issues except spam logins. Just disallow password logins and you're fine.
Same with :443 to my nginx.
I agree, there is a lot of paranoia, but honestly that's probably a good thing, because the people who are paranoid might not know that much, so a good amount of paranoia is healthy there.
The chance of being exploited is very low for me to care too too much. Why spend countless days locking up my entire infra when there's a very low low chance anyone could exploit me in the first place (obviously get your setup to a good standard, I don't recommend not reading up on anything and exposing server, etc. Just for me, I don't need to over do it).
That being said, personally I have ssh behind a vpn because that's a very important service that only I am accessing anyways, so it makes sense for me to disable that attack vector.
Can you elaborate on 'properly configured'?
The default configuration for Jellyfin is good. I mostly mean as long as you follow best practices in general you should be fine, eg:
https://jellyfin.org/docs/general/post-install/networking/reverse-proxy/
A firewall is probably the most important, having your ssh port blocked in the firewall being second.
Also, don’t use the default “data/media/{library name}” (or whatever the suggested format is) folder setup that the Trash Guide has you set up. At least change the “tv”, “movies”, etc name to something different. Jellyfin has a known vulnerability where an attacker can get access to media without valid credentials if they already know the file path. Jellyfin devs have stated that they have no intention of ever fixing this, because it would require completely divesting from the Kodi branch that everything is built on. And since everyone follows the Trash Guide to set their *Arr stack and library up, guessing file paths is laughably easy.
You’re using the suggested file naming in your *Arr stack, so Jellyfin can automatically match media? Congrats, so is everyone else. You’re using the suggested folder layout so your *Arr stack can use hardlinks? Congrats, so is everyone else. At least change the library folder names. Since your library folder doesn’t need to match the name of your Jellyfin library, you can literally have your “tv”, “movies”, and other folders be named whatever you want. Hell, name your tv folder “peepee” and your movies folder “poopoo” for all I care.
That certainly sounds like a thing you would want, nay need, to fix.
This sounds like a blocker for me to not switch to Jellyfin... What else is in there that's equally severe?
This needs to be copypasta'd as a reply to every comment suggesting that opening up jellyfin to the internet is easy and everyone should do it to get away from Plex.
having your ssh port blocked in the firewall being second
So like if I want to access my PC from outside, is it enough that I don't have a firewall installed but that I open up some random port and redirect it to my PC's port 22, and then connect to it via the random port?
make sure you aren't accidentally exposing jellyfins port directly to the internet
Same thing for Jellyfin?
If you don't want to worry too much, you can setup a vpn (like wireguard) on your server for ssh access.
Using a non standard port is a good idea, but not entirely foolproof because bots might still port scan (even if unlikely that they do that for ssh I'm not sure). At a mininum, you probably want to use keys for login like the other commenter on the main comment said.
Personally, using a vpn for when I want access to SSH when I'm out is worth the couple hours setting it up the one time (very simple setup with wireguard-easy for example). Maintenence time spent on upgrading is very low.
(Tl;dr personally I'd use a vpn to access ssh specifically rather than exposing it to the internet)
Same thing for Jellyfin?
Not 100% sure what you mean, but to clarify: Don't accidentally expose jellyfins port to the internet (eg the default port 8096). Make sure it is only accessible from outside your network through your reverse proxy.
Could you explain a bit more?
Like, right now, I have two machines on my local network. Both are running sshd on port 22.
In my router, I've set the port forwarding to be some high port number in the 19000's to forward to port 22 on the first machine, and then the same high port number incremented by one (1) to forward to port 22 on the second machine.
Also key based login only of course.
Is this insecure in some way?
Would a VPN make connecting to my computers more secure somehow? I'm not sure I understand how if so.
What I meant with the Jellyfin question was kind of, how is having it exposed via a reverse proxy different from exposing its port right away? Is it because the only allowed connection would be HTTPS/encrypted etc, maybe?
I've never set up a home network apart from physical cables and using routers and switches before, no advanced site/network configuring. Definitely interested to learn more though for when I want to serve a real media center using a NAS and like a Pi.
Your SSH setup is good.
ssh is a very resilient piece of software so I doubt with your setup you would encounter any issues.
Enforcing use of a VPN to get into your network before being able to ssh into a machine is mostly just an extra layer of defense, though using a non-standard port, only allowing key logins and disabling root user login are all layers of defense you have already added.
I thinj you'll be fine, but if you are worried, you could setup a VPN or alternatively something like Fail2Ban if you notice any brute-force attacks (which may be unlikely with the use of a non-standard port).
What I meant with the Jellyfin question was kind of, how is having it exposed via a reverse proxy different from exposing its port right away? Is it because the only allowed connection would be HTTPS/encrypted etc, maybe?
It's down to how secure the software is really.
Jellyfins (and other software) don't use really secure web servers for getting themselves accessible via the network.
Caddy (a reverse proxy, for example) is made to be exposed to the internet and so it is more resilient and safe to use.
So putting the resilient software (a good reverse proxy) infront of Jellyfin (or most other software) simply increases your security by having the more safe web server be the one interfacing with end users.
Have fun on your journey!
Okay cool, thanks for that follow-up and confirming my SHH setup seems reasonable. 🙏
There's one thing I don't really get though, with the whole reverse proxy thing and how that's supposedly safer:
putting the resilient software (a good reverse proxy) infront of Jellyfin (or most other software) simply increases your security by having the more safe web server be the one interfacing with end users.
Like, once a user client has contact with the Jellyfin instance, via the reverse proxy, wouldn't the Jellyfin instance be just as vulnerable as without the reverse proxy? Once a connection is established, or found to be available, you could just start exploiting away in the same way, right? Or wrong? If wrong, how? 😅 Maybe it's too long for a text reply? Maybe I should watch some helpful video explaining how it works. 😁
No problemo.
Thanks for pointing out the reverse proxy comment. I think I was wrong to say simply putting jellyfin behind a reverse proxy will increase your security.
The benefits may only be minute or non-existent if you don't use the reverse proxy for handling other stuff like HTTPS (and redirects to https, etc), restricting access or adding extra authentication requirements (mainly https).
It may also be good to note that Jellyfins docs explicitly do not recommend directly exposing jellyfin ports to the internet (a reverse proxy or using a vpn are recommended instead).
Still I will continue to feel safer always using a reverse proxy when I expose to the internet (maybe my misconceptions).
Thanks again, mate. So basically, if I'm exposing my junk to the world, and by junk I mean service(s), and by world I mean the open internet, I should do it using a reverse proxy and enable HTTPS, otherwise it's not really very secure? Would that be a reasonable takeaway?
Yet again, thanks. Especially for pointing out the things you (may) be not so sure about. That's admirable. 🫡
Hehe yep, that's a good takeaway and the same as what I think.
Thank you too, i enjoyed this discussion.
Awesome, same 😊 All the best to you buddy!
Dumb question: why does everyone is so terribly afraid of opening stuff to the internet ? What's the scenario?
Allowing external access to your services means that any misconfiguration or bugs can be exploited to gain control of your machine(s).
Once that happens they can be fucked with, your data stolen, your resources co-opted for someone else’s use, etc. and often times it can be made to look as though whatever bad shit it’s doing is your doing.
So, understand your security posture. You can’t be too careful. Taking over weak or exposed machines is a global industry now.
But you can, in fact, be too careful. Availability is one arm of the security triad.
If whatever complex configuration you have set up to avoid exposing something to the Internet is incompatible with something and what you wanted to do can't be done, or if you look and see that setting all that up would be too hard and don't bother to expose the service at all, then your security posture is incorrect because your service is just as unavailable as if someone else broke it.
At the same time, taking over exposed machines has never been more difficult.
It starts with being used in a botnet. Then your data can be either erased, corrupted or encrypted against ransom.
i've set up servers with static ips in datacenter settings before. the way you know you're online is usually that your cpu activity jumps a few percent from all the incoming ssh traffic from russia and china. i don't want to risk anything happening to my home server.
Missconfigurations allowing bots and shit hacking you. Overblown paranoia mostly if you just take some precautions
Okay thanks for mentionning overblown paranoia, that's what I have.
What kind of exploitable server misconfigurations are we talking about here?? Brute forcing won't work because fail2ban, right? I'm a noob and deep down I'm convinced that my homeserver is compromised and has beenpart of a bitcoin mining farm for years... Yet, not a single proof...
I'm paranoid dude, I don't need the whole world judging my awful taste in TV shows!
The first thing I opened to the internet was a SSH server. 28 minutes after opening it, I started getting constant entry attempts.
not that any of this is doable in the near future, since i'm behind cgnat and won't get my colocated bounce server up until spring.
Doesn't IPV6 allow direct external access even when cgnat is in use for IPV4?
Yes, if you have IPv6, you can open a port in the firewall and have external access. Whatever you are accessing it from must have IPv6 as well though.
This video addresses many of the concerns of hosting stuff in public, and details a way (and some tools) to do it relatively securely. (There's always a risk there'll be a zero-day vulnerability in a web application like Jellyfin, but you can mitigate against them if you use the right strategies/tools, and you're vigilant enough.)
Since you're on cgnat, you can set up Pangolin on a VPS, or Tailscale-->rinetd-->Tailscale tunnel, also on a VPS. (Apparently frp is another similar solution, with p2p proxying.)
Not spesifically helpful with your cgnat-situation, but my jellyfin runs on a isolated network and it's just directly exposed to the internet via named reverse proxy in order to share the library with family and friends. Should someone get access to that they can obviously use the VM for nefarious purposes, but it's a known risk for me and the attacker would need to breach trough either my VLAN isolation or out of the virtual environment to my proxmox host if they wanted to access my actually valuable data.
Sure, there's bots trying every imaginable password combination and such, but in my scenario even if they could breach either the jellyfin server or reverse proxy it's not that big of a deal. Obviously I keep the setup updated and do my best to keep bad actors out. but as I mentioned, breach for that one server would not be the end of the world.
With cgnat there's not much else to do than to run a VPN where server is somewhere publicly accessible and route traffic via that tunnel (obviously running a VPN-client on jellyfin-server or otherwise routing traffic to it via VPN). Any common VPN-server should do the trick.
An Idea I am also using for other things where I do not want to use a VPN:
In the casting use case you have to find a request and check if there is any parameter that you can use to safely whitelist the request. Ofcourse someone could get behind this and fake the request to match the whitelist. But without knowing that there is even a whitelist no one will really try