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!
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.
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.
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.