Closed alectrocute closed 5 years ago
It's behind a Docker so shouldn't matter much
It's behind a Docker so shouldn't matter much
I agree, Docker is a great safeguard here. However, hear me out.
Everybody should be reverse proxying the :8080 port (assuming that's what the exposed client port is) to their :80 or :443. This allows for NGINX caching, ACL, rate-limiting; a bunch of really important features that really help their szurubooru instance fly & remain secure to attacks.
Having the Docker's NGINX port exposed by default, in my opinion, isn't best practice. Maybe we should perhaps have a configuration option to have the client Docker only exposed to localhost so another localhost instance of NGINX/Apache2/whatever can pick it up and reverse proxy it to 0.0.0.0?
I'd like to hear @sgsunder opinion on this.
I'd like to hear @sgsunder opinion on this.
I'm all ears, I may be wrong. Admittedly I'm not an expert, just a hobbyist who's maybe overly paranoid about web security.
Another example is a scenario of someone using Cloudflare for DDoS protection. They're setup like this:
Public -> Cloudflare (*:443) -> NGINX caching/ACL/Lua proxy (*:80) -> Docker szuru client (*:8080)
Let's say a bad guy wants to take down the website via DDoS. They use a 0.0.0.0 scan service, such as Shodan.io to scan all websites with "title: My Cool Szurubooru Board" and somehow come across the :8080 port of the origin IP. Now they have an easy target that lacks any protection whatsoever.
The current Docker NGINX config needs to be hardened in other ways as well, such as having server_tokens off
, etc.
My making *:8080 localhost, and doing basic allow {cloudflare ip}; deny all;
on the caching NGINX instance, they're pretty much completely protected.
The solution would be making the default $PORT
in .env
as: 127.0.0.1:8080
and then adding a small "Reverse proxy the :8080 port" in the readme.
Well, I never really intended the default deployment (the docker-compose.yml
file) to be all-purpose and production ready. (I even use a different one on my personal system). The way it's written right now is to make it easy for people who find this project to spin up a full-functioning test instance on their laptop, etc.
I expected people to modify the compose configuration heavily for production use to fit their use case the best. That includes rewriting the client's network config to point to a reverse proxy if public-facing, using a better Docker volume system, running Elasticsearch on bare-metal for large deployments, switching to Kubernetes over Compose, etc.
That being said, I think there should be a note in the installation instructions that lets users know that the provided compose config is not intended to be run public-facing as-is.
The current Docker NGINX config needs to be hardened in other ways as well, such as having
server_tokens off
, etc.
That's a good idea and should be put into a pull-request. I'm not an expert on NGINX so I didn't add any important security configs to it.
I think it's okay to close it after I merged @alectrocute changes in https://github.com/rr-/szurubooru/commit/2ec6b978ac3f7c6574148e71312018fc8526b9f7 .
For those using a reverse proxy / caching application to expose the client to the internet, it's undesirable to have a fully open port (:8080) available.
Thoughts?