Exploring Layer 2 Network Security Issues in Virtualized Environments Ronny L. Bull * Clarkson University Department of Computer Science 8 Clarkson Ave. Potsdam, NY 13699 [email protected]Dr. Jeanna N. Matthews † Clarkson University Department of Computer Science 8 Clarkson Ave. Potsdam, NY 13699 [email protected]ABSTRACT Cloud service providers offer their customers the ability to access virtual private servers hosted within multi-tenant en- vironments. Typically the virtual servers are all connected to the physical network via a virtualized network within the host environment. This could be as simple as a bridged in- terface connected to multiple virtual interfaces attached to each virtual machine, or it could entail the usage of a vir- tual switch to provide more robust networking features such as VLANs, QoS, and monitoring. Since all client virtual machines are essentially connected to a virtual version of a physical networking device this leads to the question of do Layer 2 network attacks that work on physical switches ap- ply to their virtualized counterparts? This paper sets out to explore the answer. Categories and Subject Descriptors C.2.0 [Computer-Communication Networks]: Security and protection General Terms Security, Experimentation Keywords Virtualization, Networking, Security, Layer 2, Attacks 1. INTRODUCTION With the growing popularity of Internet based cloud ser- vice 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 heteroge- neous virtual machines within their environments all hosted * Homepage: http://people.clarkson.edu/~bullrl/ † Homepage: http://people.clarkson.edu/~jnm/ Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. Request permissions from [email protected]. CS657 Class Project ’13, Fall 2013, Clarkson University Copyright is held by the owner/author(s). Publication rights licensed to Clarkson University. Copyright 2013. on shared resources such as CPU, memory, and networking hardware. Within each virtual host there needs to be some provision for the guest virtual machines to be able to access network resources, especially if the customer intends to run services on the virtual server that will be accessed from the Internet. Typically virtualized hosting environments utilize either a bridged network interface or a virtualized switch such as Open vSwitch[8, 9] for Xen and KVM based envi- ronments, or the Cisco Nexus 1000V Series virtual switch for VMWare vSphere environments[2]. Virtual switches are designed to emulate their physical counterparts, and with that the question arises whether they can be exploited in the same way that physical switches can through Layer 2 vulnerabilities. 2. LAYER 2 NETWORK ATTACKS There are many Layer 2 attacks that can be performed successfully on physical networks that realistically could be duplicated on virtual networks in order to audit their secu- rity. The paper ’Tools for Attacking Layer 2 Network Infras- tructure’[11] provides descriptions for many possible attack vectors that are targeted towards Layer 2 network services and devices. Table 1 provides a summary of the different Layer 2 attack categories described in the paper as well as a brief description of each. The authors of the paper also provided information about available utilities and methods that could be utilized in order to perform the attacks listed in table 1. Table 2 provides a summarized list of the tools as well as a brief description of each. 3. INFRASTRUCTURE SETUP An experimental infrastructure was constructed that was isolated from any production networks in order to simulate the attacks without disruption of any other campus network services. The test platform consisted of three identical Dell PowerEdge 860’s with a dual core Intel Xeon 3050 processor at 2.13GHz, 4 GB of memory, and a 500 GB hard drive. All three servers had dual Broadcom NetXtreme BCM5721 Gigabit Ethernet PCI Express network interface cards in- tegrated into the motherboard. The first network interface was dedicated to dom0 on each server, and the second was setup 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, and the rest allo- cated as LVM storage for virtual machine deployment. An optimized base installation of 64 bit Gentoo Linux with a
ABSTRACTCloud service providers offer their customers the ability toaccess virtual private servers hosted within multi-tenant en-vironments. Typically the virtual servers are all connectedto the physical network via a virtualized network within thehost environment. This could be as simple as a bridged in-terface connected to multiple virtual interfaces attached toeach virtual machine, or it could entail the usage of a vir-tual switch to provide more robust networking features suchas VLANs, QoS, and monitoring. Since all client virtualmachines are essentially connected to a virtual version of aphysical networking device this leads to the question of doLayer 2 network attacks that work on physical switches ap-ply to their virtualized counterparts? This paper sets out toexplore the answer.
Categories and Subject DescriptorsC.2.0 [Computer-Communication Networks]: Securityand protection
1. INTRODUCTIONWith the growing popularity of Internet based cloud ser-
vice providers such as Amazon EC2 and Microsoft Azuremore businesses are turning to these services to host theirmission critical data and applications. Cloud providers offertheir customers the ability to roll out a plethora of heteroge-neous virtual machines within their environments all hosted
Permission to make digital or hard copies of all or part of this work forpersonal or classroom use is granted without fee provided that copies arenot made or distributed for profit or commercial advantage and that copiesbear this notice and the full citation on the first page. To copy otherwise, torepublish, to post on servers or to redistribute to lists, requires prior specificpermission and/or a fee. Request permissions from [email protected].
CS657 Class Project ’13, Fall 2013, Clarkson UniversityCopyright is held by the owner/author(s). Publication rights licensed toClarkson University.Copyright 2013.
on shared resources such as CPU, memory, and networkinghardware. Within each virtual host there needs to be someprovision for the guest virtual machines to be able to accessnetwork resources, especially if the customer intends to runservices on the virtual server that will be accessed from theInternet. Typically virtualized hosting environments utilizeeither a bridged network interface or a virtualized switchsuch as Open vSwitch[8, 9] for Xen and KVM based envi-ronments, or the Cisco Nexus 1000V Series virtual switchfor VMWare vSphere environments[2]. Virtual switches aredesigned to emulate their physical counterparts, and withthat the question arises whether they can be exploited inthe same way that physical switches can through Layer 2vulnerabilities.
2. LAYER 2 NETWORK ATTACKSThere are many Layer 2 attacks that can be performed
successfully on physical networks that realistically could beduplicated on virtual networks in order to audit their secu-rity. The paper ’Tools for Attacking Layer 2 Network Infras-tructure’[11] provides descriptions for many possible attackvectors that are targeted towards Layer 2 network servicesand devices. Table 1 provides a summary of the differentLayer 2 attack categories described in the paper as well asa brief description of each.
The authors of the paper also provided information aboutavailable utilities and methods that could be utilized in orderto perform the attacks listed in table 1. Table 2 provides asummarized list of the tools as well as a brief description ofeach.
3. INFRASTRUCTURE SETUPAn experimental infrastructure was constructed that was
isolated from any production networks in order to simulatethe attacks without disruption of any other campus networkservices. The test platform consisted of three identical DellPowerEdge 860’s with a dual core Intel Xeon 3050 processorat 2.13GHz, 4 GB of memory, and a 500 GB hard drive.All three servers had dual Broadcom NetXtreme BCM5721Gigabit Ethernet PCI Express network interface cards in-tegrated into the motherboard. The first network interfacewas dedicated to dom0 on each server, and the second wassetup to be utilized by guest virtual machines. Each sever’s500 GB hard disk was divided into four partitions; a 100MBext3 /boot, a 10GB ext3 /, a 2GB /swap, and the rest allo-cated as LVM storage for virtual machine deployment. Anoptimized base installation of 64 bit Gentoo Linux with a
MAC Attacks A switch is flooded with randomMAC addresses causing the switch’smac address mapping table to be-come full. The switch is then forcedinto a ’fail safe’ or ’hub mode’ whereevery frame is forwarded to everyport on the device.
STP Attacks Incorrect BPDU frames are sentto switches in order to modify thespanning tree topology. This couldprovide the basis for a DoS attackon the environment.
CDP Attacks Incorrect CDP information is sentto switches and routers interferingwith their normal operations.
VLAN Attacks Frames can be modified to allowtraffic to “hop” VLANs in order togain unauthorized access to por-tions of a network. Incorrect VLANinformation can also be distributedto switches changing network con-figurations or affecting network op-erations in general.
DHCP Attacks Rogue DHCP servers can be placedon a network allowing attackers toperform man-in-the middle attacks,or creating a DoS attack due to du-plicate addressing.
ARP Attacks ARP spoofing can be performed toeither make a server unreachable orto perform man-in-the middle at-tacks intercepting traffic from un-suspecting users.
Table 1: Layer 2 network infrastructure attacks
customized Linux kernel was installed on one of the serversalong with the Xen 4.3 hypervisor. The server was com-pletely setup to the point where it was deployable as a fullyfunctional Xen server utilizing a bridge network interface forboth PV and HVM guest virtual machines. A stage4 tarballwas then created from the server to be used to deploy tothe other two test servers for further development and ex-perimentation. The script depicted in figure 1 was createdand utilized to backup the system into the aforementionedstage4 tarball.
The backup script references an accompanied excludes filethat is used as a blacklist of excluded directories and filesthat should not be included in the stage4 tarball due to var-ious reasons. The excludes file that was used in conjunctionwith the backup script is depicted in figure 2.
After the stage4 tarball was created it was then used todeploy the base installation on the other two Dell Poweredgeservers. Both systems were booted to a LiveUSB installationof the SystemRescueCD Linux distribution and their harddrives were partitioned identical to the imaged server. Theprocedure outlined in figure 3 was then performed on eachserver in order to extract and deploy the operating systemonto the servers.
After the other two systems were brought online theirbridged interfaces were then converted into Open vSwitchinterfaces for comparative analysis. On the first of the two
Utility Description Attack Cate-gory
Macof/Dsniff Macof is part ofthe Dsniff packageand is used to flooda switched LANwith random MACaddresses.
MAC Attacks
Linux Bridges Bridging support forLinux
STP Attacks
Stp.c Source code that canbe used to generateBPDU frames. Canbe used as a frame-work for launchingSTP attacks
STP Attacks
IRPAS Internetwork Rout-ing Protocol AttackSuite. A suite oftools developed forattacking routers.
CDP Attacks
Ettercap Multifunction snifferfor switched LANs.Can be used forpacket capturingand dropping, OSfingerprinting, andconnection killing.
STP Attacks,ARP Attacks,MAC Attacks
Libdnet Can be used tochange a network’sconfiguration by gen-erating ARP requestpackets
ARP Attacks
VLAN Attacks Tools such as VoIPhopper can be usedto gain unauthorizedaccess to VLANs ona physical network
VLAN At-tacks
Gobbler Gobbles up all avail-able DHCP IP ad-dresses on a networkand can perform manin the middle attacks
DHCP At-tacks
SToP Can modify any rel-evant field in theBPDU messages, andcan generate enoughpackets to flood anetwork
STP Attacks
Table 2: Utilities for performing Layer 2 networkattacks
servers Open vSwitch 1.11.0 was compiled from source anddeployed due to issues with the Gentoo package manager’sversion of the software package. There seemed to be a mis-match with the running kernel version and the ebuild for the1.11.0 Open vSwitch package. Open vSwitch 2.0.0 was re-leased only a couple of weeks after the second machine wassetup and was installed from portage on the third server.The initial server was left with a simple Linux bridge inter-face for use with the virtual machines as the control part of
#!/bin/bash# Stage4 backup script# By: Ronny L. Bull# Purpose: used to clone a Gentoo system for backup# or deployment to other systems
HOSTNAME=CLOUDSEC1SUBJECT=‘‘${HOSTNAME}: Stage4 System Backup’’;DATESTAMP=‘‘‘date ’+%Y%m%d’‘’’BACKUP=/home/ronny/backup/${HOSTNAME}/stage4MAX_BACKUPS=2
Figure 2: Excludes file that is used in conjunctionwith the stage4 backup script from figure 1.
the experiment. Each attack simulation was performed iden-tically on all three machines in order to analyze the differ-ences between the environments when subjected to variousLayer 2 network attacks.
3.1 Bridged Mode ConfigurationAs stated previously the initial installation was setup to
use a network adapter configured in bridge mode that actedas the interface for the virtual machines to attach to in orderto gain network access. Bridged mode is the simplest ofconfigurations for an interface dedicated to virtual machineuse. In order to configure a network interface as a bridgedinterface it was necessary to enable the following setting inthe Linux kernel:
Networking support --> Networking options -->802.1d Ethernet Bridging[*]
Once Ethernet bridging support was enabled in the kernel
# mount the partitionsmount /dev/sda3 /mnt/gentoomkdir /mnt/gentoo/bootmount /dev/sda1 /mnt/gentoo/boot
# extract the stage4 tarballcd /mnt/gentootar -xvjpf CLOUDSEC1.tar.bz2
# create nodesmknod -m 660 /mnt/gentoo/dev/console c 5 1mknod -m 660 /mnt/gentoo/dev/null c 1 3mknod -m 600 /mnt/gentoo/dev/initctl p
# verify all partitions are correctly mappedvim /mnt/gentoo/etc/fstab
# change the hostnamevim /mnt/gentoo/etc/conf.d/hostname
# edit host entries as necessaryvim /mnt/gentoo/etc/hosts
# change IP and possibly bridge setupvim /mnt/gentoo/etc/conf.d/net
# chroot into new environmentmount -t proc none /mnt/gentoo/procmount -o bind /dev /mnt/gentoo/dev
# syncronize portage and set the system profileeix-synceselect profile set 1
# install grub to the mbrgrep -v rootfs /proc/mounts > /etc/mtabgrub-install --no-floppy /dev/sda
# exit chroot and unmount partitionsexitumount /mnt/gentoo/proc /mnt/gentoo/devumount /mnt/gentoo/boot /mnt/gentoo
# reboot into the new system!
Figure 3: Stage4 extraction procedure.
and the system was rebooted the net-misc/bridge-utils pack-age was installed for full bridging support. In order to com-plete the configuration of the bridge the file /etc/conf.d/netwas edited with the bridge information. Figure 4 shows thenetwork configuration for both the dom0 dedicated interfaceas well as the bridged interface.
Figure 4: /etc/conf.d/net configuration for manage-ment and bridged interfaces
Finally it was necessary to create a startup script for thenew bridged interface in order for it to be automaticallystarted on system boot. This was accomplished by runningthe following commands:
cd /etc/init.dln -s net.lo net.xenbr0rc-update add net.xenbr0 default/etc/init.d/net.xenbr0 start
Once the bridge was configured and started virtual ma-chines could then be setup to use the bridged interface byspecifying the following line in their respective Xen config-uration file.
vif = [ ’bridge=xenbr0’ ]
3.2 Open vSwitch Installation From SourceThe initial attempt at installing Open vSwitch on the sec-
ond server to replace the bridged interface ended up beingquite the challenge. First when installing the latest avail-able version at the time (1.11.0) through Gentoo’s packagemanager (Portage) resulted in compilation failures due to akernel miss-match. The ebuild for Open vSwitch 1.11.0 wasdependent upon an older kernel version that was no longeravailable. Instead Open vSwitch had to be built from thesource code available at the Open vSwitch website[7], andthe current kernel running on the server had to be rebuiltwith a few new options required for Open vSwitch to runproperly. The required kernel options necessary for OpenvSwitch support are:
Networking Support--> The IPv6 protocol <*>--> Network Options--> Openvswitch(M)--> 802.1Q VLAN Support(*)--> GVRP (GARP VLAN Registration Protocol) support(*)--> QoS and/or fair queueing(*)--> QoS and/or fair queueing --> SET ALL TO (M)
Once the kernel was rebuilt with the proper support, andthe server was rebooted the openvswitch module was loadedwith the following command:
modprobe openvswitch
Next it was necessary to make sure that the openvswitchmodule persisted to load on reboots. In order to do this anentry had to be made into /etc/conf.d/modules to tell thesystem to load the module at startup.
modules_3=‘‘openvswitch tun’’
The source code for Open vSwitch 1.11.0 was then down-loaded and extracted to /usr/src/openvswitch. Figure 5shows the commands used in order to compile and installOpen vSwitch 1.11.0 from the source package[6].
cd /usr/src/openvswitchtar xaf openvswitch-1.11.0.tar.gzcd openvswitch-1.11.0
Figure 5: Commands used to build Open vSwitch1.11.0 from source
Once Open vSwitch was successfully installed it was neces-sary to configure it by initializing the database and startingup the services, this process is depicted in figure 6.
Figure 6: Open vSwitch configuration and servicestartup
Since Xen defaults to using a bridge interface for vir-tual machines upon creation it was necessary to modify the/etc/xen/xl.conf file in order to configure Xen to use thenew Open vSwitch interface instead. The following changewas made in the file in order to have Xen default to usingOpen vSwitch instead of the bridged interface[10].
vif.default.script=‘‘vif-openvswitch’’
Then a modification to /etc/conf.d/net was necessary inorder to disable the bridged interface and setup the physicalnetwork interface to be used by Open vSwitch instead.
Lastly the Open vSwitch bridge for the virtual machinesto use was created and the physical network interface boundto it[4].
ovs-vsctl add-br xenbr0ovs-vsctl add-port xenbr0 enp4s0ovs-vsctl set bridge xenbr0 stp_enable=true
The guest virtual machine Xen configuration files wereleft the same as it was not necessary to change the vif dec-laration since xenbr0 was the name of the switch that wascreated. The Xen hotplug scripts provided by the xen-toolspackage allow for automatic binding of virtual machines toOpen vSwitch virtual ports upon creation, so no further con-figuration of individual switch ports was necessary.
3.3 Open vSwitch Installation From PortageShortly after Open vSwitch 1.11.0 was successfully in-
stalled from source on the second server Open vSwitch 2.0.0was released and made available via the Gentoo packagemanager. An attempt was made to install it from Portageon the third server, however the build failed due to thebridge compatibility module not compiling. This modulehas not been available in the Linux kernel for quite sometime and turned out to be a bug in the Open vSwitch Gen-too ebuild[3]. A quick modification to the ebuild so that itdid not require the module to be loaded fixed the issue andOpen vSwitch was successfully ’emerged’ onto the system.The modification consisted of the following steps:
First the module had to be removed from the ebuild’srequired modules list. This was done by editing the file/usr/portage/net-misc/openvswitch/openvswitch-2.0.0.ebuildand changing the ’MODULE NAMES’ variable from:
In order to commit the changes the following commandhad to be run:
ebuild openvswitch-2.0.0.ebuild digest
Since the ebuild builds the openvswitch kernel module bydefault the kernel had to be recompiled with all of the sameoptions as highlighted in the previous section with the onlydifference that Open vSwitch support was disabled. Oncecompleted and the system was rebooted Open vSwitch 2.0.0could be successfully ’emerged’ onto the system. It wasthen necessary to configure and initialize the Open vSwitchdatabase as well as startup the services. The configurationfile /etc/conf.d/ovsdb-server required editing in order forthe database service to start. The only real change madeto the file was the addition of ’Open vSwitch’ appended toeach entry of ’db:’ as can be seen below.
# Socket for bringing the server upDB_SOCKET=‘‘/var/run/openvswitch/db.sock’’
# Remote sockets are defined in the database by defaultREMOTE_DB=‘‘db:Open_vSwitch,Open_vSwitch,manager_options’’
# All certificates and keys are stored# in the database (if any)PRIVATE_KEY=‘‘db:Open_vSwitch,SSL,private_key’’CERTIFICATE=‘‘db:Open_vSwitch,SSL,certificate’’BOOTSTRAP_CA_CERT=‘‘db:Open_vSwitch,SSL,ca_cert’’
# Alternative path for the database# (default is /etc/openvswitch/conf.db)# DATABASE=‘‘/etc/openvswitch/conf.db’’
# Additional options# OPTIONS=‘‘’’
The same modification to /etc/conf.d/net as describedin the previous section was made in order to disable thebridged interface and enable the physical interface to beused with Open vSwitch. /etc/xen/xl.conf was also mod-ified in order to set Open vSwitch as the default bridgeinterface for virtual machines to use upon creation, andthe entry for the openvswitch kernel module was added to/etc/conf.d/modules as well. Finally the following com-mands were run to initialize the database, startup the ser-vices, and add them to the default boot run level.
Once everything was configured and started successfullythe virtual switch interface could be created as previouslydescribed, and virtual machines could be configured to uti-lize it to access the network.
3.4 Virtual Machine Choice and Configura-tion
Due to the lack of memory on each of the servers onlytwo virtual machines were deployed to each server. The
Kali Linux security distribution[5] was selected due to theplethora of network security auditing tools that come pre-installed and configured, including many of those listed intable 2. Two complete installations of Kali were installedto each server on 20GB LVM partitions as HVM guests andupdated. The following Xen configuration file was used forall instances.
4. ATTACKS PERFORMEDDue to time constraints on the project as well as a fairly
complex infrastructure setup and configuration only one Layer2 networking attack was able to be thoroughly tested acrossall three platforms. The program macof from the dsniffpackage[11] was used on a Kali virtual machine to perform amac flooding attack (figure 7) on the virtual network withineach test environment. This type of attack when performedon a physical switch typically causes the CAM table on theswitch to fill up forcing the switch to go into a “fail safe” or“hub mode” which in turn causes all packets on the networkto be broadcasted to every node connected to the switch.Wireshark was used to determine if the attack was success-ful by monitoring the network for HTTP traffic which shouldnot be interceptable by other hosts on the virtual network.
Figure 7: A malicious virtual machine running ma-cof to flood a virtual network with random mac ad-dresses and malformed packets.
All tests were conducted in the same manner. Each serverhad two Kali Linux virtual machines deployed on them. Fortesting purposes both virtual machines were brought online.On the first virtual machine (Kali1) macof was started upusing the command:
macof -i eth0
and left to run. Then Wireshark was started on the samevirtual machine and an HTTP filter was applied to only dis-play sniffed HTTP traffic. The second Kali virtual machine(Kali2) was then used to surf the web. If the attack provedto be successful then the HTTP traffic from Kali2 shouldbe viewable in Wireshark on Kali1.
5. RESULTS
5.1 Bridged InterfaceRunning the attack within the bridged virtual network
test environment resulted in a significant affect to the usabil-ity of the tenant virtual machines, resulting in a DoS typeof an attack. However, as can be seen in figure 8 the macflooding attempt did not result in the ability to sniff othervirtual machine traffic passing over the interface. This mostlikely comes from the fact that the standard bridge interfaceis missing the CAM table that typically is found on switchesthat maps known MAC addresses to switch ports, which isan essential element of the attack.
Figure 8: A malicious virtual machine running ma-cof and Wireshark to flood a bridged virtual networkwith random mac addresses and malformed packetsin attempt to sniff traffic from another tenant vir-tual machine.
5.2 Open vSwitch 1.11.0 InterfaceWhen running the attack on the Open vSwitch 1.11.0 vir-
tual network test environment not only was the same level ofunresponsiveness observed, but the attacking machine couldsuccessfully sniff traffic from another tenant machine. Figure9 depicts the results of the successful attack and providessubstance to the claim that virtual switches are vulnerableto the some of the same Layer 2 attacks as physical switches.
5.3 Open vSwitch 2.0.0 InterfaceRunning the attack on the latest version of Open vSwitch
shows that this vulnerability still exists and has not beenaddressed. The system responded in the same way as theprevious two attempts and the other tenant’s HTTP trafficwas viewable in Wireshark. Figure 10 illustrates the suc-cessful attack.
Figure 9: A malicious virtual machine running ma-cof and Wireshark to flood an Open vSwitch 1.11.0virtual network with random mac addresses andmalformed packets successfully sniffing traffic fromanother tenant virtual machine.
Figure 10: A malicious virtual machine running ma-cof and Wireshark to flood an Open vSwitch 2.0.0virtual network with random mac addresses andmalformed packets successfully sniffing traffic fromanother tenant virtual machine.
6. RELATED WORKTo my knowledge there is no other published work related
to the subject of auditing the security of Layer 2 networkingwithin virtualized environments. However there is plenty ofpublished related work dealing with Layer 2 networking is-sues inherent in physical networks. This is beneficial in thefact that published research that was performed on phys-ical networks can be repeated within virtual environmentsand comparisons can be made based upon the physical base-lines. For instance in the paper ’Tools for Attacking Layer2 Network Infrastructure’[11] the authors give an overviewof the most popular Layer 2 networking attacks as well asdescriptions of the tools used to perform them. This paperwas very helpful in identifying possible attack vectors thatcould be emulated within a virtualized environment. Thepaper ’Securing layer 2 in local area networks’[1] also de-scribes various attacks that can be performed on local andmetropolitan area networks, as well as the authors’ idea ofadding an additional security tag to the Ethernet frame foradditional protection.
7. POSSIBLE PUBLICATION VENUESIf the work was heavily expanded upon and polished I
could see it having the possibility of being published in thefollowing venues.
• SIGITE/RIIT - This work would fit well in the re-search in IT track. They really are pushing for moresubmissions in this track in order to get it established.
• SOURCE Conference - Secure Cloud Computing Cat-
egory
• USENIX Security - Possibly if it was really polished!
• The ACM Cloud Computing Security Workshop - Aninternational ACM workshop dedicated to cloud secu-rity.
8. FUTURE WORK AND EXPANDABILITYThere are many ways to extend this work and continue
on with the research. In fact I feel that this may be a gooddirection to pursue for my Ph.D. dissertation. The projecttime frame only allowed for enough time to perform a sin-gle attack on a limited set of environment configurations.It would be interesting to extend this work to other moreproduction oriented environments such as Citrix XenServerand VMWare vSphere to see if the virtual switches that areemployed in commercial products are just as vulnerable tothese types of attacks as a standard Xen/Open vSwitch in-stallation is. It would also be a good idea to look into ways ofpreventing such attacks. Typically on a physical switch thiswould be accomplished by enforcing port security to limitthe amount of MAC addresses that are allowed to access asingle interface. This prevents mac flooding attacks frombeing successful since it essentially blocks the excess MACaddresses from even being added to the CAM table effec-tively preventing an overflow incident from occurring whichis the heart of the vulnerability.
It would also be very interesting to attempt the attack out-lined in this paper on a cloud service provider such as Ama-zon EC2 or Microsoft Azure to see if their environments arevulnerable. If the result is negative then it would be worththe effort to research and attempt to establish how they arepreventing the attacks from occurring. If the result provespositive then the work could be brought to the attention ofAmazon or Microsoft in order to collaborate on a resolutionto allow for more secure multi-tenant cloud environments.
Finally in an effort to fill out the paper in order to lend itmore credibility, as well as the possibility of a publication,it would be wise to research and attempt more Layer 2 net-work attacks within the same environments in order to see ifthey prove as successful as the mac flooding attack did. Thiswould help to build the claim that virtual switched environ-ments are no more secure than their physical counterparts.
9. ASSESSMENT OF PROJECTThis project proved to be quite challenging and time con-
suming to get the infrastructure setup and established, aswell as to quickly learn how to configure and use OpenvSwitch. However once everything was properly implementedrunning the attacks was fairly simple, and the environmentis now established for future research and expansion. It wasquite surprising to see the mac flooding attack actually workand allow for sniffing over the virtual switch. Initially I hadmy doubts that it would be successful due to the fact thatit is a software switch, and one would figure that well knowphysical switch attacks would have been taken into accountduring the design of Open vSwitch. Also one would as-sume efforts were made during development and testing toprevent exploitation using the same known vulnerabilities.Fortunately however this was not the case!
With more time this project could prove to be very pro-ductive. I felt that due to the late start and the infras-
tructure requirements for the project, as well as the lack ofassistance I was unable to really dive into all of the attacksI wanted to attempt. I would very much like to continue onwith this work as my Ph.D. dissertation work since searchingfor related publications and efforts on the Internet resultedin no similar work performed on virtualized environments,and obviously there seems to be some substance to this re-search.
10. CONCLUSIONIt is important to note that the Layer 2 vulnerabilities de-
scribed in this paper are directed towards the virtual switchand not the hypervisor. With that stated these attacks couldbe performed on any host running a virtual switch for anynumber of applications, not just multi-tenant virtualizationservices. The results of this project though fairly limitedare promising. It provides proof that virtual switches canbe vulnerable to Layer 2 network attacks that have a longhistory of reliably exploiting physical devices. Further studyis necessary in order to perform a full Layer 2 security as-sessment on the state of virtual switches. In their currentstate virtual switches pose the same liability as their physicalcounter parts in terms of network security. If not properlysecured they could pose a threat to all client virtual ma-chines hosted on a multi-tenant cloud platform. One ma-licious virtual machine performing a mac flooding attackagainst the virtual switch it is connected to could be able tosniff all traffic passing over the virtual switch, which couldpotentially compromise security for a substantial amount ofclients.
11. REFERENCES[1] Altunbasak, H., Krasser, S., Owen, H. L.,
Grimminger, J., Huth, H.-P., and Sokol, J.Securing layer 2 in local area networks. In ICN’05Proceedings of the 4th international conference onNetworking - Volume Part II (2005), pp. 699–706.
[2] Cisco. Cisco nexus 1000v series switches for vmwarevsphere data sheet. Retrieved November 29, 2013 fromhttp://www.cisco.com/en/US/prod/collateral/
switches/ps9441/ps9902/data_sheet_c78-492971.
html.
[3] Gentoo Bugzilla. Bug 491672 -=net-misc/openvswitch-2.0.0 - install: cannot stat’brcompat.ko’: No such file or directory. RetrievedDecember 4, 2013 from https:
//bugs.gentoo.org/show_bug.cgi?id=491672/.
[4] Gentoo Wiki. Qemu with open vswitch network.Retrieved December 4, 2013 fromhttp://wiki.gentoo.org/wiki/QEMU_with_Open_
vSwitch_network/.
[5] Kali Linux. The most advanced penetration testingdistribution, ever. Retrieved November 29, 2013 fromhttp://www.kali.org/.
[6] Open vSwitch. How to install open vswitch on linux,freebsd and netbsd. Retrieved December 4, 2013 fromhttp://git.openvswitch.org/cgi-bin/gitweb.cgi?
p=openvswitch;a=blob_plain;f=INSTALL;hb=HEAD/.
[7] Open vSwitch. Production quality, multilayer openvirtual switch. Retrieved November 29, 2013 fromhttp://openvswitch.org.
[8] Pettit, J., Gross, J., Pfaff, B., Casado, M., andCrosby, S. Virtual switching in an era of advancededges. In ITC 22 2nd Workshop on Data Center -Converged and Virtual Ethernet Switching(DC-CAVES) (2010).
[9] Pfaff, B., Pettit, J., Koponen, T., Amidon, K.,Casado, M., and Shenker, S. Extending networkinginto the virtualization layer. In HotNets-VIII (2009).
[10] Xen Networking. Setting up open vswitchnetworking. Retrieved December 4, 2013 fromhttp://wiki.xen.org/wiki/Xen_Networking#
Setting_up_Open_vSwitch_networking/.
[11] Yeung, K.-H., Fung, D., and Wong, K.-Y. Toolsfor attacking layer 2 network infrastructure. In IMECS’08 Proceedings of the International MultiConferenceof Engineers and Computer Scientists (2008),pp. 1143–1148.
