+- Jellyfin Forum (https://forum.jellyfin.org)
+-- Forum: Off Topic (https://forum.jellyfin.org/f-off-topic)
+--- Forum: Self-hosting & Homelabs (https://forum.jellyfin.org/f-self-hosting-homelabs)
+--- Thread: Best Security Practices? (/t-best-security-practices)
Best Security Practices? - 4r5hw45twh - 2025-01-26
Hi there. I have a Cloudflare domain name which points to my server's public IP, which is then managed by NPM (in Docker) to point to whatever local stuff I want accessed from the web (such as Jellyfin, for one example). I use Ubuntu. My NPM setup works in this way: For proxy host, I use the server machine's local IP (192.x.x.x:Port) to point to JF and in JF's docker compose file, I have a port defined in it so that I can access "localhost:Port" on the native machine as well. This will all be in Docker.
I plan on self-hosting a simple blog page for friends/family/whoever really, but I want to know the best security practices when using Docker for this sort of thing. For now, I would use Ghost as the blog platform. I don't have fail2ban or anything installed on Docker, security-wise, just containers I use, with JF being the one that's publicly accessible from the Internet, and soon-to-be the blog page.
So, what should I know and what should I do?
RE: Best Security Practices? - TheDreadPirate - 2025-01-26
Fail2ban, as you mentioned, is a good start. It can read Nginx logs to look for repeat 4XX codes, which is often an indicator of a web crawler or scan bots.
Another option is to rent a VPS to act as a proxy for all access to your home server, then setup Wireguard to tunnel from the VPS to your home server.
This one is good practice, in general. Disable SSH login for root, setup PKI keys for SSH and disable password logins entirely (keys only). This has the added benefit of making it easier to setup access for, for example, a friend's server. Just give them your public key. No need to exchange passwords.
This one is optional, but is what I do. HTTPS and SSH do not use standard ports, except for hosting Matrix because I have use 443. This significantly reduces the number of bots and script kiddies that attempt to poke around since most will not spend the time to ping every port. This has the inconvenience of having to specify ports in the URL but worth it, IMO.
RE: Best Security Practices? - Host-in-the-Shell - 2025-01-26
TDP's number 1 and 3 suggestions are all you need for 99% of cases. That said, I'd also consider updating firmware/BIOS of any device that is accessible outside your network, particularly combos/routers/etc.
RE: Best Security Practices? - 4r5hw45twh - 2025-01-28
(2025-01-26, 04:50 PM)TheDreadPirate Wrote: This one is optional, but is what I do. HTTPS and SSH do not use standard ports, except for hosting Matrix because I have use 443. This significantly reduces the number of bots and script kiddies that attempt to poke around since most will not spend the time to ping every port. This has the inconvenience of having to specify ports in the URL but worth it, IMO.
So, question regarding ports: Should I not have ports open on my router for each Docker service? I thought ports needed to be open for certain things?
Mine looks like:
![[Image: sOBSHHb.png]](https://i.imgur.com/sOBSHHb.png)
RE: Best Security Practices? - TheDreadPirate - 2025-01-28
Opening ports on your router is only needed if you need that service to be accessible outside of your network. And only if that specific port is needed to enable that. For example, if you are using a reverse proxy to handle external connections you only need to open port 80 and 443 on your router. Port 8096 does not need to be opened on your router since that port is not used for external access.
RE: Best Security Practices? - 4r5hw45twh - 2025-01-28
(7 hours ago)TheDreadPirate Wrote: Opening ports on your router is only needed if you need that service to be accessible outside of your network. And only if that specific port is needed to enable that. For example, if you are using a reverse proxy to handle external connections you only need to open port 80 and 443 on your router. Port 8096 does not need to be opened on your router since that port is not used for external access.
Even though the Jellyfin port I chose is indeed used to be accessed through my domain name/Internet? Or that's what you meant with letting NPM manage that?
RE: Best Security Practices? - TheDreadPirate - 2025-01-28
Nginx Proxy Manager is handling all external accesses on ports 80 and 443. The port we published in Docker (or did we use host networking?) only refers to docker and not your router. You should NOT be opening port 8096 on your router. This would allow unencrypted, direct access to Jellyfin from remote clients. Which negates the whole purpose of setting up Nginx.
Remember, Nginx is acting as a middle man between the client and the Jellyfin server. Remote Jellyfin clients are not directly accessing Jellyfin on port 8096. They are connecting to Nginx who passes traffic to and from the server and client. Therefore port 8096 should not be open on your router.
RE: Best Security Practices? - 4r5hw45twh - 2025-01-28
(6 hours ago)TheDreadPirate Wrote: Nginx Proxy Manager is handling all external accesses on ports 80 and 443. The port we published in Docker (or did we use host networking?) only refers to docker and not your router. You should NOT be opening port 8096 on your router. This would allow unencrypted, direct access to Jellyfin from remote clients. Which negates the whole purpose of setting up Nginx.
Remember, Nginx is acting as a middle man between the client and the Jellyfin server. Remote Jellyfin clients are not directly accessing Jellyfin on port 8096. They are connecting to Nginx who passes traffic to and from the server and client. Therefore port 8096 should not be open on your router.
Ohhhhhh, I gotcha now. Would access to JF matter anyway, though, since it needs a login to access anything? Gonna disable that port after work, but just curious.
RE: Best Security Practices? - TheDreadPirate - 2025-01-28
We discourage directly exposing Jellyfin to the Internet without a reverse proxy in the middle. Jellyfin is not hardened and makes no claims to being hardened. Having Nginx handle connections significantly reduces the potential for an exploitable vulnerability that would grant unauthenticated access.
It is unlikely that you would be targeted in this manner, but not having Jellyfin directly exposed to the Internet without Nginx (or whatever your preferred reverse proxy is) further reduces risk.
Internet security is all about reducing risk to the point that the amount of effort required for an attacker to gain access is higher than the perceived reward for their effort. For schmucks like us, the reward is pretty low to nothing so the amount of effort someone is willing to expend is also low. So we are just trying to prevent low effort script kiddies and bots from exploiting already known flaws or using common attacks.
So we reduce that attack surface area by using a hardened application, like Nginx, to handle external connections.
Keep your stuff up-to-date.
Use good security best practices.