Home > Blogs > VMware Consulting Blog > Tag Archives: Dharma Rajan

Tag Archives: Dharma Rajan

Improving Internal Data Center Security with NSX-PANW Integration

Dharma RajanBy Dharma Rajan

Today’s data center (DC) typically has one or more firewalls at the perimeter securing it with a strong defense, thus preventing threats to the DC. Today, applications and their associated content can easily bypass a port-based firewall using a variety of techniques. If a threat enters, the attack surface area is large. Typically the low-priority systems are often the target, as activity on those may not be monitored. Today within the DC more and more workloads are being virtualized. Thus the East-West traffic between virtual machines within the DC has increased substantially compared to the North-South traffic.

Many time threats such as data-stealing, malware, web threats, spam, Trojans, worms, viruses, spyware, bots, etc. can spread fast and cause serious damage once they enter. For example, dormant virtual machines can be a risk when they are powered back up because they may not be receiving patches or anti-malware updates, making them vulnerable to security threats. When the attack happens it can move quickly and compromise critical systems which needs to be prevented. It is also possible in many cases that the attack goes unnoticed until there is an event that triggers investigation, by which time valuable data may have been compromised or lost.

Thus it is very critical that the proper internal controls and security measures are applied at the virtual machine level to reduce the surface area of attack within the data center. So how do we do that and evolve the traditional data center to a more secure environment to overcome today’s data center challenges without additional costly hardware.

Traditional Model for Data Center Network Security

In the traditional model, we base the network architecture with a combination of perimeter-level security by way of Layer 2 VLAN segmentation. This model worked, but as we virtualize more and more workloads, and the data center grows, we are hitting the boundaries when it relates to VLANs with VLAN sprawl, and also the increased number of firewall rules that need to be created and managed. Based on RFC 5517 the maximum number of VLANs that can be provisioned is 4,094. All this adds complexity to the traditional network architecture model of the data center. Other key challenges customers run into in production data centers is too many firewall (FW) rules to create, poor documentation, and the fear of deleting FW rules when a virtual machine is deleted. Thus flexibility is lost, and holes remain for attackers to use as entry points.

Once security is compromised at one VLAN level, the spread across the network—be it Engineering VLAN, Finance VLAN, etc.—does not take very long. So the key is not just how to avoid attacks, but also—if one occurs—how to contain the spread of an attack.

DRajan Before and After Attack

Reducing Attack Surface Area

The first thing that might come to one’s mind is, “How do we prevent and isolate the spread of an attack if one occurs?” We start to look at this by keeping an eye on certain characteristics that make up today’s data centers – which are becoming more and more virtualized. With a high degree of virtualization and increased East-West data center traffic, we need certain dynamic ways to identify, isolate, and prevent attacks, and also automated ways to create FW rules and tighten security at the virtual machine level. This is what leads us to VMware NSX—VMware’s network virtualization platform—which provides the virtual infrastructure security, by way of micro-segmenting, today’s data center environments need.

Micro-Segmentation Principle

As a first step let’s take a brief look at the NSX platform and its components:

DRajan NSX Switch

In the data plane of the NSX vSwitch that are vSphere Distributed Switches (vDS) and FW hypervisor extension modules that run at the kernel level and provide Distributed Firewalling (DFW) functionality at line rate speed and performance.

The NSX Edge can provide edge firewalling functionality/perimeter firewall to the Internet-facing side. The NSX controller is the control plane-level component providing high availability. The NSX manager is the management-level component that communicates with vCenter infrastructure.

By doing micro-segmentation and applying the firewall rules at the virtual machine level we control the traffic flow on the egress side by validating the rules at the virtual machine level, avoiding multiple hops and hair pinning as the traffic does not have to make multiple hops to the physical firewall to get validated. Thus, we also get good visibility of traffic to monitor and secure the virtual machine.

Micro-segmentation is based on the startup principal: assume everything is a threat and act accordingly. This is “zero trust” model. It is indirectly saying entities that need access to resources must prove they are legitimate to gain access to the identified resource.

With a zero trust baseline assumption—which can be “deny by default” —we start to relax and apply certain design principles that enable us to build a cohesive yet scalable architecture that can be controlled and managed well. Thus we define three key design principles.

