Security Hardening – Long White Virtual Cloudsu by

Runecast: Your Way To A More Trouble Free Virtualization Environment

Michael Webster — Sat, 08 Apr 2017 03:46:17 +0000

When you have a crisis in your VMware environment do you like manually finding a needle in a hay stack of needles to identify the root cause? Do you love spending endless hours with your fingers walking through knowledge base articles, google searches, and scratching your head while your users suffer? Do you have so much time on your hands that you want the sky to be falling so you can spend your after hours and weekends solving problems?

Hopefully the answer to all of the above is no. Most problems you encounter in your VMware environments will already be known issues, many times with a simple solution. Hopefully testing of the patches and upgrades, and combinations of hardware and software was also tested before going into production. But it’s really hard to catch everything and to constantly audit your environment against problems and configuration drift. When an ounce of prevention can prevent an avalanche of cure being needed, Runecast might be the solution you’re looking for. I caught up with the CEO and Co-Founder of Runecast, Stanimir Markov, in Melbourne recently to get the lowdown on what it is and how it can help customers prevent trouble in their VMware environments.

I’ve known Stanimir for a long time as he got his VCDX (VMware Certified Design Expert) shortly after I did. For those that don’t know VCDX is the top VMware certification that is held by a couple of hundred people in the world, people who have proven their VMware and solution architecture expertise. Which makes the knowledge that is built into Runecast all the more interesting.

So what does Runecast do? Well they have built a product called Runecast Analyzer, which they describe as follows:

Proactive VMware management solution that uses our expertise and VMware Knowledge Base articles to analyze virtual infrastructure and expose potential issues and best practice violations, before they cause major outages.

I think the last part of that sentence is the most important, i.e. doing something before it causes a major outage. Runecast uses machine learning and big data analytics and natural language processing to figure out what the VMware KB’s are saying, what the logs in your environment are saying, and what the configuration has been set to and then analyzing if the combination might lead to any issues. Anyone that has spent any time going through VMware KB’s knows this isn’t an easy task. By melding the VCDX knowledge, VMware KB, Logs, and config, and putting some very smart data scientists to work, Runecast Analyzer can continuously monitor and alert you to any irregularities that might potentially cause you a headache.

I really like the fact that Runecast Analyzer can be used in dark sites just as easily as in connected sites. It doesn’t rely on any live outside connection to do the data analysis and updates can be done offline. This is important in secure environments, such as Government organizations. Here is what the architecture looks like.

The Runecast Analyzer appliance can be deployed and operational within minutes and provides continuous compliance and monitoring across multiple vCenters. It’s a very simple and elegant solution to a very tough time consuming problem.

Final Word

If you are looking for a continuous monitoring, alerting and analysis platform to prevent problems in your VMware environment before they occur then Runecast is worth a look. It can help you reduce downtime, improve security, and reduce cost of VMware environments of any size. In the future it could well be expanded to include other parts of the VMware ecosystem including networking / switching. There are certainly a lot of opportunities for a product such as this to build on the current momentum and go into new areas.

This post first appeared on the Long White Virtual Clouds blog at longwhiteclouds.com. By Michael Webster +. Copyright © 2012 – 2017 – IT Solutions 2000 Ltd and Michael Webster +. All rights reserved. Not to be reproduced for commercial purposes without written permission.

Security Guides on VMware.com Have A New Home

Michael Webster — Fri, 24 Aug 2012 19:29:48 +0000

VMware has just announced that all their security hardening guides now have a new home. A single page that customers and partners can visit for all the latest hardening guides for vSphere and other VMware products. The url is http://vmware.com/go/securityguides. I would suggest you bookmark this now and visit it regularly.

—

This post first appeared on the Long White Virtual Clouds blog at longwhiteclouds.com, by Michael Webster +. Copyright © 2012 – IT Solutions 2000 Ltd and Michael Webster +. All rights reserved. Not to be reproduced for commercial purposes without written permission.

