51–60 of 120 posts
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…
This has some serious downsides for non-SSH applications. For example, to connect to a production database cluster, one would need to ssh through the proxy to a bastion host, and then set up port forwarding from the bastion host to the database. Setting up a simple database connection now requires shell access to a production server. This is less secure and more complex than using a traditional VPN.
I'll keep using fwknop-protected OpenSSH on OpenBSD and WireGuard, others can do whatever they want without thinking about the security vs. convenience.
Earlier quoted context omitted.
> Obviously, this isn't practical for everything If you have the engineering resources to back it up, it definitely can be. Internal services at Google usually trust the office network the same as any other -- well documented in the BeyondCorp paper if you're interested.
My understanding based on the folks I know at Google is that BeyondCorp paper was a PoC that was implemented in part of their corp network, that is called Production, not to be confused with the production network that hosts their search site. That network still requires a VPN and a hardened Linux laptop to access. Not every service has been modified to implement the RPC calls / authenticated protobuf code changes. S…
You don't get direct SSH access to production machines or any other lower level network access like packet sniffing on the production network.
No, no, no. The whole point of a VPN or SSH jumpbox is to airgap critical infrastructure with unknown vulnerabilities behind a hardened point of access. Putting production infrastructure on the public internet is beyond idiotic and regressive, and an invitation to be hacked by an unlimited and unknown number of exploits. It took forever to get departmental firewalls at a big name university where I worked because sys…
Really?
No, no, no. The whole point of a VPN or SSH jumpbox is to airgap critical infrastructure with unknown vulnerabilities behind a hardened point of access. Putting production infrastructure on the public internet is beyond idiotic and regressive, and an invitation to be hacked by an unlimited and unknown number of exploits. It took forever to get departmental firewalls at a big name university where I worked because sys…
So, they have drawn their lines of defense in a position you are not used to, and therefore they are beyond idiotic and regressive? Really?
No, no, no. The whole point of a VPN or SSH jumpbox is to airgap critical infrastructure with unknown vulnerabilities behind a hardened point of access. Putting production infrastructure on the public internet is beyond idiotic and regressive, and an invitation to be hacked by an unlimited and unknown number of exploits. It took forever to get departmental firewalls at a big name university where I worked because sys…
Yes, I completely agree. This post is literally an endorsement of that idea, with enterprise port knocking mixed in for additional security. At no point in this post do I advocate simply opening all servers to the Internet. Quite the opposite.
If you have suggestions for how I could be clearer in the post, please let me know.
Earlier quoted context omitted.
So, they have drawn their lines of defense in a position you are not used to, and therefore they are beyond idiotic and regressive? Really?
Yeap. There is a night and day difference in attack surfaces between isolating access to a single (or HA pair) jumpbox and N boxes on the internet with no real DMZ or private admin network. Feelings and fashions don't make stupid configurations better. If you have a problem with honest opinions from someone with 25 years of experience, I think you need thicker skin or I can choose to simply not comment and let stupid…
TLDR: Use a complicated SSH proxy instead of a VPN. This has some serious downsides for non-SSH applications. For example, to connect to a production database cluster, one would need to ssh through the proxy to a bastion host, and then set up port forwarding from the bastion host to the database. Setting up a simple database connection now requires shell access to a production server. This is less secure and more com…
I'm curious: why is utilizing port forwarding over these mutually authenticated SSH tunnels less secure than employing a VPN? From my perspective, port forwarding still adds a level of intentionality which reduces the likelihood of an incident/accident.
Meh, this sounds like it's paid for by okta. It also doesn't cover the real use case scenario of vpns - non-technical folks need to access internal services. What's presented is a reasonable approach for ssh control. Oh, and I'm pretty sure Cloud Passage has a port-knocking based solution in the real world which also gives 2fa access for ssh.
I blog about things that I encounter at work and find interesting. That happens to often be a cross-section of infrastructure and identity!