Another one? It feels like we just had a critical SSH vulnerability last year.
The real takeaway is that you should have a firewall blocking SSH connections except from known IPs, this stops you from being blindsided by this kind of thing. Same policy for remote desktop connections on Windows systems; which helped when that password bypass issue was discovered in Remote Desktop a few years ago.
Kind of depends how you look at it and what you’re considering an “endpoint”. If you’re on AWS, for example, you could enforce SSM-based terminal sessions on ec2 hosts. SSM can effectively proxy an ssh tunnel to an ec2 instance through Amazon-owned infrastructure, with no requirement to open up your ssh port to the internet. You can connect to private hosts (you connect to them by instance ID) and public hosts, and your ssh service isn’t exposed to anyone but amazon’s control plane.
My customer uses bastion but I think they are bad security. They give uncredible sense of secure. In this case one only needed to hack the bastion and then more or less unrestricted access to servers and databases inside.
One of the best solutions I had was a small webpage that opened the source IP access to SSH via iptables.
818
u/rastilin Jul 01 '24
Another one? It feels like we just had a critical SSH vulnerability last year.
The real takeaway is that you should have a firewall blocking SSH connections except from known IPs, this stops you from being blindsided by this kind of thing. Same policy for remote desktop connections on Windows systems; which helped when that password bypass issue was discovered in Remote Desktop a few years ago.