An Unbroken Chain of Trust is of Paramount Importance

Michael Webster — Sun, 29 Apr 2012 11:44:09 +0000

There has been a lot of coverage over the past week about Anonymous’ Hardcore Charlie releasing some old 2003/2004 code of the VMware ESX Hypervisor on the Internet. The release of the code may not cause anyone any immediate increased risk of attack. If you want to know why keep reading.

The reason I say that it will not likely cause any immediate risk of attack is because even if the code did contain some sort of vulnerability, the chances that your environment would be exposed is very low, provided some basic best practices have been followed. The hackers would have to first understand the code, and then find a weakness that could be exploited. You would have had to not been applying security patches and updates for an extremely long time, be on a completely unsupported version of the ESX Hypervisor, and the hackers would have to first infiltrate your environment. Chances are the security vulnerabilities that did exist in the code are mostly already known, and have already been patched. Just hope or check you’ve implemented the patches or have long since upgraded to a newer version.

One of my good friends Rogan Mallon (CISSP) has a good analogy that I think is appropriate to this discussion. Humans are vulnerable to bullets, you just need to take adequate precautions like Kevlar vests and not hanging out in the wrong part of town (like avoiding the middle of Kabul at night for example). This way you’re unlikely to get shot. The code fits into that category.

Infiltrating an environment is easier said than done, especially if you have a secure design, hardened your configuration, and implemented proper security controls. This could be as simple as having a separate management network for access to vCenter and your VMware hosts, with access limited to only trusted admins, having them log in as themselves, and having all actions go via vCenter. You should always follow the concept of least privilege and separation of duties. You should have the management network protected by firewall and it is a good idea to have a jump box, such as a terminal server or VMware View Desktops, VPN, or other secure mechanism to access it. The mere fact that your entire management infrastructure and access to the hypervisor is secured on a separate part of your internal network and limited to only trusted individuals reduces the chances of attack from any vulnerability that exists now or in the future. Just remember, vulnerabilities in things are found all the time, even in secure software, and you need to be prepared.

The easiest way to attack an environment is from the inside, either through an existing vulnerability, via social engineering, or a disgruntled admin. Attack from all of these things are possibilities at all times. This is why VMware goes to a lot of effort to produce the Security Hardening Guides and putting their software through Common Criteria Certification and other Security Tests, and recommends customers implement common sense security best practices. The impact of attack regardless of the probability could be unacceptably high. So implementing a secure infrastructure management design and following good security practices is of paramount importance.

This leads me to the title of this article. An unbroken chain of trust is of paramount importance when you are building your infrastructure. When you are building your environment, the foundation of your business, it is critical that you ensure the software you are implementing is genuine and hasn’t been tampered with. One of the avenues of attack I didn’t mention in the previous paragraph is through a Trojan or back door implemented in what looks like legitimate code. Fooling people into running Trojans is like a sport for hackers, and if security statistics are anything to go by there are plenty of people who are willing to run their malicious code. If you don’t obtain the version of VMware software from the VMware Website (or any other vendor software from the vendor website), and you don’t compare the md5 or sha hash against the software you obtain, you are putting your organization at unnecessary risk. Having an unbroken chain or trust is of paramount importance to ensure you are installing the genuine article and not a counterfeit or impersonator.

Just in case you hadn’t heard about the code leak here is some of the coverage from the past week.

Anonymous’ Hardcore Charlie disputes downplaying of VMware code
Anonymous’ Hardcore Charlie on the VMware leak and why he did it
Anonymous Hacker Claims Credit For VMware ESX Code Leak
VMware Confirms ESX Server Hypervisor Source Code Leak
VMware Security Note RE Source Code Leak

Final Word

Always remember the three Maxims of Cloud Computing: Hardware Fails, People Make Mistakes, Software has Bugs / Security Vulnerabilities.

