2000382-en[1]

You might also like

Download as pdf or txt
Download as pdf or txt
You are on page 1of 7

WHITE PAPER

Alternatives for Securing


Virtual Networks
A Different Network Requires a Different Approach—
Extending Security to the Virtual World

Copyright © 2011, Juniper Networks, Inc. 1


WHITE PAPER - Alternatives for Securing Virtual Networks

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

The vGW Virtual Gateway Solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

Enforcing Security Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

Continuous Protection for Migrating VMs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

Detecting Intrusions Without Adding Overhead . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

Supporting Administrators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

Processes for Installing a Firewall in the Virtual Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

Conclusion—Securing the Whole Enterprise Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

About Juniper Networks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2 Copyright © 2011, Juniper Networks, Inc.


WHITE PAPER - Alternatives for Securing Virtual Networks

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® vGW Virtual Gateway 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, the vGW
monitors and controls inter-VM traffic, enforcing security policies at the individual VM level. Because vGW 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

Copyright © 2011, Juniper Networks, Inc. 3


WHITE PAPER - Alternatives for Securing Virtual Networks

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.

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.

4 Copyright © 2011, Juniper Networks, Inc.


WHITE PAPER - Alternatives for Securing Virtual Networks

The vGW Virtual Gateway


Juniper Networks vGW Virtual Gateway 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. vGW is the first
purpose-built stateful firewall that mitigates virtual network risks while maintaining virtualization ROI.

Enforcing Security Policies


The vGW 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 vGW provides “write once, protect many” efficiency.

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 vGW, 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, vGW maintains the
connected states of all applications within the migrating VM. Only vGW 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 vGW 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.

vGW 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.

Copyright © 2011, Juniper Networks, Inc. 5


WHITE PAPER - Alternatives for Securing Virtual Networks

Supporting Administrators
Security considerations alone make vGW 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 vGW 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. vGW Virtual Gateway)


Traditional Firewall vGW Virtual Gateway

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

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 vGW automatically connects with vCenter and imports operating
data on all VMs. The vGW dashboard shows live statistics on each VM’s resource utilization along with its network activity.
The vGW 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 vGW 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 vGW Virtual Gateway provides
the thorough, continuous, and efficient security required by today’s virtualized data centers.

6 Copyright © 2011, Juniper Networks, Inc.


WHITE PAPER - Alternatives for Securing Virtual Networks

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 www.juniper.net.

Corporate and Sales Headquarters APAC Headquarters EMEA Headquarters To purchase Juniper Networks solutions,
Juniper Networks, Inc. Juniper Networks (Hong Kong) Juniper Networks Ireland please contact your Juniper Networks
1194 North Mathilda Avenue 26/F, Cityplaza One Airside Business Park representative at 1-866-298-6428 or
Sunnyvale, CA 94089 USA 1111 King’s Road Swords, County Dublin, Ireland
authorized reseller.
Phone: 888.JUNIPER (888.586.4737) Taikoo Shing, Hong Kong Phone: 35.31.8903.600
or 408.745.2000 Phone: 852.2332.3636 EMEA Sales: 00800.4586.4737
Fax: 408.745.2100 Fax: 852.2574.7803 Fax: 35.31.8903.601
www.juniper.net

Copyright 2011 Juniper Networks, Inc. All rights reserved. Juniper Networks, the Juniper Networks logo, Junos,
NetScreen, and ScreenOS 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.

2000382-001-EN Feb 2011 Printed on recycled paper

Copyright © 2011, Juniper Networks, Inc. 7

You might also like