[HN Gopher] In which I agree with the federal government and bas...
___________________________________________________________________
In which I agree with the federal government and bash VPNs for fun
and profit
Author : EthanHeilman
Score : 24 points
Date : 2022-02-15 17:41 UTC (1 days ago)
(HTM) web link (www.bastionzero.com)
(TXT) w3m dump (www.bastionzero.com)
| codeflo wrote:
| I agree with the goal, but I have trouble imagining reaching it
| in a typical enterprise/government IT environment. I agree that
| VPN is a crutch. The alternative is that every little legacy
| intranet application needs a fully staffed and security-aware
| maintenance team. That team needs to work full time to keep the
| technology up to date so that everything can be patched, forever.
| Many little internal tools wouldn't exist in such an environment.
| Maybe that's not entirely a bad thing, but it's very different
| from today's expectations.
| gigel82 wrote:
| Yeah right, the folks that write our intranet tools are the ones
| not qualified enough to work on a shipping product (I know this
| is harsh but the few exceptions just prove the rule).
|
| No way in hell we'd expose their stuff directly to the internet,
| especially since these internal tools deal with things like
| benefits, paystubs, asset allocations, access control, etc.
| EthanHeilman wrote:
| The government's point here is that qualified people should be
| writing those intranet tools. It is no longer ok to write
| insecure janky software because "don't worry we can secure
| later by putting it behind a VPN/Firewall". That is fixing bad
| engineering with duck tape. The correct approach is to engineer
| it correctly.
|
| Write your software as if it was going to be directly exposed
| to the internet. While VPNs do provide protection, they do not
| provide sufficient protection.
|
| If software isn't safe to use without a VPN, it isn't safe to
| use with a VPN either.
| bradknowles wrote:
| TLDR: Bastion Zero let's you log into individual hosts, not
| networks.
|
| But it obviously doesn't go down to the app level, which is what
| the original government document is actually saying we should do.
| Unless you can guarantee that one host belongs to one and only
| one app, then restricting things to the host level doesn't really
| help you that much beyond segmented VPNs.
|
| So, I don't really see how this is a huge improvement.
| EthanHeilman wrote:
| Disclaimer I helped design the bastion-zero protocol. Sorry for
| the wall of text, I just care a lot about this protocol and I
| think it is really neat so I'm always excited to talk about it.
|
| > But it obviously doesn't go down to the app level, which is
| what the original government document is actually saying we
| should do.
|
| Bastion-zero does go down to the app level. Bastion Zero lets
| you log into roles in applications not mere hosts or ports.
| This is one of the big advantages of bastion-zero over say
| tailscale or segmented VPNs.
|
| With kube, bastion-zero you could enforce a policy that a
| particular user identity, say "Alice@example.com", can only
| access the control plane of certain kube clusters with the kube
| role 'dev-user'.
|
| Not only is this policy enforced at the application and role
| level but logs are application and identity aware as well.
|
| Look at an example of using bastion-zero for shell access.
| Alice's gsuite identity is Alice@example.com and lets say she
| has a policy in bastion-zero which allows her to login to the
| linux shell as 'qa-user' on the host 'qa-dev-123'. Without
| bastion-zero logs on 'qa-dev-123' would only capture the 'qa-
| user' performed some action so:
|
| 1. Application role: 'qa-user',
|
| 2. hostname: 'qa-dev-123',
|
| 3. Action: 'rm -rf /'
|
| That isn't helpful if multiple people can sign in as 'qa-user'.
| Additionally since the logs are stored on the host, an attacker
| might be able to delete or tamper with them after the fact.
|
| With bastion-zero, the bastion captures the logs off-the-wire
| preventing tampering and it associates each action Alice takes
| with:
|
| 1. OpenID Connect auth session: 'a specific authorization token
| issued by gsuite and associated with a particular machine',
|
| 2. Alice's OpenID Connect identity: 'Alice@example.com',
|
| 3. Application role: 'qa-user',
|
| 4. hostname: 'qa-dev-123',
|
| 5. cryptographic identity of host: 'pubkey:0x4e32...'
|
| 6. Action: 'rm -rf /'
|
| This way we can tell, oh Alice's OpenID Connect identity token
| has been compromised on her laptop. Revoke that token. What
| other actions where taken under that token? Did the attacker
| successfully answer an MFA challenge from the Bastion? Yes? we
| know Alice's MFA secret has been compromised.
|
| Our goal with basiton-zero:
|
| * all parties have pubkeys which are strongly bound to their
| identity forever, but only usable over short periods of time
|
| * all pubkeys are short lived and ephemeral you are expected to
| generate new ones, you don't need to remember old ones
|
| * all the content of all messages is digitally signed by public
| keys producing logs which can be cryptographically attributed
|
| * no single points of trust or compromise
|
| * policy and logging are identity and application aware
| kevwil wrote:
| I read this as "... bash (the shell) VPNs for fun and profit" and
| thought, "what a cursed title!". Now I get it. LOL
___________________________________________________________________
(page generated 2022-02-16 23:00 UTC)