4 ms·

Best practices usually call for not exposing the SSH endpoints to the public internet. The principal risk is vulnerabilities in the underlying SSH server implem

by rl3 8mo ago

Best practices usually call for not exposing the SSH endpoints to the public internet. The principal risk is vulnerabilities in the underlying SSH server implementation. Historically, critical flaws that can compromise you are few and far between. However, these days AI is already starting to become adept at reverse engineering. If you must, you'd typically use a bastion host that's configured just for the purpose of handing inbound SSH connections, and is locked down to a maximal degree. It then routes SSH traffic to your other machines internally. I'd argue that model is outdated though, and the prevailing preference is putting SSH behind the firewall on internal networks. Think Wireguard, Tailscale, service meshes, and so on. With AWS, restricting SSH ports via security groups to just your IP is simple and goes a long way.

Msurrow 8mo ago
But doesn’t your argument that the principal risk [with ssh] is vulnerabilities also apply to the alternatives you say is best practice? Firewalling off ssh (but not http(s)) has the risk of vulns in the FW software. Tailscale, wireguard etc also has the risk of vulns in that software? So what’s the difference in risk of ssh software vulns and other software vulns? Also, another point of view is that vulnerabilities are not very high on the risk ladder. Weak passwords, password reuse etc are far greater risks. So, the alternatives to ssh you suggest are all reliant on passwords but ssh, in the case, is based on secure keys and no passwords. Should “best practices” not include this perpective?
- rl3 8mo ago
  Good defense is layered. For vulnerabilities, complexity usually equals surface area. WireGuard was created with simplicity in mind. >So, the alternatives to ssh you suggest are all reliant on passwords but ssh, in the case, is based on secure keys and no passwords. WireGuard is key-based. I highly suggest reading its whitepaper: https://www.wireguard.com/papers/wireguard.pdf https://www.wireguard.com/papers/wireguard.pdf
  - Msurrow 8mo ago
    Sure, no one said it wasnt layered. But saying ssh is a risk “on principle” due to possible vulnerabilities, and then implying that if wireguard is used then that risk isnt there is wrong. Wireguard, and any other software, has the same vuln risk “on principle”. > For vulnerabilities, complexity usually equals surface area. WireGuard was created with simplicity in mind. That is such consultant distraction-speak. Simple software can have plenty vulns, and complex software can be well tested. Wireguard being “created with simplicity in mind” doesn’t not make it a better alternative to ssh, since it doesn’t mean ssh wasnt created with simplicity in mind. I don’t disagree that adding a vpn layer is an extra layer of security which can be good. But that does not make ssh bad and vpn good. Further, they serve two different purposes so its comparing Apples to oranges in the first place.
    - rl3 8mo ago
      >That is such consultant distraction-speak. Or how large companies actually think about this risk in the real world. Expose SSH ports to the public internet willy-nilly and count the seconds until their ops and security teams come knocking wondering what the heck. YMMV of course, but that's generally how it goes. Are critical SSH vulns few and far between, as far as anyone knows? Yes. Do large companies want to protect against APT-style threats with nation-state level resources? Yep. Does seeing hundreds if not thousands of failed login attempts a day directly on their infrastructure maybe worry some people, for that reason? Yup. You call it consultant distraction speak, I call it educating you about what Wireguard actually is, because in your original reply you suggested it was password-based. >Further, they serve two different purposes so its comparing Apples to oranges in the first place. Not when both can be used to protect authentication flows. One is chatty and handshakes with unauthenticated requests, also yielding a server version number. The other simply doesn't reply and stays silent. >Simple software can have plenty vulns, and complex software can be well tested. In this case, both are among some of the most highly audited pieces of software on the planet.
      - Msurrow 8mo ago
        I’m calling it consultant speak because your response to an argument is to bring up something else, instead of actually responding. The same with this last reply; you can keep throwing out new points all you want, but thats not going to make you correct in the original question. Saying or implying that one software has a “principle” risk of vulnerabilities that another software doesn’t is plain and simply wrong. And that has nothing to do with all the other stuff about layered defence, vpns, enterprise security, chatty protocols or whatever you want to pile on the discusion.

by rl3 8mo ago

Msurrow 8mo ago

But doesn’t your argument that the principal risk [with ssh] is vulnerabilities also apply to the alternatives you say is best practice? Firewalling off ssh (but not http(s)) has the risk of vulns in the FW software. Tailscale, wireguard etc also has the risk of vulns in that software? So what’s the difference in risk of ssh software vulns and other software vulns? Also, another point of view is that vulnerabilities are not very high on the risk ladder. Weak passwords, password reuse etc are far greater risks. So, the alternatives to ssh you suggest are all reliant on passwords but ssh, in the case, is based on secure keys and no passwords. Should “best practices” not include this perpective?

rl3 8mo ago
Good defense is layered. For vulnerabilities, complexity usually equals surface area. WireGuard was created with simplicity in mind. >So, the alternatives to ssh you suggest are all reliant on passwords but ssh, in the case, is based on secure keys and no passwords. WireGuard is key-based. I highly suggest reading its whitepaper: https://www.wireguard.com/papers/wireguard.pdf https://www.wireguard.com/papers/wireguard.pdf
- Msurrow 8mo ago
  Sure, no one said it wasnt layered. But saying ssh is a risk “on principle” due to possible vulnerabilities, and then implying that if wireguard is used then that risk isnt there is wrong. Wireguard, and any other software, has the same vuln risk “on principle”. > For vulnerabilities, complexity usually equals surface area. WireGuard was created with simplicity in mind. That is such consultant distraction-speak. Simple software can have plenty vulns, and complex software can be well tested. Wireguard being “created with simplicity in mind” doesn’t not make it a better alternative to ssh, since it doesn’t mean ssh wasnt created with simplicity in mind. I don’t disagree that adding a vpn layer is an extra layer of security which can be good. But that does not make ssh bad and vpn good. Further, they serve two different purposes so its comparing Apples to oranges in the first place.
  - rl3 8mo ago
    >That is such consultant distraction-speak. Or how large companies actually think about this risk in the real world. Expose SSH ports to the public internet willy-nilly and count the seconds until their ops and security teams come knocking wondering what the heck. YMMV of course, but that's generally how it goes. Are critical SSH vulns few and far between, as far as anyone knows? Yes. Do large companies want to protect against APT-style threats with nation-state level resources? Yep. Does seeing hundreds if not thousands of failed login attempts a day directly on their infrastructure maybe worry some people, for that reason? Yup. You call it consultant distraction speak, I call it educating you about what Wireguard actually is, because in your original reply you suggested it was password-based. >Further, they serve two different purposes so its comparing Apples to oranges in the first place. Not when both can be used to protect authentication flows. One is chatty and handshakes with unauthenticated requests, also yielding a server version number. The other simply doesn't reply and stays silent. >Simple software can have plenty vulns, and complex software can be well tested. In this case, both are among some of the most highly audited pieces of software on the planet.
    - Msurrow 8mo ago
      I’m calling it consultant speak because your response to an argument is to bring up something else, instead of actually responding. The same with this last reply; you can keep throwing out new points all you want, but thats not going to make you correct in the original question. Saying or implying that one software has a “principle” risk of vulnerabilities that another software doesn’t is plain and simply wrong. And that has nothing to do with all the other stuff about layered defence, vpns, enterprise security, chatty protocols or whatever you want to pile on the discusion.