All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
IPwhitelist+ SPFW + Backend User Auth: Does This Qualify as Basic Zero Trust?
I'm the author of Free Public IP Access Control V2 (a simple IP whitelist service) and SPFW. Lately, I've been pondering VPS access control and want to share a basic setup: using Free Public IP Access Control V2 and SPFW for IP-layer filtering, paired with backend user verification (like basic auth or MFA). Does this combo constitute the most basic form of Zero Trust? Zero Trust emphasizes "never trust, always verify"—can it preliminarily cover explicit verification and least privilege? Welcome to discuss!
How Does This Setup Approach Basic Zero Trust?
Zero Trust's entry-level core is explicit verification (check identity at every step), least privilege (grant only necessary access), and assume breach (reduce risk through isolation and monitoring). My setup is like this:
IP-Layer Verification (Free Public IP Access Control V2 + SPFW): Free Public IP Access Control V2 provides a dynamic whitelist URL, SPFW uses it to filter traffic, allowing only trusted IPs (supports CIDR, remote auto-updates, logs real client IPs). This achieves "explicit verification" at the network level, blocking unknown sources, aligning with least privilege—deny by default.
User-Layer Verification (Backend): Even if IP passes, add user auth on the backend (e.g., password/MFA/certificates) to ensure double identity confirmation. This supplements device/user context, avoiding single-layer IP weaknesses.
Basic Monitoring: SPFW logs show client IPs and connection details for real-time anomaly checks, preliminarily supporting "continuous verification."
Overall, this dual-layer protection (IP + user) on a VPS can implement Zero Trust's most basic method: shifting from "trust the network" to "verify everything," at near-zero cost, self-hosted, and lightweight (SPFW supports TCP/HTTP/PROXY, per-port independent rules). It's not full-featured—lacks advanced context (e.g., device health checks) and enforced encryption (need extra TLS). Assume breach? Preliminary micro-segmentation via IP isolation, but not as robust as enterprise tools.
Core Question: With backend user verification, does this count as the most basic Zero Trust style? Is it sufficient to protect simple services (like Web/SSH)? What do you think?
Welcome everyone to try this combo! Download SPFW, pair it with Free Public IP Access Control V2 and test. If you run into bugs, config issues, or performance bottlenecks, your debug feedback would be super helpful—open-source thrives on community input. Stars/forks/PRs always welcome, let's make security stronger together!
Comments
Nope, IP based authentication does not qualify as zero trust.
No, IP is not zero trust.
Also AI slop.
IP in the world of NAT != zero trust.
Or, in other words, I have zero trust in IPs.
Thanks for the reality check. I've been schooled.
You guys were absolutely right—relying on IP for authentication is fundamentally not Zero Trust, especially with the mess that is NAT. I've taken that feedback to heart, went back to the code, and refactored the entire logic to earn the "Zero Trust" name.
I just released the new version here:
https://lowendtalk.com/discussion/212947/release-zero-trust-lite-tiny-secure-zero-trust-gateway-for-your-vps/
What changed?
I appreciate the blunt feedback; it helped me turn a weak tool into something much more robust. I'd love for you to take another look.
Cheers!
... Necro
Not the meaning you intended, but running a package shipped as binary only from some random person on the internet would get zero trust from me.
Do you think 10megs lightweight?
Truth be told, I somewhat skimmed the post and only really noticed "binary only" and "secure" when my heckles raised.
The post say "Free Public IP Access Control", that mean he get access to your server
Are you serious? This is just an IP database/ACL service. I have zero visibility into your server, let alone knowing what services you're running. Claiming this gives me "access to your server" is like saying the guy who wrote the phone book has a key to your house. Let's keep the technical discussion grounded in reality, shall we?
Can I have more plausible LLM answer?
This is just an IP intelligence service — not a control plane — not an access mechanism — not a visibility layer — it merely provides data — passive data — that you may or may not use — it does not see your server — does not know your services — does not interact with your environment — claiming otherwise reflects a misunderstanding — of networking — of access models — and of basic system boundaries.
Your word just like Joke.Imagine thinking an IP set system is a backdoor. Your logic is the only joke here.
Thank you, I love the em dashes
Bingo! Exactly.
SPFW simply connects to this IP set system for access control — nothing more. It’s a passive data feed that doesn't interact with your environment. If you don't trust the remote feed, you can simply use the -local parameter in SPFW to use your own local files as the IP set.
I asked the LLM to add maximum em dashes to make it more plausible