I’m just a novice at self hosting and I see a lot of talk about the risks of exposing stuff to the world. Here’s my setup:
-Rpi4 hosting Overseerr
-Desktop computer hosting Nginx and some Cloudflare DDNS update containers
Cloudflare directs request.domain.com to my home IP address. Nginx forces HTTPS and directs the request to the Pi.
Is there any risk in this setup or are there more steps I can take to secure it?
What you are doing is exposing ports to the internet and advertising you home IP.
Which is fine, mostly.A better way has been mentioned with cloudflare tunnels. This means your server connects out to cloudflares servers, instead of cloudflare forwarding to your IP.
It would then leverage all the protections that cloudflare offers (ddos protection, client filtering etc).
However, cloudflare then has access to everything that goes through it.
It’s very secure, chances are cloudflare doesn’t care about your traffic, and as long as everything is legal you will be fine.If you don’t want cloudflare knowing all of your servers served traffic, then you either need to run your own reverse-proxy-over-vpn style endpoint on a VPS (that you trust), or accept the additional risk of leaking your home network public IP.
If you accept the additional risk of leaking your home IP, then it’s worth making sure your firewall/router is up to scratch.
Make sure it has active development (which is why most people use something like opnsense), and is always up to date (to ensure any vulnerabilities are patched).
Beyond that, the system is as secure as you want it to be. The more secure, the more maintenance and upkeep it needs.
There are many things you can do.The easiest is to firewall on your devices. So the reverse proxy will only accept inbound from WAN, cannot establish its own connections to WAN, and whatever connections are required for forwarding to the pi.
And the pi would be firewalled to only allow incoming connections from the reverse proxy, cannot establish connections to wan, and whatever else is needed for it to function.
Where these rules are established is up to you. They could be on the router/firewall with each device on its own vlan (or pvlan if you are fancy). This is the most secure, but harder to implement.
Or they could be on the device itself, as long as the processes that are “doing the thing” cannot change the firewall rules (ie, don’t run them as root or as a privileged user). Correctly configured, this is as secure as doing it on the router/firewall.The idea here is to prevent any hacker moving sideways (ie from the device they own to another device).
If they own a device, then they can’t do anything with it - even if they extract all keys, passwords and secrets from it.Another interesting thing is to run an (outbound) proxy on your firewall. Force all outbound 80/443 through the proxy (via dnat rules), and have your servers trust the proxy’s root CA.
What this means is that the firewall can then decrypt all outbound http connections, allowing for easy packet inspection.
If a server is downloading dodgy scripts, then hopefully your Deep Packet Inspection tool will catch them and shut it down.
You can do the same for DNS resolution (dnat redirect to a DNS resolving service), and whitelist only the DNS entries your services require.Most basic attack would be easily caught it completely shut down by these kinds of things.
There is also crowdsec.
It can do a bunch of things.
It can run on things like opnsense, or the servers themselves.
It can then detect malicious traffic according to crowd sourced detection/metrics (which, I believe, you contribute to by using it) and block it.
But, honestly, might as well just use Cloudflare Tunnels.Security is about layers.
What if someone manages to get Remote Code Execution on this service? How do I detect it? How to I prevent it? How do I limit it to that device?
And have regular offline backups. So if something gets hacked and bitlocked, you can wipe the server and restore from a backup (and practice this. No point having a backup strategy if it ends up not working when you need it).But honestly? Do you need to expose this to the internet?
Would it be easier to run a VPN, so only trusted devices can connect to it in the first place? (Wireguard would be my recommendation here)If it is sitting on the internet, it can be discovered. What are you running for a firewall and intrusion protection?
Uh… I’m not. Just a regular router and stuff.
On your firewall block all IP addresses except Cloudlflare’s IP ranges
Configure Cloudflare’s firewall to block any connections from outside your home country.
Since you’re using cloudflare already you could utilize their cloudflare tunnel feature, that way you don’t need DDNS or any open ports, and your home IP will be hidden.
I would rather just making a wireguard vpn and having control of my data, but privacy might not be his concern.
For public access you would need a VPS somewhere to act as an ingress point, so that might be more than OP wants to deal with.
If you utilize logins something like fail2ban would be a good addition, as well as something for anti-malware/hacking/injection prevention etc. when I had a public Nextcloud I had Apache set up with mod-security with the owasp rule set loaded.
The biggest risks of hosting something public at home besides ddos attacks is scripts that get regularly run against any open port they can find on the internet that if successful could encrypt your data for ransomware etc. I personally realized this was all just for me and the wife and running the services through a vpn (ZeroTier was fantastically easy to set up) removed most of the risk while letting us access remotely
I tried looking into fail2ban but I haven’t successfully set it up yet.
To my understanding, if they try to DDOS the domain then cloudflare will shut them out. However they could very well just DDOS my IP, at which point I’m like any other potential target.
Anything on the public internet is some amount of risk.
It sounds reasonably configured, and for a single service that’s been fairly robust, the only thing you really should make sure you’re doing is updates - better if you configure automatic updates, so you don’t even have to think about it.
unattended-upgrades is what you’d want on a Debian-alike for updates, and Overseerr depends on how you installed it.
@jws_shadotak Make sure no ports other than 80 and 443 are exposed from the outside and force everything through https
Done