1) Isolation and segmentation – Isolation is the foundation of most network security, whether for compliance, containment or simply keeping development, test and production environments from interacting. Segmentation from a firewalling point of view refers to micro-segmentation on a single Layer 2 segment using DFW rules.

2) Unit-level trust/least privileges What this means is to provide access to a granular entity as needed for that user, be it a virtual machine level or something within the virtual machine.

3) And the final principle is ‘Ubiquity and Centralized Control’. This helps to enable control and monitoring of activity by using the NSX Controller, which provides a centralized controller, the NSX manager, and the cloud management platforms that provide integrated management.

Using the above principle, we can lay out an architecture for any greenfield or brownfield data center environment that will help us micro-segment the network in a manner that is architecturally sound, flexible to adapt, and enables safe application enablement with the ability to integrate advanced services.

DRajan Micro Segmentation

 

Dynamic Traffic Steering

Network security teams are often challenged to coordinate network security services from multiple vendors in relationship to each other. Another powerful benefit of the NSX approach is its ability to build security policies that leverage NSX service insertion, with Dynamic Services chaining and traffic steering to drive service execution in the logical services pipeline. This is based on the result of other services that make it possible to coordinate otherwise completely unrelated network security services from multiple vendors. For example, we can introduce advanced chaining services where―at a specific layer—we can direct specific traffic to, for example, a Palo Alto Networks (PANW) virtual VM-series firewall for scanning, threat identification, taking necessary action quarantine an application if required.

Palo Alto Networks VM-series Firewalls Integration with NSX

The Palo Alto Networks next-generation firewall integrates with VMware NSX at the ESXi server level to provide comprehensive visibility and safe application enablement of all data center traffic including intra-host virtual machine communications. Panorama is the centralized management tool for the VM-series firewalls. Panorama works with the NSX Manager to deploy the license and centrally administer configuration and policies on the VM-series firewall.

The first step of integration is for Panorama to register the VM-series firewall on the NSX manager. This allows the NSX Manager to deploy the VM-series firewall on each ESXi host in the ESXi cluster. The integration with the NetX API makes it possible to automate the process of installing the VM-series firewall directly on the ESXi hypervisor, and allows the hypervisor to forward traffic to the VM-series firewall without using the vSwitch configuration. It therefore requires no change to the virtual network topology.

DRajan Panorama Registration with NSX

To redirect traffic the NSX service composer is used to create security groups and define network introspection rules that specify traffic from guests who are steered to the VM-series firewall. For traffic that needs to be inspected and secured by the VM-series firewall, the NSX service composer policies redirect traffic to the Palo Alto Networks Next-Gen Firewall (NGFW) service. This traffic is then steered to the VM-series firewall and is processed by the VM-series firewall before it goes to the virtual switch.

Traffic that does not need to be inspected by the VM-series firewall, for example, network data backup or traffic to an internal domain controller, does not need to be redirected to the VM-series firewall and can be sent to the virtual switch for onward processing.

The NSX Manager sends real-time updates on the changes in the virtual environment to Panorama. The firewall rules are centrally defined and managed on Panorama and pushed to the VM-series firewalls. The VM-series firewall enforces security policies by matching source or destination IP addresses. The use of Dynamic Address Groups allows the firewall to populate members of the Dynamic Address Groups in real time, and forwards the traffic to the filters on the NSX firewall.

Integrated Solution Benefits

Better security – Micro-segmentation enables reduced surface area of attack. It enables safe application enablement and protection against known and unknown threats to protect virtual and cloud environments. The integration enables easy identification and isolation of compromised applications faster.

Simplified deployment and faster secure service enablement – When a new ESXi host is added to a cluster, a new VM-series firewall is automatically deployed, provisioned and available for immediate policy enforcement without any manual intervention.

Operational flexibility – The automated workflow allows you to keep pace with VM deployments in your data center. The hypervisor mode on the firewall removes the need to reconfigure the ports/vSwitches/network topology; because each ESXi host has an instance of the firewall, traffic does not need to traverse the network for inspection and consistent enforcement of policies.

Selective traffic redirection – Only traffic that needs inspection by VM-series firewall needs redirection.

Dynamic security enforcement – The Dynamic Address Groups maintain awareness of changes in the virtual machines/applications and ensure that security policies stay in tandem with changes in the network.

