Objective 1.2: Secure ESXi, vCenter Server, and vSphere Virtual Machines

And here are the following topics underneath this objective:

  • Enable / Configure / Disable services in the ESXi Firewall
  • Enable Lockdown Mode
  • Configure Network Security Policies
  • Add an ESXi host to a directory service
  • Apply permissions to ESXi hosts using Host Profiles
  • Configure virtual machine security Policies
  • Create / Manage vCenter Server Security Certificates

I will try to take these one at a time.

ESXI Firewall

Working with services in the ESXi firewall is not too difficult, this can be done on a per host basis under the configuration tab for it or the manage tab using the web client. Most of my material will be using the web client since that is the way things are going. That being said there are a number of ways to work with the firewall settings. You can 1) Set a security profile set in a host profile and apply that to a host (or number of hosts). 2) You can use ESXCLI commands from the command line to customize. 3) You can go through the Web Client. The Procedure to do that would be the following:

  1. Go through the Web Client to the host you are looking to change.
  2. Click the Manage Tab and then click on Settings
  3. Now Click on Security Profile
  4. The Web client will now show a list of incoming and outgoing connections with the ports.
  5. You can select to enable or disable the rule.

You can also allow or restrict these services to specific IP address. By default all IP addresses are allowed.

Lockdown Mode

Lockdown mode has been created to increase security to your hosts. Those of us familiar with vSphere 5 were already of there being a lockdown mode available for your hosts. For vSphere 6 there is now an additional lockdown mode available for use. Strict Lockdown Mode. The lockdown modes now shape up like this:

  • Normal Lockdown Mode: This kills access to the machine through the client to the host, and will deny root access through SSH. However you can still access the physical machine and DCUI is still able to be logged into and used.
  • Strict Lockdown Mode: This will also disable the DCUI client. If there are no exception users and it loses access to the vCenter server, you will need to reinstall the host.

In order to enable Lockdown mode you need to perform the following steps:

  1. Navigate to the host in the object browser that you want to modify
  2. Click on the host and then on the Manage Tab.
  3. Click on Settings and then click on Security Profile on the left side.
  4. Scroll down until you see the Lockdown Mode Section
  5. Click on Edit and choose desired Mode.

Configuring Network Policies

So configuring network policies, what are they talking about? Perform the following steps

  1. Navigate to the host you are interested in and click on Manage Tab for that host
  2. Click on the Networking Button
  3. Click on the Virtual Switches
  4. Now Depending on whether you want to change the vSwitch or Port Group you would click on the pencil associated with that object.

Now at this point you can decide to work your security magic on either on the Virtual Switch itself or you can impose your will on the Port Group. Your options are the same either way just where they want to apply the policy and if they want the same one on everything, or just a subset. Your Options are as follows:

  • Promiscuous Mode: Reject(Default) or Accept
  • MAC address Changes: Accept(Default) or Reject
  • Forged Transmits: Accept(Default) or Reject

So what do these options mean?

Promiscuous mode being set to Accept will remove the filtering on by default and will receive all traffic observed. This can be useful if you are running Wireshark or some other IDS or packet sniffing program. Otherwise you would generally leave this off.

MAC address changes setting affects the traffic that a virtual machine receives. If set to Reject, ESXi won’t honor requests to change the effective MAC address to a different address than the initial MAC address. The Initial MAC address is set for a vNic when ESXi assigns the NIC to a virtual machine. The OS sees the vNIC with a MAC address and should use that MAC address and it becomes the effective MAC address. Occasionally you might change this to receive traffic coming to a different MAC, such as in the case of Microsoft Network Load Balancing. Where the OS would present a separate NIC to load balance and you want the VM to receive on that MAC address. You would need to make sure that the setting was set to Accept in this case.

Forged Transmits setting affects traffic the virtual machine sends. When this is set to accept ESXi does not compare the source and effective MAC addresses. If the OS tries to send out traffic as a different MAC then ESXi sets for it, and this is set to Reject, ESXi will drop the packets into the bit bucket (trash). The guest OS will most likely assume that the packets are being dropped.

Add an ESXi host to a directory service

Adding an ESXi host to AD or LDAP is not difficult at all. Just follow the following steps:

  1. Navigate to the host, and then click on Manage
  2. Click on Settings and then scroll down to Authentication Services
  3. The top section has to do with adding the host to a domain, so click on Join Domain
  4. You are now presented with a box for Join Domain
  5. Enter in the Domain and User Credentials (will need to be a user in the Domain with admin privileges) and click OK
  6. When it is successful, your Domain will show up and Directory Services Type will say the type of Domain (Active Directory) you chose

 

Apply Permissions to ESXi Hosts using Host Profile

I assume that if you have gotten this far and you are taking a delta exam and not starting from scratch, that you have at least a rudimentary idea of what host profiles are. However just in case, a host profile is a list of host configuration options that can be applied to a host/s or a cluster in order to keep your machines as close to each other as possible. This can come in handy for you as the administrator, since they are centrally managed and can improve efficiency, compliance, and also enable you to use time saving features such as Auto Deploy. You also need to have the proper licensing in place to be able to use this feature. This requires Enterprise Plus licensing.

