A Critical Analysis of Layer 2 Network Security in

Virtualized Environments

Ronny L. Bull

bullrl@clarkson.edu

A Doctoral Dissertation Research Proposal

Submitted to theDepartment of Computer Science

Clarkson Universityin Partial Fulfillment of the

Requirements for theDegree of

Doctor of Philosophy

Postdam, New YorkFall 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 DoctoralDissertation 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 inregards to my own work and the portrayal of others’ work. This Doctoral Dissertation Research

Proposal does not include proprietary or classified information.

Ronny L. Bullbullrl@clarkson.edu

Certificate of Approval:

A Critical Analysis of Layer 2 Network Security in

Virtualized Environments

Ronny L. Bull

bullrl@clarkson.edu

Permission is granted to Clarkson University to make copies of this Doctoral DissertationResearch Proposal at its discretion, upon the request of individuals or institutions and at their

expense. The author reserves all publication rights.

Ronny L. Bullbullrl@clarkson.edu

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 Background and Related Work 1

1.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.2 Network Configuration Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.2.1 Bridging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.2.2 Switching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

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

1.4 Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2 Detailed Research Plan 7

v

2.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.2 Research Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.3 Preliminary Research - MAC Flooding Attacks . . . . . . . . . . . . . . . . . . . . . 9

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

2.4 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 randomMAC addresses and malformed packets. . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.3 A malicious virtual machine running macof on an Open vSwitch virtual network andsuccessfully 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 rogueDHCP server. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.6 Presence of a poisoned DNS server on a network whos address is provided to clientsassociated with a rogue DHCP server. . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.7 Malicious VM configured as a router on a network whose address is provided toclients 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 leveragesthe 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 dif-ferent environments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.3 New virtual machines added to each hypervisor platform for Layer 2 DHCP attacktesting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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 vir-

tualized 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 work-

loads 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 coun-

terparts. 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 virtu-

alization 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 Hyper-

V 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 MACaddresses 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 some-

what 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 sub-

stance 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 successfullysniffing 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 informa-

tion in transit remains confidential.

Hypervisor Virtual Switch Vulnerable

OS Xen 4.3 Linux 802.1d Bridging No

OS Xen 4.3 Open vSwitch 1.11.0 Yes

OS Xen 4.3 Open vSwitch 2.0.0 Yes

Citrix XenServer 6.2 Open vSwitch Yes

MS Server 2008 R2 w/ Hyper-V MS Hyper-V Switch No

MS Hyper-V 2008 - Free MS Hyper-V Switch No

VMware vSphere (ESXi) 5.5 Default vSwitch 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 Virtual Switch VM Usability

OS Xen 4.3 Linux 802.1d Bridging DoS/Unusable

OS Xen 4.3 Open vSwitch 1.11.0 Significant delays

OS Xen 4.3 Open vSwitch 2.0.0 Significant delays

Citrix XenServer 6.2 Open vSwitch Significant delays

MS Server 2008 R2 w/ Hyper-V MS Hyper-V Switch Some delays

MS Hyper-V 2008 - Free MS Hyper-V Switch Some delays

VMware vSphere (ESXi) 5.5 Default vSwitch Some delays

Table 2.2: Summary of virtual network usability during a MAC flooding attack for seven different environ-ments

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 com-

pleted 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 associatedwith 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 adefault 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 BASHshellshock 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 exper-

iments. 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 Updates Applied Services VIFs

CentOS 6.5 (minimal) Fully Updated DNSMasq (DHCP/DNS) 1

CentOS 6.5 (minimal) Fully Updated Simple Router 2

CentOS 6.5 (minimal) Fully Updated Apache (Web) 1

CentOS 6.5 (minimal) No Updates Left Vulnerable to ShellShock 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 Virtual Switch Vulnerable

OS Xen 4.3 Linux 802.1d Bridging Yes

OS Xen 4.3 Open vSwitch 1.11.0 Yes

OS Xen 4.3 Open vSwitch 2.0.0 Yes

Citrix XenServer 6.2 Open vSwitch Yes

MS Server 2008 R2 w/ Hyper-V MS Hyper-V Switch Yes

MS Hyper-V (free) MS Hyper-V Switch Yes

VMware vSphere Default vSwitch Yes

Table 2.4: Summary of DHCP shellshock attack across seven test environments

Hypervisor Virtual Switch Vulnerable

OS Xen 4.3 Linux 802.1d Bridging Yes

OS Xen 4.3 Open vSwitch 1.11.0 Yes

OS Xen 4.3 Open vSwitch 2.0.0 Yes

Citrix XenServer 6.2 Open vSwitch Yes

MS Server 2008 R2 w/ Hyper-V MS Hyper-V Switch Yes

MS Hyper-V (free) MS Hyper-V Switch Yes

VMware vSphere Default vSwitch Yes

Table 2.5: Summary of poisoned DNS server attack across seven test environments

19

Hypervisor Virtual Switch Vulnerable

