ALTERNATIVES FOR SECURING VIRTUAL NETWORKS

Transcription

1 White Paper ALTERNATIVES FOR SECURING VIRTUAL NETWORKS A Different Network Requires a Different Approach Extending Security to the Virtual World Copyright 2013, Juniper Networks, Inc. 1

2 Table of Contents Executive Summary...3 Introduction...3 VM Security Challenges...3 VMware Technologies Bring Added Challenges...3 Extending Physical Security to the Virtual Arena... 4 Limitations of Firewalls Built for a Different World... 4 Securing the Virtual Machine... 4 Firefly Host... 4 Enforcing Security Policies... 4 Continuous Protection for Migrating VMs... 5 Detecting Intrusions Without Adding Overhead... 5 Supporting Administrators... 5 Processes for Installing a Firewall in the Virtual Network... 6 Conclusion Securing the Whole Enterprise Network... 6 About Juniper Networks Copyright 2013, Juniper Networks, Inc.

3 Executive Summary Invisible networks are spreading within data centers. Virtualization of computing hardware is creating these networks of VMs within physical servers. Traditional network monitoring and security measures are unable to see or control the growing volume of inter-vm traffic. Enterprises are increasingly concerned about the risks of virtual networks, which range from undeterred malware exploits to mixing trusted and untrusted systems. Some have scaled back the scope and economic benefits of virtualization. Others have tried to apply traditional security to the virtual environment. However, key virtualization technologies such as VMotion from VMware break the traditional models of physical network tools. Juniper Networks Firefly Host* has been purpose-built to mitigate the risks of virtual networks, while maintaining the ROI of virtualization. A next-generation security solution specifically designed for the virtual environment, Firefly Host monitors and controls inter-vm traffic, enforcing security policies at the individual VM level. Because Firefly Host was designed from scratch to secure the latest virtualization technologies, it provides the thorough protection and ease of operation missing from traditional physical networking products and workarounds. In this white paper, we will examine the virtualization issues that challenge today s data centers and discuss their best options for securing virtual networks. Introduction VM Security Challenges An increasingly large share of data center network traffic is occurring between VMs within a virtualization server on the virtual network, yet the VM and network administrators have minimal ability to see or control inter-vm communication. By default, every VM on the host can communicate directly with every other VM through a simple virtual switch, without any inter-vm traffic monitoring or policy-based inspection and filtering. Inter-VM traffic on a host doesn t touch the physical network it is invisible to traditional network monitoring tools and unprotected by physical network security devices. As a result, VMs are highly vulnerable to attack. For example, a buffer overflow attack on a vulnerable application can enable an attacker to run arbitrary code in a VM. And with no packet inspection or filtering of virtual network traffic, the attacker can gain access to all other VMs resident on the host. Experienced security professionals know that IT workloads with different levels of trust should never exist in the same security domain. Mixing trust levels can result in privilege escalation that allows unauthorized parties to view confidential data. A Web server that grants access to the general public or to all employees, for example, must not have an unfiltered connection to an enterprise resource planning (ERP) system with private employee data or unreleased financials. Most IT-related government and industry regulations demand that enterprises take necessary steps to prevent trust level breaches. Yet for various reasons, VMs with different trust levels often wind up on the same host with nothing to filter the traffic between them. For instance, it is easy for even non-it employees to create and deploy new VMs. The potential for mixing trust levels is therefore even greater than in the physical world, where provisioning new physical servers takes more time and planning. It is also easy to accidentally combine trusted and untrusted workloads in the same security domain when transitioning a VM from a low trust testing environment to a more trusted production environment. Using offshore contractors for development or QA can increase this exposure. VMware Technologies Bring Added Challenges VMware live migration technologies VMotion and DRS magnify the potential for inadvertently mixing trust levels. On the one hand, achieving the full economic benefits of virtualization requires using VMotion, but the downside is unpredictable combinations of trusted and untrusted VMs sharing the same virtual subnet. The financial justification for virtualization often depends on maximizing capacity utilization or hosting more and more VMs on a single piece of hardware. IT groups may have little incentive to assess trust levels and strictly segregate VM workloads accordingly. To make matters worse, VM administrators may not be aware that the safeguards that shield sensitive data and critical applications on the physical LAN do not exist within virtualization servers. Faced with the real risks of mixed trust levels in virtual environments, some network security professionals have reined in the scope of virtualization. Some greatly limit the number of VMs per physical host, and perhaps assign a different physical network interface card (NIC) to each one, in order to isolate VMs from one another. Some go so far as to prohibit the use of VMotion or DRS (or both) to avoid compromising enterprise security. The disadvantage of this brute force approach is a reduction in the operating and capital cost savings available from virtualization. Buying, powering, cooling, hosting, and maintaining extra hardware for new VMs purely to address security concerns is an expensive solution that can have a severely negative impact on a project s ROI. *Formerly vgw Virtual Gateway Copyright 2013, Juniper Networks, Inc. 3

