Configuring VMware vShield App firewalls

VMware vShield App firewall overview

VMware vShield App is a hypervisor-based application-aware firewall solution for virtual data centers. vShield App plugs directly into VMware vSphere to protect against internal network-based threats and reduce the risk of policy violations within the corporate security perimeter by using application-aware firewalls with deep packet inspection and connection control based on source and destination IP addresses.

vShield App provides the following key benefits:

Back to top

Adding a device for the vShield App firewall in BMC Network Automation

You add the VMware vShield App device in BMC Network Automation by defining the context ID of the data center or the data center name in a user-defined security context field. If use want to use the context ID instead of the data center name, ensure that you retrieve this security context by executing a REST API call to the vshield Manager by typing https://vshieldManagerHostNameOrIPAddress/api/2.0/services/usermgmt/scopingobjects in your web browser before performing the following procedure:

1. Select Network > Spans > Devices.
2. In Device Type, specify VMware vShield App.

3. In Security Context, specify the context ID of the data center retrieved earlier, as shown in the following figure:
   

4. In Host Name/IP Address/URL, specify the management IP address or host name of the vShield Manager, as shown in the following figure:
   
   
   

Back to top

Guidelines for creating the container blueprint

• vShield App is shared among containers and not deployed per container.
• The container blueprint must have a node blueprint of containerFirewallHostBlueprint type with a defined virtualGuestBlueprint.
• The virtualGuestBlueprint must have the following flags defined:
  • useHostAddressForGuest=true
  • useExistingGuestDeviceFlag=true
  • independentFlag=true (only if you want the firewall to toggle independently)
  • accessLayerFlag=true

• If independentFlag is true, in the containerFirewallHostBlueprint tag, define conditional configureActionInfoBlueprints and unconfigureActionInfoBlueprints tags as shown in the following sample:
  
  

  <nodeBlueprint xsi:type="containerFirewallHostBlueprint" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
    <addressBlueprints/>
    <category>4</category>
    <configureActionInfoBlueprints/>
    <dummyHostFlag>false</dummyHostFlag>
    <name>Firewall</name>
    <numVrfs>0</numVrfs>
    <role>Firewall</role>
    <unconfigureActionInfoBlueprints/>
    <virtualGuestBlueprint xsi:type="containerVfwBlueprint">
      <configureActionInfoBlueprints>
        <configureActionInfoBlueprint xsi:type="mergeActionInfoBlueprint">
          <name>Configure vShieldApp Namespaces</name>
          <condition>-EXISTS- container.nodes['VFW']</condition>
          <templateGroups>
            <item>Configure vShieldApp Namespaces</item>
          </templateGroups>
        </configureActionInfoBlueprint>
        <configureActionInfoBlueprint xsi:type="mergeActionInfoBlueprint">
          <name>Clean App Rules</name>
          <condition>-EXISTS- container.nodes['VFW']</condition>
          <templateGroups>
            <item>Dummy</item>
          </templateGroups>
        </configureActionInfoBlueprint>
      </configureActionInfoBlueprints>
      <guestAddressBlueprints/>
      <useHostAddressForGuest>true</useHostAddressForGuest>
      <useExistingGuestDeviceFlag>true</useExistingGuestDeviceFlag>
      <guestDeviceName>${container.nodes[Firewall].device.name}</guestDeviceName>
      <guestNodeName>VFW</guestNodeName>
      <sharesVirtualDevice>false</sharesVirtualDevice>
      <accessLayerFlag>true</accessLayerFlag>
      <defaultEnabledFlag>true</defaultEnabledFlag>
      <independentFlag>true</independentFlag>
      <unconfigureActionInfoBlueprints>
        <unconfigureActionInfoBlueprint xsi:type="mergeActionInfoBlueprint">
          <name>Clean App Rules</name>
          <templateGroups>
            <item>Clean App Rules</item>
          </templateGroups>
        </unconfigureActionInfoBlueprint>
      </unconfigureActionInfoBlueprints>
  

• The template defined for Dummy must not have any configuration object because no object is required. To designate a dummy template, add an exclamation mark (!) in that template content.

• For vShield App, no guest device is created. The host acts as a guest in the container. Therefore, in the container blueprint, the name of the guest device defined by the guestDeviceName tag must be the name of the host device represented by ${container.nodes[firewallHostNodeName].device.name}. 


• The managedInterfaceBlueprint must contain the names of the port profiles created in vCentre for a particular network through port group creation. The portTypeBlueprint tag in the container blueprint must include these port profiles for the defined hypervisor.
• If an external preconfigured network exists, you must define a managedInterfaceBlueprint tag for that external network. The name of the managed interface defined for the external network must be the same as the port profile used for the external network.
• If existing port groups are used as managed interfaces for the vShieldApp firewall, all the rules existing on those interfaces are deleted and reapplied when the first rule is added into the ACL.

• You can specify system-defined rules by adding ruleBlueprint tags under the inboundAclBlueprint and outboundAclBlueprint tags.
  
  

  Warning

  If container provisioning fails because of ruleBlueprint failure error, modify the -ConfigureAppNamespaces.xml template to increase the delay specified in the pollIntervalSecondsargument.

  For example: ex- add-delay -pollMax 2 -pollIntervalSeconds 50

• Use the following base protocols from different applications to block or permit traffic on vShield App:
  
  

  Protocol number	Protocol  name
  1	ICMP
  2	IGMP
  4	IPV4
  6	TCP
  17	UDP
  41	IPV6
  43	IPV6ROUTE
  44	IPV6FRAG
  46	RSVP
  47	GRE
  50	ESP
  51	AH
  58	IPV6ICMP
  59	IPV6OXT
  60	IPV6OPTS
  108	IPCOMP
  111	IPX
  115	L2TP
  132	SCTP

Back to top

Guidelines for inbound and outbound ACLs

A single managed interface must have one ACL as shown in the following code sample:

<managedInterfaceBlueprints>
  <managedInterfaceBlueprint>
    <bridgeInterfaceNames/>
    <inboundAclBlueprint>
      <enablePathUpdates>true</enablePathUpdates>
      <name>Inside-IN</name>
    </inboundAclBlueprint>
    <name>Inside-${container.id}</name>
    <servicedSegmentNames>
      <servicedSegmentName>Inside</servicedSegmentName>
    </servicedSegmentNames>
  </managedInterfaceBlueprint>
  <managedInterfaceBlueprint>
    <bridgeInterfaceNames/>
    <inboundAclBlueprint>
      <enablePathUpdates>true</enablePathUpdates>
      <name>Outside-IN</name>
    </inboundAclBlueprint>
    <name>Outside-${container.id}</name>
    <servicedSegmentNames>
      <servicedSegmentName>Outside</servicedSegmentName>
    </servicedSegmentNames>
  </managedInterfaceBlueprint>
</managedInterfaceBlueprints

Back to top

Sample pod and container blueprints

You can find sample pod and container blueprints and related templates in the BCAN_HOME\public\bmc\bca-networks\csm\samples\sampleWithVshieldApp directory on the BMC Network Automation application server. For additional information about the sample pod and container blueprints for use with a VMware vShield App firewall, see Pod model and Container model.