Cisco 4500 Power Supplies

I've had several times where the question of what type of power does a switch require has come up during design and installs. How much PoE can it provide if we use this power supply or that one?

Here's a handy little web page from Cisco that I always struggle to find... It's all on the 4500 series power supplies and PoE capabilities and is great for determining whether you can plug in your switch or not...

http://www.cisco.com/en/US/prod/collateral/switches/ps5718/ps4324/product_data_sheet09186a00801f3dd9.html

Oh and I apologize for the lack of virtual-ness in the post, but I'm afraid that's how my posts will be. :)

VMware Static MAC addresses

I have come across the need for the static MAC addresses on many machines that I have P2V'd that have licensing tied to a single MAC.

Here is a great doc link and a a link to a tool to set many vm's at a time.

http://virtrix.blogspot.com/2007/04/vmware-configuring-static-mac-address.html


http://www.run-virtual.com/?page_id=173

Microsoft NLB in VMWare

I have been setting up MS NLB's for Exchange and Sharepoint for awhile now and have come across a list of best practices if building the environment in a virtual environment.

1.) You must use Multicast NLB’s – Unicast will cause failover and load balancing to occur very slowly or not at all due to ARP Cache not being refreshed and moved to new Virtual Hosts quick enough. The work around to make Unicast (Turning off Switch Notify) work will cause VMotion and DRS issues inside of vSphere. These should get you started

a. http://telnetport25.wordpress.com/2008/03/24/quick-tip-configuring-network-load-balancing-nlb-on-windows-2008-for-exchange-cas-servers/

b. http://msmvps.com/blogs/clusterhelp/archive/2007/10/05/exchange-server-2007-hub-transport-and-client-access-service-on-the-same-nlb-cluster.aspx

2.) By default server 2008 has IP forwarding disabled which means you either need to add a default gateway to the NLB Multicast nic (not desirable) or reenable IP forwarding (easy and preferred)

a. http://www.windowsreference.com/windows-server-2008/dual-nic-nlb-configuration-with-windows-server-2008-nlb-clusters/

3.) Because Microsoft cannot follow an RFC the MS NLB’s Multicast MAC address is not recognized by most hardware vendors by default. You will most likely need to statically add an Arp entry on your router. Here is an example for Cisco (provided by Rob)

a. http://www.cisco.com/en/US/products/hw/switches/ps708/products_configuration_example09186a0080a07203.shtml

SRM 4.0 Best Practices Guide

The SRM Best practices guide was released a few weeks ago.

Here is the link.  Very good read.
http://blogs.vmware.com/uptime/2009/12/vmware-vcenter-site-recovery-manager-40-performance-and-best-practices-white-paper-posted.html


and for those that want to play with SRM but dont have the equipment here is a guide on how to do it.

http://tendam.wordpress.com/2008/11/18/srm-in-a-box-final-release-the-complete-setup/

Awesome guide.

Another great place for guides is

http://viops.vmware.com/home/community/availability?view=documents

VMware VIEW4 Deployment

After doing a few of these a few things keep coming back and I wanted to point them out and give some links.

The desktop image has become the single most important factor is making sure your implementation is successful from the end user perspective.  This is the guide from VMware that is buried in the Administrator guide.

http://www.vmware.com/files/pdf/resources/vmware-view-xp-deployment-guide.pdf 

TCPDump has the best guides that I have seen when it comes to VDI deployments.

Desktop Tweaks

http://www.tcpdump.com/kb/virtualization/virtual-desktop/windows-xp-tweaks-for-view.html

General Link for VDI

http://www.tcpdump.com/kb/virtualization/virtual-desktop/ 

SSL Certificate guide, generate and install

http://www.tcpdump.com/kb/virtualization/virtual-desktop/installing-a-ssl-certificate-on-vmware-view/intro.html

ThinApp

http://www.tcpdump.com/kb/virtualization/virtual-desktop/thinapp-deployment-guide/intro.html 

VMware Security Explained

A great description on why we break out the service console from the network nics from the VMware security blog.


http://blogs.vmware.com/security/


October 6th Post

The Common Vulnerability Scoring System and VMware network isolation

The Common Vulnerability Scoring System (CVSS) is an standard for assessing the severity of computer system security vulnerabilities. CVSS is composed of three metric groups: Base, Temporal, and Environmental, each consisting of a set of metrics. For those not familiar with CVSS, here is a blog post Common Vulnerability Scoring System (CVSS) Explained.

1. Base: represents the intrinsic and fundamental characteristics of a vulnerability that are constant over time and user environments.
2. Temporal: represents the characteristics of a vulnerability that change over time but not among user environments.
3. Environmental: represents the characteristics of a vulnerability that are relevant and unique to a particular user's environment.

