|
Objective 2.2 - Install and Configure a Virtual Networking Infrastructure to Meet set Security Design Requirements |
 |
 |
|
Written by Matthijs van den Berg
|
|
Tuesday, 20 January 2009 18:29 |
KNOWLEDGE
- Understand network segmentation benefits and best practices
Though it is theoretical possible to put all traffic for management en VMs in one network segment it is generally a best practice to segment different traffic types into separate network segment. These segments can be separated by a router, Firewall or remain isolated.
Reasons to separate networks can origin from security, management or performance perspectives. Best practices usually recommend the following network segments:
- Service Console
A segment for management of the Virtual Infrastructure. Because the Virtual Infrastructure can be compared to a physical hardware infrastructure that usually is protected by many locks and security systems. VMware recommends to separate Service Console traffic from storage, VMotion or VM traffic.
- VMotion
It is recommended to isolate VMotion traffic. VMotion traffic is unencrypted and should be separated from other traffic. Vmotion traffic generally created peak data bursts. The VMotion segment only need to be available on the ESX servers and does not have to be routed, meaning you can have a separate VLAN / switch for this purpose.
- iSCSI / NFS
Storage traffic should be separated from user / VM traffic because of the same reasons VMotion traffic shoud; performance and Security. The traffic also demands high bandwidth and is unencrypted.
- VM Networks
Client traffic from and to Virtual Machines should be separated from management traffic for security reasons and optional, depending on the applications, for performance reasons. When designing a client network layout also the VM security aspects should be taken into account like internet traffic and traffic from secure systems that should be separated. These consideration can lead to multiple VM networks.
More info regarding security considerations: http://www.vmware.co.nz/.
-
- Isolation of Service Console traffic
To separate Service Console Traffic VMware recommends:
- Create a separate VLAN for management tool communication with the service console
- Configure network access for management tool connections with the service console through a single virtual switch and one omore uplink ports
- As an alternative, you can choose to configure the service console on a separate physical network segment. Physical segmentation provides a degree of additional security in that it is less prone to subsequent misconfiguration.
- Isolation of VMkernel traffic
Use a dedicated, isolated network for VMware VMotion and iSCSI
- Because VMotion information is not encrypted, it is critical that this network be isolated from any other use. If you want to encrypt VMotion traffic, you have the option of using hardware-based SSL encryption.
-
- Vmotion and iSCSI generally generate large amounts of network traffic. It is recommended to separate this traffic on physical network adaptors and optionally physically separated switches.
- Define common network security risks and explain their impact to a virtual network infrastructure
- Label Virtual Networks Clearly
Risk: A VM can easily be placed into the wrong VLAN. This can for example lead to sensitive traffic n a non-secure VLAN.
Label all your virtual networks appropriately to prevent confusion or security compromises. This labeling prevents operator error due to a virtual machine being attached to a network it is not authorized for or to a network that could allow the leakage of sensitive information.
- Do Not Create a Default Port Group
Risk: A default portgroup is created on the same network as the Service Console. This can lead to VM’s sniffing the Service Console traffic.
During ESX Server installation, there is an option to create a default virtual machine port. However, this option creates a virtual machine port group on the same network interface as the service console. If this setting is left unchanged, it could allow virtual machines to detect sensitive and often unencrypted information. Since the service console should always be on a separate, private network, this option should never be used except in a test environment.
- Use a Dedicated, Isolated Network for VMotion and iSCSI
Risk: Because VMotion information is not encrypted, the entire state of a virtual machine could potentially be snooped on the network used for VMotion.
Therefore, it is critical that this network be isolated from any other use. If you want to encrypt VMotion traffic, you have the option of using hardware-based SSL encryption. Encryption is not available for iSCSI disk I/O, so you must keep this network strictly controlled, too.
- Use a Dedicated Network for the Service Console
Risk: Management traffic might be intercepted and (ESX) server can be connected to by all servers and PCs in the network.
To counter both issues described above it is recommended to separate the Service Console traffic from the VM en VMotion traffic. Personally I create a separate VLAN for the service console and the Virtual Center Server. Administrators connect to a public interface on the VCS for management.
- Do Not Use Promiscuous Mode on Network Interfaces
Risk: All VM’s can see all network traffic on that VSwitch and can sniff this traffic.
Promiscuous Mode let’s a VSwitch act like an old fashioned HUB. When promiscuous mode is enabled for a vmnic switch, all virtual machines connected to the virtual switch have the potential of reading all packets sent across that network, from other virtual machines as well as any physical machines or other network devices. When promiscuous mode is enabled for a vmnet switch, all virtual machines connected to the vmnet switch have the potential of reading all packets across that network — that is, traffic among the virtual machines connected to that vmnet switch.
- Protect against MAC-address spoofing
Risk: MAC address spoofing to impersonate another system
A guest OS can change the MAC address it uses to a new MAC address. This address then becomes the new valid address. A guest can impersonate a MAC address to gain access to a net work or perform attacks because the impersonated address is allowed on that network.
- MAC address changes
You can use the “MAC address changes” option in VMware to disallow MAC address changes. (default allowed - security recommended disallowed).
- Forged Transmits
Another way to secure MAC address changes is to enable “Forged Transmits”. This option checks the MAC Address field in the packets transmitted by the OS (default allowed – security recommended disallowed). If the MAC address field in the package does not match the configured address the package will be dropped.
- Describe and configure virtual switch security policies
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.
- 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
SKILLS AND ABILITIES
TOOLS
- CLI
- esxcfg-vswitch
- esxcfg-vswif
- esxcfg-vmknic
- VI client
|
