Reason for my question is the following:
I want to host some services on my public server and while they all have normal password protection, I want to ensure the security a tiny bit more. Therefore I want to limit the access to the specific services through ufw and nginx to specific IP addresses. For my homeaddress I can use DYNDNS to get my current IP. However that will not work for my phone, when I’m on the go.
I don’t want to constantly use vpn, as it slows down the speed of the internet connection significantly. Instead I would much prefer to just simply keep my server updated on my phones IP, so I can update the necessary config files through a script and thus allow my phone to access the services, where ever I am.
The correct answer has been given a few times here, split tunnelling.
But your idea is mental. If your IP changes and access is locked down by IP address how do you expect your phone to connect to your server to tell it about the new IP if it can;t access the server due to the fact it hasn’t got the correct IP in the allow list?
Yeah I thought about this problem. I don’t want to lock down all ports for nginx, but instead only certain websites through nginx rules.
The webhook receiver would remain open to the public, but would require a long passphrase that would result in ban through fail2ban, if entered incorrectly.I know this isn’t ideal, but that’s what I had in mind, when thinking about the problem.
I think you are overcomplicating and undercomplicating things at once.
Proper VPNs will allow split tunneling — only the traffic that needs to go through the VPN will go through the VPN.
So, the solution would be:
- Set up a VPN capable of split tunneling — vanilla Wireguard and tailscale should work
- Set up split horizon DNS so that you get are pointed to the internal/VPN-facing IP address of your server while connected to the VPN *???
- Profit
You can probably run some sort of dyndns client on android. I’d think maybe in something like termux.
Otherwise, check out mutual-TLS, also known as client SSL.
We use SSL all the time for servers, but the same can be done for clients.
I run eveything behind an nginx reverse proxy that handles all that with the ssl_client_verify directive beefier proxying the request to the different services.
You generate a cert that’s to be installed on the phone.
On a new connection, the server will challenge the client for its certificate and just drop eveything else.
I’d say it’s as secure as doing VPN with PKI, but without having to keep the vpn running.A few caveats: not all apps and browsers support mTLS.
The best option would be to have a DynDNS client on your phone (which your server can check) for what you want.
However, the reason VPN exists and is popular is because it works with the required security. Trusting an IP address alone leaves yourself open to abuse from another user at your ISP, your ISP, or even simply someone sending you a link to a specially crafted webpage which contains some HTTP requests, etc.
Ironically, allowing the phone to send it’s IP address to your home server opens up the whole network to abuse, as the update would need to be allowed from an IP address that’s not already known.
There’s a reason we don’t use security by obscurity.
Home Assistant Companion App does this
VPN split tunnelling is what you need
This is inventing security. Which is generally a bad idea. If you are worried about someone being able to hack you because their up isn’t blocked you are saying that your security is wholly hinging on the thing that updates your allowed IP restriction. Which itself has no IP restriction (it can’t cause how else would it work). And you are hoping that the security on that endpoint is WAAAAY better than something like a firewall
For iOS there is an app called “Host Monitor”. https://apps.apple.com/app/id989644054
You can connect (ping) hosts (URL, IPs) and can do this even in background.
The frequency can be set to ~hourly, 6 times per day or manual.
So if you set up the server end to fetch the IP of the device with Host Monitor checking; you could make things work the way I believe you want it 😉
Your describing port knocking.
An interesting and (effective?) security by obscurity technique.
An example:
Host port 443 web server, but by default the port is fully firewalled unless you give the secret “knock”.
So you hit port 5444 first, the router sees a request to 5444, and adds the source address to a list of allowed devices for the actual 433 port. Now, just your client ip can successfully connect to port 443 as normal.
Most security researchers balk at it as wholly dumb and ineffective. But I disagree. With port knocking I get ZERO hits to my publicly exposed SSH port 22 on my actual server. The firewall shows all the port scanners hitting my block port 22, thousands per day. But unless they hit my secret combo of ports first, they don’t get to the allow port 22 rule.
More complex rule would be used in production:
Hit port 5001, then 5009, then 6120, then 4001 now you can hit your actual service port. And if you don’t hit them in order, no go. To reach 5009, you must hit 5001 first, to hit 6120, you must have hit 5009, which already required to have hit 5001. Add a rule where if you hit 5008, it all closes and starts over to preclude a port scanner from triggering all your rules.
Mikrotik routers have the ability to do this with firewall rules that just trigger and add a client ip to a transient src-address list. The longer your chain the better.
Android has an app called “port knocker” that makes it easy to open the door any time automatically.
Only issue is someone watching your traffic will easily see your port knocks, but that’s a local, persistent adversary, not a transient scan, so yea, I get why serious security people say meh, but the threat your preventing as an individual is the random drive by scans and brute force scripts, and it’s 100% effective at preventing those.
