vShield Zones is basically a firewall framework to protect your VMs without requiring external or hardware based firewalls. It requires Advanced or higher licencing. For study I’d suggest going through Eric Siebert’s blogposts (part one, two, and three) to start with (they cover real world issues) and then getting stuck into the official docs – they cover everything on the blueprint. There’s quite a bit to learn making this is one of the larger objectives on the VCAP-DCA blueprint.
NOTE: vShield Zones is NOT the same as vShield App, Edge, and Endpoint so make sure you download the right version. The VCAP-DCA exam only covers v1.0 of vShield Zones (not the most recent v4.1) and doesn’t cover the more feature rich vShield App Suite. See VMware’s product page for more details.
- Identify vShield Zones components
- Identify the four CLI command modes
Skills and Abilities
- Configure vShield Zones
- Backup and restore vShield Manager Data
- Backup CLI Configuration
- Create/Delete Layer 2/3/4 firewall rules using VM Wall
- Install/Uninstall a vShield manually and from template
- Configure vShield Manager plug‐in capability
- Configure VM Flow charts
- Update vShield Zones
- Add/Edit/Delete User Accounts
- Assign rights to a user
- Add/Delete Application‐Port Pair mapping
- Execute/Schedule Execution of virtual machine discovery
- Utilize vShield Zones CLI commands to configure and monitor vShield Zones
- Analyze traffic using VM Flow to determine root cause of network related issues
Installing vShield Zones
Deployed as an appliance with two components;
- Setup the vShield Manager appliance
- Deploy the vShield Manager from OVF
- Create a port group on the vSwitch which hosts your VM traffic, named vsmgmt and amend the vNIC on the vShield Manager VM to use this network.
- Power up the VM, login with ‘admin’ and ‘default’, then run ‘setup’ to configure the server.
- Allocate IP details
- Upgrade VMtools (you can use the ‘Automatic’ option – being Linux based no reboot is required)
- Initial install of the vShield Agent
- Deploy from OVF and then convert to a template. This simply gets the agent ready for deployment.
If you’re wondering whether VMtools make a significant difference to this customised Linux appliance see (the pointless) VMwareKB1011501! You can also find out what’s new in vShield Zones 1.0 Update 1.
Deploying/uninstalling an agent from template
Deploying a template based agent
- In vShield Manager, choose the host and click ‘Install vShield’ tab.
- Complete the fields giving a unique name and IP to each agent;
- Wait for the installation to complete. A new vSwitch (and associated portgroups) will be created (named as per the original vSwitch but with a ‘_VS’ postfix). You can monitor progress in the VI client;
- Upgrade VMtools in the vShield appliance once configuration has completed (you can use the ‘Automatic option’ – being Linux based no reboot is required)
- If the vShield appliance is in an HA/DRS cluster;
- Go to HA settings and set ‘Disabled’ under Virtual Machine Options
- Go to DRS settings and set ‘Disabled’ under Virtual Machine Options
- Edit the .VPX to prevent vMotion warnings due to the ‘internal only’ vSwitch (see p13 of the vShield Quick Start guide)
Uninstalling a template based agent
- Simply select the vShield agent in the inventory and click on the ‘Uninstall’ tab. You’ll be presented with a summary of actions to be carried out.
- Click Uninstall to confirm.
Deploying/uninstalling an agent manually
If you’re using a VDS you’ll need to deploy the vShield agent manually. I guess this might also be useful in case the automated deployment fails for any reason.
For a standard vSwitch;
- On your chosen host, create a new vSwitch (with a name which reflects it’s a vShield vSwitch)
- On the same host create two new portgroups (three if you want a separate mgmt portgroup);
- Unprotected on the original vSwitch (with the physical NIC)
- Protected on the new vSwitch_VS you created in step 1
- Install the agent (Deploy from OVF, power on VM, install VMtools) to your chosen host
- Assign the three vShield agent vNICs to the three portgroups;
- Management portgroup
- Protected (vNIC2)
- Unprotected (vNIC3)
- Configure the vShield agent via the CLI
- Login as admin/default
- Enable the interfaces using ‘no shutdown’ (as per Cisco devices). The interfaces are referred to as ‘u0’, and ‘p0’.
- Add the vShield agent to the vShield Manager
- Settings & Reports -> Manual Install, complete the fields (VM name, IP)
- Move the VMs to the new vSwitch.
For a dvSwitch the process is even more convoluted. I’m not going to cover it here – if it comes up in the exam refer to pages 36-41 in the vShield Administration Guide. I hope it doesn’t!
Uninstalling a manually installed agent
- In vSphere move the vNIC assignments for each VM to the unprotected vSwitch
- In vShield Manager go to Settings & Reports -> Configuration -> Manual Install
- Select the agent and click Remove
- In vSphere remove the extraneous portgroups
Execute/schedule discovery of virtual machines
- In vShield Manager, select the agent you want to configure then click on ‘VM Discovery’ tab.
- Select Automated and then set the ‘Scheduled Discovery Status’ to ‘Continuous’. Click OK.
Updating vShield Zones
- Done via vShield Manager, Settings & Reports –> Updates
- Updated via offline bundles (not integrated with VUM)
- No notifications when updates are available, and I couldn’t find any updates (though not entierly sure where to look). Not the easiest to use then!
- Very little useful detail in official documentation
Backup and restore
It’s recommended to backup your system configuration regularly (which consists of configuration details, audit logs and event history).
- Go to Settings & Reports -> Configuration -> Backups and configure the appropriate fields. Decisions required;
- FTP or SFTP
- One off or scheduled
Users and groups exist both in the vShield Manager, the vShield Manager CLI (not the same accounts as the GUI) and also separately in every vShield agent. This means managing your users can be quite a chore (there’s no AD integration either).
Possible rights (who came up with these?);
- R = read only
- CRUD = read and write
Resources (which can have the above rights granted to them);
vShield Manager vCenter plugin
This isn’t real integration with the VI client, it simply allows you to open the vShield Manager webpage within the VI client. Under Settings & Reports -> Configuration -> vSphere plugin click Register. After registering the plugin it’ll show up in the Solutions section of the VI client. All rather pointless really!
This is the actual firewall component.
- Rules are hierarchical and can be specified at a datacentre or cluster level
- The default rules (both layer4 and layer2/3) ALLOW all traffic. The default rules can’t be added to or deleted, but they can be changed to DENY instead.
- Layer2/3 rules (TCP, IP, ARP) can ONLY be configured at a datacentre level.
- As is typical for firewalls, all traffic is matched against the rules from top to bottom of the table – the first rule which matches is enforced
- The two common configurations;
- Allow all traffic but deny specific traffic as defined in the VM Wall
- Deny all traffic but allow specific traffic as defined in the VM Wall
The screenshot below shows a layer 4 rule I created which DENIES access to RDP (on port 3389 by definition) from any VM outside my cluster;
Add application-port pair mappings
vShield Zones ships with definitions for many well known protocols (for example RDP on TCP port 3389). If you need to create new mappings (for example VNC isn’t present) you can;
- Select either datacentre or cluster node
- Go to the VM Flow tab, then click ‘Edit Mappings’
- Click Add at the bottom of the screen. Fill in the columns accordingly.
VM Flow is your monitoring tool to see traffic flows and the impact of any rules you’ve defined. There are two available views, graphical (real time?) ‘charts’ and ‘reports’ which are a tabular table.
Reports are generally more useful as they let you see actual metrics. The screenshot below clearly shows the three blocked RDP attempts I made after creating a rule to deny RDP (port 3389);
You can also create VM Wall rules directly from the VM Flow reports. Simply drill down far enough and click on the VM Wall radio button – it’ll automatically switch to the VM Wall screen with a rule prepopulated.
You can also look at the logs directly although if there’s significant traffic in your network this may well become hard to read pretty quickly;
- Select the vShield agent in question (one reason NOT to use this method – it won’t always be easy to know which host)
- Click Configuration -> Show Status then click on Show Logs at the bottom of the screen. In the screenshot below you can again see my blocked RDP attempts (in a slightly harder to read format).
Administering vShield Zones at the command line
Identify the four CLI modes
Administering either vShield Manager or a vShield agent at the CLI is much like (insert vendor or choice: Cisco, Vyatta,Netapp) administration. There are four command modes which give access to different commands and tab completion can be used to effectively navigate;
- Basic – this is a read only mode (with the exception of the ‘setup’ wizard)
- Accessed via ‘enable’ (password is optional)
- Typical operations: enable an interface (‘no shutdown’), reboot
- You must use ‘write’ to make any changes persistent
- Accessed via ‘config terminal’. Familiar eh?
- Typical operations: clear vmwall rules, copy running-config startup-config, set the ‘enable’ password, add/edit/delete user accounts
- Interface configuration.
- Accessed via ‘interface <mgmt. | p0 | u0>’
- Typical operations: set an IP address
Backup CLI configuration
This is shockingly basic. Just like a Cisco device the configuration is stored in a ‘running config’ which you can simply cut and paste as a backup.
- Select the vShield agent in the vShield Manager Inventory
- Click Configuration -> CLI Configuration
- Click ‘Back up’.
All this does is copy the contents of the top window to the bottom window. In the event you need to restore the configuration you would simply cut and paste the configuration from the bottom window into the CLI (at the configuration prompt) to restore the settings.
NOTE: There is no date/timestamp or even comments field for the backup window, so it’d be easy to forget when the backup was taken and what the state was at the time. I’d have thought cut and pasting this to a Notepad document would provide a better service than this built in backup!
Dave Convery’s post on vShield Zones’ shortcomings
VMworld 2010 vShield Zones lab (subscription required at time of writing)