Home > Blogs > VMware Consulting Blog > Tag Archives: NSX

Tag Archives: NSX

VMworld Session Preview: Advanced Network Services with NSX

Romain Decker

 

By Romain Decker

It is no secret that IT is in constant evolution. IT trends such as Cloud Adoption, Distributed Applications, Micro-Services or Internet of Things have emerged over the last years.

Nevertheless, the focus is still on applications and on how they compute and deliver data to consumers. Whether their role is to generate revenue, pilot industries, logistics, health or even your programmable thermostat; top level goals of organizations are still security, agility and operational efficiency, everything else associated with the applications has changed:

  • Threats have become more advanced and persistent.
  • Users now access the data center from devices and locations that represent significant challenges.
  • Application architectures are now more widely distributed and more dynamic than ever before.
  • Infrastructure changes have evolved with the convergence of resources and questions around public cloud offerings.

VMware NSX is a perfect fit to address these concerns from the network and security standpoint. NSX reproduce all Network & Security services of Data Centers in logical space for best speed/agility and a deeper security.

Visit my session at VMworld Las Vegas (Session ID: NET7907) to hear the detailed presentation on NSX firewall, load balancing and SSL-VPN capabilities.

And don’t forget, the GUI is not the king! 😉


Presenter: Romain Decker
Session Number: NET7907
Session Title: Advanced Network Services with NSX
Date and Time: 8/30/16 (Tuesday) 2:00 PM

Abstract: Applications are everywhere and increasingly more complex. They require much more than switching and routing on the network side. Clouds should be able to host any applications, including the complex ones. This session will discuss the concepts for designing and operating NSX network services such as firewalling, load balancing, and VPN. We will examine and explain how you can better consume those services by automating them, or by using other mechanisms such as NSX API. After this session, you will leave with a better understanding of how NSX Network and Security services work, and how to leverage them to better support your applications.

Schedule Builder


Romain Decker is a Senior Solutions Architect member of Professional Services Engineering (PSE) for the Software-Defined Datacenter (SDDC) portfolio – a part of the Global Technical & Professional Solutions (GTPS) team.

Demo – Dynamically Enforcing Security on a Hot Cloned SQL Server with VMware NSX

Originally posted on the Virtualize Business Critical Applications blog.

Niran_Even_Chen

 

By Niran Even-Chen

VMware NSX is a software defined solution that brings the power of virtualization to network and security.

There are many great papers about NSX in general: for example here & here and many others, the purpose of this demo is not to dive into everything that NSX does. Instead I have focused on one capability in particular and that is the intelligent grouping of NSX Service Composer with the Distributed VMware NSXFirewall (DFW) and how to utilize it to make life easier for SQL DBAs and security admins, its doesn’t have to be only SQL Server, it can be any other database or application for that matter but for this demo I am focusing on SQL Server.

First, a bit of background: The NSX Service Composer allows us to create groups called “Security groups”. These Security groups can have a dynamic membership criteria that can be based on multiple factors: It can be part of the computer name of a VM, its guest OS name, the VM name, AD membership or a tag (tags are especially cool as they can be set automatically by 3rd party tools like antivirus and IPSs, but that is for a different demo)

These Security groups are than placed inside the Distributed Firewall (DFW) rules which allows us to manage thousands of entities with just a few rules and without the need to add these entities to the Security Group manually.

In the demo I have created an environment that is set with 0 trust policy, that means that everything is secured and every packet between the VMs is inspected, the inspection is done on the VMs vNIC level in an east-west micro segmentation way. That means that if a certain traffic is not defined in the DFW it is not allowed to go through.

This is something that wasn’t really possible to do before NSX

Our production app database is an SQL database and in the demo the DBA wants to hot-clone it aside for testing purposes, but obviously the cloned SQL Server needs to have some network traffic allowed to pass to it, yet it needs to be secured from everything else.

Instead of having the traditional testing FW zone with its own physical servers, I created the rules that apply to a test DBs in the DFW, created a dynamic membership Security Group, and nested that group in the rules. Now, any database server that I will clone which corresponds to the criteria will be automatically placed in the rules.  What’s really nice about this is that no traffic is going northbound to the perimeter FW because the packet inspection is done on the vNIC of the VMs (and only relevant rules to it are set on it) , no additional calls to security admins to configure the FW are needed after the first configuration has been made. This is a huge time saver, much more efficient in terms of resources (physical servers are now shared between zones) and a much more secure environment than having only a perimeter FW.

As usual, any comment or feedback is welcome

Cheers,

Niran


Niran is a VMware Staff Solutions Architect in the Enterprise Application Architecture team at who is focused on creating solutions for running Microsoft OS’s and apps on vSphere and vCloud Air platforms and providing top deal support to strategic customers globally.

Automating Security Policy Enforcement with NSX Service Composer

Romain DeckerBy Romain Decker

Over the past decade, IT organizations have gained significant benefits as a direct result of compute virtualization, permitting a reduction in physical complexity and an increase in operational efficiency. It also allowed for dynamic re-purposing of underlying resources to quickly and optimally meet the needs of an increasingly dynamic business.

In dynamic cloud data centers, application workloads are provisioned, moved and decommissioned on demand. In legacy network operating models, network provisioning is slow and workload mobility is limited. While compute virtualization has become the new norm, network and security models remained unchanged in data centers.

NSX is VMware’s solution to virtualize network and security for your software-defined data center. NSX network virtualization decouples the network from hardware and places it into a software abstraction layer, thus delivering for networking what VMware has already delivered for compute and storage.

