A Critical Analysis of Layer 2 Network Security in
Virtualized Environments
Ronny L. Bull
[email protected]
A Doctoral Dissertation Research Proposal
Submitted to the
Department of Computer Science
Clarkson University
in Partial Fulfillment of the
Requirements for the
Degree of
Doctor of Philosophy
Postdam, New York
Fall 2014
A Critical Analysis of Layer 2 Network Security in
Virtualized Environments
Except where reference is made to the work of others, the work described in this Doctoral
Dissertation Research Proposal is my own or was done in collaboration with my advisory
committee. Further, the content of this Doctoral Dissertation Research Proposal is truthful in
regards to my own work and the portrayal of others’ work. This Doctoral Dissertation Research
Proposal does not include proprietary or classified information.
Ronny L. Bull
[email protected]
Certificate of Approval:
A Critical Analysis of Layer 2 Network Security in
Virtualized Environments
Ronny L. Bull
[email protected]
Permission is granted to Clarkson University to make copies of this Doctoral Dissertation
Research Proposal at its discretion, upon the request of individuals or institutions and at their
expense. The author reserves all publication rights.
Ronny L. Bull
[email protected]
Fall 2014
iii
Abstract
Cloud service providers offer their customers the ability to access virtual private servers hosted
within multi-tenant environments. Typically these virtual machines are connected to the physical
network via a virtualized network within the host environment. This could be as simple as a bridged
interface connected to multiple virtual interfaces attached to each virtual machine, or it could entail
the usage of a virtual switch to provide more robust networking features such as VLANs, QoS, and
monitoring. All client virtual machines are essentially connected to a virtual version of a physical
networking device. In this research, I intend to explore whether Layer 2 network attacks that work
on physical switches apply to their virtualized counterparts by performing a systematic study across
four major hypervisor environments with seven different virtual networking configurations. In the
preliminary research performed each environment was evaluated by utilizing a malicious virtual
machine to run a MAC flooding attack along with Wireshark in order to verify if it was possible to
eavesdrop on other client traffic passing over the same virtual network. It was concluded that out
of the four virtual switch implementations tested Open vSwitch proves to be the most vulnerable
to MAC flooding allowing for an attacker to capture a co-resident virtual machine’s network traffic.
These initial results highlight the necessity for further research in the area of virtualized network
security.
iv
Table of Contents
List of Figures
viii
List of Tables
ix
1
1 Background and Related Work
1.1
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1
1.2
Network Configuration Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2
1.2.1
Bridging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2
1.2.2
Switching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3
Layer 2 Network Attacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4
1.3.1
MAC Attacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4
1.3.2
STP Attacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4
1.3.3
VLAN Hopping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
1.3.4
DHCP Attacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
1.3.5
ARP Spoofing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6
1.3
1.4
7
2 Detailed Research Plan
v
2.1
Motivation
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7
2.2
Research Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7
2.3
Preliminary Research - MAC Flooding Attacks . . . . . . . . . . . . . . . . . . . . .
9
2.4
2.3.1
Bridged Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.3.2
Open vSwitch 1.11.0 Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.3.3
Open vSwitch 2.0.0 Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.3.4
Citrix XenServer 6.2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.3.5
Microsoft Hyper-V Server 2008 R2 . . . . . . . . . . . . . . . . . . . . . . . . 12
2.3.6
VMware vSphere (ESXi) 5.5 . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.3.7
Summary of Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Current Work - DHCP Attacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.4.1
Duplicate Addressing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.4.2
Rogue DNS Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.4.3
Incorrect Default Gateway . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.4.4
Remote Execution of Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.4.5
Test Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.4.6
Summary of Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.4.7
Mitigation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.5
Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.6
Proposed Timeline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
vi
3 Conclusion
22
Bibliography
23
vii
List of Figures
1.1
A basic bridge using a forwarding table to pass requests between network segments.
2
1.2
A switch and its CAM table. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3
2.1
A malicious virtual machine located on a multi-tenant virtual network. . . . . . . . .
9
2.2
A malicious virtual machine running macof to flood a virtual network with random
MAC addresses and malformed packets. . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.3
A malicious virtual machine running macof on an Open vSwitch virtual network and
successfully sniffing HTTP traffic with Wireshark from another tenant virtual machine. 11
2.4
Dynamic Host Configuration Protocol process. . . . . . . . . . . . . . . . . . . . . . 14
2.5
Duplicate addressing within a broadcast domain due to the presence of a rogue
DHCP server. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.6
Presence of a poisoned DNS server on a network whos address is provided to clients
associated with a rogue DHCP server. . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.7
Malicious VM configured as a router on a network whose address is provided to
clients as a default gateway when associated with a rogue DHCP server. . . . . . . . 17
2.8
Malicious DHCP server passing a configuration option to a client VM that leverages
the BASH shellshock vulnerability instructing the client to delete everything in /
recursively. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
viii
List of Tables
2.1
Summary of MAC flooding attack results across seven test environments . . . . . . . 13
2.2
Summary of virtual network usability during a MAC flooding attack for seven different environments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.3
New virtual machines added to each hypervisor platform for Layer 2 DHCP attack
testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.4
Summary of DHCP shellshock attack across seven test environments . . . . . . . . . 19
2.5
Summary of poisoned DNS server attack across seven test environments . . . . . . . 19
2.6
Summary of invalid default gateway attack across seven test environments . . . . . . 20
2.7
Summary of rogue default gateway attack across seven test environments . . . . . . 20
2.8
Plan for completion of research . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
ix
Chapter 1
Background and Related Work
1.1
Introduction
With the growing popularity of Internet based cloud service providers such as Amazon EC2
and Microsoft Azure, more businesses are turning to these services to host their mission critical
data and applications. Cloud providers offer their customers the ability to roll out a plethora of
heterogeneous virtual machines within their environments, all hosted on shared resources such as
CPU, memory, and networking hardware. Each virtual host must provision guest virtual machine
access to network resources, especially if Internet accessible services will be offered on the guest.
Typically virtualized hosting environments will utilize either a bridged network interface or a virtualized switch such as Open vSwitch[31, 32] for Xen and KVM based environments, or the Cisco
Nexus 1000V Series virtual switch for VMware vSphere environments[12]. These virtual switches
are designed to emulate their physical counterparts. Whether they can be exploited through Layer
2 vulnerabilities in the same manner warrants further investigation. It is important for users of
multi-tenant cloud services to understand how secure their network traffic is from other users of
the same cloud services. If another tenant can launch a Layer 2 network attack and capture all the
network traffic flowing from and to their virtual machines, this is clearly important to know. By
understanding which virtual switches are vulnerable to which attacks, users can evaluate the workloads they run in the cloud, consider additional security mechanisms such as increased encryption
and/or pressure cloud providers to deploy monitoring and detection of possible Layer 2 attacks.
The vulnerability across virtual switch products to various categories of Layer 2 network attacks
has not been thoroughly examined. In my preliminary research a systematic study was performed
to evaluate the effects of MAC flooding attacks across four major hypervisor environments with
seven different virtual network configurations. Currently I am conducting research geared toward
determining the effects of Layer 2 DHCP attacks within the same test environments. VLAN and
ARP attacks will also be explored using the experimental infrastructure in order to provide a
detailed overview of the state of Layer 2 network security in virtualized environments.
1
1.2
Network Configuration Options
As previously stated virtual networks are configured to use either a virtual bridge or virtual
switch in order to provide inter-networking capabilities for connected virtual machines. These Layer
2 virtual networking devices can then be bound to a physical network interface on the host machine
in order to connect the virtual network to the physical world so that virtual machines can interact
with physical devices from the local network or the Internet.
1.2.1
Bridging
Bridged mode is the simplest of configurations for an interface dedicated to virtual machine use.
A bridge connects two or more network segments at Layer 2 creating separate collision domains[34].
A forwarding table[22, 34] is utilized that consists of a list of MAC addresses that are associated
with devices located on each network segment connected to the bridge (Figure 1.1). Requests are
forwarded based upon the destination MAC address located within the Ethernet frame. A frame
is forwarded across the bridge only if the MAC address in the destination block of the frame is
reachable from a different segment attached to the bridge. Otherwise, the frame is directed to a
destination address located on the same segment as the transmitting device or dropped.
Figure 1.1: A basic bridge using a forwarding table to pass requests between network segments.
2
In virtualized environments, guest machines utilize user-space network TAP interfaces that
simulate a Layer 2 network device in order to connect to the virtual bridge. Typically, the virtual
bridge is configured and bound to a physical interface on the host machine that is dedicated solely
to virtual machine traffic.
1.2.2
Switching
Physical switches have the capability of operating at Layer 2 or higher of the OSI model.
Switches can be thought of as multi-port bridges[34] where each port of the switch is considered
as its own isolated collision domain. Instead of a forwarding table switches employ the use of
content addressable memory, otherwise known as a CAM table[34]. Content addressable memory
is specialized memory hardware located within a switch that allows for the retention of a dynamic
table or buffer that is used to map MAC addresses of devices to the ports they are connected to
(Figure 1.2). This allows a switch to intelligently send traffic directly to any connected device
without broadcasting frames to every port on the switch. The switch reads the frame header for
the destination MAC address of the target device, matches the address against its CAM table, then
forwards the frame on to the correct device. The use of a CAM table and the separation of collision
domains are key factors in preventing eavesdropping of network traffic between devices connected
to the switch. However, a physical switch is an embedded device and has a finite amount of memory
available to its CAM table, once it is used up the switch can no longer dynamically add to its buffer
thereby forcing it into hub mode. The majority of physical switches in use today employ CAM
chips that are capable of holding up to 32,000 addresses[34] which can easily be saturated by a
single MAC flooding attack in a very short amount of time.
Figure 1.2: A switch and its CAM table.
3
Virtual switches are an advanced form of virtual networking that emulate their physical counterparts. They are capable of providing features such as VLAN traffic separation, performance and
traffic monitoring, as well as quality of service (QoS) solutions. Virtual machines are connected to
a virtual switch by the way of virtual interfaces (VIF) which are similar to the TAP devices used
in conjunction with virtual bridges. Also just like physical switches, virtual switches utilize CAM
tables emulated in software in order to manage the flow of traffic between devices connected to
different virtual interfaces.
1.3
Layer 2 Network Attacks
1.3.1
MAC Attacks
The most popular attack in this category is the MAC flooding attack. In this attack, a switch is
flooded with numerous random MAC addresses in order to fill up the content addressable memory
(CAM) buffer within the switch forcing it into a fail safe mode, otherwise known as hub mode.
When a switch is operating in hub mode, the inherent separation of collision domains is broken
and all frames passing through the switch are forwarded to all connected devices. This allows for
passive eavesdropping of all traffic passing through the device. MAC flooding can be mitigated by
enforcing port security on physical switches which imposes a limit on the amount of MAC addresses
that can send traffic to a specific port[11]. This feature is not implemented within the majority of
the virtual switches available today rendering them vulnerable to MAC flooding attacks.
1.3.2
STP Attacks
In this type of attack, incorrect BPDU frames are sent to switches in order to modify the
spanning tree topology implemented on the network. By exploiting STP, an attacker could perform
a man-in-the-middle (MITM) attack allowing eavesdropping on traffic passing between two nodes
on a network[23]. The attacker could also cause a denial of service (DoS) situation rendering
services unavailable to legitimate users. These attacks can be mitigated on Cisco Catalyst switches
by enabling either the Cisco Catalyst BPDU Guard or Root Guard feature on the device[23]. Seeing
as these are proprietary features available only on Cisco Catalyst switches they offer no help in
preventing these attacks from being successful within a virtualized network that utilizes STP.
4
1.3.3
VLAN Hopping
VLAN hopping is the term used to describe an attack where an Ethernet frame is modified to
force traffic to traverse (hop) VLANs in order to allow an attacker to gain unauthorized access to
restricted portions of a network. More specifically, an attacker modifies the VLAN tag embedded
in the frame to contain the ID of the target VLAN on the network. In order to perform this type of
attack against a switch, the attacker must be connected to a port on the device that is a member of
the default VLAN, or one that is setup as a trunk port. When the modified frame is passed through
the switch, the VLAN tag is read and the switch places it within the correct broadcast domain
associated with that VLAN ID. If successful, the attacker can then proceed to intercept traffic
on the target VLAN or perform other malicious activities such as DoS attacks against services
running on that particular portion of the network. VLAN hopping can be mitigated by enforcing
strict VLAN configuration of physical switch ports to prevent unauthorized access to the default
VLAN or trunk ports.
1.3.4
DHCP Attacks
In order to perform a Layer 2 DHCP attack an attacker must place a rogue DHCP server on a
network in hopes that clients in the broadcast domain associate with it rather than the legitimate
DHCP server. Once a client receives an IP address lease from a malicious DHCP server under an
attacker’s control, that client could also be seeded with the IP address of a poisoned DNS server, an
incorrect default gateway, or be forced to run malicious code. This type of attack could also cause
DoS situations where duplicate addressing occurs on the network causing the resources bound to
those addresses to be inaccessible. These attacks can be mitigated by enforcing static addressing,
or by using utilities to monitor the network and alert administrators when this type of activity is
encountered.
1.3.5
ARP Spoofing
ARP spoofing is a technique used by attackers that allows for the hijacking of traffic destined
for another host. Specifically, by using ARP spoofing an attacker can perform a man-in-the-middle
(MITM) attack that allows for eavesdropping between two hosts on a network. An attacker can
also broadcast fake ARP messages to a network to redirect traffic or create DoS situations. ARP
spoofing attacks can be mitigated by using static ARP entries for all hosts on a network, however
this is a cumbersome task and is typically avoided unless absolutely necessary. More often that not
5
savvy administrators will employ the use of network monitoring utilities to watch for suspicious
behavior and react accordingly based upon the alerts.
1.4
Related Work
There has already been a substantial amount of work performed studying the vulnerability of
physical networks to Layer 2 attacks, but the impact on virtual networks has not received much
attention. A literature review revealed that there is a plethora of publications addressing Layer 2
networking issues inherent in physical networks[2, 13, 23, 40]. This is beneficial in the fact that
published research previously performed on physical networks can be repeated[14] within virtual
environments and comparisons can be made based upon the physical baselines. For instance in
a paper entitled Tools for Attacking Layer 2 Network Infrastructure[40] the authors provide an
overview of the most popular Layer 2 networking attacks as well as descriptions of the tools used
to perform them. This work was very helpful in identifying possible attack vectors that could
be emulated within a virtualized environment. The paper entitled Securing layer 2 in local area
networks[2] also describes various attacks that can be performed on local and metropolitan area
networks, as well as the authors’ idea of adding a security tag to the Ethernet frame for additional
protection. Cisco also published a white paper[13] regarding VLAN security in their Catalyst
series of switches. The paper discloses testing that was performed on the switches in August of
2002 by an outside security research firm @stake which was acquired by Symantec in 2004. In the
white paper they discussed many of the same attacks that were mentioned in Tools for Attacking
Layer 2 Network Infrastructure, however the authors also went into detail about best practices
and mitigation techniques that could be implemented on the physical switches in order to prevent
the attacks from being successful. It is very pleasing to see a vendor openly publish a document
regarding security weaknesses of their products and use it to help educate end users on how to
secure the products against those particular threats.
6
Chapter 2
Detailed Research Plan
2.1
Motivation
My interest and experience over the past 10 years has been focused in the areas of virtualization
technologies, network security, and voice over IP. For my master’s thesis I constructed a highly
scalable virtualized environment to use for many of the network and computer security classes
offered at SUNYIT[6, 8]. This environment provides an isolated sandbox that can be used by
students to practice malicious attacks against vulnerable machines, as well as setup Asterisk servers
to use in the voice over IP classes that I offer. For my Ph.D. Dissertation research I wanted to
extend upon the work that I have already performed. Originally I was looking at the viability of
hosting commercial voice over IP services within virtualized environments in order to consolidate
resources in data centers. One of the major components of this research was to evaluate the security
of running VoIP services in multi-tenant environments. After some discussions with my advisor
we came to the conclusion that VoIP traffic is just like any other traffic traversing over a virtual
network, and we figured that a much larger contribution could be made if we evaluated the security
of virtualized network traffic as a whole rather than just a few specific protocols and services.
After performing a literature review it was found that there are very few publications related to
network security in virtualized environments. Most of the work that is currently available deals with
developing security appliances[4] and frameworks[9, 33], yet there is a large absence of available
work concerning Layer 2 network security threats and mitigation strategies for virtualized networks.
2.2
Research Environment
An experimental infrastructure has been constructed and isolated from any production networks
in order to simulate the attacks across seven different virtual network configurations without causing
disruption to other campus network services. The initial test platform consisted of three identical
Dell PowerEdge 860 server systems with dual core Intel Xeon 3050 processors at 2.13GHz, 4 GB of
7
memory, and a 500 GB hard drive. All three servers contain dual Broadcom NetXtreme BCM5721
Gigabit Ethernet PCI Express network interface cards integrated into the motherboard. The first
network interface was dedicated to the privileged control domain on each server for administrative
functions, and the second configured to be utilized by guest virtual machines. Each sever’s 500
GB hard disk was divided into four partitions; a 100MB ext3 /boot, a 10GB ext3 /, a 2GB swap,
with the remainder allocated to LVM storage for virtual machine deployment. An optimized base
installation of 64-bit Gentoo Linux with a customized 3.10.7-gentoo-r1 kernel was installed on one
of the servers along with the Xen 4.3 hypervisor. The server was completely setup to the point
where it was deployable as a fully functional Xen server utilizing a bridge network interface for
both para-virtualized and hardware virtualized guest machines. A backup script was created and
utilized to capture the system into a stage4 tarball, an archive for rapid deployment of the configured
operating system to the remaining test servers for further development and experimentation. The
backup script references an accompanied excludes file that is used as a blacklist of directories and
files that should not be included in the stage4 tarball due to various reasons.
Deployment of the stage4 tarball to the remaining Dell PowerEdge servers began with booting
each system to a LiveUSB installation of the SystemRescueCD Linux distribution and partitioning
their disks identical to the imaged server. A procedure was then performed on each server in order
to extract and deploy the operating system from the previously created stage4 tarball. After these
remaining systems were brought online their bridged interfaces were converted into Open vSwitch
interfaces for comparative analysis. One of the servers was configured with Open vSwitch 1.11.0
compiled from source due to issues with the Gentoo package manager’s version of the software
package. Open vSwitch 2.0.0 was released only a few weeks after the previous machine was setup
and was installed from portage on the remaining server. The initially staged server was left with a
simple Linux bridge interface for use with the virtual machines as the control part of the experiment.
To expand and add some variety to the experiment three production quality commercial virtualization solutions were tested to verify if they were vulnerable as well. Three more servers were
acquired and configured with Citrix XenServer 6.2, Microsoft Windows Server 2008 R2 with the
Hyper-V hypervisor, and VMware vSphere (ESXi) 5.5 respectively. The hardware utilized for the
Citrix XenServer 6.2 system was identical to the initial test systems, however the Microsoft HyperV and VMware vSphere hypervisors were both installed to more modern machines with quite a
bit more memory and processing power in order to accommodate for operating system overhead as
well as a lack of additional Dell PowerEdge 860 systems. The Hyper-V and vShpere systems were
also each outfitted with two network adapters in order to provide separate dedicated interfaces for
administrative purposes and virtual machine use.
8
Initially two virtual machines were deployed to each host system, one of which was setup as
a malicious client attempting to eavesdrop on the traffic of other tenant virtual machines (Figure
2.1). The Kali Linux security distribution[21] was selected due to the plethora of network security
auditing tools that come pre-installed and configured. Two complete installations of Kali were
installed to each server on 20GB LVM partitions as HVM guests. The systems were allocated
static IP address on the same isolated subnet as the servers and were completely updated. Each
attack simulation was performed identically on all platforms in order to analyze the differences
between the environments when subjected to the MAC flooding attack.
Figure 2.1: A malicious virtual machine located on a multi-tenant virtual network.
2.3
Preliminary Research - MAC Flooding Attacks
For the preliminary research only one Layer 2 networking attack was explored and thoroughly
tested across all platforms. The program macof from the dsniff package[40] was used on a Kali
virtual machine to perform a MAC flooding attack (Figure 2.2) on the virtual network within each
test environment. This type of attack when performed on a physical switch typically causes the
CAM table on the switch to fill up forcing the device to go into a fail safe or hub mode which
in turn causes all packets on the network to be broadcast to every node connected to the switch.
Wireshark was used to determine if the attack was successful by monitoring the network for HTTP
traffic which should not be intercept-able by other hosts on the virtual network.
9
Figure 2.2: A malicious virtual machine running macof to flood a virtual network with random MAC
addresses and malformed packets.
All tests were conducted in the same manner. Each server had two Kali Linux virtual machines
deployed on them. For testing purposes both virtual machines were brought online. On the first
virtual machine (Kali1) macof was started up using the command:
macof -i eth0
and left to run. Then Wireshark was started on the same virtual machine and an HTTP filter was
applied to only display sniffed HTTP traffic. The second Kali virtual machine (Kali2) was then
used to surf the web. If the attack proved to be successful then the HTTP traffic from Kali2 should
be viewable in Wireshark on Kali1.
2.3.1
Bridged Interface
Running the attack within the bridged virtual network test environment resulted in a significant
affect to the usability of the tenant virtual machines, essentially creating a DoS type of attack.
However, the MAC flooding attempt did not result in the ability to sniff other virtual machine
10
traffic passing over the interface. This most likely comes from the fact that the standard bridge
interface is missing the CAM table that typically is found on switches mapping known MAC
addresses to switch ports, an essential element of the attack. Since the random MAC addresses
have no actual presence on any segment connected to the virtual bridge they are dropped.
2.3.2
Open vSwitch 1.11.0 Interface
When running the attack on the Open vSwitch 1.11.0 virtual network test environment some
level of unresponsiveness was observed with the virtual machines, but the systems were still somewhat usable. Secondly, in this case the attacking machine could successfully sniff traffic from
another tenant machine. Figure 2.3 depicts the results of the successful attack and provides substance to the claim that virtual switches are vulnerable to some of the same Layer 2 attacks as
physical switches.
Figure 2.3: A malicious virtual machine running macof on an Open vSwitch virtual network and successfully
sniffing HTTP traffic with Wireshark from another tenant virtual machine.
2.3.3
Open vSwitch 2.0.0 Interface
Running the attack on the latest version of Open vSwitch available at the time of this research
shows that this vulnerability still exists and has not been addressed. The system responded in
the same way as the previous two attempts and the other tenant’s HTTP traffic was viewable in
Wireshark.
11
2.3.4
Citrix XenServer 6.2
The first commercial virtualization product that was tested was Citrix XenServer 6.2. Citrix
utilizes an older stabilized version of Open vSwitch to provide virtual switching services to its client
machines. When the MAC flooding test was attempted in the XenServer environment it was found
that a single instance of macof did not produce the same results that were experienced in prior
tests. HTTP traffic from the other client virtual machine was able to be sniffed but only in spurts.
It was necessary to run multiple simultaneous instances of macof in order to successfully sniff traffic
reliably from the target virtual machine. It was also found that the flooding was able to escape
the virtual environment which caused all upstream physical switches to go into hub mode as well.
Not only did this allow the malicious virtual machine running Wireshark to sniff traffic from other
tenant virtual machines, it also was able to eavesdrop on traffic from physical machines located
within the same broadcast domain that the the physical Ethernet adapter was connected to.
2.3.5
Microsoft Hyper-V Server 2008 R2
Microsoft Windows Server 2008 R2 along with the Hyper-V hypervisor were installed to a Dell
PowerEdge 2950 server system containing dual quad core Intel Xeon 5140 processors at 2.33GHz,
32GB of memory, and a 145GB SATA hard drive. Testing was performed both with and without
the Windows Firewall service enabled to identify if there was any affect on the results. Testing
under both conditions within the Server 2008 R2 environment proved to be unsuccessful due to
the fact that Microsoft Windows Server 2008 R2 provides some minimal protection for virtualized
network traffic, this includes protection against MAC address spoofing[24]. Further testing was
performed on the free version of Microsoft Hyper-V using an identical Dell PowerEdge 2950 server
system to see if the protection offered by Server 2008 R2 is also built into the bare metal product.
As with previous environment testing was performed both with and without the Windows Firewall
service enabled. It was concluded that under both conditions the free version of Microsoft Hyper-V
2008 was also unaffected by the MAC flooding attack since it is built upon a minimal version of
Microsoft Windows Server 2008 R2 entitled Server Core. The Core version of Microsoft Server 2008
R2 still provides the same level of network protection as the full version, but only allows for the
installation of specific server roles to the operating system[25], in this case the Hyper-V hypervisor.
12
2.3.6
VMware vSphere (ESXi) 5.5
VMware vSphere (ESXi) 5.5 was deployed to a custom built server using a Supermicro X9SCL
server motherboard, a quad core Intel Xeon E21240 processor at 3.30GHz, 24GB of memory,
and a 500GB SATA hard drive. All testing was performed identically to the previous trials for
completeness, however due to the VMware end user license agreement[38] I am prevented from
publishing any of the results.
2.3.7
Summary of Results
It can clearly be seen from the results summarized in Table 2.1 that any virtualized network
environment built upon the Open vSwitch virtual switch is vulnerable to MAC flooding attacks,
and has the potential to expose its client traffic to eavesdropping. Therefore, if a virtual machine
is transmitting sensitive information over a virtual network that uses any implementation of Open
vSwitch precautions should be taken such as using encryption in order to ensure that the information in transit remains confidential.
Hypervisor
OS Xen 4.3
OS Xen 4.3
OS Xen 4.3
Citrix XenServer 6.2
MS Server 2008 R2 w/ Hyper-V
MS Hyper-V 2008 - Free
VMware vSphere (ESXi) 5.5
Virtual Switch
Linux 802.1d Bridging
Open vSwitch 1.11.0
Open vSwitch 2.0.0
Open vSwitch
MS Hyper-V Switch
MS Hyper-V Switch
Default vSwitch
Vulnerable
No
Yes
Yes
Yes
No
No
No
Table 2.1: Summary of MAC flooding attack results across seven test environments
It was also observed that under certain configurations the MAC flooding attack would cause
severe latency crippling the virtual network and the usability of the virtual machines on the host
while the attack was under way. Table 2.2 provides a summary of the usability of the virtual
machines while the host virtual network was under attack.
13
Hypervisor
OS Xen 4.3
OS Xen 4.3
OS Xen 4.3
Citrix XenServer 6.2
MS Server 2008 R2 w/ Hyper-V
MS Hyper-V 2008 - Free
VMware vSphere (ESXi) 5.5
Virtual Switch
Linux 802.1d Bridging
Open vSwitch 1.11.0
Open vSwitch 2.0.0
Open vSwitch
MS Hyper-V Switch
MS Hyper-V Switch
Default vSwitch
VM Usability
DoS/Unusable
Significant delays
Significant delays
Significant delays
Some delays
Some delays
Some delays
Table 2.2: Summary of virtual network usability during a MAC flooding attack for seven different environments
2.4
Current Work - DHCP Attacks
Layer 2 Dynamic Host Configuration Protocol attacks typically consist of an attacker placing
a rogue DHCP server on a network that essentially competes with the legitimate DHCP server
when responding to client addressing requests broadcast to the network. Setting up a DHCP server
on a Linux virtual machine is a fairly simple task that only requires installing the dnsmasq or
dhcpd services and making a few minor configuration changes. The entire process can be completed in a short amount of time allowing an attacker to quickly place a rogue DHCP server within
a multi-tenant virtualized environment. Since DHCP requests and responses are broadcast across
the network (Figure 2.4) the attacks rely on the attacker’s DHCP server to respond to the address
request before the legitimate DHCP server in order to be successful.
Figure 2.4: Dynamic Host Configuration Protocol process.
14
2.4.1
Duplicate Addressing
The main idea behind the DHCP protocol is to automatically allocate addresses to client
computers and devices on a network while avoiding duplicate addressing. If two DHCP servers
are running on the same network and are providing addresses in the same range there is a high
likelihood that duplicate addressing will occur (Figure 2.5). When this condition arises it can cause
a denial of service situation that renders the resources bound to those devices inaccessible. This
could also be leveraged to direct traffic to a malicious server instead of an authentic one by giving
the malicious server the same IP address as the authentic one. This would rely on the malicious
server responding to the clients request first.
Figure 2.5: Duplicate addressing within a broadcast domain due to the presence of a rogue DHCP server.
2.4.2
Rogue DNS Server
When a client receives an IP address lease from a DHCP server it usually is also pushed DNS
server information for the network. If the client is seeded with the IP address for a poisoned DNS
server under an attacker’s control (Figure 2.6) the client could potentially be directed to spoofed
websites and services setup by the attacker to capture private information from the user such as
usernames, passwords, credit card numbers, and other personally identifiable information (PII)
that the attacker could use to further penetrate the organization.
15
Figure 2.6: Presence of a poisoned DNS server on a network whos address is provided to clients associated
with a rogue DHCP server.
2.4.3
Incorrect Default Gateway
If clients on a network obtain incorrect default gateway information from a rogue DHCP server
under an attacker’s control they will be unable to route traffic outside of the local network creating
a denial of service situation for resources on other subnets or the Internet. An attacker can also
push the IP address of a default gateway that leads the client into a malicious honeypot network
that can be setup to mirror another subnet on the network (Figure 2.7). This could then be used
to capture information from the user without their knowledge.
2.4.4
Remote Execution of Code
The DHCP protocol allows for the passing of many options, one of these options has recently
been used in order to execute remote code on a DHCP client machine running the Bash shell.
This exploit has been referred to as ShellShock[26, 27] and allows an attacker to leverage a DHCP
option in order to take advantage of a vulnerability in the bash shell to execute remote commands
on a vulnerable client system[1, 37] (Figure 2.8). This is a very high risk vulnerability and the full
extent of its effect are not yet known since Bash is utilized in many scripts and services that are
essential to most Linux/Unix systems including Mac OS X.
16
Figure 2.7: Malicious VM configured as a router on a network whose address is provided to clients as a
default gateway when associated with a rogue DHCP server.
Figure 2.8: Malicious DHCP server passing a configuration option to a client VM that leverages the BASH
shellshock vulnerability instructing the client to delete everything in / recursively.
17
2.4.5
Test Environment
The same test environment that was used for the MAC flooding attacks in the preliminary
research was also utilized for conducting the DHCP attacks. It was necessary to create four new
virtual machines within each hypervisor platform in order to setup scenarios to conduct the experiments. Each new machine was created based upon a minimal installation of CentOS 6.5[10], and
configured for a specific purpose (Table 2.3).
Operating System
CentOS 6.5 (minimal)
CentOS 6.5 (minimal)
CentOS 6.5 (minimal)
CentOS 6.5 (minimal)
Updates Applied
Fully Updated
Fully Updated
Fully Updated
No Updates
Services
DNSMasq (DHCP/DNS)
Simple Router
Apache (Web)
Left Vulnerable to ShellShock
VIFs
1
2
1
1
Table 2.3: New virtual machines added to each hypervisor platform for Layer 2 DHCP attack testing
The first virtual machine was configured as a DHCP server using DNSMasq[36] a lightweight
DHCP and DNS server. The second was setup as a simple router using iptables[3] to forward traffic
between two broadcast domains using NAT and two network interfaces. The third VM was setup
as a basic Apache[35] web server, and the fourth was configured as a minimal client that was left
unpatched and vulnerable to shellshock. The DNSMasq server was setup to pass option 100 to
clients which was configured to leverage the shellshock exploit in order to remotely execute the
echo command on the target machine and place text into a file in /tmp[20]. The following code
was placed into the /etc/dnsmasq.conf file on the DHCP server as a proof of concept to illustrate
the vulnerability without damaging the client system.
dhcp-option-force=100,() { :; }; /bin/echo ’Testing shellshock vulnerability’>/tmp/shellshock_test
The DNSMasq server was then used to attempt the other DHCP attacks previously described
against the minimal shellshock client which was setup to pull a DHCP address. Since DNSMasq
also provides DNS server functionality the rogue DHCP server doubled as the poisoned DNS server
that was passed to clients receiving addresses. The third CentOS 6.5 minimal virtual machine was
configured as a basic HTTP server running Apache to receive the redirected web traffic. The DNS
server was setup to direct all traffic destined to www.gmail.com to be redirected to the malicious
web server. A command line web browser called elinks[16] was then used in the shellshock VM to
visit www.gmail.com in order to observe the effect.
Lastly the DHCP server was configured to pass a bad default gateway address to clients that
obtained their network configuration from it. First it was set to pass 1.1.1.1 as the default gateway
18
with the intention of causing a DoS for access of subnets outside of the existing broadcast domain.
Then the DHCP server was configured to point clients to the second virtual machine that was
setup as a router to direct traffic to a malicious honeynet. This in conjunction with a poisoned
DNS server allows the attacker to direct traffic to malicious servers setup within the honeynet. In
each case the previously used web server was placed in the honeynet, and a DNS entry was setup
to direct traffic to it through the rogue default gateway.
2.4.6
Summary of Results
The following tables provide a summary of the results of running the individual DHCP attacks
across seven different testing environments.
Hypervisor
OS Xen 4.3
OS Xen 4.3
OS Xen 4.3
Citrix XenServer 6.2
MS Server 2008 R2 w/ Hyper-V
MS Hyper-V (free)
VMware vSphere
Virtual Switch
Linux 802.1d Bridging
Open vSwitch 1.11.0
Open vSwitch 2.0.0
Open vSwitch
MS Hyper-V Switch
MS Hyper-V Switch
Default vSwitch
Vulnerable
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Table 2.4: Summary of DHCP shellshock attack across seven test environments
Hypervisor
OS Xen 4.3
OS Xen 4.3
OS Xen 4.3
Citrix XenServer 6.2
MS Server 2008 R2 w/ Hyper-V
MS Hyper-V (free)
VMware vSphere
Virtual Switch
Linux 802.1d Bridging
Open vSwitch 1.11.0
Open vSwitch 2.0.0
Open vSwitch
MS Hyper-V Switch
MS Hyper-V Switch
Default vSwitch
Vulnerable
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Table 2.5: Summary of poisoned DNS server attack across seven test environments
19
Hypervisor
OS Xen 4.3
OS Xen 4.3
OS Xen 4.3
Citrix XenServer 6.2
MS Server 2008 R2 w/ Hyper-V
MS Hyper-V (free)
VMware vSphere
Virtual Switch
Linux 802.1d Bridging
Open vSwitch 1.11.0
Open vSwitch 2.0.0
Open vSwitch
MS Hyper-V Switch
MS Hyper-V Switch
Default vSwitch
Vulnerable
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Table 2.6: Summary of invalid default gateway attack across seven test environments
Hypervisor
OS Xen 4.3
OS Xen 4.3
OS Xen 4.3
Citrix XenServer 6.2
MS Server 2008 R2 w/ Hyper-V
MS Hyper-V (free)
VMware vSphere
Virtual Switch
Linux 802.1d Bridging
Open vSwitch 1.11.0
Open vSwitch 2.0.0
Open vSwitch
MS Hyper-V Switch
MS Hyper-V Switch
Default vSwitch
Vulnerable
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Table 2.7: Summary of rogue default gateway attack across seven test environments
2.4.7
Mitigation
Layer 2 DHCP attacks can be mitigated by enforcing static IP addressing, DNS entries, and
default gateways. Utilities such as DHCP snooping can also be used to monitor Layer 2 DHCP
traffic on the network and alert administrators when this type of activity is occurring. Software
Defined Networking could potentially be utilized in order to define filters that look for DHCP client
requests on the broadcast domain and specifically forward them to the correct server. However this
would require further investigation and experience with SDN in order for me to make the claim for
sure. The results of this research indicate that both virtual and physical networks that have not
be secured against DHCP attacks are vulnerable to all of the attacks that were discussed.
2.5
Future Work
It is my intention to further explore the other Layer 2 networking attacks previously described
in this proposal in order to perform a full assessment on the state of Layer 2 network security in
virtualized environments. I also intend to investigate ways of preventing such attacks by utilizing
known countermeasures as well as researching and developing solutions and best practices specific to
20
securing virtualized network environments. An example would be the case of MAC flooding attacks
as presented from the preliminary research which would normally be mitigated by enforcing port
security on a physical switch to limit the amount of MAC addresses that are allowed to access
a single interface. This prevents MAC flooding attacks from being successful since it essentially
blocks the excess MAC addresses from even being added to the CAM table effectively preventing
an overflow incident from occurring which is the heart of the vulnerability. The majority of virtual
switches available today do not offer this feature, therefore it is necessary to explore other alternative
preventative measures possibly within the realm of software defined networking (SDN)[28] since
most virtual switches are able to integrate with an OpenFlow controller.
2.6
Proposed Timeline
Timeline
Sept. 27th 2014
Dec. 2014
Feb. 2015
May 2015
Aug. 2015
Sept. 2015
Feb. 2016
Sept. 2016
Dec. 2016
Feb. 2017
Mar. 2017
Apr. 2017
Work
Topic Selection
Research Area Refined
Evaluation of Required Resources
Test Environment Implemented
Test Environment Expanded
Attack Vectors Identified
Preliminary Results (MAC Flooding) Acquired
Preliminary Results Presented at DerbyCon 4.0
DHCP Attack Results Acquired
MAC Flooding & DHCP Attack Results Paper Submission
(Targets: USENIX Security ‘15 & USENIX HotCloud ‘15)
VLAN Hopping Attack Results Acquired
ARP Spoofing Attack Results Acquired
Present New Results at DerbyCon 5.0
VLAN Hopping & ARP Spoofing Attack Results Paper Submission (Targets: USENIX Security ‘16 & USENIX HotCloud ‘16)
Mitigation Techniques & Best Practices Identified
Dissertation First Full Draft
Mitigation Techniques & Best Practices Paper Submission
(Targets: USENIX Security ‘17 & USENIX HotCloud ‘17)
Dissertation Final Copy Submissions
Dissertation Defense
Table 2.8: Plan for completion of research
21
Progress
Completed
Completed
Completed
Completed
Completed
Completed
Completed
Completed
In Progress
Goal
Goal
Goal
Goal
Goal
Goal
Goal
Goal
Goal
Goal
Chapter 3
Conclusion
It is important to note that the Layer 2 vulnerabilities described in this research proposal are
directed towards the virtual networking devices and not the hypervisor. With that stated these
attacks could be performed on any host running a virtual switch for any number of applications, not
just multi-tenant virtualization services. The results of both the preliminary and current research
performed are promising. They provide proof that virtual network environments can be vulnerable
to Layer 2 network attacks with a long history of reliably exploiting physical devices. Further
study is necessary in order to perform a full Layer 2 security assessment on the state of virtual
networking devices. In their current state virtual switches pose the same liability as their physical
counterparts in terms of network security. If not properly secured against Layer 2 network security
attacks they could pose a threat to all client virtual machines hosted on a multi-tenant cloud
platform. As proven in the preliminary research, one malicious virtual machine performing a MAC
flooding attack against the virtual switch it is connected to could be able to sniff all traffic passing
over that virtual switch, potentially compromising the confidentiality, integrity, and availability of
a substantial amount of clients.
22
Bibliography
[1] Accuvant Labs. Bourne again shell (bash) remote code execution vulnerability - bash
shell shock advisory. Retrieved Oct 5, 2014 from http://files.accuvant.com/web/file/
c18f38696677495085074e51178da52b/Bash%20ShellShock%20Advisory.pdf.
[2] Altunbasak, H., Krasser, S., Owen, H. L., Grimminger, J., Huth, H.-P., and
Sokol, J. Securing layer 2 in local area networks. In ICN’05 Proceedings of the 4th international conference on Networking - Volume Part II (2005), pp. 699–706.
[3] Ayuso, P. N., McHardy, P., Kadlecsik, J., Leblond, E., and Westphal, F. The
netfilter.org project. Retrieved Oct 21, 2014 from http://www.netfilter.org.
[4] Barjatiya, S., and Saripalli, P. Blueshield: A layer 2 appliance for enhancing isolation and security hardening among multi-tenant cloud workloads. In 2012 IEEE/ACM Fifth
International Conference on Utility and Cloud Computing (2012), pp. 195–198.
[5] Buhr, A., Lindskog, D., Zavarski, P., and Ruhl, R. Media access control address spoofing attacks against port security. In WOOT’11: Proceedings of the 5th USENIX conference
on Offensive technologies (2011), pp. 1–1.
[6] Bull, R. Design and implementation of computer science virtualized lab environment.
Retrieved Oct 19, 2014 from http://web.cs.sunyit.edu/~bullr/publications/bullr_
thesis.pdf.
[7] Bull, R. Exploring layer 2 network security in virtualized environments. Retrieved Oct 19,
2014 from http://youtu.be/tLrNh-34sKY.
[8] Bull, R. Migrating a voice communications laboratory to a virtualized environment. In SIGITE ’13 Proceedings of the 14th annual ACM SIGITE conference on Information Technology
education (2013), pp. 189–194.
[9] Cabuk, S., Dalton, C., Ramasamy, H., and Schunter, M. Towards automated provisioning of secure virtualized networks. In CCS ’07, Proceedings of the 14th ACM conference
on Computer and communications security (2007), pp. 235–245.
[10] CentOS. The centos project. Retrieved Oct 21, 2014 from http://www.centos.org.
[11] Cisco Systems, Inc.
Catalyst 6500 release 12.2sx software configuration guide.
Retrieved May 12, 2014 from http://www.cisco.com/c/en/us/td/docs/switches/lan/
catalyst6500/ios/12-2SX/configuration/guide/book/pref.html.
23
[12] Cisco Systems, Inc.
Cisco nexus 1000v series switches for vmware vsphere data
sheet. Retrieved November 29, 2013 from http://www.cisco.com/en/US/prod/collateral/
switches/ps9441/ps9902/data_sheet_c78-492971.html.
[13] Cisco Systems, Inc. Vlan security white paper [cisco catalyst 6500 series switches].
Retrieved October 18, 2014 from http://www.cisco.com/en/US/products/hw/switches/
ps708/products_white_paper09186a008013159f.shtml#wp39211.
[14] Clark, B., Deshane, T., Dow, E., Evanchik, S., Finlayson, M., Herne, J., and
Matthews, J. N. Xen and the art of repeated research. In USENIX 2004 Proceedings of the
Annual Technical Conference - FREENIX Track (2004), pp. 135–144.
[15] die.net. dhcp-options - linux man page. Retrieved Oct 5, 2014 from http://linux.die.
net/man/5/dhcp-options.
[16] ELinks. Elinks full-featured text www browser. Retrieved Oct 21, 2014 from http://www.
elinks.or.cz.
[17] Gentoo Bugzilla. Bug 491672 - =net-misc/openvswitch-2.0.0 - install: cannot stat ’brcompat.ko’: No such file or directory. Retrieved December 4, 2013 from https://bugs.gentoo.
org/show_bug.cgi?id=491672/.
[18] Gentoo Wiki. Qemu with open vswitch network. Retrieved December 4, 2013 from http:
//wiki.gentoo.org/wiki/QEMU_with_Open_vSwitch_network/.
[19] Hu, W., Hicks, A., Zhang, L., Dow, E., Soni, V., Jiang, H., Bull, R., and
Matthews, J. A quantitative study of virtual machine live migration. In CAC ’13, Proceedings of the 2013 ACM Cloud and Autonomic Computing Conference (2013), p. Article No.
11.
[20] Information Security Stack Exchange.
bash - shellshock dhcp exploitation.
Retrieved Oct 19, 2014 from http://security.stackexchange.com/questions/68877/
shellshock-dhcp-exploitation.
[21] Kali Linux. The most advanced penetration testing distribution, ever. Retrieved November
29, 2013 from http://www.kali.org/.
[22] LAN MAN Standards Committee. IEEE Standard for Local and Metropolitan Area Networks: Media Access Control (MAC) Bridges. The Institute of Electrical and Electronics
Engineers, Inc., New York, NY, 2004.
[23] Lauerman, K., and King, J. Stp mitm attack and l2 mitigation techniques on the cisco
catalyst 6500. Retrieved May 12, 2014 from http://www.cisco.com/c/en/us/products/
collateral/switches/catalyst-6500-series-switches/white_paper_c11_605972.pdf/.
[24] Microsoft. Hyper-v virtual switch overview. Retrieved May 18, 2014 from http://technet.
microsoft.com/en-us/library/hh831823.aspx.
[25] Microsoft. What is server core? Retrieved June 4, 2014 from http://http://msdn.
microsoft.com/en-us/library/dd184075.aspx.
24
[26] National Vulnerability Database. Cve-2014-6271. Retrieved Oct 5, 2014 from http:
//web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-6271.
[27] National Vulnerability Database. Cve-2014-7169. Retrieved Oct 5, 2014 from http:
//web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-7169.
[28] Open Networking Foundation. Software-defined networking: The new norm for networks. Retrieved May 13, 2014 from https://www.opennetworking.org/images/stories/
downloads/sdn-resources/white-papers/wp-sdn-newnorm.pdf.
[29] Open vSwitch. How to install open vswitch on linux, freebsd and netbsd. Retrieved December
4, 2013 from http://git.openvswitch.org/cgi-bin/gitweb.cgi?p=openvswitch;a=blob_
plain;f=INSTALL;hb=HEAD/.
[30] Open vSwitch. Production quality, multilayer open virtual switch. Retrieved November 29,
2013 from http://openvswitch.org.
[31] Pettit, J., Gross, J., Pfaff, B., Casado, M., and Crosby, S. Virtual switching in
an era of advanced edges. In ITC 22 2nd Workshop on Data Center - Converged and Virtual
Ethernet Switching (DC-CAVES) (2010).
[32] Pfaff, B., Pettit, J., Koponen, T., Amidon, K., Casado, M., and Shenker, S.
Extending networking into the virtualization layer. In HotNets-VIII (2009).
[33] Saripalli, P., and Walters, B. Quirc: A quantitative impact and risk assessment framework for cloud security. In 2010 IEEE 3rd International Conference on Cloud Computing
(2010), pp. 280–288.
[34] Seifert, R., and Edwards, J. The All-New Switch Book. Wiley Publishing, Inc., Indianapolis, Indiana, 2008.
[35] The Apache Software Foundation. The apache software foundation. Retrieved Oct 21,
2014 from http://www.apache.org.
[36] thekellys.org. Dnsmasq - network services for small networks. Retrieved Oct 19, 2014 from
http://www.thekelleys.org.uk/dnsmasq/doc.html.
[37] TrustedSec. Shellshock dhcp rce proof of concept. Retrieved Oct 5, 2014 from https:
//www.trustedsec.com/september-2014/shellshock-dhcp-rce-proof-concept/.
[38] VMware Inc. Vmware vsphere end user license agreement. Retrieved May 21, 2014 from
http://www.vmware.com/download/eula/esxi50_eula.html.
[39] Xen Networking. Setting up open vswitch networking. Retrieved December 4, 2013 from
http://wiki.xen.org/wiki/Xen_Networking#Setting_up_Open_vSwitch_networking/.
[40] Yeung, K.-H., Fung, D., and Wong, K.-Y. Tools for attacking layer 2 network infrastructure. In IMECS ’08 Proceedings of the International MultiConference of Engineers and
Computer Scientists (2008), pp. 1143–1148.
25