5 ms·

Wow, "ssh wepay.com" works. Turn that off. Once again, "cloud" doesn't mean "lol, we don't need to know about servers!"

by seiji 16y ago

modoc 16y ago
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?
ez77 16y ago
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?
- whakojacko 16y ago
  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.
- Firehed 16y ago
  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.
  - nwmcsween 16y ago
    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.
    - poet 16y ago
      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.
      - nwmcsween 16y ago
        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.
        count 16y ago
        If you're using SSH, you should be using keys, and not passwords.
        nwmcsween 16y ago
        Those aren't mutally exclusive
        count 16y ago
        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!
- modoc 16y ago
  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.
deleted 16y ago
[deleted]
Firehed 16y ago
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.
- seiji 16y ago
  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."
  - joeuser12 16y ago
    seiji, an open ssh port also isn't that big a deal. Every large network has an ssh entry point somewhere. I did a quick check before and at least it only accepted ssh-2. But yes, I agree with you that having that entry point on the main domain is a bad idea, but realistically we are talking about security through obscurity here. With enough guessing you can find the ssh entry point for any large site. The trick is whether you can get through it. They tend to all have 2-factor auth behind them making it extremely hard to bypass. I have no idea whether wepay has 2-factor auth behind theirs though.
- gesh 16y ago
  You guys run your servers out of your offices?
  - joeuser12 16y ago
    A quick traceroute would tell you that they don't. He probably meant the source ip range for restricting access changed due to the office move.
iuguy 16y ago
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.
- viraptor 16y ago
  It will certainly limit possibilities of 0day ssh exploitation.
  - iuguy 16y ago
    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.
    - viraptor 16y ago
      > 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?

Wow, "ssh wepay.com" works. Turn that off. Once again, "cloud" doesn't mean "lol, we don't need to know about servers!"

by seiji 16y ago

Wow, "ssh wepay.com" works. Turn that off. Once again, "cloud" doesn't mean "lol, we don't need to know about servers!"

modoc 16y ago

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?

ez77 16y ago

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?

whakojacko 16y ago
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.
Firehed 16y ago
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.
- nwmcsween 16y ago
  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.
  - poet 16y ago
    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.
    - nwmcsween 16y ago
      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.
      - count 16y ago
        If you're using SSH, you should be using keys, and not passwords.
        nwmcsween 16y ago
        Those aren't mutally exclusive
        count 16y ago
        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!
modoc 16y ago
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.

deleted 16y ago

[deleted]

Firehed 16y ago

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.

seiji 16y ago
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."
- joeuser12 16y ago
  seiji, an open ssh port also isn't that big a deal. Every large network has an ssh entry point somewhere. I did a quick check before and at least it only accepted ssh-2. But yes, I agree with you that having that entry point on the main domain is a bad idea, but realistically we are talking about security through obscurity here. With enough guessing you can find the ssh entry point for any large site. The trick is whether you can get through it. They tend to all have 2-factor auth behind them making it extremely hard to bypass. I have no idea whether wepay has 2-factor auth behind theirs though.
gesh 16y ago
You guys run your servers out of your offices?
- joeuser12 16y ago
  A quick traceroute would tell you that they don't. He probably meant the source ip range for restricting access changed due to the office move.

iuguy 16y ago

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.

viraptor 16y ago
It will certainly limit possibilities of 0day ssh exploitation.
- iuguy 16y ago
  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.
  - viraptor 16y ago
    > 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?