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)
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
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)