Virtualization Adapted Adapting Business Processes for Virtual Infrastrcuture (and vice-versa)

2011/08/11

ESX vSwitch L2 Security

Filed under: it,security,virtualization — Tags: , , , , , , — iben @ 11:58

VMware vSphere ESX Host Virtual Switch Layer 2 Security Features

The virtual switch has the ability to enforce security policies to prevent virtual machines from impersonating other nodes on the network. There are three components to this feature. These should all be set to “REJECT” to enable the security feature.

•Promiscuous mode is disabled by default for all virtual machines. This prevents them from seeing unicast traffic to other nodes on the network.

•MAC address change lockdown prevents virtual machines from changing their own unicast addresses. This also prevents them from seeing unicast traffic to other nodes on the network, blocking a potential security vulnerability that is similar to but narrower than promiscuous mode.

•Forged transmit blocking, when you enable it, prevents virtual machines from sending traffic that appears to come from nodes on the network other than themselves.

Cisco Nexus 1000v Switch Layer 2 Security

MAC ACLs

MAC ACLs are ACLs that filter traffic using information in the Layer 2 header of each packet.

http://www.cisco.com/en/US/docs/switches/datacenter/nexus1000/sw/4_0/security/configuration/guide/security_9mac_acls.html

Port Security

Port security lets you configure Layer 2 interfaces permitting inbound traffic from a restricted set of MAC addresses called secure MAC addresses. In addition, traffic from these MAC addresses is not allowed on another interface within the same VLAN. The number of MAC addresses that can be secured is configurable per interface.

http://www.cisco.com/en/US/docs/switches/datacenter/nexus1000/sw/4_0/security/configuration/guide/security_10port.html#wp1210839

DHCP Snooping

DHCP snooping acts like a firewall between untrusted hosts and trusted DHCP servers by doing the following:

•Validates DHCP messages received from untrusted sources and filters out invalid response messages from DHCP servers.

•Builds and maintains the DHCP snooping binding database, which contains information about untrusted hosts with leased IP addresses.

•Uses the DHCP snooping binding database to validate subsequent requests from untrusted hosts.

Dynamic ARP inspection (DAI) and IP Source Guard also use information stored in the DHCP snooping binding database.

http://www.cisco.com/en/US/docs/switches/datacenter/nexus1000/sw/4_0_4_s_v_1_2/security/configuration/guide/n1000v_security_12dhcpsnoop.html#wp1272686

Dynamic Address Resolution Protocol (ARP) Inspection (DAI)

DAI is used to validate ARP requests and responses as follows:

•Intercepts all ARP requests and responses on untrusted ports.

•Verifies that a packet has a valid IP-to-MAC address binding before updating the ARP cache or forwarding the packet.

•Drops invalid ARP packets.

DAI can determine the validity of an ARP packet based on valid IP-to-MAC address bindings stored in a Dynamic Host Configuration Protocol (DHCP) snooping binding database. This database is built by DHCP snooping when it is enabled on the VLANs and on the device. It may also contain static entries that you have created.

If an ARP packet is received on a trusted interface, the device forwards the packet without any checks. On untrusted interfaces, the device forwards the packet only if it is valid.

http://www.cisco.com/en/US/docs/switches/datacenter/nexus1000/sw/4_0_4_s_v_1_2/security/configuration/guide/n1000v_security_13arpinspect.html#wp1329252

IP Source Guard

IP Source Guard is a per-interface traffic filter that permits IP traffic only when the IP address and MAC address of each packet matches the IP and MAC address bindings of dynamic or static IP source entries in the Dynamic Host Configuration Protocol (DHCP) snooping binding table.

You can enable IP Source Guard on Layer 2 interfaces that are not trusted by DHCP snooping. IP Source Guard supports interfaces that are configured to operate in access mode and trunk mode. When you initially enable IP Source Guard, all inbound IP traffic on the interface is blocked except for the following:

•DHCP packets, which DHCP snooping inspects and then forwards or drops, depending upon the results of inspecting the packet.

•IP traffic from static IP source entries that you have configured in the Cisco Nexus 1000V.