Inside NSX, the Service Composer is a built-in tool that defines a new model for consuming network and security services; it allows you to provision and assign firewall policies and security services to applications in real time in a virtual infrastructure. Security policies are assigned to groups of virtual machines, and the policy is automatically applied to new virtual machines as they are added to the group.

RDecker 1

From a practical point of view, NSX Service Composer is a configuration interface that gives administrators a consistent and centralized way to provision, apply and automate network security services like anti-virus/malware protection, IPS, DLP, firewall rules, etc. Those services can be available natively in NSX or enhanced by third-party solutions.

With NSX Service Composer, security services can be consumed more efficiently in the software-defined data center. Security can be easily organized by dissociating the assets you want to protect from the policies that define how you want to protect them.

RDecker 2

Security Groups

A security group is a powerful construct that allows static or dynamic grouping based on inclusion and exclusion of objects such as virtual machines, vNICs, vSphere clusters, logical switches, and so on.

If a security group is static, the protected assets are a limited set of specific objects, whereas dynamic membership of a security group can be defined by one or multiple criteria, like vCenter containers (data centers, port groups and clusters), security tags, Active Directory groups, regular expressions on virtual machine names, and so on. When all criteria are met, virtual machines are immediately moved to the security group automatically.

In the example below, any virtual machine with a name containing “web”―AND running in “Capacity Cluster A”―will belong to this security group.

RDecker 3

 

Security group considerations:

  • Security groups can have multiple security policies assigned to them.
  • A virtual machine can live in multiple security groups at the same time.
  • Security groups can be nested inside other security groups.
  • You can include AND exclude objects from security groups.
  • Security group membership can change constantly.
  • If a virtual machine belongs to multiple security groups, the services applied to it depend on the precedence of the security policy mapped to the security groups.

Security Policies

A security policy is a collection of security services and/or firewall rules. It can contain the following:

  • Guest Introspection services (applies to virtual machines) – Data Security or third-party solution provider services such as anti-virus or vulnerability management services.
  • Distributed Firewall rules (applies to vNIC) – Rules that define the traffic to be allowed to/from/within the security group.
  • Network introspection services (applies to virtual machines) – Services that monitor your network such as IPS and network forensics.

Security services such as vulnerability management, IDS/IPS or next-generation firewalling can be inserted into the traffic flow and chained together.

Security policies are applied according to their respective weight: a security policy with a higher weight has a higher priority. By default, a new policy is assigned the highest weight so it is at the top of the table (but you can manually modify the default suggested weight to change the order).

Multiple security policies may be applied to a virtual machine because either (1) the security group that contains the virtual machine is associated with multiple policies, or, (2) the virtual machine is part of multiple security groups associated with different policies. If there is a conflict between services grouped with each policy, the weight of the policies determine the services that will be applied to the virtual machine.

For example: If policy A blocks incoming HTTP and has a weight value of 1,000, while policy B allows incoming HTTP with a weight value of 2,000, incoming HTTP traffic will be allowed because policy B has a higher weight.

The mapping between security groups and security policies results in a running configuration that is immediately enforced. The relationships between all objects can be observed in the Service Composer Canvas.

RDecker 4

 

Each block represents a security group with its associated security policies, Guest Introspection services, firewall rules, network introspection services, and the virtual machines belonging to the group or included security groups.

NSX Service Composer offers a way to automate the consumption of security services and their mapping to virtual machines using a logical policy, and it makes your life easier because you can rely on it to manage your firewall policies; security groups allow you to statically or dynamically include or exclude objects into a container, which can be used as a source or destination in a firewall rule.

Firewall rules defined in security policies are automatically adapted (based on the association between security groups and policies) and integrated into NSX Distributed Firewall (or any third-party firewall). As virtual machines are automatically added and removed from security groups during their lifecycle, the corresponding firewall rules are enforced when needed. With this association, your imagination is your only limit!

In the screenshot below, firewall rules are applied via security policies to a three-tier application; since the security group membership is dynamic, there is no need to modify firewall rules when virtual machines are added to the application (in order to scale-out, for example).

RDecker 5

 

Provision, Apply, Automate

Service Composer is one of the most powerful features of NSX: it simplifies the application of security services to virtual machines within the software-defined data center, and allows administrators to have more control over―and visibility into―security.

Service Composer accomplishes this by providing a three-step workflow:

      • Provision the services to be applied:
        • Registering the third-party service with NSX Manager (if you are not using the out-of-the-box security services available)
        • Deploying the service by installing if necessary the components required for that service to operate into each ESXi host (“Networking & Security > Installation > Service Deployments” tab)
    • Apply and visualize the security services to defined containers by applying the security policies to security groups.
    • Automate the application of these services by defining rules and criteria that specify the circumstances under which each service will be applied to a given virtual machine.

Possibilities around the NSX Service Composer are tremendous; you can create an almost infinite number of associations between security groups and security policies to efficiently automate the how security services will be consumed in the software-defined data center.

You can, for example, combine service composer capabilities and VMware vRealize Automation Center to achieve secure, automated, on-demand micro-segmentation. Another example is a quarantine workflow, where― after a virus detection―a virtual machine is automatically and immediately moved to a quarantine security group, whose security policies can take action, like remediation, strengthened firewall rules and traffic steering.


Romain Decker is a Technical Solutions Architect in the Professional Services Engineering team and is based in France.