Selfhosted
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:
- awesome-selfhosted software
- awesome-sysadmin resources
- Self-Hosted Podcast from Jupiter Broadcasting
Any issues on the community? Report it using the report flag.
Questions? DM the mods!
view the rest of the comments
@foremanguy92_@lemmy.ml ,
Step 1: get a cheap VPS, or even a free one (https://www.oracle.com/cloud/free/)
Step 2: If you've a static IP at home great, if you don't get a dynamic DNS from https://freedns.afraid.org/ or https://www.duckdns.org/
Step 3: Install nginx on the VPS and configure it as reverse proxy to your home address. Something like this:
Step 4: Point your A record of example.org to your VPS.
Step 5: there's a potential security issue with this option: https://nginx.org/en/docs/http/ngx_http_realip_module.html#set_real_ip_from and to get around this you can do the following on the home server nginx config:
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 withserver { 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 likeproxy_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.
The chances someone is going to DDOS a residential IP is small as important as you think you are nobody cares about taking down someones plex server.
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.
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.
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 aren’t wrong, but that’s also the point… It makes no difference if they’re securing a VPS or their own network. In fact, they’d need to secure both systems — and I’ve seen so many neglected VPS’s in my time… I’ll be the first to admit: myself included.
There are very valid reasons to need a tunnel; CGNAT, ISP level port blocking, network policies (ie campus dorm), etc etc etc. However, if you read the other replies, this doesn’t seem to be the case here, and OP doesn’t seem to even know why they’re hiding their IP. They just wanted to do it because of some loose notion that it may be nice since they’re opening up their port.
For someone in that situation, introducing a whole stack that punches through the firewall via an VPN or alike introduces way more risk than just securing down the gateway directly, and handle the other issues as they come up.