Accelerated deployments of business-critical applications – Enterprises can provision security services faster and utilize capacity of cloud infrastructures, and this makes it more efficient to deploy, move and scale their applications without worrying about security.

For more information on NSX visit: http://www.vmware.com/products/nsx/

For more information on VMware Professional Services visit: http://www.vmware.com/consulting/


Dharma Rajan is a Solution Architect in the Professional Services Organization specializing in pre-sales for SDDC and driving NSX technology solutions to the field. His experience spans Enterprise and Carrier Networks. He holds an MS degree in Computer Engineering from NCSU and M.Tech degree in CAD from IIT

How NSX Simplifies and Enables True Disaster Recovery with Site Recovery Manager

Dharma RajanBy Dharma Rajan

VMware Network Virtualization Platform (NSX) is the network virtualization platform for the software-defined datacenter (SDDC). Network virtualization using VMware NSX enables virtual networks to be created as software entities, saved and restored, and deleted on demand without requiring any reconfiguration of the physical network. Logical network entities like logical switch, logical routers, security objects, logical load balancers, distributed firewall rules and service composer rules are created as part of virtualizing the network.

To provide continuity of service from disaster recovery (DR), datacenters are built with capabilities for replicating and recovering workloads between protected and recovery sites. VMware Site Recovery Manager (SRM) helps to fully automate the recovery process.

From a DR point the recovery site has to be in synch with the protected site at all times from a compute, storage and networking point of view to enable seamless fast recovery when the protected site fails due to a disaster. When using SRM today for DR there are a couple of challenges customers face. From a compute perspective one needs to prepare the host at the recovery site, pre-allocate compute capacity for placeholder virtual machines and create placeholder virtual machines themselves.

From a storage point, the storage for protected applications/virtual machines needs to be replicated and kept in synch. Both of these steps are easy and has been handled by SRM-, vSphere- and/or Array-based replication. The challenge today is the networking piece of the puzzle. As illustrated below, depending on the type of networking established between protected and recovery site, various networking changes (carve out Layer-2, Layer-3, Firewall, Load balancer policy in recovery site, re-map of network if IP address space overlap, recreate policies, etc.) may have to be manually done to ensure smooth recovery. This adds a lot of time, subject to human error in making the changes, inability to meet internal and external SLA. The result of this is the network is the bottleneck that prevents seamless disaster recovery. From a business perspective this can easily translate into millions of dollars in business loss based on criticality of workloads/services impacted.

DRajan 1

Why Are We Running into the Networking Challenge?

The traditional DR solution is tied tightly to physical infrastructure (physical routers, switches, firewalls, load balancers). The security domains of the protected and recovery sites are completely separate. As networking changes, be it new adds, delete, updates are made (say IP address, Layer-2 extension changes, subnets, etc.) at the protected site, no corresponding automated synchronization happens at the recovery site. Thus one may have to do Layer-2 extension to preserve the changes, create and maintain special scripts, manage the tools, and perform manual DR setup and recovery steps across different infrastructure layers and vendors (physical and virtual). From a process point it requires coordination across various teams within your company, good bookkeeping and periodic validation, so you are always ready to address a DR scenario as quickly as you can.

What is the Solution?

VMware NSX from release 6.2 offers a solution that enables customers to address the above-cited networking challenges. NSX is the network virtualization platform for the SDDC. NSX provides the basic foundation to virtualize networking components in the form of logical switching, distributed logical router, distributed logical firewall, logical load balancer, and logical edge gateways. For a deeper understanding of NSX see more at: http://www.vmware.com/products/nsx

NSX 6.2 release has been integrated with SRM 6.1 to enable automated replication of networking entities between protected and recovery sites.

DRajan 2

How Does the Solution Work?

NSX 6.2 supports a couple of key concepts that will intelligently understand that it is logically the same network on both sites. These concepts include:

  1. a) “Universal Logical Switches” (ULS) – This allows for the creation of Layer-2 networks that span vCenter boundaries. This means that when utilizing ULS with NSX there will be a virtual port group at both the protected and recovery site that connect to the same Layer-2 network. When virtual machines are connected to port groups that are backed by ULS, SRM implicitly creates a network mapping, without requiring the admin to configure it. Providing seamless network services portability and synchronization automatically reconnects virtual machines connected to a ULS to the same logical switch on the other vCenter.

