by MaxikCZ 3 days ago
Reverse proxy itself will do barely any defense, what you need in combination is an authgate (authentik, authelia), and here we are moving from "simple reverse proxy" to fun weekend activity and then some getting it to work as expected. + it kills the app auth flow, so only web interface is suitable for this.
You can use a reverse proxy and still have working app auth, I have set this up via Authelia with the OIDC Jellyfin plugin.
However:
- This is EVEN MORE complex than "just" a reverse proxy.
- I'm not really sure it wins much security, because...
- at least I'm not relying on Jellyfin's built-in auth but I'm now relying on its/the plugin's OIDC implementation to not be completely broken.
- attackers can still access unauthenticated endpoints.
Overall I really wish I could just do dumb proxy auth which would solve all these issues. But I dunno how that would work with authing from random clients like Wii (and more importantly for me, WebOS).
> Reverse proxy itself will do barely any defense, what you need in combination is an authgate
What’s your threat model?
Same as anyones: random bots scanning IP/ports to find established services and trying exploits from the book.
With a reverse proxy, I don't see how this would work. The whole way the reverse proxy works is you use a subdomain name ("jellyfin.yourdomain.org") to access Jellyfin, rather than some other service on your server. The reverse proxy sees the subdomain name that was used in the HTTP request, and routes the traffic based on that. Scanning only the IP address and port won't get attackers to Jellyfin; they need to know the subdomain name as well.
The only tricky part here would be to make sure you’re doing a wildcard certificate, so that your subdomain doesn’t appear in Certificate Transparency logs.
true, but I kinda dont want hiding from plain sight to be my only line of defence.
If you expose Jellyfin on 443, have HTTPS properly set up (which Caddy handles automatically), your admin password is not pswd1234 (or you straight up disable remote admin logins), and use a cheap .com domain rather than your IP--what is the actual attack surface in that case?
As far as I can remember that is more or less what is usually suggested by Jellyfin's devs, and I have yet to see something that convinces me about its inadequacy.
He claims there are known exploits. Though I also want to know if this is really true.
The absolute worst thing I can see in there is that an third party who somehow managed to get a link to one of your library items (either directly from you or from one of your users--or by spending the next decade bruteforcing it I guess) could stream said item: https://github.com/jellyfin/jellyfin/issues/5415#issuecommen...
Everything else looks to me like unimportant issues, that would provide someone who's already logged in as a user minor details about your server.
Nearly everyone uses the *arr stack with the Trash guides.
Which means that the paths are pretty damn uniform.
Unless I am misunderstanding the discussion on GitHub, the attacker would still need to know the exact path where the file is saved, and the name of the file itself. Even then, all they can do is download the file from your device--which they could just torrent themselves for a fraction of the effort.
A DDoS is still a valid attack.
Very few consumer connections can manage, say, 100 clients downloading a massive video file simultaneously.