4 ms·

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

by 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?

by iuguy 16y ago

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?