Privacy to disconnect your identity from the service? There is no solution to this. Full stop. Even with Tor, the state backed acronym entities will figure it out if you get on their radar.
If your objective is to keep your service online, you’re going to be hard pressed to find cost effective alternatives… Commercial solutions are expensive, like, “if you have to ask about the price, you can’t afford it” expensive.
Alternatively, you can try to roll your own by having many many proxy servers yourself… but if you’ve got a target on your back, you’ll never have enough instances; DDOS-as-a-Service is much cheaper than the amount of reverse proxies required to keep your service online.
There’s probably other use cases, but chances are, you’d still be hard pressed to find a solution that’s cost effective.
I would like to access to my server only trough the proxy, like if I put my real IP I end up with nothing, but if I put the proxy IP it show me my server
Setup a VPN on a VPS. Use traefik and authelia. Authelia will be your authentication portal and traefik will tunnel the traffic from the auth portal to configd locations within the VPN. Get your home network on that VPN.
Step 3: Install nginx on the VPS and configure it as reverse proxy to your home address. Something like this:
server {
listen 80;
server_name example.org; # your real domain name you want people to use to access your website
location / {
proxy_pass http://home-dynamic-dns.freeprovider... # replace with your home server IP or Dynamic DNS.
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_redirect off;
}
}
Step 4: Point your A record of example.org to your VPS.
http {
(...)
real_ip_header X-Real-IP;
set_real_ip_from x.x.x.x; # Replace with the VPS IP address.
}
This will make sure only the VPS is allowed to override the real IP of the client.
Step 6: Once your setup works you may increase your security by using SSL / disabling plain HTTP setup letsencrypt in both servers to get valid SSL certificates for real domain and the dynamic DNS one.
Proceed to disable plain text / HTTP traffic. To do this simply remove the entire server { listen 80 section on both servers. You should replace them with server { listen 443 ssl; so it listens only for HTTPs traffic.
Step 7: set your home router to allow incoming traffic in port 443 and forward it into the home server;
Step 8: set the home server's firewall to only accept traffic coming from outside the LAN subnet on port 443 and if it comes from the VPS IP. Drop everything else.
Another alternative to this it to setup a Wireguard tunnel between your home server and the VPS and have the reverse proxy send the traffic through that tunnel (change proxy_pass to the IP of the home server inside the tunnel like proxy_pass http://10.0.0.2). This has two advantages: 1) you don't need to setup SSL at your home server as all the traffic will flow encrypted over the tunnel and 2) will not require to open a local port for incoming traffic on the home network... however it also has two drawbacks: you'll need a better VPS because WG requires extra processing power and 2) your home server will have to keep the tunnel connected and working however it will fail. Frankly I wouldn't bother to setup the tunnel as your home server will only accept traffic from the VPS IP so you won't gain much there in terms of security.
Say someone wants to take your service down, you've got 500Mbits line at home ISP, and 10Gbits on your VPS; they sends 1Gbits of traffic to your VPS, your VPS happily tries to forward 1Gbits, fully saturating your home ISP line. Now you're knocked offline.
Say someone discovers the actual IP, dropping traffic from anything else other than the VPS doesn't help if they just, again, flood your line with 500Mbits of traffic. The traffic still flows from the ISP to your gateway before they could be dropped.
Say someone wants to perform SQL injection on your website, there is no WAF in this stack to prevent that.
Say someone abuses a remote code execution bug from the application you're hosting in order to create a reverse shell to get into your system, this complex stack introduced doesn't protect that.
You've provided a comprehensive guide, and I don't want to single you out for being helpful, but I must ask: What problem does this solve, and does OP actually have the problem this stack can solve? From the replies we've seen in this thread, OP doesn't have sufficient understanding to the full scope of the situation. Prescribing a well intended solution might be helpful, but it gives a false sense of security that doesn't really help with the full picture.
You aren't wrong but the things you're mentioned are always an issue, even if he was running the entire website on a VPS.
VPS happily tries to forward 1Gbits, fully saturating your home ISP line. Now you’re knocked offline.
Yeah, but at the same time any VPS provider worth it will have some kind os firewalling in place and block a DDoS like that one. People usually don't ever notice this but big providers actually have those measures in place and do block DDoS attacks without their customers ever noticing. If they didn't hackers would just overrun a few IPs and take all the bandwidth the provider has and take their all their customers down that way.
I'm not saying anyone should actually rely only on the VPS provider ability to block such things but it's still there.
The OP should obviously take a good read at nftables rate limiting options and fail2ban. This should be implemented both at the VPS and his home server to help mitigate potential DDoS attacks.
Say someone abuses a remote code execution bug from the application you’re hosting in order to create a reverse shell to get into your system, this complex stack introduced doesn’t protect that.
It doesn't and it was never supposed to mitigate that as the OP only asked for a way to reverse proxy / hide is real IP.
You could try Tailscale? It creates a secure tunnel to your server so you don't have to connect it to the internet. Not sure if that checks all your boxes though.
I was looking into Tailscale, but it got me a little worried. I'm not very knowledgeable, so I hope someone can correct me
They don't allow ssh, so you have to give your keys over them and they manage your ssh connection? That seems idiotic. Surely that can't be correct?
I'm my use case, I was wanting to rsync to an off-site Synology from a Linux box. Synology also doesn't allow ssh over their VPN service - frustrating.
I'm not really knowledgeable about it, but there is an article from Tailscale that explains how they use SSH (basically it creates a separate SSH server specifically for Tailnet traffic). From what I understand, this feature is relatively new.
Pretty much the only thing I use Tailscale for is remotely SSHing from my phone to my home NAS, and they definitely don’t manage my keys. They do have a “Tailscale SSH” feature I don’t use…
You can always use something like SSHwifty It retains your logins through your browser's session data and never on your server, but it will allow you to remote into your local system from anywhere on the WWW if you desire to do so. With Tailscale, once you are connected into your Tailnet, you can pretty much SSH into any of your devices as long as the subnet sharing flag is turned on I believe. I've never had any issues with mine not allowing any SSH connections.
Then you can't "hide" your server IP without a VPS/VPN set up. Maybe I'm not understanding what you're asking? Your public IP is visible to any machine you connect to and that includes Cloudflare's servers.
Are you worried about copyright or something? This isn't legal advice, but I doubt they give a shit unless you're hosting content illegally for a large number of people. Obviously, only take the risk if you are comfortable with the potential consequences where you live.
Set up a VPS. Create a VPN tunnel from you local network to the VPS. Use the VPS as the edge router by opening ports on the VPS firewall and routing incoming traffic on those ports through the VPN tunnel to servers on your local network.
I used to do this to get around CGNAT. I ran RouterOS in a Digital Ocean droplet and setting up a wire guard tunnel between it and my local Mikrotik router.
It will obscure your local WAN IP and give you a static IP but that's about the only benefit. And you have to be pretty network savvy to configure it correctly.
It does not make you immune to DDoS attacks and is honestly more headache to maintain (albeit just a small headache).
Not heard of RouterOS before ... <quick search> I didn't realise jad released firmware that would run in a normal VM... don't suppose you have anything to compare it to pfSense?
They do maintain an x86 build. I haven't used pfSense but I have used OpnSense so that's that closest thing I have to compare it to. I think the upside and downside to RouterOS/Mikrotik is the same thing: it allows very granular control over almost everything. Maybe to a fault. It's probably overkill for most home networks.
DDOS protection is going to depend on the VPS. But for most services you could spin up a pretty lean Debian vm running a proxy like nginx proxy manager and run that over the tunnel. Something like opnsense seems like overkill.
AFAIK tor websites (onion service) doesn't require exit node, and no one knows your IP unless you are unlucky enough all nodes you connected are controlled by same entity.