OS Xen 4.3 Linux 802.1d Bridging Yes

OS Xen 4.3 Open vSwitch 1.11.0 Yes

OS Xen 4.3 Open vSwitch 2.0.0 Yes

Citrix XenServer 6.2 Open vSwitch Yes

MS Server 2008 R2 w/ Hyper-V MS Hyper-V Switch Yes

MS Hyper-V (free) MS Hyper-V Switch Yes

VMware vSphere Default vSwitch Yes

Table 2.6: Summary of invalid default gateway attack across seven test environments

Hypervisor Virtual Switch Vulnerable

OS Xen 4.3 Linux 802.1d Bridging Yes

OS Xen 4.3 Open vSwitch 1.11.0 Yes

OS Xen 4.3 Open vSwitch 2.0.0 Yes

Citrix XenServer 6.2 Open vSwitch Yes

MS Server 2008 R2 w/ Hyper-V MS Hyper-V Switch Yes

MS Hyper-V (free) MS Hyper-V Switch Yes

VMware vSphere Default vSwitch 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 Work Progress

Topic Selection Completed

Research Area Refined Completed

Evaluation of Required Resources Completed

Test Environment Implemented Completed

Test Environment Expanded Completed

Attack Vectors Identified Completed

Preliminary Results (MAC Flooding) Acquired Completed

Sept. 27th 2014 Preliminary Results Presented at DerbyCon 4.0 Completed

Dec. 2014 DHCP Attack Results Acquired In Progress

Feb. 2015 MAC Flooding & DHCP Attack Results Paper Submission(Targets: USENIX Security ‘15 & USENIX HotCloud ‘15)

Goal

May 2015 VLAN Hopping Attack Results Acquired Goal

Aug. 2015 ARP Spoofing Attack Results Acquired Goal

Sept. 2015 Present New Results at DerbyCon 5.0 Goal

Feb. 2016 VLAN Hopping & ARP Spoofing Attack Results Paper Sub-mission (Targets: USENIX Security ‘16 & USENIX Hot-Cloud ‘16)

Goal

Sept. 2016 Mitigation Techniques & Best Practices Identified Goal

Dec. 2016 Dissertation First Full Draft Goal

Feb. 2017 Mitigation Techniques & Best Practices Paper Submission(Targets: USENIX Security ‘17 & USENIX HotCloud ‘17)

Goal

Mar. 2017 Dissertation Final Copy Submissions Goal

Apr. 2017 Dissertation Defense Goal

Table 2.8: Plan for completion of research

21

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 - bashshell 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., andSokol, J. Securing layer 2 in local area networks. In ICN’05 Proceedings of the 4th in-ternational conference on Networking - Volume Part II (2005), pp. 699–706.

[3] Ayuso, P. N., McHardy, P., Kadlecsik, J., Leblond, E., and Westphal, F. Thenetfilter.org project. Retrieved Oct 21, 2014 from http://www.netfilter.org.

[4] Barjatiya, S., and Saripalli, P. Blueshield: A layer 2 appliance for enhancing isola-tion and security hardening among multi-tenant cloud workloads. In 2012 IEEE/ACM FifthInternational Conference on Utility and Cloud Computing (2012), pp. 195–198.

[5] Buhr, A., Lindskog, D., Zavarski, P., and Ruhl, R. Media access control address spoof-ing attacks against port security. In WOOT’11: Proceedings of the 5th USENIX conferenceon 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 SIG-ITE ’13 Proceedings of the 14th annual ACM SIGITE conference on Information Technologyeducation (2013), pp. 189–194.

[9] Cabuk, S., Dalton, C., Ramasamy, H., and Schunter, M. Towards automated provi-sioning of secure virtualized networks. In CCS ’07, Proceedings of the 14th ACM conferenceon 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 datasheet. 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., andMatthews, J. N. Xen and the art of repeated research. In USENIX 2004 Proceedings of theAnnual 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 ’brcom-pat.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., andMatthews, J. A quantitative study of virtual machine live migration. In CAC ’13, Pro-ceedings 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 November29, 2013 from http://www.kali.org/.

[22] LAN MAN Standards Committee. IEEE Standard for Local and Metropolitan Area Net-works: Media Access Control (MAC) Bridges. The Institute of Electrical and ElectronicsEngineers, Inc., New York, NY, 2004.

[23] Lauerman, K., and King, J. Stp mitm attack and l2 mitigation techniques on the ciscocatalyst 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 net-works. 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 December4, 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 inan era of advanced edges. In ITC 22 2nd Workshop on Data Center - Converged and VirtualEthernet 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 frame-work 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., Indi-anapolis, 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 fromhttp://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 fromhttp://www.vmware.com/download/eula/esxi50_eula.html.

[39] Xen Networking. Setting up open vswitch networking. Retrieved December 4, 2013 fromhttp://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 infras-tructure. In IMECS ’08 Proceedings of the International MultiConference of Engineers andComputer Scientists (2008), pp. 1143–1148.

25