rr- / szurubooru

Image board engine, Danbooru-style.
GNU General Public License v3.0
704 stars 178 forks source link

Client should be behind 127.0.0.1, not 0.0.0.0 #231

Closed alectrocute closed 5 years ago

alectrocute commented 5 years ago

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?

rr- commented 5 years ago

It's behind a Docker so shouldn't matter much

alectrocute commented 5 years ago

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?

rr- commented 5 years ago

I'd like to hear @sgsunder opinion on this.

alectrocute commented 5 years ago

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.

sgsunder commented 5 years ago

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.

rr- commented 5 years ago

I think it's okay to close it after I merged @alectrocute changes in https://github.com/rr-/szurubooru/commit/2ec6b978ac3f7c6574148e71312018fc8526b9f7 .