To enable the administration of your various virtual machines, storage, clusters, datacenters, and the like, you can now use the vSphere 5 Web Client. Before it can be used, it must be authorized; the best instructions I found for this are here. Follow the steps in the “Authorizing the vSphere Web Client (Server)” section. This is a one-time configuration necessary to enable the vSphere Web Client.

Once authenticated, you will see something that looks very similar to the Windows-based vSphere Client running in your browser.

This will satisfy most of your management needs, but it leaves out an all-important capability; the ability to remotely view the console of the systems. There’s a Console button, but it won’t work on a Mac. Once you’ve installed a machine, you can typically enable some sort of remote desktop capability in the operating system, but what do you do before then? If you’re running Windows, you use the vSphere client and open a console, but on a Mac, you’re out of luck. Right? Wrong.

There is an under-documented feature of vSphere that allows the capability of opening up VNC connections from the host directly to the console of the virtual machine. To perform this, we first have to enable incoming connections to your vSphere server, as vSphere 5 has an integrated firewall. This is the one step you will actually need to use the Windows vSphere Client; everything else can be done using the Web Client. This step needs to be executed once for each vSphere or ESXi host running virtual machines you want to access using VNC.

In the Windows vSphere client, choose the host you wish to enable VNC connections on. Choose the Configuration tab and on the left choose Security Profile. On the right, next to Firewall click Properties… As VMWare does not include VNC as a protocol, it is not listed as an available option. However the ports allowed by the gdbserver protocol will suit our purposes. Check the box next to gdbserver. (It is also wise to highlight the gdbserver line and click the Firewall… button and lock down where you will allow these VNC connections to take place from; in ours I restricted this to our intranet.) Click OK and you’ve now enabled the incoming ports to be used for VNC.

Finally, enabling VNC access to the console machines is a matter of setting advanced configuration parameters on each virtual machine, which can only be done when the virtual machine is off. To open up the advanced configuration:

• In the Windows vSphere client, choose the machine, click Edit Settings…, click the Options tab, choose Advanced->General on the left, and click Configuration Parameters… on the right.
• In the Web client, choose the machine, click Edit Settings… under the VM Hardware section, click VM Options, click Advanced, and click Edit Configuration….

In both cases, you now want to add three rows by clicking the Add Row button.

Once you’ve added these rows and click OK, you can now use a VNC client to connect to the console of the machine. Power up the machine, and then using Finder on the Mac, choose Go->Connect to Server (or hit Command-K), and type the following:

vnc://<ip or name of esxi host>:<port chosen in configuration settings>/

and click Connect. You will be prompted for your password, and depending on your client/version of OSX you may receive a warning about how keystroke encryption is not enabled. Accept the warning, and you will see the console of the virtual machine! (And note, since Macs don’t already use the three-finger salute, you can safely just press Ctrl-Alt-Del in that VNC-window to log into Windows systems!)

Once you’ve installed the operating system of choice, and enabled that OS’ remote desktop capability, you may want to disable this VNC access. Just shut down the VM, go back into the advanced options and change the RemoteDisplay.vnc.enabled setting to false.

Hopefully at some point soon, VMWare will enable a true web-based console application (which doesn’t require host-specific plugins to be installed) to go with their nice new web client. Until then, this is a reasonable workaround for accessing virtual machines using a Mac.

• Run deeper analytics across physicians groups and facilities, which can include relevant patient data…
• Provide a wide community of health professionals with feedback on the use and effectiveness of protocols…
• Share similar and alternative protocols and their analyses across many medical facilities and individual providers…

Anyone want to guess what’s completely missing from their approach?  You guessed it, any mention of security.  The commonly misunderstood (and frequently misspelled) HIPAA makes it pretty clear that the privacy and confidentiality of personal health information must be protected.  Even without HIPAA, it would just make good sense to be extra careful when sharing information and running data mining and analytics across large sets of health information.

The only mention of keeping information safe in the article is the fact that there is a division of data between the protocol, protocol modifications, and actual patient data – but it is very difficult to draw such bright, clear lines considering medical records and information.  How can you be sure the protocol modification a doctor submits won’t include information on the patient he tried it on?  Without even mentioning or considering the need for the protection of privacy, confidentiality, and data integrity within such a system, the authors of this article have done themselves and the software community a disservice.  Security requirements and threats must be considered at every phase of the life cycle, especially during the architecture phase.  As Kenneth Van Wyck and Mark Graff put it in their book Secure Coding: Principles and Practices,

