Objective 2.7 – Build Security Requirements into the Logical Design

This objective refers to the overall security of the whole Virtual Infrastructure. As the Virtual Infrastructure grows by day so does the security concern for it. As of today most of the Tier 1 Applications/DB’s run on Virtual Machines, so it is important to protect the data and ensure it doesn’t reach the wrong hands.

Let us look at some of the measures we can take to mitigate the security risks:

  1. Do not allow a single person in the organization to access the whole Infrastructure, this poses security risk if that person suddenly disappears. It is important to provide role based access to different teams, such as Networks, Storage, ESX Admins and so on…this will ensure that business or end users are not dependant on single person or team.
  2. Rather than assigning individual permissions on objects in the vCenter, it is recommended to create roles with appropriate privilages and assign Groups to those roles. This will ensure centralized access control and restricted privilages (based on roles) to the users in the environment.
  3. Proper access control is important, what if someone suspended a Tier 1 application VM? what if someone cloned a VM and stole the data? what if someone snapshotted a VM which took up huge space in the datastore causing other VM’s to be in suspended state? So it’s important to understand which group is authorised to perform which task. This can be achieved by creating roles and granting required privileges
  4. Do not allow the users to login as root on the Console, instead create local accounts on the ESX (which requires the user to run the root commands using sudo) or integrate it with Active Directory. For ESXi the permissions can be managed through vSphere Management Assistant (vMA)
  5. From security perspective it is recommended to segregate all kinds of Network Traffic through VLANS (vMotion and IP storage traffic should be on a non routable network/VLAN) to avoid a man in the middle attack. Especially for vMotion because everything is migrated over the network and the traffic isn’t encrypted at all
  6. Change Management is the biggest challenge when it comes to Security, Changes should be well documented i.e. Description, Justification, the impact of the change, the risk assement, who is gonna do what and who are the mandatory approvers, the implementation details, whether the change has been tested, the backout plan and so on….without these mandatory details its difficult to control the unintended outages caused by change control
  7. If at all you are planning to join the vCenter Servers in Linked Mode, If a user or group has Admin  privileges on the top level, these permissions are propagated down the tree and that person/group will have admin access on every single object in all the vCenter Servers that are in Linked mode. So ensure the privileges are defined correctly
  8. There should be proper Audit Control and Compliance in place. Host profiles are a best fit to check the Cluster and ESX/ESXi host compliance, but it requires enterprise plus license though. Apart from external audits, there should be an internal audit to ensure all the changes to the Infrastructure are well documented

Let us look at the DMZ setup in one’s environment:

The Virtual Infrastructure will be required to host Virtual Machines which have external-facing interfaces. there are 3 options that can be explored for DMZ configurations:

Partially Collapsed with Seperate Physical zones: This kind of setup requires you to install seperate ESX Cluster in each phycsicall zone so that the application types and security risks are completely seperated. This is an easy solution with less complex configuration and less miconfiguration, but not cost effective and more importantly it does not use Virtualization to its full operational efficiencies.

Partially Collapsed with Seperate Virtual zones: In this setup your Virtual Machines are hosted on the same ESX/ESXi Cluster but rather they are seperated through network connections of each zone, with firewall seperating the different network zones on the network level. This canbe achieved by creating seperate vSwitch for each zone or by using 802.1q VLANs. Although it comes with greater complexity and more error prone as lot of manual configuration is required.

Fully Collapsed DMZ Zones: In this setup, the firewalls are placed on a Virtual Appliance which handles network segregation thus removing the physical firewall. This is much comlex to setup and requires regular audit complaince to ensure everything is configured as expected.

Let me highlight Top 5 items from the Security hardening Guide:

ESX/ESXi host:

  • Disable ESXi Shell access
  • Disable SSH
  • Disable DCUI when required actions can be performed via vCenter Server
  • Enable Lock down mode
  • Enable syslog on a remote server, centralized logging and easy to retain the logs if the host has rebooted unexpectedly


  • Disable all the unsued hardware i.e. CD/Floppy, Serial Ports and so on….
  • Secure your VM as you would in a physical world, by applying recent security patches, Antivirus etc…
  • Limit console sessions if possible, should really use RDP in case of Windows and SSH for Linux
  • User templates whereever possible so that all your Virtual Machines are compliant


  • Isolate the Network Traffic using VLANs, especially vMotion and IP Storage traffic on non routable network
  • Ensure the port groups are labelled correctly which match your Infrastrcuture’s network naming standards
  • Use the appropriate Security Policy, by default, Promiscous Mode is set to Reject, Forged Transmits and Mac Address Changes are set to Accept
  • no native vlan as 1, because frames from ESXi specified as VLAN 1 will be tagged with a “1” which is not the case for cisco, because frames on VLAN 1 from a Cisco physical switch will be untagged, because this is considered as the native VLAN
  • Disable Spanning Tree Protocol or enable PortFast on external switches
  • As a best practice, it is recommended to set the ESX/ESXi host’s NIC to Auto Negotiate


  • Install vCenter with service account
  • As usual, the vCenter should be patched regularly
  • If Possible, place vCenter & VI Client and ESXi hosts between firewalls

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s