Always take measures to protect your environment, it doesn’t have to be difficult or necessarily costly. Take a risk based approach depending on your organization risk profile. Seek advice from independent security professionals. Make sure you design your environment with basic common sense security best practices from day one. If you need help with your design or to review your design and your environment there are plenty of companies you can contact, including my company (via the author page).

—

vSphere Security Hardening Policy and SRM 5

Michael Webster — Thu, 12 Apr 2012 13:25:05 +0000

VMware is in the process of working on the vSphere 5 edition of the Security Hardening Guide and will shortly make a public draft available for comment (I’ll let you know when it’s available). This will be great news to the many people who have been waiting patiently for it since the vSphere 5 release. A lot of work is going into making this edition of the Security Hardening Guide much more user friendly and easier to use and implement. Many of the locked down items will be the same as in 4.1, and of course some changes and enhancements too. Another difference this time around is there are now new implications and restrictions on functionality introduced by the recommendations due to changes at least one popular VMware vCenter Management Tool. This is where Site Recovery Manager (SRM) v5 comes into the picture.

This isn’t going to be a log article as I want your opinion and I have two Yes/No Polls for your to answer. SRM v5 introduced a lot of great new functionality, workflow improvements, more logical and useful dependency mappings and start-up orders, greater scale, greatly improved performance for recovery plans and recovery operations. The performance of recovery operations are now significantly faster to run than in the previous version. However to get that performance increase VMware has changed the mechanism used to change IP addresses and communicate with the Virtual Machines for some operations.

If you’re not sure what I’m talking about check out the vSphere 4.1 Hardening Guide and search for VMX30 or VIX.

This change is significant if you apply the security hardening recommendations. SRM now requires that the VIX API be enabled on all protected virtual machines that will have their IP changed during recovery. There are no other options available. You either use the VIX API and live with the security risks, or you don’t change the IP addresses on the VM’s during recovery.There is no option to use the old change of IP address mechanism that was slower but didn’t rely on the VIX API, which would have been a very good option to have in my opinion. This has already caused me design problems in a number of customer environments.

If you don’t have a need to disable the VIX API because your security policy and vSphere Hardening policy doesn’t really justify this level of security then the change to SRM is going to be no problem and in fact extremely beneficial for you. Thins will run much faster. If however you have strict security and hardening policies and some of the VM’s targeted for protection require the VIX API to be disabled, and need an IP address change during recovery, you will have a problem and need to deal with it. There are a number of potential ways to solve the problem, but none are very elegant or easy to implement.

So this leads me to the two polls. Do you have a policy to disable the VIX API, and will this cause you a problem with SRM that might force you not to use it? Please let me know and get as many of the people you know to respond to this survey. If I get enough responses I will send this feedback onto VMware to review. If nobody cares enough about it, I’ll forget it and move onto something else.

Verify Security Hardening of vSphere 5

Michael Webster — Sun, 26 Feb 2012 01:40:46 +0000

At the moment there is no security hardening guide for vSphere 5, and the vSphere Compliance Checker is also not compatible with vSphere 5. Both will eventually be updated, but until then what can you do to ensure that your hardening configuration has been applied correctly? The answer is running the VMware vSphere Security Hardening Report Check Script that was developed by William Lam. However to make it work with vSphere 5 there is a slight modification that is necessary.

The script itself can be obtained from the VMware Communities Web Site at http://communities.vmware.com/docs/DOC-11901. The site also contains usage instructions and a lot of good comments and feedback. You can execute the script from any system that has the Perl SDK installed, which includes the vSphere Management Appliance (vMA).

To get the script to work against vSphere 5 hosts A quick modification of the script is required. Update parts of the script as follows:

from: @supportedApiVer = qw(4.0.0 4.1.0);
to: @supportedApiVer = qw(4.0.0 4.1.0 5.0.0);

The output is in HTML form which compares environment configuration against the vSphere 4.x Security Hardening Guide. The vSphere 4.x hardening guide is a good starting point even on vSphere 5.0.

A big thanks to Andy Morse at Datacom New Zealand for providing this information and bringing this to my attention.