Hacker News Reader

Comment by exabrial | Hacker News Reader

Pure Zero Trust is just as ridiculous as using Pure-VPN-around-a-garden. The first gives an attacker unlimited retries, and the second gives an attacker full system access once they breach the outer wall.

The correct solution is somewhere in the middle: block everything by default to get you to an inner courtyard, where the zero trust model is deployed... (which ironically he suggests by deploying port knocking (port knocking is a bad idea (TCP/UDP ports are sent in the clear and the "key" is never rotated)))

The best model is probably "block everything" by default, then allow access to the inner courtyard via a VPN, where then the Zero Trust model is deployed. You remove the ability for an attacker to have unlimited retries, but access to resources still requires individual authentication.

View on HN

He doesn't ACTUALLY suggest port knocking, just the concept ("do something in order to open a firewall hole"). The proposed solution using Lambda w/ 2FA is actually pretty cool.

Correct, but his solution is a hair improvement at best over port knocking.

A VPN means an individual connection is authorized into the interior courtyard.

A Lambda with 2FA to whitelist an IP, then a cron job to cleanup means everyone at your local cafe wireless access point is also authorized into the inner courtyard.

No, the IP whitelist is only to allow access to the network entry point. So if you had a VPN, it would open the port to the VPN server. In our case, it opens the port to the cordoned-off SSH-based network entry point. It's not the replacement of an existing authorization layer; its an addition where one usually isn't found.

Why does pure zero trust give unlimited retries? If you use rate limiting, good password policy, and strong 2FA then most motivated attackers are going to seek a different entrance.

The vulnerability in your stack may be before your limits/policies are checked.

Rate limiting across distributed systems is a notoriously hard problem to solve.

So VPN in to a subnet where only a bastion host is exposed effectively?

I used to think the same way as the author, i.e. if there is already a secured SSH bastion host and IAP-protected internal services, why do we still need VPN?

The answer is of course defense in depth.

I wonder why the author seems to reply to every comments other than this.

Not to be particularly combative to this top-level comment author, but I did not see a reason to reply because I did not feel they had read the post particularly closely.

Obviously defense in depth can go as deep or shallow as you see fit, given an organization's resources. We believe that the short-lived SSH certificates, IP whitelisting (via "enterprise port knocking"), endpoint authentication (device trust), password authentication, and multifactor authentication are enough to protect a single production deployment. Encompassing all of that with a VPN seemed unnecessary when other protection mechanisms like the above, and additional mechanisms that we won't speak to publicly, are taken into account.

Like with anything, it's a game of risk, and it is up to each organization to decide what risk level they will tolerate. I believe most organizations have deployed VPNs in a way that gives them a higher exposure, and simply wanted to share some of the things we have learned through the process :)

Also just to note there is nothing to stop you from using a rotating port knock key, particularly if you are willing to assume the client's clock is reasonably accurate.

Yes, but not nearly as impossible as it should be. The amount of precision to pull of a timing attack is difficult, but the amount of computing power to refactor 4098bit RSA keys requires computers that don't exist [yet].

Nothing stopping you from HMACing the request IP+time with whatever crypto function you like and sending it in a series of encoded port knocks.

The only issue I've run into with port knocking is places that heavily restrict outbound ports/protocols. Though technically that is solvable too I just haven't bothered.

It's still sent in the clear and observable by anyone that see your network traffic.

The only things in clear text are your currently IP, the time, and the AES signature. The attacker doing a packet capture already knows your IP and probably owns a watch but it's unlikely they know how to break AES to sign a modified message as you.

Why not zero trust on the VPN? (And zero access otherwise)

Reply on news.ycombinator.com