As a general rule, the hardest vulnerabilities to fix are those resulting from architectural or design decisions. You may be surprised at how many of the vulnerabilities you have heard of we ascribe to errors at “pure think” time.

By developing an 8 page article published in a respected technical journal without any mention of the need for security controls in such a system, the authors of this article have once again helped me with my job security.  It is still difficult for me to foresee the day where security and risk management training programs won’t be necessary, and we won’t need an information security industry.

The basic gist of the attack is that a “normal” certificate is issued from a well-known and trusted CA (in this case “Equifax Secure Global eBusiness CA-1″) and then use the “magic” of MD5 hashing to create a certificate that collides with the “real” one, but just happens to be a CA. This CA can then issue certificates as they please, and your browser will trust them, no questions asked.

The details are a bit more in depth, and unless you study cryptography, you will find rather boring and dry. However, MD5 hashes have been known to collide in X.509 certificates since 2005, and this paper just takes it a step further and shows how bad this really is. The attack requires a little bit of money (to buy certificates) and some statistics on how the CA operates (how soon certs are issued, what the “next” serial number will be). Then a knowledge of how to collide MD5 hashes is used to create a new certificate – with the CA basic constraint set to “true”. Suddenly, you have a CA certificate that is trusted by all of the major browsers.

What does this mean for “normal” people? It means that an attacker can now create a site that looks just like your bank’s but takes your username and password, and your browser isn’t going to complain about it. You’ll have a lock, or a yellow location bar, or whatever your browser uses to indicate that the site is “trusted” and “secure”. However, you’ll be giving your username and password to the attacker.

What can you do about it? Immediately, remove the Equifax Secure Global eBusiness CA-1 from the list of trusted CAs – I’ve provided links below for how to do that on various systems and browsers. However, that is certainly not the only CA that is vulnerable, just the one that’s been proven to be vulnerable. There are several CAs listed in the linked paper that issue MD5 certificates – stop trusting them too. In the long run, the CAs have to fix themselves and stop using MD5 hashes in certificates. SHA-1 is better, and SHA-256 is best (good luck finding a CA that issues only SHA-256 hash certificates).

How to distrust CAs:

• OS X – Keychain. Double-click the CA in X509Anchors (Tiger) or System Roots (Leopard) and under Trust, select “Never Trust”.
• Firefox – The instructions are for the Comodo certificate, but it’s the same thing.
• Internet Explorer (and anything that uses MS CAPI, like Outlook).

Security personnel may at times place foreign visitors under surveillance.  Hotel rooms, telephones, and fax machines may be monitored, and personal possessions in hotel rooms, including computers, may be searched without the consent or knowledge of the traveler.  Foreign government officials, journalists, and business people with access to advanced proprietary technology are particularly likely to be under surveillance.

Therefore, we recommend the following approach for 2008 Olympics Visitors in order to keep their information and belongings safe:

• If at all possible, leave your computing devices home.  It will eliminate potential travel hassles, and alleviate the need to keep tabs on your things while you are out and about.  Enjoy the Olympic Games, and take a vacation from your email.
• If you bring a computing device, keep it with you at all times.  If you cannot bring the device with you, inquire at your hotel about a safe, or other secure storage area.  Hotel rooms and rental cars are prime places for theft to occur in China.
• Use file or disk encryption.  Products such as TrueCrypt or SecureDoc, or operating system capabilities such as Encrypting File System or BitLocker can keep your information safe even if your device is stolen.
• If you must write down passwords, secure them.  If you keep a post-it note with passwords on the lid of your notebook, the criminal may be able to use this information to get further access to the information in your machine or your networks.
• Keep your identification documents safe. Keep passports and other identification documents safe from pick pockets.  The State department recommends travelers make photocopies of their passport bio-data pages and Chinese visas and to keep these in a separate, secure location in case of passport theft.

We hope visitors to Beijing find this information useful, and stay safe during their visit to the 2008 Olympic Summer Games!