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

Bastion hosts

pandastrike.com

Post reply on HN
Print view View original

11–20 of 59 posts

Re: Bastion hosts

#11

Post by akerl_ »

tptacek wrote: post #4

Jump boxes are a good idea. A better idea, if you're in AWS, is to use a VPC and just VPN into your environment; the VPN terminator in the VPC serves the same purpose as a jump box. If OpenVPN scares you, you can still do layer-4 filtering to minimize the impact of losing the OpenVPN server (ie, to get it to "no worse than if we hadn't used VPCs in the first place). "Single-packet authentication" is, I think, silly,…

Calling fwknop "hand-rolled auth" seems like quite the stretch. If passing around requests via GPG signed and encrypted messages is "rolling your own crypto", then what isn't hand-rolled?

Re: Bastion hosts

#12

Post by tptacek »

akerl_ wrote: post #11
tptacek wrote: post #4

Jump boxes are a good idea. A better idea, if you're in AWS, is to use a VPC and just VPN into your environment; the VPN terminator in the VPC serves the same purpose as a jump box. If OpenVPN scares you, you can still do layer-4 filtering to minimize the impact of losing the OpenVPN server (ie, to get it to "no worse than if we hadn't used VPCs in the first place). "Single-packet authentication" is, I think, silly,…

Calling fwknop "hand-rolled auth" seems like quite the stretch. If passing around requests via GPG signed and encrypted messages is "rolling your own crypto", then what isn't hand-rolled?

I don't care what you call it; the point is, it doesn't save you from anything that the correct SSH configuration doesn't already protect you from.

If you really believe that OpenSSH is too scary to expose to the Internet for fear of memory corruption flaws, don't stop at a half-measure like "port authentication". After all: once you "authenticate" the port, the attacker can simply hijack your TCP connection to trigger the flaw.

Instead, write a plugboard proxy, and have it apply a static-keyed AES-CTR transform to the data.

I think this is silly, but if you're trying to protect yourself from OpenSSH bugs, at least do something that actually protects you from OpenSSH bugs.

Re: Bastion hosts

#13

Post by akerl_ »

cthalupa wrote: post #6

Jumphosts have their uses, but in this case, I really don't see it. As others have pointed out, better yet is VPN only access. As for the port knocking silliness, well, I don't see any reason for it. http://bsdly.blogspot.com/2012/04/why-not-use-port-knocking....

It's worth noting that single packet auth is distinct from port knocking. fwknop isn't relying on "secret" port combinations: it's using GPG to sign/encrypt requests.

Re: Bastion hosts

#14

Post by cdubz »

neohaven wrote: post #3

Direct quote from the page at the other end of this link : "You appear to be using a browser that may not be able to display our site correctly. Generally, this is beause it's an older browser that doesn't support a lot of the newer, awesome features in open Web standards. Rather than provide an untested and possibly subpar experience of our site, may we suggest downloading one of these fine browsers? (We think you'l…

TBH, > 6 months old is hopelessly outdated. Welcome to the future, grampa.

Re: Bastion hosts

#15

Post by cthalupa »

akerl_ wrote: post #13
cthalupa wrote: post #6

Jumphosts have their uses, but in this case, I really don't see it. As others have pointed out, better yet is VPN only access. As for the port knocking silliness, well, I don't see any reason for it. http://bsdly.blogspot.com/2012/04/why-not-use-port-knocking....

It's worth noting that single packet auth is distinct from port knocking. fwknop isn't relying on "secret" port combinations: it's using GPG to sign/encrypt requests.

It's not meaningfully different - most of the same flaws still apply.

Say you have a bad actor behind the same NAT'ed IP. Good User A signs their SPA, and the firewall opens up for 30 seconds... during which Malicious User B has access.

What real advantage are you gaining vs. just having restricted firewall rules in the first place? Lowering the window of time an attacker has access? If you're not using password auth that could be brute forced, who cares about the window? Either they have the keys or an exploit needed to get in, or they don't.

Re: Bastion hosts

#17

Post by the_french »

kev009 wrote: post #16

This article goes from mediocre to bad when it starts advocating security by obscurity.