Creating a Host Profile is simple. You can do it one of two ways. You can either navigate to the host you have configured to use as the reference host and then right click and Host Profile and Extract Host Profile like the below

Or you can navigate right to Host Profiles from the Home Screen

And then after you click on the Host Profiles. You can click on the (+) sign to add a new. It will then pop out a screen and ask you what host you want to use as the reference host.

After you create the Host Profile, then you can go back in to edit if you need to as well. You will need to do this by going to the Host Profiles screen from the Home Menu as mentioned above. After you get there you can click on the Host Profile you want to edit and click Edit Settings. Some of the settings you can set are seen here.

After all that is done, from the same screen, you will need to attach the host profile to a host/s or cluster/s. Then you can run a scan against them to see if they are compliant or not. If not you can Remediate them to bring them into compliance.

Configure Virtual Machine Security Policies

For security it is good to think of your virtual machine the same as a physical machine. You have all the same abilities as a physical machine for securing, firewall on the VM itself and make sure you restrict who has physical access to the VM, and of course patching. You have a number of advantages in these things though since you are using a VM. You can employ things like templates to create a fully patched version of your server when you bring it up, reducing the time it takes to secure it. You can also restrict ability to use the VMRC or Remote Console. The ability to use this should be treated the same as a person having physical access to the machine.

There are other things to also consider as well. Such as if someone were to gain access to the machine, he/she could possibly introduce a program that would start eating resources in your environment. If this were to go unchecked, it runs the possibility of not only affecting that virtual machine but also all others sharing the same resources. You can use something like limits or shares to prevent this from happening.

Also as always, only give the VM what it needs to run. Don’t have unnecessary hardware or features that you won’t use on it. You can disable things like copy/paste and Host Guest File System to further increase your security. Finally we have,

Create / Manage vCenter Server Security Certificates

Personally in the past, I have always let VMware handle the certificates for me, however if you have a need for replacing the self-signed with ones that are signed by a third-party or enterprise certificate authority, VMware can definitely accommodate you. If you have been working with them in previous versions, you will need to know that the 5.5 certificate replacement tool will not work for 6.0 due to the new architecture. There are certs used for just about all authentication services in VMware now.

For vCenter Server, you can use the following to view and replace certificates:

  • vSphere Certificate Manager Utility – You can perform all common certificate replacement tasks from the command-line
  • Certificate Management CLIs – Perform all certificate management tasks with dir-cli, certool, and vecs-cli
  • vSphere Web Client certificate management – View certificates, including expiration information

There is a lot of information included in replacing or regenerating certs in the VMware environment and some of it depends on which cert you are replacing. The CLI tools you can use to do this are as follows:

  • certool – this allows you to generate and manage certificates and keys. This is part of the VMCA
  • vecs-cli – This allows you to manage the contents of VMware certificate store instances. This is part of the VMAFD
  • dir-cli – This allows you to create and update certificates in the VMware Directory Service. Also part of the VMAFD

Core Identity Services

  1. vmdir – This handles SAML certificates management for authentication with vCenter SSO
  2. VMCA (VMware Certificate Authority) – Issues certificates for VMware solution users, machine certificates for machines on which services are running, and ESXi host certificates. VMCA can be used as is, or as an intermediary CA. VMCA issues certificates to only clients that can authenticate to SSO in the same domain.
  3. VMware Authentication Framework Daemon (VMAFD) – Includes the VMware Endpoint Certificate Store (VECS) and several other authentication services. VMware administrators interact with VECS; the other services are used internally.

Certificate Management Tool Locations

  • Windows
    • C:\Program Files\VMware\vCenter Server\vmafdd\vecs-cli.exe
    • C:\Program Files\VMware\vCenter Server\vmafdd\dir-cli.exe
    • C:\Program Files\VMware\vCenter Server\vmcad\certool.exe
  • Linux
    • /usr/lib/vmware-vmafd/bin/vecs-cli
    • /usr/lib/vmware-vmafd/bin/dir-cli
    • /usr/lib/vmware-vmca/certool

Just due to the sheer depth of certificate management I will defer to the guide for further direction.

 

 

 

 

 

VCP 6 Delta Beta Exam Study Material (series)

Objective 1.1: Configure and Administer Role-Based Access Control

Ok so starting off with the first objective here. Underneath are the following topics:

  • Identify common vCenter Server privileges and roles
  • Describe how permissions are applied and inherited in vCenter Server
  • View/Sort/Export user and group lists
  • Add/Modify/Remove permissions for users and groups on vCenter Server inventory objects
  • Create/Clone/Edit vCenter Server Roles
  • Determine the correct roles/privileges needed to integrate vCenter Server with other VMware products
  • Determine the appropriate set of privileges for common tasks in vCenter Server

So first it is good to go over a few things. We will start with the type of permissions that are available to us.

In order to perform tasks on objects or be able to view properties or even log in, we need to have the proper permissions associated with the user we are logging in with. We have:

vCenter Server Permissions – These permissions are assigned through the vCenter for an object that the vCenter manages. This permission is made up of one or a number of privileges that you are allowing this user to have for that object. This would include things such as modification of a VM or creation of datastores etc.

