Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

SSH Bastion Host Best Practices

goteleport.com

Post reply on HN
Print view View original

21–30 of 91 posts

Re: SSH Bastion Host Best Practices

#21

Post by loudmax »

alecco wrote: post #4

Twice I've seen Bastion Hosts compromised. Both times it practically gave the attackers the highest access. In one case it basically hid where the attack came from (compromised logs and all). In another it let them hijack an admin's password by reading his sudo. IMHE, Bastion Hosts suck. If you are forced to use one, send logs to a safer one-way storage encrypted and put tampering triggers everywhere you can in the B…

I can see that you can get a lot of things wrong with a bastion host, but if implemented sensibly, it should just be one more layer of a defense-in-depth strategy. What would you recommend instead of a bastion host?

Re: SSH Bastion Host Best Practices

#22

Post by vngzs »

staticassertion wrote: post #17
mrweasel wrote: post #7

There's a few weird things, but it's mostly okay. Do not trust the firewall on the bastion host, if an attack can get into the bastion host, they can disable the firewall, so it cannot be used to limit egress. It's better than nothing, but consider using a firewall that's managed on a via a separate management network. I do agree that you should only allow SSH from a few known IPs. Limiting the number of users is wei…

> if an attack can get into the bastion host, they can disable the firewall, so it cannot be used to limit egress. This assumes that the attacker can get unconstrained root access to the system. It's fine to assume that attackers will but it's not as if you can't make that difficult. Agree with the rest of what you said though.

From a defense standpoint, one should consider "shell on a box" to usually mean attackers can get root on a box. If they can get persistence, they can wait for a kernel CVE to abuse.

Now, if you're just using a bastion as a jump host, you don't need to offer shells on it. Just allow people to proxy a port to behind the bastion and be done with it.

    PermitTTY no
    ForceCommand /usr/sbin/nologin
    AllowTcpForwarding yes
    AllowAgentForwarding no

Re: SSH Bastion Host Best Practices

#23

Post by LinuxBender »

unixhero wrote: post #18
LinuxBender wrote: post #2

Good writup. One thing I would add for bastions if you wanted to harden them would be to disable session multiplexing if you are using MFA/2FA. MaxSessions 1 The default is 10. The plus side of multiplexing is that subsequent connections using the same ssh connection channels are not validated against the authorization mechanisms such as login or 2FA . This reduces friction and speeds up the login process because log…

Thanks a lot, great hardening considerations. It would be interesting to hear what you think of Keykloak.

Sorry I have never used it so I don't have an opinion. That looks like an oauth/openid/saml ssh integration?

Re: SSH Bastion Host Best Practices

#24

Post by whynotminot »

tsuraan wrote: post #20
whynotminot wrote: post #15

Earlier quoted context omitted.

I wish we could save posts. So this reply is my method… thanks for the write up.

You can click the timestamp on a post, and then click the "favorite" link, and that'll add the comment to your favorites list (which I think would be https://news.ycombinator.com/favorites?id=whynotminot&commen... for you).

TIL! Thank you very much

Re: SSH Bastion Host Best Practices

#25

Post by ghjnut »

tptacek wrote: post #12
ghjnut wrote: post #10

Could someone do me a solid and explain best security practices around bastion hosts and vpn? e.g. - would you still require users connected to the vpn to go through a bastion host? - would you ever run bastion/vpn through the same box? - are there preferred access use cases for each?

Yes, you would still have people connect to the bastion if they're on the VPN; part of the point of a bastion is to have a central place to monitor and control SSH access, which a VPN doesn't really do for you. Additionally, you will inevitably end up with team members who need access to the VPN (to reach staging and test versions of your applications, or to access customer support consoles) but don't get SSH access;…

Thanks for the response, that clears things up quite a bit. Would you create jump-boxes per environment or do you generally just have 1 with all the different service/env access logic?

Re: SSH Bastion Host Best Practices

#26

Post by vladdoster »

A superset of these best practices in the article would be CIS benchmarks. Collectively agreed on by industry leaders and provide extensive resources that span the gamut of cloud, networking, and storage infrastructure.

CIS supported technologies: https://www.cisecurity.org/cis-benchmarks

CIS Audit AWS infra: https://github.com/toniblyx/prowler

Better to be proactive than reactive :^)

Re: SSH Bastion Host Best Practices

#27

Post by AtNightWeCode »

joshgachnang wrote: post #14

Can someone explain to me the benefits of limiting the IPs that can SSH into the bastion? It seems to me the main thing that's protecting against are misconfigurations of SSH (accidentally letting root log in with no password or something) or a zero day in SSH but I'm not convinced by either.

What do you want to be paranoid about? One access point or a million access points?

Re: SSH Bastion Host Best Practices

#28

Post by mindcrime »

whynotminot wrote: post #15
LinuxBender wrote: post #2

Good writup. One thing I would add for bastions if you wanted to harden them would be to disable session multiplexing if you are using MFA/2FA. MaxSessions 1 The default is 10. The plus side of multiplexing is that subsequent connections using the same ssh connection channels are not validated against the authorization mechanisms such as login or 2FA . This reduces friction and speeds up the login process because log…

I wish we could save posts. So this reply is my method… thanks for the write up.

You can always just upvote the comment. Your profile page has a link to see comments (and stories) you've upvoted in the past. See:

https://news.ycombinator.com/upvoted?id=YOURUSERNAME&comment...

Re: SSH Bastion Host Best Practices

#29

Post by belter »

vladdoster wrote: post #26

A superset of these best practices in the article would be CIS benchmarks. Collectively agreed on by industry leaders and provide extensive resources that span the gamut of cloud, networking, and storage infrastructure. CIS supported technologies: https://www.cisecurity.org/cis-benchmarks CIS Audit AWS infra: https://github.com/toniblyx/prowler Better to be proactive than reactive :^)

If you are on AWS you dont need bastion hosts anymore. Use Session Manager.

Re: SSH Bastion Host Best Practices

#30

Post by staticassertion »

vngzs wrote: post #22
staticassertion wrote: post #17

Earlier quoted context omitted.

> if an attack can get into the bastion host, they can disable the firewall, so it cannot be used to limit egress. This assumes that the attacker can get unconstrained root access to the system. It's fine to assume that attackers will but it's not as if you can't make that difficult. Agree with the rest of what you said though.

From a defense standpoint, one should consider "shell on a box" to usually mean attackers can get root on a box. If they can get persistence, they can wait for a kernel CVE to abuse. Now, if you're just using a bastion as a jump host, you don't need to offer shells on it. Just allow people to proxy a port to behind the bastion and be done with it. PermitTTY no ForceCommand /usr/sbin/nologin AllowTcpForwarding yes All…

I think it's probably reasonable when performing your incident response or even threat modeling to assume the attacker has or could escalate privileges. The linked article doesn't discuss anything that would make that harder, although perhaps practices like staying patched and minimizing attack surface are somewhat assumed (they do bring up choosing your OS based on minimizing attack surface for example).

There's also a lot you can do to harden that boundary. You can harden your kernel, you can execute user's shells in constrained environments like docker containers or restricted shells, leverage sandboxing technologies like apparmor or selinux, etc.

The user/root boundary can be a lot thinner than people expect, so I get why you'd want to point out that reliance on the attacker not escalating should be met with an evaluation of that boundary, but I think it may be understating the boundary to unconditionally not trust a host based firewall, or to say that getting onto the bastion itself is enough to disable the firewall when it does indeed require escalation.

Post reply on HN