I am hoping that you have recovered from the scare I gave you in Part 1, and I hope that I gave you some food for thought in Part 2 with some action items that will further lock down your vSphere/ESXi environment. Here, we continue with the rest of VMware’s recommendations for decreasing the risk that a ransomware attack will be successful on your organization, dear reader.
I will also add in my usual commentary where appropriate.
A Side-rant To You 1337 h@xx0r Security Professionals Out There . . .
It may seem weird to start with a rant, but there’s a lot of teamwork mentioned in this one, especially with Security Professionals, and I would like to address them now:
We get it. You’re this generation’s Kevin Mitnik.
Your Profile Pic at work has a skull on it somewhere and/or you’re wearing a hoodie . . .
. . . indoors.
You socially engineered your way into getting free coffee every day on the days you have to come into the office. And no one is any the wiser.
You used to hack into your family’s router growing up to get access to the sites that your dad blocked. And he was none the wiser.
You know about hacks to systems that most IT people simply don’t and you’re proud of it. Some of which were found or made before you were even born.
And boy do you like saying so in meetings.
All of that doesn’t mean you get to humiliate people because they don’t know what you know. That’s not being a Security Professional. That’s just being an asshole.
My plea here is that you should be happy when people come to you for help and be a good educator about what they can do to make your life easier. In other words, don’t be a dick.
Now to the list . . .
Use Multifactor Authentication (MFA)
There are plenty of MFA vendors out there. Find the right one for you. It is a good idea to lock down your vCenter logins with this. It is possible to MFA your ESXi logins as well. In fact, that was in the recommendations in the aforementioned vSphere Security guide.
You can file this one under “Defense in Depth”.
Harden vCenter Like You Would Any Linux-based Appliance, and Don’t Forget About the VM-layer Security
In that same Security guide, there’s a tab in the Excel CSV to lockdown your VCSA. This is going to take testing and decisions. Many of the recommendations are Linux-based security lockdown processes, such as limiting access to SSH and enforcing password policies that match what you have on your ESXI hosts.
And while we are at it, don’t forget about settings on the VM that will secure them as well. This is all listed in that same Excel CSV file included with the VMware vSphere Security guide. Don’t forget about ensuring that individuals who have console access is following the rule of Least Privilege.
While we’re at it, don’t forget about locking down the vROPs appliance, or any other Linux-based appliance that runs VMware software.
Ensure Physical Security Measures Are in Place
An additional thing that keeps me up at night are attacks from the inside by the, “disgruntled employee,” or “1337 h@xx0r plugs into the network” and launches their attacks from a Kali Linux USB drive . . . YEAH!
There’s also the usual “employee clicked a thing that launched a scripted attack on their Windows machine client”. And that’s an important consideration. But what about someone plugging into the network and wreaking havoc that way?
If there’s an ethernet plug in the wall that is never used, it shouldn’t be enabled. And no one should have access to switch ports all willy nilly, of course.
Not to mention the usual physical proximity security: locking up all the things that are physical and locking down all the things that are technological.
Validate Network Segmentation and Consider Network Access Control
This one’s going to take some teamwork. At the very least, you should ensure that your Management Network is separate from, well, everything else. You should have a chat with your friendly neighborhood Network Engineer for this one.
And again, I can’t stress enough the importance of Defense in Depth here. Let’s say a “1337 h@xx0r” does plug into the network, which would be bad, by the way.
If you have the network properly segmented, then they should not be able to get into the Management Network aforementioned. Which means they at least can’t launch attacks against your ESXi hosts directly, or vCenter for that matter.
Also consider using Network Access Control (NAC). This measure ensures that if someone is able to get past physical security, and then they are able to make their way to a port that is open and enabled and running, and then they are able to find a way onto a network, their client machine must pass the muster of NAC.
This is yet another Defense in Depth strategy.
Ensure Regular Security Scans and Audits
Hey – more teamwork! Perhaps you have a security team that will do this for you. Perhaps not. The bottom line here is that a good and regularly scheduled Security audit, from perhaps software like Tenable, as an example, will help ferret out issues that you may not see on your own.
This is a good thing. Will it find every possible vulnerability? Maybe not. But it will at least allow for you to do your due diligence in standardizing your environment. Patch those machines that are not compliant, or configure them in a way that ensure it’s not vulnerable.
If anything, at least you have line of sight to those that are not compliant and can take action accordingly.
Speak With Your Backup Team About Ransomeware-aware Backup Utilities That Can Store Backups That are Unavailable to the Infrastructure.
In the year 2022, the best backup utilities will be what I call “ransomeware-aware”. Not to have any biases toward any backup or DR provider, but many of them have some feature base that will detect if a ransomware attack has been attempted, perhaps through file integrity checks or other methods.
Not unlike Virus Protection on desktops or servers, they will have a database of well-known ransomware-attack definitions to thwart them so you have a point in time definition of that very attack.
Furthermore, as mentioned previously, a lot of ransomware attacks (nasty little buggers that they are) will attempt to encrypt your backups too.
Ensure that whatever backup utility you are using that your DR architecture will have your backups inaccessible by the infrastructure at large, including DR that can be rebuilt while in quarantine.
Questions? Hit me up on twitter @RussianLitGuy or email me at bryansullins@thinkingoutcloud.org. I would love to hear from you.
Thinking Out Cloud 