Hacker News Reader

Comment by seiji | Hacker News Reader

Wow, "ssh wepay.com" works. Turn that off.

Once again, "cloud" doesn't mean "lol, we don't need to know about servers!"

That's totally nutty. Not sure how they passed a PCI audit like that. In fact, I don't see that they are PCI certified on their site?

Thanks for catching that. We've spent the last week moving into a new office and it must have slipped by as we were getting everything reconfigured. It's been locked down again.

One part of me wants to pat you on the back and say, "It's okay, everybody makes mistakes."

The other part of me wants to say, "You have nine million dollars in funding. Figure shit out. This isn't a game."

You guys run your servers out of your offices?

I must admit I didn't know the big domains disabled ssh. Naive/beginner's question: how do programmers work remotely at these companies (if it's allowed at all)? Do they ssh into other (safe) servers, from which a safe transfer is eventually made into the production servers?

You could set it up by allowing sshing to a server on a subdomain something like ssh.xyz.com or vpn.xyz.com and from there can ssh to production servers, which are set up to only allow ssh internally.

It's a matter of setting up VPNs and IP-restricting where you can SSH in from. You can also set up port knocking and other SSH-related security measures. It depends how much convenience you're willing to trade for security.

Practicality trumps everything, after 10+ years of using ssh and trying port knocking and everything else none of it works when you're 4000km away in another country with only a handheld to access the servers.

I think it should probably company policy at a financial institution not to allow someone in a different control on a handheld device to access the servers.

I use layered security (in the sense of servers) with a password lifetime of 10 days. I deal with servers daily and the issue of compromise has been twice in on firewall containers/servers which was fine as the systems in place found it, found the issue with the net facing software and I fixed it. Practicality doesn't mean no security.

If you're using SSH, you should be using keys, and not passwords.

Those aren't mutally exclusive

Can you require keys AND passwords? I haven't been able to figure out how to get that to function - if passwords are allowed, it lets you in with or without a key, from what I can tell. I'd be happy to be wrong though!

Generally you VPN in (using two-factor auth for PCI compliance) to a private network and can SSH in from there. Public facing SSH is generally a bad idea. Also it didn't seem like they had any firewall rules preventing brute forcing.

Don't necessarily turn it off. Make sure you've hardened SSH, only do key-based authentication and limit access to specific source IP addresses or use something like fail2ban.

Then spend the time to properly look at your information security requirements and develop a plan to comply with them.

If you just turn off SSH you're going to have a lot of pain with little gain or loss if it's properly configured.

It will certainly limit possibilities of 0day ssh exploitation.

Just out of interest, how many 0day pre-auth OpenSSH vulnerabilities are you aware of? The last publicly disclosed pre-auth OpenSSH vulnerability that if exploited would lead to arbitrary code execution came out in 2006.

I'm not saying that SSH 0day doesn't exist, but why SSH and not other 0day for say a VPN or the HTTP server? I think I see what you're saying, perhaps that SSH 0day is more valuable and less likely to be publicly disclosed but without any data on attacks in the wild, someone at wepay needs to make a risk decision.

My main point isn't that they shouldn't harden their platform, on the contrary I think they should, but they need to do so in a structured manner that doesn't leave them with a bigger mess to deal with. Hardening SSH isn't hard, hardening an IPSEC 2FA VPN is going to be a different story.

> but why SSH and not other 0day for say a VPN or the HTTP server

More hosts have SSH than VPN available. SSH is pretty much standardised in comparison to VPN. VPN touches mostly certificates and network interfaces, while SSH touches the whole authentication stack, so there's a possibility of exploiting whatever pam environment you're using. Also, you can drop root in most VPN solutions, but not in SSH (by design).

Sure - hardening SSH is enough and most likely thing to do in case of standard servers. But if you're providing some special services... why not add the special protection?

Reply on news.ycombinator.com