Preventing unauthorized SSH access

With the increase of interactive intrusions (60% YoY - More information is available on the CrowdStrike Global Threat Report), instead of looking for the latest technology available in the world, I believe we really need to do the basics well. In short, interactive intrusions are the ones where the Threat Actor behaves like a system admin or an advanced user, manually moving between systems using native tooling and protocols so they can go undetected by EDRs and other security controls. I believe there is no magic and no silver bullet to stop these kind of intrusions, what you need to do is a layered security model that tackle the main vectors or avenues known to be leveraged by adversaries.

One of the critical pieces is to secure access to your Linux servers. Several companies have an enterprise password vault/Jump Servers/PAM solution where all SSH access must go through this platform before you can reach the target servers such as database servers, file servers, web servers ,etc. So ideally, an user would never be able to access a database servers using SSH directly. ideally all access must go through your jump servers so it can be controlled, audited, etc.

While PAM does a good job in rotating passwords, recording SSH sessions, etc. We need to be realistic and sorry to say that most intrusions I was involved in the last 3 years, had one of the top # 3 PAM players already deployed. It doesn't means that PAM doesn't work and also it doesn't means that PAM vendorA or vendorB doesn't work. What really happens is that Threat Actors are always evolving and there are techniques/attacks they can use besides how many times you rotate privileged passwords in a day.

One of the things we can do to avoid these attacks such as pass the hash, skeleton key, kerberoasting, or even unauthorized access using valid credentials, is to make sure that all SSH access is just allowed if initiated from your PAM/Jump systems. So in this case, the Threat Actor would need to break into your PAM solution or Jump servers first, before they can pivot to your database servers for instance. And we know that while it's not impossible it will be a lot harder. Same applies to RDP access. Desktop Firewalls also helps, however, mainly for large organizations it is not effective since you will need to rely in an agent installed on every single endpoints experience tells me that we would always have blind spots, so it's a lot harder to control/manage.

If you have your Linux servers are joined to your Active Directory domain which is something pretty easy to do nowadays, you can use CrowdStrike to monitor the authentication traffic in your Domain Controllers, and then block any SSH/RDP access to our critical severs unless they are coming from your authorized Jump Servers, PAM systems, etc. You will spend 10 minutes to create a rule like that and believe in me or not, it will greatly increase your security posture against interactive intrusions. If you would like to see this use case, please watch this video.