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.
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.
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
Edit: ddos protection would also be adviseable I think cloudflare might have that built in though
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.
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)
I assumed as much by your question, that’s why I mentioned it… 😄 Do some research, at least set up some basic rules to only allow the connections that you want accessing your public stuff. My first web server got hacked so badly in the first week of having it only that it couldn’t even be logged in to, so I had to start over from scratch.
As a quick primer… a firewall basically denies everything, then you poke holes in it to allow specific things. A typical example from when I started was sharing folders between Windows machines – turns out anybody with an internet connection could ALSO see those and make changes to my files! Add a firewall and don’t allow the sharing ports, and now nobody can see them. The “block-all” feature also protects you in case you make mistakes in your setup such as running an SQL server and not controlling who has access to it.
You are not logged in. However you can subscribe from another Fediverse account, for example Lemmy or Mastodon. To do this, paste the following into the search field of your instance: !selfhosted@lemmy.world
A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don’t control.
Rules:
Be civil: we’re here to support and learn from one another. Insults won’t be tolerated. Flame wars are frowned upon.
No spam posting.
Posts have to be centered around self-hosting. There are other communities for discussing hardware or home computing. If it’s not obvious why your post topic revolves around selfhosting, please include details to make it clear.
Don’t duplicate the full text of your blog or github here. Just post the link for folks to click.
Submission headline should match the article title (don’t cherry-pick information from the title to fit your agenda).
No trolling.
Resources:
selfh.st Newsletter and index of selfhosted software and apps
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.
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.
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.
@jws_shadotak Make sure no ports other than 80 and 443 are exposed from the outside and force everything through https
Done
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
Edit: ddos protection would also be adviseable I think cloudflare might have that built in though
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.
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.
I assumed as much by your question, that’s why I mentioned it… 😄 Do some research, at least set up some basic rules to only allow the connections that you want accessing your public stuff. My first web server got hacked so badly in the first week of having it only that it couldn’t even be logged in to, so I had to start over from scratch.
As a quick primer… a firewall basically denies everything, then you poke holes in it to allow specific things. A typical example from when I started was sharing folders between Windows machines – turns out anybody with an internet connection could ALSO see those and make changes to my files! Add a firewall and don’t allow the sharing ports, and now nobody can see them. The “block-all” feature also protects you in case you make mistakes in your setup such as running an SQL server and not controlling who has access to it.