Access to self hosted apps for non techies

So this is more of a discussion topic than anything I think. I wholly agree with the stance that I keep my self hosted apps behind my vpn and not publicly expose anything. However that becomes and issue when I want to move other folks onto my self hosted services. Most people really aren’t going to turn on the vpn so they can use the self hosted service. So I’ve been considering using Netbird reverse proxy to expose those apps that are beneficial to have access to for folks such as Actual Budget or eventually Nextcloud so that I can move my family data off of google cloud. I know this adds a layer of protection but honestly I’m not sure how much. With port forwarding your firewall is really all that is between you and the big bad ole internet. With the reverse proxy there is more it would seem but really I’m not sure if it’s all that much better. So just looking for thoughts from you all.

The only thing you’re adding security wise is diverting your IP address if you plan to run netbird in the cloud. You’re not going to stop anyone poking at the services you expose though.

That’s what I had thought but I was seeing a lot of folks going that way happily and was wondering if I was missing something.

All you can do is babysit, make sure you are always patched and hope that these services are security audited regularly.

Exposing actual budget is hard for me to put directly on the internet. It’s an open source project and who knows how bad the security is on it. And your finances at that.

You obviously know the risk, but I’d encourage you to reconsider.

Yeah Actual Budget is one I was more concerned with. The only real benefit is to do tracking of expenditures when you spend instead of saving receipts till later but as you said much bigger risk.

Limit the attack surface by setting each with a free ddns client and then in your firewall only those fqdn’s are allowed through the open port

Easy enough with opnsense pfsense by creating an alias list

Although I simply refuse to open any ports anymore, it’s just too dangerous now with the way things are in this current climate

Exposing services to the internet always involves risk, and you have to weigh the benefit against the potential impact. But putting everything behind a VPN does not automatically solve those problems.

A VPN is still an internet-facing service. You are trusting that the software is properly audited, securely configured, patched regularly, and does not contain exploitable vulnerabilities. A lot of people also do not enforce MFA for VPN access. If the VPN is compromised, an attacker could potentially gain access to much of the internal network rather than just one exposed application—unless you have strong segmentation, least-privilege access, and a zero-trust design in place.

Defense in depth is the better approach. Put public-facing services behind a WAF, isolate them from the host using containers or VMs, keep the entire stack patched, and automate updates where it makes sense. A WAF can also complement network-level filtering such as pfBlockerNG on pfSense.

1 Like

The second best layer of defense after a VPN is, in my opinion, mTLS with a reverse proxy.

In a nutshell, you yourself generate suitable SSL certificates - one per family member - and install it on their device in their browser. Then it is completely transparent for them, they just use the browser like they would any other website.

What it does for you, security wise, it allows people with suitable SSL certificates installed to pass through the reverse proxy and access whatever it is you want to make available and the Internet at large doesn’t even get to see what is behind the proxy.

Yep defense in depth is always on my mind. Really the VPN I think for the most part just limits how many openings on bad ole net one has but is still and entry point. Having 2fa enabled is something I think most underestimate even in the pro tech world. I’ve had that argument a time or two. Some great insights thanks.

I had looked into mTLS a while back on Cloudflare tunnels. Really like the concept of it just haven’t gone much further with it. Cloudflare was a consideration I meant to add to my original post and forgot. Scatter brain lol. I’m very much enjoying this thread and all the info everyone is providing.

Hmm DDNS is something I need to research not a concept I know much about in this case anyway.

Cloudflare tunnels aren’t very useful in your particular scenario.

Cloudflare proxy on the other hand can sit in front of your reverse proxy. It is typically used when you self host websites available to the world but don’t want to expose your public IP address and expose yourself to DDOs attacks. But again not very useful in your particular scenario.

Neither of them provide additional security per se, more in the form of hiding your true IP behind them.

CF also provides a WAF which will provide additional protection for your web services. Another option if you want to stay self hosted WAF look into bunkerweb.

Ah cool I didn’t know that self hosted WAF’s existed. Thinking back it should have been obvious. I’m behind CGNAT so I have to use something like Netbird or CF tunnels. I honestly haven’t decided how to move forward yet but I definitely want to move the family over to self hosted so I’ve started thinking about things and this was the topic I kept coming back to. I use Netbird now to access my self hosted apps remotely but for me it’s easy. Getting the non tech people on board with it is more challenging lol.

Simplistic easiest way is the dynamic dns system, nothing is 100% secure but the next best thing after NetBird is …

setup a free account at dynu.com say

Setup dynu client on phone:laptop/desktop or router at remote location

Add the dynu addresses to a whitelist list in your firewall as well as any remote locations with fixed IP’s

In your port forwarding rules only allow addresses in this list to access the port

Above will do as it’s for home use not business use where non techy compliance issues/politics/egos etc also come into play :slight_smile: