With all the fuss going round about the latest Linux vulnerability you will probably get a request from your local Security Officer to produce a report which of your Linux systems are vulnerable to the Shellshock bug. And, seen there are already several known exploits, who can blame him for asking such a report.
Since a lot of these Linux boxes are running under vSphere, we can use PowerCLI to produce such a report. The Invoke-VMScript cmdlet is the vehicle I use in the following function. With the Invoke-VMScript cmdlet it is very easy to execute, what is considered the best test to check for the vulnerability.
Update2 September 29 2014: the 2nd test from the Shellshocker gives a syntax error. The test is replaced by the one found on Michael Boelen‘s website in How to protect yourself against Shellshock Bash vulnerability. Big thanks to for the pointer.
Update1 September 29 2014: the function was updated to include tests for most of the known Shellshock vulnerabilities. The tests were collected from the Shellshocker site.
Continue reading PowerCLI and the Linux Shellshock vulnerability
For good security measures you should change the password of your root account on your ESX(i) servers on a regular basis. Instead of logging on to each and everyone of your ESX(I) servers, you can easily automate this process.
But what about the new ESX(i) hosts you will roll out in between root password changes and where you use a Host Profile to configure these new ESX(i) hosts ? Will you need to run a script after the deployment to change the root password ?
Turns out that you can easily update the root password in your Host Profile with the help of an SDK method.
Continue reading Change the root password in hosts and Host Profiles
A couple of weeks ago Charu Chaubal published his draft vSphere 4.0 Security Hardening Guides in the Security & vShield Zones community. If you haven’t read them yet, you definitely have to put them on your To-do list.
A vSphere administrator often considers security as a necessary evil that he has to take care of at a point in time, preferably a few days before an audit is going to take place 😉
Charu’s Guides can make this exercise a lot easier. And if we add to those guides some scripts to automate the hardening process, the vSphere administrator has no more excuses to tackle security on a regular basis (like it should be !).