posted

1 Comment

This blog provides best practices for deploying vCloud Networking and Security 5.1 App Firewall. Thanks to Shubha Bheemarao, Ray Budavari and Rob Randell for helping me in compiling this.

Installation

  • Install vCloud Networking and Security Manager (aka vShield Manager) on a dedicated management cluster. Other components that get installed on this cluster are VMware vCenter Server, vCloud Director etc.
  • vCloud Networking and Security Manager should be run on an ESXi host that is not affected by downtime, such as frequent reboots or maintenance mode operations. Use vSphere HA to increase the resilience of the Manager. Thus, a cluster with more than one ESXi host is recommended.
  • Install vCloud Networking and Security App Firewall on all vSphere hosts within a cluster so that virtual machines remain protected as they migrate between vSphere hosts.
  • The management interfaces of vCloud Networking and Security components should be placed in a common network, such as the vSphere management network. Manager requires IP connectivity to the vCenter Server, ESXi host, and App Firewall virtual machine. Refer the KB article for the network port requirements for vCloud Networking and Security. It is a best practice to separate management traffic from the production traffic.
  • If the vCenter Server or vCenter Server database virtual machines are on the ESXi host on which you are installing App Firewall, migrate them to another host before installing App Firewall or exclude these virtual machines from vCloud Networking and Security App Firewall protection.
  • Install VMware Tools on each Virtual Machine. The vCloud Networking and Security Manager collects the IP addresses of virtual machines from VMware Tools on each virtual machine. Use App Firewall SpoofGuard to authorize the IP addresses reported by VMware Tools to prevent spoofing.  With SpoofGuard use trust on first use to reduce the administrative overhead.

Firewall Policy Management

  • Use vCenter containers (vApps, resource pools, port groups, etc.) and security groups (grouping of vApps, resource pools, port groups, vNICs etc.) instead of IP addresses for policy enforcement. This allows creating security policies that can follow virtual machines during the vMotion process, and are completely transparent to IP address changes and network renumbering. In addition, use of vCenter containers and security groups enable rules to be dynamic. When a new virtual machine joins the container or security group, the rules are applied automatically and not required to define new rules.
  • Use service groups to combine multiple services to reduce the number of entries in the rule table.
  • Ethernet rules control which higher-level protocols (like ARP, IPv6, PPP and so on) can communicate over L2. By assessing what communication is required between applications and each tier of the application, create Ethernet rules that block all unnecessary traffic with a default any to any allow at the end.  Ethernet rules are enforced before the General rules. When a packet is allowed by an Ethernet rule, it will be further inspected by General rules. When a packet is denied by Ethernet rule, General rules are not evaluated.
  • General rules control the specific L3 traffic based on IP addresses, as well as L4 traffic based on TCP and UDP ports. Explicitly add rules to allow the communication required between applications and each tier of the application, with a default any to any deny at the end.
  • Set a firewall rule to have L2 isolation between servers in a security group when applicable e.g. isolate one web server from another web server. This can prevent the spread of malware when one machine gets infected and provides PVLAN like capability, but more easily managed. App firewall provides better security than PVLANs particularly when combined with SpoofGuard.
  • Set the Fail Safe mode to Block – in the remote event of App Firewall service virtual machine failure, this setting ensures to block the traffic to all virtual machines running on the host preventing any security vulnerability.
  • App Firewall protects applications within the virtual datacenter, whereas Edge Firewall provides protection at the perimeter of the virtual datacenter. In multi-tenant deployments, each tenant would have separate Edge devices.  For firewalling between virtual machines within the same tenant use App Firewall. Whereas, for isolating traffic between tenants use Edge Firewall.
  • In a multi-tenant deployment, App Firewall allows you to assign independent IP addresses to specific port groups. You can mark a port group as an independent namespace, and then the datacenter level firewall rules no longer apply to that port group. This is done automatically for VXLAN virtual wires i.e. a separate namespace created for each VXLAN network.

Day to Day Operations / Troubleshooting

  • Regularly monitor the allowed/denied flows using Flow Monitoring to ensure that firewall rules are set up correctly. Use Flow Monitoring to audit network traffic, define and refine firewall policies, and identify threats to the network.
  • Setup syslog servers on App Firewall for central logging. Enable logging on a per rule basis to send the Allow/Deny syslog messages to central syslog server. Use ‘Rule ID’ in the App Firewall rule table to correlate the syslog messages with the corresponding Firewall rules.
  • Setup NTP to ensure accurate timestamps on log messages. All App Firewall instances use the NTP server configuration of the vCloud Networking and Security Manager.
  • Use the comments field in each App Firewall rule to keep track of the changes.
  • Use the Load History option to revert the vCloud Networking and Security App firewall configuration to a previous version. vCloud Networking and Security Manager saves the App firewall configuration each time new firewall rules are published and retains the previous ten configurations.
  • Schedule periodic backup of vCloud Networking and Security Manager data, which can include configuration, events, and audit log tables.
  • After creating a full backup of the vCloud Networking and Security Manager Database, shut down the virtual machine then take a snapshot or full clone of the virtual machine prior to any upgrades. Refer the KB article for additional information.

Get notification of these blogs and more vCloud Networking and Security information by following me on Twitter @vCloudNetSec.