4 Extending Physical Security to the Virtual Arena Other enterprises have tried securing VMs by extending physical network security to the virtual arena. Most often, they assign a small group of VMs or even a single VM to its own host-based VLAN to achieve segmentation and isolation. A major drawback of VLAN-based security is the growth in complexity and administrative costs that occurs as the VM population grows. Costs accelerate due to the extra time needed to: Set up and maintain VLANs for each new virtualization server and VM group Synchronize VLAN configurations on virtual and physical switches Troubleshoot and fix configuration errors such as assigning a VM to the wrong VLAN Manage the growth and complexity of access control lists as VLANs proliferate Ensure compatibility between physical network and virtual network security policies All of these factors apply to a static VM environment. They can become far worse if the enterprise uses VMotion, with VMs continually on the move between hosts and virtual switches. Despite all of the added cost and complexity, host-based VLANs leave a security gap whenever more than one VM is assigned to a given VLAN. Without a traffic monitoring and filtering mechanism, inter-vm communication within the VLAN remains invisible and outside the realm of traditional policy enforcement. Limitations of Firewalls Built for a Different World Some security managers have tried using traditional perimeter firewalls to secure virtual networks. They redirect inter- VM traffic to physical firewalls for inspection and then send it back into the virtualization servers. Alternatively, some try installing perimeter firewalls as VMs on virtual servers. Both schemes suffer from major limitations. The leading perimeter firewalls were architected years before the newer features of virtualization existed. As such, they lack tight integration with virtualization management systems such as VMware vcenter. This makes deployment and administration highly manual, arduous, and error-prone processes. Also, traditional firewalls aren t able to maintain state information or provide continuous protection for VMs during VMotion or DRS. Network security administrators must undertake constant and labor-intensive firewall policy adjustments to account for VMs traveling between physical servers. External perimeter firewalls have the additional limitation of being incapable of inspecting or filtering inter-vm communications. Conversely, running perimeter firewalls on virtualization servers can create an unacceptably large overhead burden due to their typically high resource requirements. If the perimeter firewalls are supplemented with an intrusion prevention system (IPS) running on the host, there may be little capacity left for applications. Securing the Virtual Machine Finally, none of the workarounds or applications of physical network technology to the virtual environment addresses the threat of the rogue VM. New virtual machines typically begin life with their network ports open and many protocols available to many sources. As such, a new VM deployed in any way that is not completely isolated from every other VM becomes an instant source or destination for malware or other exploit. Clearly, virtualized environments demand security measures specifically designed for them. Only purpose-built defenses can preserve virtual network security, regulatory compliance, and the financial benefits of virtualization. Firefly Host Juniper Networks Firefly Host addresses the inadequacies and excessive costs of applying physical security measures to virtual networks, and has been architected for the virtual environment and its unique challenges. Firefly Host is the first purpose-built stateful firewall that mitigates virtual network risks while maintaining virtualization ROI. Enforcing Security Policies The Firefly Host installs as a virtual appliance on each virtualization host and inspects all traffic to and from each VM guest. Administrators use a web-based management console to define and centrally manage traditional firewall rules that include allowed and rejected sources, destinations, protocols, actions to take, etc. Rules can apply to all VMs, a group of VMs with similar connectivity and security needs (such as Web servers), or a single VM. Policies built with these rules can also be enforced at the global, group, and per-vm levels. This three-tiered rule and policy structure simplifies administration while giving network administrators granular control of virtual network traffic. Where older firewall technologies often require manual replication of rules across multiple physical firewalls, the Firefly Host provides write once, protect many efficiency. 4 Copyright 2013, Juniper Networks, Inc.