DRajan 3

NSX 6.2 ULS Integration with SRM 6.1 Automatic Network Mapping

  1. b) Cross vCenter Networking and Security enables key use cases such as:
  • Resource pooling, virtual machine mobility, multi-site and disaster recovery
  • Cross-vCenter NSX eliminates the need for guest customization of IP addresses

and management of portgroup mappings, two large SRM pain points today

  • Centralized management of universal objects, reducing administration effort
  • Increased mobility of workloads; virtual machines can be “vMotioned” across vCenter Servers without having to reconfigure the virtual machine or making changes to firewall rules

The deployment process would ideally be to:

  • Configure Master NSX Manager at primary site and Secondary NSX Manager at recovery site
  • Configure Universal Distributed Logical Router between primary and secondary site
  • Deploy Universal Logical Switch between primary and recovery site and connect it to Universal Distributed Logical Router
  • Deploy the VRO plugin for automation and monitoring
  • Finally map SRM network resources between primary and recovery sites

Supported Use Cases and Deployment Architectures

The primary use cases are full site disaster recovery scenarios or unplanned outage where the primary site can go down due to a disaster and secondary site takes immediate control and enables business continuity. The other key use case is planned datacenter migration scenarios where one could migrate workloads from one site to another maintaining the underlying networking and security profiles. The main difference between the two use cases is the frequency of the synchronization runs. In a datacenter migration use case you can take one datacenter running NSX and reproduce the entire networking configuration on the DR side in a single run of the synchronization workflow or run it once initially and then a second time to incrementally update the NSX objects before cutover.

DRajan 4

Other supported use cases include partial site outages, preventive failover, or when you anticipate a potential datacenter outage, for example, impending events like hurricanes, floods, forced evacuation, etc.

The standard 1:1 deployment model with one site as primary and another as secondary is the most common deployed model. In a shared recovery site configuration, like for branch offices, you install one SRM server instance and NSX on each protected site. On the recovery site, you install multiple SRM Server instances to pair with each SRM server instance on the protected sites. All of the SRM server instances on the shared recovery site connect to the same vCenter server and NSX instance. You can consider the owner of an SRM server pair to be a customer of the shared recovery site. You can use either array-based replication or vSphere replication or a combination of both when you configure an SRM server to use a shared recovery site.

DRajan 5

Logical Disaster Recovery Architecture Using NSX Universal Objects

What Deployment Architecture Will the Solution Support?

This solution applies to all Greenfield and Brownfield environments. The solution will need the infrastructure to be base-lined to vCenter 6.0 or later, ESXi 6.0 or later, vSphere Distributed switch, SRM 6.0 or later with NSX 6.2 or later.

SRM can be used for different failover scenarios. It could be Active-Active, Active-Passive, Bidirectional, and Shared Recovery.

Integrated Solution Advantages

The ability to automate the disaster recovery planning, maintenance and testing process becomes much simpler, with automation enabling significant operational efficiencies.

  • The ability to create a network that spans vCenter boundaries creates a cross-site Layer-2 network, which means that after failover, it is no longer necessary to re-configure IP addresses. Not having to re-IP recovered virtual machines can further reduce recovery time by up to 40 percent.
  • There is more automation with networking and security objects. Logical switching, logical routing, security policies (such as security groups), firewall settings and edge configurations are also preserved on recovered virtual machines, further decreasing the need for manual configurations post-recovery.
  • Making an isolated test network with all the same capabilities identical to a production environment becomes much easier.

In conclusion, the integration of NSX and SRM greatly simplifies operations, lowers operational expenses, increases testing capabilities and reduces recovery times.

For more information on NSX visit: http://www.vmware.com/products/nsx/

For more information on SRM visit: http://www.vmware.com/products/site-recovery-manager/

For more information on VMware Professional Services visit: http://www.vmware.com/consulting/

 


About the Author:

Dharma Rajan is a Solution Architect in the Professional Services Organization specializing in pre-sales for SDDC and driving NSX technology solutions to the field. His experience spans Enterprise and Carrier Networks. He holds an MS degree in Computer Engineering from NCSU and M.Tech degree in CAD from IIT