Hacker News Reader

Comment by notpushkin | Hacker News Reader

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

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.

https://github.com/jellyfin/jellyfin/issues/5415

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.

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.

Reply on news.ycombinator.com