Global Permissions – These are permissions assigned to a user that needs to access more than one solution. For example a user needs to access not just vCenter but also vRealize Operations Manager. This is a permission that spans across the whole vsphere.local (or whatever you named your SSO domain) These are also replicated across the domain.

Group Memberships – These are permissions associated with a group. It is much easier to apply permissions to a group and then just add or remove a user rather than assigning roles to a user every time you need to change. A user can me a member of more than one group and will receive the union of the privileges associated with the groups (keep in mind that most restrictive applies)

ESXi Local Permissions – This is only for managing a single ESXi host.

The Permission Model

There are 4 concepts that make up the permission model. Permissions, Users and groups, Privileges, and Roles.

Permissions – Every object in the vSphere world has associated permissions. These permissions specify what privileges that group or user have on that object.

Users and Groups – You can only assign permissions to authenticated users or groups. These can either be the built-in users and groups in vCenter or they can be from one of the added identity sources (such as AD).

Roles – Roles are predefined sets of privileges. Instead of having to find out what permissions you need to assign to a user or group, every single time. You can gather privileges into a single Role – such as VM Creator, to easier assign them. There are a number of them already pre-defined in vCenter for you

Privileges – These are the fine grained access controls. You group these into Roles.

Assigning permissions.

There are a few things to keep in mind when assigning permissions. You can assign permissions to a Parent object so that the child objects can inherit the permission as well (If inheritance is on). Child permissions will always override Parent permissions. What does this mean? If you were to create permissions on a child object that deny being able to modify it, even if the user has admin rights on the parent, he will not be able to do so.

A user will also receive the aggregate of the groups he/she are added to. If one group has read permission and also belongs to a group with modify permission, that user will get both of the permissions. Now if one of those groups happens to be more restrictive, such as a Read-Only permission or Access Denied, then that will take precedence no matter what other group they belong to, for that object.

In order to Add Permission to an Object you need to do the following:

  1. Browse to the object you that you want to add the permission to in the Object Navigator
  2. Click on the object and then click on Manage tab and then under that click on Permissions

pic1

 

  1. Click on the Add (+) icon and then on the Window that comes up, click on Add
  2. Click on the Domain and either choose the SSO Domain or Identity Source where the user resides

pic2

5. After the user is selected you then need to assign a Role that has the desired access you wish to assign          to this user – Also choose if it propagates to children objects or not.

6. Click OK and your user should now show up in the middle pane

pic3

 

That’s all there is to it. To modify, just click in the middle pane on the user you wish to modify and then click on the pencil.

To remove, click on the user you wish to remove and then click on the red ‘x’.

 

The above assumes you have the privileges you want for that user already setup in a role. If you don’t you will need to first create a role with the needed privileges.

 

If you don’t you will need to do the following.

From the Main Home Screen, click on Administration on the Object Navigator Pane (left pane)

  1. Click on Roles on the left hand pane
  2. You can now choose from either creating a new Role from scratch or copying one of the existing Roles and then Modifying it. To create a new Role click on the plus sign (+) if you wish to copy an existing, click on the Role you wish to copy and then click the Clone Role Button.
  3. When you create a new Role you are presented with a box to give it the name of the Role and underneath all the privileges available to assign to it.

pic4

4.    If you decided to choose door number 2 and clone an existing role this is what it                  might look like.

pic5

5.  You would then go in just like the other, and choose what privileges you want that              role to have.

Incidentally you would go to the same basic place for global permissions as well. The Global Permissions are there to give a user/group privileges to all objects in a hierarchy.

  1. Go to Administration from the Home Screen and then click on Global Permissions

pic6

  1. In order to add to it, once again, click on the plus sign (+). Or to modify, click on the object and then on the pencil icon.

In order to assign Global Permissions, you need the .Permissions.Modify permission privilege on the root object for all inventory hierarchies

There are a number of Default Roles to be aware of as well. They are as follows:

Administrator Role – Users assigned this Role are allowed to view and perform all actions for this object. By default administrator@vsphere.local has the Administrator role on both vCenter Single Sign On and vCenter Server after installation.

No Access Role – Users assigned this role cannot view or change the object in any way. All new users and groups are assigned this role by default. The only users not assigned this by default are the Administrator@vsphere.local, root user, and vpxuser.

Read Only Role – Users assigned this role are only able to view the state of the object and details about the object. They cannot view the remote console and all actions on the menu and toolbars are not allowed.

Required Privileges for Common Tasks

This is where it starts getting tricky because everything is very granular. You need to think of not just the privilege that you are assigning but also what are you performing it on. I am going to just “borrow” the table from the PDF. And only the Create a Virtual Machine. For the rest of them feel free to view the PDF.

pic7

Here is the link to the Security Guide – http://pubs.vmware.com/vsphere-60/topic/com.vmware.ICbase/PDF/vsphere-esxi-vcenter-server-60-security-guide.pdf

Alright. I think that about covers this particular point. Next up will be Objective 1.2 on Securing ESXi, vCenter Server, and vSphere Virtual Machines.