Best Security Practices?

[4r5hw45twh]

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?

[TheDreadPirate]

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.

[Host-in-the-Shell]

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.

[4r5hw45twh]

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:

[TheDreadPirate]

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.

[4r5hw45twh]

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?

[TheDreadPirate]

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.

[4r5hw45twh]

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.

[TheDreadPirate]

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.

[bjd223]

Just be careful pushing video through Cloudflare, even though they removed the video limitation from their TOS apparently they are still banning heavy users who eat up too much bandwidth on the free tier.

Anyway as you may know simply putting a service behind a reverse proxy does not automatically increase security. It's only when you start adding services on top of that.

I don't use Cloudflare specifically but things like geo IP blocking, IP banning (which you already mentioned, DDoS mitigation (not really hacking but annoying none the less), SSL are some good things to consider using.

As far as running a web server I would make sure it is up to date as possible at all times, and put it on its own VLAN, docker network, whatever, so it is only routable to the Internet and not your network.

Web servers are pretty high on the radar of hackers so you would want to take some extra care with one.