New Year… Brings Changes

With the New Year brings some new changes; I am transferring inside of VMware to a new group that is focusing on Cloud Consumption.

Cloud Consumption… WTH is that?

For the past, well as long as I have been in IT, I have been doing ‘Ping, Power and Pipe’. With IaaS it is in my opinion it has been done, most any experienced IT person could stand up IaaS.

In my new role I will be focusing on methods to consume the cloud offerings. For example, how does one define a service (in the ITIL sense) from this ‘Ping, Power, and Pipe’? Another example, what requirements does a consumer have? How can the cloud offering satisfy those requirements?

More importantly… “Define the services that consumers will utilize, while driving the architecture of the physical”

Happy New Years! 2013 will most definitely be a challenging year.

Symform Security Analysis

This morning on twitter I was asked if Symform “Secure Online Backup” was as secure as SpiderOak (my favorite online storage/backup solution). Here is my analysis from reading Symform’s publically facing documents.

How it works:

According to Symform’s website, your data is processed at the folder level. Meaning that all files in a folder are encrypted together. This does give the benefit of being able to de-duplicate the files inside that folder, it is not clear if this is at the block or file level though. If done at the block level this would be analogous to compression, if done at the file level I would image not much savings in space since it is uncommon for duplicate files in the same folder.

These files are encrypted with AES256 (good job there), but what generates this key? Since there would be a separate key per folder/container it would be near impossible for the end user to manage these keys. That means the Symform Cloud Control is generating and managing these keys for you the end user. (This is confirmed by their own documentation)

After your files are encrypted (in 64MB folder chunks), they are then broken into 1MB chunks. Parity fragments are then generated out of those 1MB chunks, 32 parity fragments to be exact. Those parity chunks are then sent out to the Symform Global Cloud Storage Network, and distributed to 96 devices.

Analysis:

That seems fine right? Your data is spread among 96 random devices on the internet, encrypted and secure.

Well that is the problem, who controls the decryption/encryption keys? Symform does.
Who controls where your data is stored on this ‘Global Cloud Storage Network? Symform does.

From a stand point of Trust No One, Symform fails the test. A hacker can still get your AES keys, and the location of those blobs on the internet. A government agency can still subpoena for your data, and have access to the decrypted data.

While it looks like a neat technology, SpiderOak still wins in my opinion, since I control the encryption keys and where my data resides (Amazon S3 storage).

Host Isolation Response Settings

Over the past few weeks I have had some people ask what I would recommend for host isolation addresses and responses, when using vSphere x.x with high availability (HA) enabled.

First off as with most everything in computers ‘It depends’.

Items to consider with host isolation response is what type of storage is being utilized? Is it considered an outage if the vSphere hosts can talk to each other but the virtual machines (VMs) cannot? How stable is my management network? Is datastore heart-beating setup correctly? The list can of things to consider can be quite long.

Here is what I generally recommend…

NAS Based Storage Options (iSCSI or NFS)

First, set one of the host isolation response addresses to the virtual IP (VIP) or the IP of the storage array. This will tell you if you can at least talk to the array; chances are that is you cannot talk to the array your machines have already failed.

That brings me to the isolation response, since the VMs should already be dead, remember the NAS array and host are no longer able to communicate, I recommend ‘Power Off’. If you were to leave the response to ‘Leave Powered On’ you can run into a chance of corruption on the guest disks. Think about it, the disk goes away for 60 seconds, then comes back. Do you think that VM is going to be able to recover, what are the odds of it corrupting that vital disk? What about ‘Shutdown Guest’, well that has a chance of the same exact thing happening.

Power Off in this setting is the safest setting, not only will it allow for that VM to be brought up elsewhere, you run a less chance of corruption or VM failure.

Fiber based storage (SAN)

With fiber the network isolation address does not matter as much, reason being the storage is not relying on the network for communication.

General Host Isolation Techniques

If it is considered a down time for the VM network to fail but not the management network, is there a way we can mitigate this?

Of course, put a vmkernel port on the virtual machine network, enable it for HA traffic, then place an isolation address of that networks gateway in to the HA configuration.

vCNS App – Spoofguard Deployment

Spoofguard records the IP address of each vNIC secured by vShield App. Spoofguard can be configured in two different modes, automatic and manual.

In Automatic mode the first IP that is presented for each vNIC is recorded and allowed to communicate without authorization. If the IP of the vNIC changes, the machine will no longer be able to communicate on the network until the new IP is approved.

In manual mode all IPs must be approved prior to being allowed to communicate; even existing virtual machines will be blocked until approved.

When enabling Spoofguard in an environment where there are existing virtual machines, it is recommended to enable Spoofguard in ‘Automatic’ mode. Once the vNICs are learned and reviewed it is then acceptable to switch to Spoofguard to ‘Manual’ mode, which will restrict all new virtual machines from communicating until approved. When deploying vShield App to a greenfield environment Spoofguard can be enabled with ‘Manual’ mode.
Once Spoofguard has flagged a VNIC for approval, it must be approved prior to traffic being allowed to transmit. This is true even if Spoofguard is later disabled; all VNICs that are in ‘Require Approval’ will require approval before they can transmit.

When utilizing vShield App in a vCloud Director environment Spoofguard should not be enabled. The reason for this is that when vCloud Director brings a virtual machine online for the first time the machine will boot up and broadcast an IP (either DHCP or a pre-defined IP). When the machine is fully booted the guest customization script takes effect and changes the IP to the one defined in vCloud Director. Spoofguard will learn the first IP and not allow the VM to communicate on the network until the new IP is approved. It is possible to use vCenter Orchastrator to automate this approval process; that discussion and how to is out of the scope of this document.

Spoofguard currently supports only one IP per VNIC, so one cannot specify a secondary or failover IP.

iOS 6 – Ad Tracking

You can disable (well limit) the ad tracking that is done in iOS 6. This setting turns off the ability for advertisers to use what is called the ‘Advertising Identifier’. This replaces the devices UUID which is a non-anonymous way of tracking usage. The advertising identifier is ‘anonymous’ (though further research needs to be done).

Here is how to disable the ability for advertisers to track you at all (once they move from the old deprecated UUID model).

  1. Fire up your iOS device
  2. Under Settings
  3. Find General
  4. Click on About
  5. Scroll to the bottom and select ‘Advertising’
  6. Set the ‘Limit Ad Tracking’ to ‘On’

You are done. Now go forth, untracked from iOS ads (the Apple ones anyway).

vCNS Edge 5.1 VIX_E_DISK_FULL ERROR Fix

VMware this morning released a KB article and a fix for the Edge devices filling up on disk space. While it did not kill the edge or cause an outage, it did stop you from being able to make changes to the Edge’s configuration.

The official fix will be released on this site: https://my.vmware.com/web/vmware/info/slug/securityproducts/vmwarevcloudnetworkingandsecurity/51

The upgrade/patch will require the standard vCloud Network Security (vShield) upgrade process where the Edge device will need to be replaced with the new code. (READ: Possible outage of network for a few moments while the Edge is swapped)

How do you know if you have this problem?

In vCloud Director, attempting a reconfig fails with this error:

VIXEDISK_FULL

In vCloud Director, when looking at Edge Gateways, you receive this error:

Edge VM backing the edge gateway is unreachable

Just remember, when this happens it is not causing an outage or a network failure. The edge is basically running ‘headless’ at that time, and will not accept any ruleset changes.

Browse Categories