5 Continuous Protection for Migrating VMs Using VMotion, administrators can conduct virtualization hardware maintenance with little or no application downtime, and also maximize hardware capacity utilization. The inability of host-based VLANs or legacy firewalls to secure these high value capabilities and protect VMs in flight highlights the need for purpose-built virtual network security. With Firefly Host, the virtual firewall is attached to a VM at all times and travels with it during a VMotion event. This assures continuous security policy enforcement before, during, and after every live migration. Just as importantly, Firefly Host maintains the connected states of all applications within the migrating VM. Only Firefly Host provides this combination of always on protection and virtualization feature support. Detecting Intrusions Without Adding Overhead While controlling traffic and enforcing policies is paramount for virtualization security, being able to detect attacks occurring exclusively within the virtual network is also extremely valuable. The challenge in this case is to avoid burdening the virtualization server with the heavy processing overhead characteristic of network IDS. Attack signatures and detection techniques are essentially the same in the physical and virtual environments, so it can make sense to leverage existing physical IDS/IPS systems. The Firefly Host makes this possible with rule-based mirroring of virtual network traffic to external network devices. The advantages of this approach to intrusion detection and prevention are minimal additional cost or overhead and continuous monitoring during VMotion events. Numerous studies have identified human error as a primary cause of security breaches. Mistakes such as misconfigurations can expose vulnerable applications and servers to attack. The problem is especially severe in the virtual world, where the phenomenon of VM sprawl is evidence that virtualization is occurring outside established change management processes and other IT checks. Firefly Host mitigates the risks of VM sprawl. It automatically applies an administrator defined default firewall policy to every newly created VM, closing any security holes before they can be exploited. For example, a default policy might only allow use of specified administrative protocols while blocking all other traffic. The initial policy can be customized when the security posture and connectivity needs of the VM are better understood. Supporting Administrators Security considerations alone make Firefly Host the right choice for protecting VMs. In addition, the solution has the advantage of being much easier to set up and maintain than alternatives. As shown in the following table, automated installation allows administrators to deploy the Firefly Host with a few clicks. By way of contrast, deploying a legacy firewall in a virtual environment is a cumbersome process with many opportunities for error. Table 1. Administration Requirements (traditional firewall vs. Firefly Host) Traditional Firewall Firefly Host 1. Create a new vswitch 1. Click items to secure in UI (entire ESX server, specific port group, etc.) 2. Create promiscuous port group on original vswitch 2. Click Secure button 3. Create promiscuous port group on new vswitch 4. Create firewall VM a. Copy VM archive b. Extract VM files c. Add VM to vcenter d. Configure NIC connections 5. For each port group to be secured, create a mirror of it on the secured vswitch 6. Move each VM to be secured to the new vswitch/port group 7. Remove previous port group 8. Create new secured port group using name of original port group 9. Move VMs to final port group Copyright 2013, Juniper Networks, Inc. 5

6 Processes for Installing a Firewall in the Virtual Network Administrators need to know both the operational and security status of a VM in order to troubleshoot problems and design policies most effectively. That s why, after installation, the Firefly Host automatically connects with vcenter and imports operating data on all VMs. The Firefly Host dashboard shows live statistics on each VM s resource utilization along with its network activity. The Firefly Host solution also synchronizes automatically and on demand with vcenter to quickly secure newly created VMs. Monitoring, logging, and analyzing inter-vm traffic at the individual VM level is a prerequisite for creating a secure environment. Accordingly, the Firefly Host provides the same real-time views of traffic into and out of each VM that the Altor Networks Virtual Network Security Analyzer (VNSA) offers. It outputs firewall log data in system log format, broadening security event correlation systems coverage to the virtual network. It uses SNMP traps to send admin alerts via existing network management systems. And it provides printable reports of historical VM traffic trends over configurable periods to support compliance audits and to help with firewall policy definition. Conclusion Securing the Whole Enterprise Network An increasingly large share of data center network traffic is occurring between virtual machines within a virtualization server on the virtual network, yet the VM and network administrators have minimal ability to see or control inter-vm communication. Inter-VM traffic on a host doesn t touch the physical network, and as such it is invisible to traditional network monitoring tools, and unprotected by physical network security devices. As a result, traditional network monitoring and security measures are unable to effectively manage the growing volume of inter-vm traffic, leaving VMs highly vulnerable to attack. It is hard to justify a lower security posture for the virtual network than for its physical counterpart. In many cases, the data passing between VMs arguably needs a higher level of security. The cost, complexity, and security limitations of using physical network security within the virtual environment rule out pre-virtualization technologies as viable choices. Only Juniper Networks pioneering, purpose-built Firefly Host provides the thorough, continuous, and efficient security required by today s virtualized data centers. About Juniper Networks Juniper Networks is in the business of network innovation. From devices to data centers, from consumers to cloud providers, Juniper Networks delivers the software, silicon and systems that transform the experience and economics of networking. The company serves customers and partners worldwide. Additional information can be found at Corporate and Sales Headquarters Juniper Networks, Inc North Mathilda Avenue Sunnyvale, CA USA Phone: 888.JUNIPER ( ) or Fax: APAC and EMEA Headquarters Juniper Networks International B.V. Boeing Avenue PZ Schiphol-Rijk Amsterdam, The Netherlands Phone: Fax: To purchase Juniper Networks solutions, please contact your Juniper Networks representative at or authorized reseller. Copyright 2013 Juniper Networks, Inc. All rights reserved. Juniper Networks, the Juniper Networks logo, Junos and QFabric are registered trademarks of Juniper Networks, Inc. in the United States and other countries. All other trademarks, service marks, registered marks, or registered service marks are the property of their respective owners. Juniper Networks assumes no responsibility for any inaccuracies in this document. Juniper Networks reserves the right to change, modify, transfer, or otherwise revise this publication without notice EN Nov 2013 Printed on recycled paper 6 Copyright 2013, Juniper Networks, Inc.