The NSX hands-on labs are the most popular by far.
At last week’s VMworld 2014, the award for most attention generated clearly goes to NSX. Not only were there over 50 sessions spread throughout the event and a significant amount of vendors focusing on highlighting integration of NSX with their product, but close to 40% of the Hands on Labs were running a single course: SPL-SDC-1403 – VMware NSX Introduction.
And that is not without a reason; NSX – VMware’s Software Defined Networking (SDN) solution – will drastically change the way we look at networking, previously a mostly physical affair.
Now, SDN as a concept is much older than NSX. Multiple vendors – including VMware – have tried to introduce this technology to the datacenter before. Cisco has its Nexus1000V which integrate with vSwitches to provide advanced functionality, VMware started off with the vShield products such as vShield Zones and vShield App (which later evolved into vCloud Networking & Security) and Brocade integrates with Openflow/Opendaylight. But all of these solutions had two major issues: integration with virtualisation products was clunky at best, and more importantly: the underlying physical network was still by and large manually operated.
Back in 2012, when VMware acquired Nicira, none of the major network vendors had solved this issue yet, and as such there was quite some scepticism from the networking community. But two years later, with the final product released and vendors showing their support, even the most conservative of network administrators and architects have to admit that network virtualisation is here to stay.
The problems with today’s security
As was mentioned in the VMworld keynote, the two major issues with datacenter security right now are
- Day to day operations consist largely of manual changes. While some parts of the related processes can be automated, changes to firewall rules, load balancers, ids systems, etc. mostly mean a system administrator has to log in to a device, change the settings in a GUI (or run a script if you’re lucky) and confirm that the change was performed correctly.
- We focus the bulk of our security budget and resources on protecting the perimeter. We invest in massive edge firewalls, IDS, two factor authentication for external users, etc. But once an attacker manages to get through, there is usually very little stopping them from moving through the internal network unhindered. As the keynote showed, most datacenters are like an egg. A hard outer shell with a soft gooey center.
There are quite a few reasons why security is generally set up this way. First of all, there is the issue that network management is very labour-intensive. Every new application, service or device requires you to configure new firewall rules, load balancers and security appliances, which tends to grow out of hand very quickly. it is not uncommon to see perimeter firewalls with tens of thousands of rules, not all of which have an obvious function. If you wanted to protect multitiered apps internally as well, a perimeter would need to be established between every tier of the app, increasing complexity even more and fragmenting your security policies across multiple devices. In addition, with the tendency of application development to move to shorter and shorter release cycles and increasingly frequent test/dev releases, network operations generally cannot keep up. So the logical choice is to put as much general protection in place as possible and try to prevent any security breaches on the edge of the datacenter.
The issue of high turnaround times on network changes is one we can solve through the use of templates. NSX allows a security administrator to define generic blueprints called security policies which define preset security settings such as firewall rules, content scanning and integration with third party security products. Because NSX can apply a security setting to a vSphere object dynamically instead of a source or destination IP, it means these blueprints can now be defined once and reused anywhere. These security policies can in turn be consumed either by statically including vSphere objects (datacenters, logical switches, virtual machines, clusters, etc.) or by dynamically applying the security policy based on properties such as a security tag, active directory users and groups or by matching the name of an object. You could – for example – apply a rule that only allows HTTP and HTTPS traffic inbound to all machines with the prefix web- in their VM name. Because these rules are applied to vSphere objects instead of static IP addresses, your infrastructure will be protected even if a virtual machine changes IP address, moves to a different network or gets deployed without notifying network operations.
A classic 3-tier application, implemented in NSX. Credits: networkinferno.com
The second issue we talked about – the protection of internal networks in addition to the datacenter edge – can be simplified in two ways. The most obvious solution is to place separate virtual machines in a separate logical switch and use the distributed router feature of NSX to filter traffic between machines on different switches. This is a very valid solution and is comparable to how this would be done in a physical network world. The second – and much more elegant – solution is to take advantage of the distributed firewall’s ability to filter layer 3-7 traffic between layer 2 adjacent virtual machines. Because the hypervisor has full insight into all network traffic passing through it, you can connect all virtual machines in your multitiered app to the same logical switch, and filter any undesired traffic leaving or entering the VM, even if traffic is not actually routed over a layer 3 interface. Besides multitiered apps, some other use cases for this are isolating desktops in your VDI environment without having to resort to private VLANs, allowing only specific ports between application servers even in the same tier, or quarantine of infected systems. By properly using the distributed firewall in your environment, any security breaches can be contained at the virtual machine level.
In addition to the security features offered by NSX (logical firewalling, distributed firewalling, data security) the product also allows third party vendors to integrate seamlessly with existing components, allowing you to automatically configure any security solutions you already have. Examples of products are Trend Micro’s deep security, Palo Alto’s range of security appliances and management products and F5’s loadbalancer solutions. Whether you already have products in place and would like to keep using them or have a business case for which the default products do not suffice, any vendor can integrate its product into NSX, allowing you to deploy, monitor and configure everything centrally.
Truly dynamic protection
By using the security policies we mentioned earlier, you can build a security policy that will automatically enforce security in a manageable way. Through the use of vRealize Automation (formerly VCAC) you can deploy blueprints with preconfigured security groups to ensure virtual machines are protected even before they are powered on, and by using tags to apply security policies you can automatically quarantaine virtual machines or users in case of an infection, a data leak or malicious behaviour. This allows you to respond to any incident immediately and prevent any collateral damage.
An example of this would be a public web server in your DMZ that is potentially compromised. As soon as the security breach is detected, the machine is tagged as exhibiting suspicious behaviour through the vSphere API, and any security policy that is applied to machines with this tag will now be enforced. This will either allow you to take the machine offline, restrict its allowed traffic, start an external integrity monitoring of the machine or enable additional traffic inspection to determine the root cause. Through the use of third party products such as Rapid7’s Nexpose these additional security policies could even be applied preemptively if a vulnerability scan detects a potential risk. Auditing systems or users is also possible in this way by assigning security policies as soon as Data security detects any sensitive data.
NSX is not just for virtual devices
By extending your virtual network to the physical world, all the security features offered by NSX are now also available to any non-virtualized systems you might have. Vendors such as Cumulus Networks, Juniper and Arista have released a VTEP (VXLAN Tunnel Endpoint) implementations for their hardware. VTEP-enabled devices allow you to treat any physical network or device connected to your switch as an extension of your NSX networks. This allows you to filter traffic even between a layer 2 adjacent physical and virtual device, route traffic from physical machines through your virtual logical distributed routers or edge gateways where firewall rules can be applied, enforce data security and monitor these systems without requiring any legacy security devices for these systems. The only disadvantage in this is that physical machines are only identifiable by IP or MAC address, but any existing security policy you have already defined for your virtual infrastructure can also be applied to these physical resources.
In closing, NSX will allow you to drastically simplify your network security by automating deployment or letting application owners self-service security policies. In addition, because it offers some unique features not present in current security solutions, we are now able to protect virtual machines at the hypervisor level without the use of in-guest firewalls, ensuring that resources are always protected, regardless of operating system, configuration or any changes performed by application owners. As more and more vendors extend their products into NSX, you can deploy the solution that best fits your needs and secure your infrastructure the way you’ve always wanted to but never really could.
If you would like to discuss the possibilities of NSX, I am reachable by phone (+31 6 29007866) or email.