A software vendor can typically fill out the base metrics score because things are supposed to be constant. But it turns out that VMware products break the definition of a CVSS base score. A base metric is comprised of the following:

• Access Vector (AV)
• Access Complexity (AC)
• Authentication (Au)
• Confidentiality Impact (C)
• Integrity Impact (I)
• Availability Impact (A)

Now consider only the Access Vector (AV) metric. Here is the definition:

Metric Value	Description
Local (L)	A vulnerability exploitable with only local access requires the attacker to have either physical access to the vulnerable system or a local (shell) account. Examples of locally exploitable vulnerabilities are peripheral attacks such as Firewire/USB DMA attacks, and local privilege escalations (e.g., sudo).
Adjacent Network (A)	A vulnerability exploitable with adjacent network access requires the attacker to have access to either the broadcast or collision domain of the vulnerable software. Examples of local networks include local IP subnet, Bluetooth, IEEE 802.11, and local Ethernet segment.
Network (N)	A vulnerability exploitable with network access means the vulnerable software is bound to the network stack and the attacker does not require local network access or local access. Such a vulnerability is often termed "remotely exploitable". An example of a network attack is an RPC buffer overflow.

In this blog post I intend to show with VMware products the CVSS Access Vector (AV) can be different depending on how virtual networking is setup, and is thus affected by the user environment. Perhaps CVSS should consider moving the Access Vector metric from the Base metric set to Environmental metric set. I will show why it is so important to isolate your management network, because when using VMware's best practices the CVSS base score of many vulnerabilities will be reduced.

Consider the following scenarios.

In the following scenarios we'll take a look at an ESX system with several virtual machines. The virtual machines are connected to the Internet.

Scenario 1

This is where both the ESX Service Console (or the ESXi management network) and the virtual machine network are both on the same vSwitch which connects them to the Internet. Note this is NOT recommended! Most Operating Systems don't have virtual switches or layer 2 network isolation, and so they would fall under Scenario 1 where all networking is exposed to the Internet. This Leaves the CVSS Access Vector value to be Network.

Scenario 2

Here the management network is on a different vSwitch and on a totally different network then the virtual machines which are connected to the Internet. There is NO direct route from the Internet to the management interface, nor to the ESX Service Console. This is VMware's recommendation for platform security best practices and it provides an additional layer of protection. In this scenario using the CVSS definitions, the management network is on a local IP subnet or Adjacent Network, and the virtual machine port group is on the Internet or CVSS defined "Network."

Vulnerabilities

Now consider a vulnerability in the ESX Service Console. Let's take CVE-2008-4309, "a denial-of-service flaw was found in the way net-SNMP processes SNMP GETBULK requests. A remote attacker who issued a specially-crafted request could cause the snmpd server to crash."
The National Vulnerability Database rates this CVE as:
CVSS v2 Base Score:5.0 (MEDIUM) (AV:N/AC:L/Au:N/C:N/I:N/A:P)
But this also assumes the Access Vector is Network (AV:N). If you are following VMware's best practices, then your management network is isolated. There is no way an attacker from the Internet/Network can get to the management network stack, even if there is a flaw in the management network stack, thus the only Access Vector is through the Adjacent Network (AV:A). This adjustment in the Access Vector to (AV:A) from (AV:N) changes the CVSS score to:

CVSS v2 Base Score:3.3 (LOW) (AV:A/AC:L/Au:N/C:N/I:N/A:P)
This is just one example where a base metric Access Vector doesn't meet the CVSS criteria of "the characteristics of a vulnerability that are constant with time and across user environments" because of virtualization. While looking at CVSS we noticed a few other interesting conditions that need to be considered because of virtualization. But we'll leave that to another post.
All ESX Service Console vulnerabilities and ESXi management service vulnerabilities can also be modified when using VMware security best practices as shown above. The Access Vector is no longer just Network (AV:N), but it becomes Adjacent Network (AV:A) when using multiple virtual switches
So when evaluating security risk using CVSS consider how you have deployed your machines, consider how the networking is setup and if you are following VMware's best practices you may be able to lower your CVSS score to better reflect your risk. If you NOT following VMware's best practices, perhaps it is time to re-evaluate your security setup and consider isolating your management network.

DMZ on vSphere with Cisco Nexus Whitepaper

http://www.vmware.com/files/pdf/dmz-vsphere-nexus-wp.pdf

Great Whitepaper co-branded by both Cisco and VMware

VMware Distributed Switch

A great guide on what it is, how it works and how to migrate to it.

http://blogs.vmware.com/networking/2009/07/vnetwork-distributed-switchmigration-and-configuration.html