The device permits the IP traffic when DHCP snooping adds a binding table entry for the IP address and MAC address of an IP packet or when you have configured a static IP source entry.

The device drops IP packets when the IP address and MAC address of the packet do not have a binding table entry or a static IP source entry.

http://www.cisco.com/en/US/docs/switches/datacenter/nexus1000/sw/4_0_4_s_v_1_2/security/configuration/guide/n1000v_security_14sourceguard.html#wp1096775

Reference Links

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

http://www.cisco.com/en/US/docs/solutions/Enterprise/Data_Center/vmware/VMware.html#wp696333

Labels:


2010/03/19

Number of ports to use for standard and distributed virtual switches

Filed under: virtualization — Tags: , , , , , , , , , , , , , , , , , — iben @ 14:30

VMware just updated their KB: Reserved or overhead ports for virtual switches (http://kb.vmware.com/kb/1008040) and we’ve run into this issue a number of times since upgrading to vSphere ESX 4. These new high memory hardware architectures allow an unprecedented number of virtual machine guests to be consolidated on a single ESX host.

By default a vswitch may not have enough ports to support the consolidation ratio your equipment can support. New ESX hosts can have 256 GB of RAM with 4 hex core processors and easily support 100 or more virtual machines. These virtual machines might have 1, 2, or more vNICs configured and each would need a port on the vswitch. One might imagine the need for 500 to 1000 ports needed per esx host. Why not just make it 2000 so we don’t have to worry about it later on?

Once you run out of vswitch ports you cannot power on any more vms on that host and even get errors about unplugged network cable.  Increasing the vSwitch port allocation seems easy enough, vmotion all workload off the host, put it in maintenance mode, change the vswitch config, reboot. Some system administrators run into this issue and decide to make the number of ports allocated to the vswitch really high to prevent this from ever being an issue. This can cause problems though.

There’s a limit of how many vswitch ports in total an ESX host has to hand out to it’s various vswitches. In addition, if security is a concern, you may start running firewall virtual appliances like vShield Zones or Catbird. WAN Accerators and Performance Monitoring tools like AppSpeed also require additional vSwitches to be created. Ports used on these vSwitches all take away from the total bucket of available ports.

Once 4096 ports are allocated to existing vSwitches you will not be able to add additional hosts to a vNetwork Distributed Switch either.

We also have the following Security Recommendation:

Only allocate vswitch ports to virtual machines on demand and as needed.

This will make it difficult if not impossible to “plug” a VM into the wrong network by accident. Testing for this can be done manually through the vSphere Client. If there are no ports available on a vSwitch then this is a positive test.

1. While connected to the vCenter Server Navigate to Home – Inventory – Networking in the vSphere Client and click on the vDS in question.
2. Click on the Ports Tab
3. If all of the ports in the list have a VM associated with it in the “connected”column then this is a positive test.

Deployment scenarios where a very large number of uplinks are teamed together on a single virtual switch might significantly impact the number of  ports on that virtual switch available for virtual machine use, and the overall size of the virtual switch might need to be adjusted accordingly.
 
The current port utilization data for virtual switches can be reviewed by using the esxcfg-vswitch –list command.
 
The current overhead utilization on a given virtual switch can be calculated by subtracting the Used Ports value for all PortGroups from the Used Ports value for that virtual switch.

Recommendation: Use VNDS vNetwork distributed Switches for all Virtual Machine traffic and limit the number of ports assigned to each standard vSwitch used for vmkernel and service console.

Standard vSwitch Procedure:

Note: A server reboot is required to apply the following configuration change.  Migrate the virtual machines off the ESX host to prevent any downtime.   On the vswitch there is an option to specify the number of ports the vswitch supports.  

To view this setting:

  1. Click the Configuration tab of the ESX host in the Virtual Infrastructure Client (VI Client).
  2. Click Networking.
  3. Click Properties.

  4. Click on vSwitch.
  5. Click Edit.

  6. On the General tab select the number of ports you want and click OK.

 

  • Reboot the ESX host for changes to take effect.

    • Reference Links

    Powered by WordPress