Security by obscurity is perfectly fine when it's part of a layered approach. It will help keep attackers from learning the details of your architecture and will also stop skiddies in their tracks.

Re: Bastion hosts

#18

Post by lmm »

Bastion hosts are the wrong approach, as are VPNs. They might have had some merit in the days of handcrafted servers, where "hardening" was something you could do to a single machine. But nowadays, especially on AWS, there's no point in a configuration that isn't automatically reproducible - in which case, why not harden all your machines?

Then you avoid having a single point of failure. If and when a single SSH key is compromised, there are a limited number of hosts that key had access to - and unless that's the log server, you have secured logs so you can figure out what happened. Different keys can have different capabilities, rather than a one-size-fits-all policy on the bastion. It makes it harder for an attacker to know where to get the boss's keys. And you can expand your system geographically without the performance compromises of a VPN; your servers already make encrypted, secured calls to each other (over SSH, SSL or a very small number of vetted protocols), expose only those ports that are actively used. Your attacker could steal your entire system documentation and it wouldn't make any difference, because the system is truly secured, not relying on obscurity.

Re: Bastion hosts

#19

Post by tene »

tptacek wrote: post #12
akerl_ wrote: post #11

Earlier quoted context omitted.

Calling fwknop "hand-rolled auth" seems like quite the stretch. If passing around requests via GPG signed and encrypted messages is "rolling your own crypto", then what isn't hand-rolled?

I don't care what you call it; the point is, it doesn't save you from anything that the correct SSH configuration doesn't already protect you from. If you really believe that OpenSSH is too scary to expose to the Internet for fear of memory corruption flaws, don't stop at a half-measure like "port authentication". After all: once you "authenticate" the port, the attacker can simply hijack your TCP connection to trigg…

I personally don't use Single Packet Authentication, for exactly the reasons you cite here, but I can understand some of the motivations. The use case that feels convincing to people that do use it, from what I've been able to understand, is that it does protect them somewhat from misconfiguring OpenSSH. If you fuck up and leave password auth enabled and a password set, and you fuck up and don't have monitoring on failed authentication and something like fail2ban or denyhosts, then fwknop is yet another thing that you'd have to fuck up before you're wide open to the brute-force crawlers. One solution to this is "just don't fuck up", but I can understand people having different levels of paranoia about this. Sure, it also protects you from bugs in OpenSSH, but misconfiguration is WAY more likely for your average OpenSSH installation.

Re: Bastion hosts

#20

Post by jpgvm »

phil21 wrote: post #10
tptacek wrote: post #4

Jump boxes are a good idea. A better idea, if you're in AWS, is to use a VPC and just VPN into your environment; the VPN terminator in the VPC serves the same purpose as a jump box. If OpenVPN scares you, you can still do layer-4 filtering to minimize the impact of losing the OpenVPN server (ie, to get it to "no worse than if we hadn't used VPCs in the first place). "Single-packet authentication" is, I think, silly,…

> A better idea, if you're in AWS, is to use a VPC and just VPN into your environment; Is it though? Is having your (and your co-workers) desktops/laptops/and possibly more directly able to access production servers at a packet level a good idea? I would posit that it is not. A bastion host can be used to lock down more than firewalls, and reduces the attack surface living on your network considerably. > VPN terminat…

Bastion hosts are generally a bad idea. There is not a single implementation of a bastion host that doesn't have significant security holes. This is doubly true if you want to do proper group based access control.

Most notable of these issues is the nature of either needing SSH agent forwarding enabled or storing a copy of the private keys on the bastion host (please don't do that). There are ofcourse ways of dealing with this but they aren't worth it.

It's fundamentally much better to just harden every system and implement proper federated authentication and authorization with LDAP. It also makes it much nicer to implement things like MFA and device level authentication.

Remember, it's very rarely that an attacker is going to be able to successfully walk in or break down the front door. Your security holes are very unlikely to be in your administrative channels like SSH/RDP but rather crappy applications or services you may be running on your systems.

Those crappy bits of software + insider threat are the 2 main things you generally need to deal with. Ensuring systems are sufficiently isolated from one another helps with both of these and bastion hosts just add another layer of shared stuff between workloads that should stay entirely separate.

Post reply on HN