Hacker News Reader

Comment by tptacek | Hacker News Reader

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, and I've never recommended it to anyone. It's hard to think of a case where hand-rolled authentication in front of SSH has saved anyone with a proper SSH configuration (keys-only-no-passwords). You can skip that step.

View on HN

> 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 terminator in the VPC serves the same purpose as a jump box.

It certainly serves the same network separation purposes a jump box does, but is not able to dictate the access environment nearly as much. If only your jump box has access to servers (and production servers properly filtered), every bit of remote access must go through that single ingress/egress point. And that point can have security policy built-in as well for multi-person teams. For example: I can enforce certain key types being utilized on remote hosts, logging of ssh sessions, etc.

I also agree the "single packet authentication" is silly though. Most bastion hosts these days will be behind VPN already. Just another riff on port knocking really.

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.

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.

I didn't say forgo the VPN. That would be unnecessarily increasing your attack service. In fact I specifically mentioned doing whatever you can to increase isolation between workloads, this includes ensuring access between dev, support and production machines is either not possible or is via careful controlled and audited means.

I only said bastion hosts are bad and generally decrease overall security because it's almost impossible to craft one that doesn't create more security holes than it closes.

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

Bastion hosts are generally a bad idea.

It's fundamentally much better to just harden every system

You must be one of those people that don't make mistakes and only use bug-free software across their entire deployment.

For the rest of us, DMZ's and bastion hosts are the only way to limit our attack surface to something that can be realistically managed.

> "Single-packet authentication" is, I think, silly, and I've never recommended it to anyone. It's hard to think of a case where hand-rolled authentication in front of SSH has saved anyone with a proper SSH configuration (keys-only-no-passwords). You can skip that step.

I agree. I usually use simple port knocking for that purpose. Surely you can agree that "no ports listening" is a better circumstance than "tcp/22 open to the world, with key-based-auth only"?

A VPN is redundant (and requires special client), whereas port knocking to open a port for ssh (that only supports key-based auth) is a simple matter of a few "nc -w 1" lines in a script before you ssh...

EDIT: Saw your posts below. You presuppose that such OpenSSH-zero-day holding attackers are specifically targeting you, which is not invalid; however a spray-and-pray quickly after public release is much more probable in a lot of cases.

Do you have a good reference to administering an OpenVPN server? Setting it up is easy, setting it up with HA is also no problem, but administrating OpenVPN for a startup that doesn't have a dedicated sysadmin would be a very useful guide.

This thread is dead, but: everyone really should enable OpenVPN's tls-auth option. tls-auth simply HMAC's each packet that would otherwise be fed to the SSL protocol, which is really good for reducing the impact of SSL-vulnerability-du-jour.

(tls-auth doesn't protect you from vulnerabilities in the OpenVPN data protocol, but that's a lot simpler.)

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.

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.

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?

You're not thinking the threat model through. If you're not concerned about the kinds of serious, dedicated attackers who have OpenSSH zero-day, you're fine leaving properly-configured OpenSSH exposed. If you are concerned about those attackers, port knocking is barely a speed bump.

I also dispute that a plugboard proxy is "more complicated" than "cryptographic port knocking".

I agree with what you say regarding the APT scenario, port knocking is mostly useless there. It wouldn't be an effective camouflage in that case, and one probably has bigger problems than a hypothetical OpenSSH zero-day then.

I'm not aware of any available plugboard proxy solution, so it would have the added complication of hacking it together. That's what I meant. And there are diminishing returns there: a non-criptographic port knocking scheme with a few packets could be good enough as a camouflage in many cases. But I still find it to be a time saver in the more general case (not APT). I think having cleaner logs is worth using this simple trick then.

> If you are concerned about those attackers, port knocking is barely a speed bump.

is this because you expect this class of attackers to be able to thwart port knocking more or less trivially ?

Reply on news.ycombinator.com