- 1 Post
- 274 Comments
- @atzanteol@sh.itjust.works to
English - •
- thehackernews.com
- •
- 14d
- •
No - you’re not installing an app from the App Store. You’re running services now. There needs to be some minimum assumed knowledge about what that entails. And if you don’t have that knowledge you should expect to seek it out separately.
And if you’re too lazy or think “gee that’s difficult” then guess what? Self-hosting’s not for you. No shame - go pay for a service instead.
Nginx scales better than Apache does for static content and proxying, so it started to take over market share.
A home gamer handling a handful of users is unlikely to ever notice a difference.
But the configuration for nginx is simpler nout of the box for most things which is probably the real reason people use it at home.
It’s fairly obvious I feel.
You’re saying rather than use a system tool that does the exact thing that you want you should bodge together a cron job that accomplishes your goal but doesn’t actually do what you want.
Like say you want to stop the docker service for some reason? systemctl stop docker will do that. Then your cron job will restart it. That’s not the desired outcome. You want the service running IF the service SHOULD be running. Which is a different thing than “always running”. And its’ exactly what you get for free with systemd without any silly custom BS.
Fella, you have a huge knowledge deficit for what you’re trying to do here…
Docker does make running services easier and isn’t overkill for what you’re doing. But it’s not necessary and it’s fine if you don’t want to use it.
Debian is fine as well.
You need to get some experience before you continue self-hosting. Start firing up some vms or something. If that seems like “too much work” then perhaps this hobby isn’t for you. Running servers isn’t like grabbing an app from the app store. You’re going to need to invest some time here.
Put your reverse proxy in a DMZ, so that only it is directly facing the intergoogles
So what? I can still access your application through the rproxy. You’re not protecting the application by doing that.
Install a single wildcard cert and easily cover any subdomains you set up
This is a way to do it but not a necessary way to do it. The rproxy has not improved security here. It’s just convenient to have a single SSL endpoint.
There’s even nginx configuration files out there that will block URL’s based on regex pattern matches for suspicious strings. All of this (probably a lot more I’m missing) adds some level of layered security.
If you do that, sure. But that’s not the advice given in this forum is it? It’s “install an rproxy!” as though that alone has done anything useful.
For the most part people in this form seem to think that “direct access to my server” is unsafe but if you simply put a second hop in the chain that now you can sleep easily at night. And bonus points if that rproxy is a VPS or in a separate subnet!
The web browser doesn’t care if the application is behind one, two or three rproxies. If I can still get to your application and guess your password or exploit a known vulnerability in your application then it’s game over.
My reverse proxy setup allows me to map hostnames to those services and expose only 80/443 to the web,
The mapping is helpful but not a security benefit. The latter can be done with a firewall.
Paraphrasing - there is a bunch of stuff you can also do with a reverse proxy
Yes. But that’s no longer just a reverse proxy. The reverse proxy isn’t itself a security tool.
I see a lot of vacuous security advice in this forum. “Install a firewall”, “install a reverse proxy”, etc. This is mostly useless advice. Yes, do those things but they do not add any protection to the service you are exposing.
A firewall only protects you from exposing services you didn’t want to expose (e.g. NFS or some other service running on the same system), and the rproxy just allows for host based routing. In both cases your service is still exposed to the internet. Directly or indirectly makes no significant difference.
What we should be advising people to do is “use a valid ssl certificate, ensure you don’t use any application default passwords, use very good passwords where you do use them, and keep your services and servers up-to-date”.
A firewall allowing port 443 in and an rproxy happily forwarding traffic to a vulnerable server is of no help.
It’s listed as a privacy option on my pixel. It may be different for others but you could try searching the settings for “vpn” or “privacy.”