…maybe use a reverse proxy…
+1 post.
I would suggest definitely reverse proxy. Caddy should be trivial in this use case.
cheers,
hsdkfr734r@feddit.nl 4 months ago
One aspect is how interesting you are as a target. What would a possible attacker gain by getting access to your services or hosts?
The danger to get hacked, is there but you are not Microsoft, amazon or PayPal. Expect login attempts and port scans from actors who map out the internets. But I doubt someone would spend much effort to break into your hosts if you do not make it easy.
DDOS protection isn’t something a tiny self hosted instance would need (at least in my experience).
Firewall your hosts, maybe use a reverse proxy and only expose the necessary services. Use secure passwords (different for each service), add fail2ban or the like if you’re paranoid. Maybe look into MFA. Use a DMZ (yes, VLANs could be involved here). Keep your software updated so that exploits don’t work. Have backups if something breaks or gets broken.
In my experience the biggest danger to my services is my laziness. It takes steady low level effort to keep the instances updated and running. (Yes there are automated update mechanisms - unattended upgrades i.e. -, but also downwards compatibility breaking changes in the software which will require manual interactions by me.)
…maybe use a reverse proxy…
+1 post.
I would suggest definitely reverse proxy. Caddy should be trivial in this use case.
cheers,
Reverse proxies don’t add security.
lol
I don't get why they say that? Sure, maybe the attackers don't know that I'm on Ubuntu 21.2 but if they come across https://paperless.myproxy.com and the Paperless-NGX website opens, I'm pretty sure they know they just visited a Paperless install and can try the exploits they know.
Yes, the last part was a bit snarky, but I am truly curious how it can help? Since I've looked at proxies multiple times to use it for my selfhosted stuff but I never saw really practical examples of what to do and how to set it up to add an safety/security layer so I always fall back to my VPN and leave it at that.
I’m positive that F5’s marketing department knows more than me about security and has not ulterior notice in making you think you’re more secure.
Snark aside, they may do some sort of WAF in addition to being a proxy. Just “adding a proxy” does very little.
I have a dozen services running on a myriad of ports. My reverse proxy setup allows me to map hostnames to those services and expose only 80/443 to the web, plus the fact that an entity needs to know a hostname now instead of just an exposed port. IPS signatures can help identify abstract hostname scans and the proxy can be configured to permit only designated sources. Reverse proxies also commonly get used to allow for SSL offloading to permit clear text observations n of traffic between the proxy and the backing host. Plenty of other use cases for them out there too, don’t think of it as some one trick off/on access gateway tool
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.
May not add security in and of itself, but it certainly adds the ability to have a little extra security. Put your reverse proxy in a DMZ, with a firewall and only certain ports exposed to your origins. Install a single wildcard cert and easily cover any subdomains you set up. There’s 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.
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.
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.
A reverse proxy is used to expose services that don’t run on exposed hosts. It does not add security but it keeps you from adding attack vectors.
They usually provide load balancing too, also not a security feature.
All reverse proxies i have used do rudimentary DDoS protection: rate limiting. Enough to keep your local script kiddy at bay - but not advanced stuff.
You can protect your ssh instance with rate limiting too but you’ll likely do this in the firewall and not the proxy.
thirdBreakfast@lemmy.world 4 months ago
+1 for the main risk to my service reliability being me getting distracted by some other shiny thing and getting behind on maintenance.
TheButtonJustSpins@infosec.pub 4 months ago
I’m in this comment.
dogsnest@lemmy.world 4 months ago
It’s crowded.