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

21–30 of 59 posts

Re: Bastion hosts

#21

Post by jpgvm »

lmm wrote: post #18

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…

Better yet. Store the authorized public keys in LDAP or similar system. (AuthorizedKeysCommand makes this super simple these days).

That way you can rotate them easily if the private keys become compromised.

I recently built a system using this technique and synced the keys to S3, very effective.

Re: Bastion hosts

#22

Post by rsync »

the_french wrote: post #17
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.

Exactly.

(Your most secure server) is not as secure as (your most secure server with some obscurity added).

Re: Bastion hosts

#23

Post by rsync »

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....

I've been doing this sysadmin thing for a long, long time, and have built some large, high profile platforms,[1][2] and I can tell you that few things have made me happier than port knocking.

Yes, it is a password with a tiny number of "bits". But nobody suggested using only port knocking, so that's not significant.

Yes, if my attacker is sharing the exact same NAT'd IP as me then they have a window to attack ... my fully hardened server, which was no worse than what was presented to them before.

Finally (and this is what makes me happiest) my sshd is not exposed to whatever new exploit might be discovered tomorrow that doesn't require user credentials. It's not exposed to being DOS'd by a buffer overflow vuln. It's not filling my logs with brute forcers all day and night.

I love port knocking.

[1] JohnCompanies (first VPS provider)

[2] rsync.net

Re: Bastion hosts

#24

Post by philjr »

rsync wrote: post #23
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....

I've been doing this sysadmin thing for a long, long time, and have built some large, high profile platforms,[1][2] and I can tell you that few things have made me happier than port knocking. Yes, it is a password with a tiny number of "bits". But nobody suggested using only port knocking, so that's not significant. Yes, if my attacker is sharing the exact same NAT'd IP as me then they have a window to attack ... my…

just run ssh on a non-standard port and you get the same benefits

Re: Bastion hosts

#25

Post by tptacek »

jpgvm wrote: post #20
phil21 wrote: post #10

Earlier quoted context omitted.

> 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…

To a one, every medium- and large- sized application deployment I've tested that failed to set up VPC (or something like it) has fallen to some stupid oversight on some stupid backend, support, or dev machine. Don't rely on individual host hardening for security; you'll fail.

Re: Bastion hosts

#26

Post by peterwwillis »

In the Enterprise world, jump boxes are more typically just a hack implemented by IT workers who don't want to go about properly setting up a firewall and 802.1x/vlan/vpn/ipsec/etc to allow strict control to a protected network resource. (Or because they don't have the hardware capability to do it, or their network admin decided against it).

The only two proper excuses for ever using a bastion host are "I don't have the money to do it right" and "I don't have the time to do it right."

Re: Bastion hosts

#27

Post by arde »

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…

Yes, an AES-CTR transformation would be more secure than any port knocking variety such as SPA, at the cost of being more complicated. But the point in port knocking is not its intrinsic security, which is not worth to talk about: its point is actually the obscurity it adds to some other secure access method such as SSH, and its ease of implementation and usage. With it you get much shorter and less noisy logs to monitor, and it's almost for free. In a way, it can be compared to camouflage: its dirt cheap and quite effective at avoiding hits. Bulletproof vests or armoring are still required, but the question is why would you NOT be camouflaged when you can?

Re: Bastion hosts

#28

Post by peterwwillis »

rsync wrote: post #23
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....

I've been doing this sysadmin thing for a long, long time, and have built some large, high profile platforms,[1][2] and I can tell you that few things have made me happier than port knocking. Yes, it is a password with a tiny number of "bits". But nobody suggested using only port knocking, so that's not significant. Yes, if my attacker is sharing the exact same NAT'd IP as me then they have a window to attack ... my…

Mr. Sysadmin, I have four questions:

1. When was the last time your sshd was hit with a 0day?

2. Why aren't you running grsec to prevent buffer overflows (amongst other things) ?

3. Wouldn't it be easier to DOS your host with excess traffic (like all modern DDOS attacks), rather than find a remote-code-execution buffer overflow 0day and use it solely to starve resources on a bastion host?

4. Why don't you use a VPN? If you used a udp-based VPN nobody would even know the port was open (connectionless) and you could even require a preshared key, which is the more secure equivalent of port knocking.

Re: Bastion hosts

#29

Post by rudolf0 »

jpgvm wrote: post #20
phil21 wrote: post #10

Earlier quoted context omitted.

> 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…

>It's fundamentally much better to just harden every system and implement proper federated authentication

Much better? Yes. More practical? No.

Once you have a network of more than 3 hosts, host security can quickly become difficult to maintain. This means not just keeping up to date on patches but auditing all your configurations and carefully reviewing applications and services.

Every organization in the world has serious host security issues. For example, a company like Google has an excellent security team and presumably world class endpoint security, but there's almost no question that an attacker on some segment of their internal network would be able to pivot and take over hosts (the lateral movement would likely be noticed by their SOC, perhaps within an hour or less, but it would still be after-the-fact).

Proper network segmentation and architecture makes most of those issues much less risky though, as it is much harder to actually get to any of those hosts.

Re: Bastion hosts

#30

Post by rudolf0 »

lmm wrote: post #18

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…

You're describing an overly optimistic scenario. "Why not just harden all your machines?" Because it's more complicated than that. Yes, you can automate basic hardening (configuration of access controls, limited use of SSH keys), but how do you automate hardening of RPC between one server and another, or hardening of those 3 internal administration web apps which may or may not have some local file disclosure and crypto flaws?

Defense-in-depth is still the only sensible way to handle security. You do what you can on the host side, but bastion hosts, jump hosts, VPNs, etc. provide an additional layer to make lateral movement much more difficult for an attacker.

Post reply on HN