The NEDAC mechanism uses containment techniques at network and data link levels. Upon detecting a worm infection, the destination port used by the identified worm
traffic is used to apply a network level countermeasure by blocking worm traffic coming in to a network. Additionally, the data link level containment system is used to block
3.6 Summary
all outbound datagrams from a host that has been identified by the detection system
as infected. This is achieved by automatically applying an access control for infected host on a network switch. These countermeasure techniques provide NEDAC with the
potential to not only block an identified worm infection from an internal network host, but also worm traffic coming into the network from a remote host, which is a combined
countermeasure solution to protect internal and remote network hosts.
3.6
Summary
This chapter has presented the design of an improved worm detection and containment
scheme termed NEDAC. The NEDAC design uses a cross-layer solution that detects worm infection at the network layer and then contains the infection using data link and
network level containment solutions. The detection system of NEDAC applies different worm detection techniques for client and server host in a network and uses ARP request
datagrams to inactive internal IP addresses to identify worm infection from both client and server hosts. A comparative analysis of NEDAC and two previously reported de-
tection schemes has been presented to show the advances of NEDAC over the existing schemes. Having developed a countermeasure solution, the research work seeks to de-
velop a safe and convenient environment as a research tool for empirical assessment of the developed worm countermeasure solution. Chapter four presents the details of the
Chapter 4
THE V-NETWORK TESTBED
4.1
Introduction
Having proposed a countermeasure solution for fast scanning network worms, it is de-
sirable to develop an environment that can be used to test and evaluate the proposed solution, with a view to quantifying the achievable improvements. Therefore a safe and
convenient environment that is isolated from the Internet is needed.
This chapter presents the design and implementation of a virtualised testing environ-
ment that comprises suitable features for worm propagation and countermeasure sys- tems. These include management facilities that simplify the creation of virtual host
in large scale, re-usability and tearing down large number of virtual hosts and genera- tion/replay of background traffic. Section 4.2 presents the background to virtualisation
and virtualised testbeds. Sections 4.3 and 4.4 present the details of the testbed design and implementation respectively. Sections4.5 and Section 4.6 present the details of the
worm daemon and management scripts provided by the testbed to manage and facilitate worm propagation experiments. Finally, Section4.8 summarises the chapter.
4.2
Background
Virtualisation (Chiueh and Brook,2005;Sahoo et al.,2010) refers to the technology used
to create an abstraction layer between computer hardware and an operating system and applications running on top of it. This layer provides infrastructural support using low-
4.2 Background
level resources to create multiple virtual instances that are independent and isolated from
each other, such as a virtual computer, an operating system (OS), a storage device, or computer network resources. Virtualisation consolidates workloads in a way that
allows one physical machine to be multiplexed for many different users, which improves the efficiency of a data centre by allowing more work to be done on a smaller set of
physical nodes (Hwang et al., 2013). This provides flexibility, portability, re-usability and less resource requirements and is therefore suitable to be used in research work.
Virtualisation is most commonly implemented using a hypervisor, i.e., a software or firmware component used to create virtual system resources.
A hypervisor or Virtual Machine Monitor (VMM), which lies between hardware and an operating system, divides system resources, such as CPU, memory and storage into
several independent smaller components. Each component known as ’virtual machine’ is capable of running an operating system with the support of the CPU as if it is on
a physical machine. The main advantage is the isolation provided for each component to operate without affecting others. Hypervisors are divided between Type 1 and Type
2 (Sherman, 2014). A Type 1 hypervisor runs directly on system hardware with each virtual machine running on top of the hypervisor. The Type 2 hypervisor runs on a host
operating system, with each virtual machine running on top of the hypervisor. There are numerous hypervisors ranging from open-source hypervisors such as the KVM (Kivity
et al., 2007) and Xen (Barham et al., 2003), to commercial hypervisors such as the VMware vSphere (Lowe, 2011) and Microsoft Hyper-V (Velte and Velte, 2009).
The survey of related work presented in Chapter 2 has identified that virtualisation
systems have the potential to achieve high fidelity, scale, effectiveness and speed and are therefore suitable for malware experimentation. However, the previously reported
virtualised testbeds reviewed in Chapter 2 have limited experimental scale, platform dependency, and provide no support for background traffic and management interface
for re-usability of experiments.
Thus a virtualised network environment has been developed to facilitate controlled worm propagation and the testing of countermeasure systems. The testbed, termed Virtualised
4.3 V-Network Design
Network (V-Network), has been developed with scalability, re-usability, portability and
resource efficiency as desirable attributes. V-Network is aimed at studying the infection and propagation patterns of network worms and testing a range of countermeasure sys-
tems. V-Network is platform independent, which makes it convenient for UNIX-based or Windows-based experimentation, and is designed with the capability of resetting and
re-running experiments from a standard baseline in a controlled environment either using a graphical user interface or command line scripts.
4.3
V-Network Design
The V-Network testbed contains four virtualised enterprise networks that comprise a number of virtual network cells. The virtual network cells contain LANs with a DHCP
server for IP address management, a DNS server for name resolution, an NTP server to provide a time synchronization service for the virtual hosts, a logging server to keep a
record of worm infection activities and routers for internal routing services. The virtual enterprise networks are connected together to enable data communication and routing
services across the internetwork. The design was chosen to study how worm infection spreads across multiple networks that are physically and geographically separated and
to facilitate the deployment of countermeasure systems. Figure 4.1 details the logical design of an enterprise network in the V-Network testbed. The V-Network testbed uses
the Quagga routing suite (Ishiguro et al.,2007) to provide routing services. The VMware vSphere 5.5 (Lowe,2011) hypervisor has been used for virtualisation services, which also
comprises VMware vCenter Server for remote management of the ESXi servers. VMware vSphere was chosen for the development of the V-Network testbed due to its strong
performance in comparison to KVM, Xen and Microsoft Hyper-V in the utilization of CPU, memory disk I/O and network I/O as determined byHwang et al. (2013).
4.3 V-Network Design
DHCP DHCP
DHCP DHCP
NETWORK CELL A NETWORK CELL B
NETWORK CELL C NETWORK CELL D
Gateway Virtual host X.0.0.0/10 X.64.0.0/10 X.128.0.0/10 X.192.0.0/10 WAN Enterprise Network 1 10.0.0.0/8 Enterprise Network 2 11.0.0.0/8 Enterprise Network 3 13.0.0.0/8 Enterprise Network 4 12.0.0.0/8 DMZ DNS Server NTP Server Internet and external networks Firewall Log Server
4.4 V-Network Implementation
4.4
V-Network Implementation
The V-Network testbed has been implemented using the following resources:
• Four servers running VMware ESXi 5.5 server for virtualisation services, each with an Intel Core i7 (12 virtual cores at 3.40 GHz) processor, 64GB of RAM and 2TB
of hard disk storage capacity.
• Two servers running the Quagga routing suite to provide routing services, each
with an Intel Core i7 (8 virtual cores at 3.40GHz) processor, 24GB of RAM and 1TB of hard disk storage capacity.
• A server running the NTP daemon for time synchronization across all hosts, with an Intel Core i7 (8 virtual cores at 3.40GHz) processor, 24GB of RAM and 1TB
of hard disk storage capacity.
• A server running a custom-developed logging server daemon to keep record of host
activities, with an Intel Core i7 (8 virtual cores at 3.40GHz) processor, 16GB of RAM and 1TB of hard disk storage capacity.
• A server running VMware vCenter server for managing the ESXi servers remotely, with an Intel Core i7 (8 virtual cores at 3.40GHz) processor, 16GB of RAM and
1TB of hard disk storage capacity.
• Two Ethernet switches.
Figure 4.2 presents the physical design of the V-Network testbed. Each ESXi server
accommodates virtual machines in different “portgroups”. The portgroups are attached to virtual switches in order to form a number of virtualised LANs within the V-Network
testbed. The management network has been configured to enable administrative control over the V-Network ESXi servers. The vCenter Server is used to manage the entire
vSphere environment, i.e., all of the ESXi servers in the V-Network testbed and other hardware resources using the “management portgroup” of each ESXi server.
vCenter
Server Log Server
Router (Quagga)
vSphere Web Client Administrator
ESXi Host A ESXi Host B ESXi Host C ESXi Host D
Management Network
Traffic Network
NTP Server VMKernel Port Vmotion
Management network port
Virtual Switch 1 Server portgroup
Virtual machine portgroup
Server portgroup Virtual machine portgroup
Virtual Switch N
.
Virtual management switch
VMKernel Port Vmotion Management network port
Virtual Switch 1 Server portgroup
Virtual machine portgroup
Server portgroup Virtual machine portgroup
Virtual Switch N
.
Virtual management switch
VMKernel Port Vmotion Management network port
Virtual Switch 1 Server portgroup
Virtual machine portgroup
Server portgroup Virtual machine portgroup
Virtual Switch N
.
Virtual management switch VMKernel Port Vmotion
Management network port
Virtual Switch 1 Server portgroup
Virtual machine portgroup
Server portgroup Virtual machine portgroup
Virtual Switch N
.
Virtual management switch
4.4 V-Network Implementation
The vCenter Server also supports the use of PowerCLI (Dekens and Renouf, 2011),
which enables the management of the vSphere environment using scripts. Thus, using PowerCLI through vCenter Server, scripts can be used to clone a desired number of
virtual machines, take virtual machine snapshots, restore virtual machines and servers to a base state after an experiment, clean and re-create virtual machines, start and stop
virtual machines and remotely manage the entire V-Network environment. The vSphere Web client is used to remotely monitor, control and manage the infrastructure through
the vCenter Server using the GUI. The traffic network is used to provide other network services such as routing and time synchronization. The DMZ of the V-Network testbed
is connected to the Internet through a firewall for NTP update prior to experimentation. The Internet connection is then removed before the experiments begin.
Figure 4.3 details the physical and logical design of the V-Network implementation. The virtualised enterprise networks were configured using four class A IP address spaces
by default. The IP addressing can be reconfigured to any desired class and subnet depending on the requirements of the malware experimentation used. The virtualised
enterprise networks were also connected together using the border router that allows access to other physical or virtualised networks and the Internet. The testbed supports
vCenter
Server Log Server
Border Router (Quagga) VSphere Web
Client Administrator
ESXi Host A ESXi Host B ESXi Host C ESXi Host D
Management Network
Traffic Network
NTP Server
Firewall Virtualised
LAN 2 Virtualised LAN 3
Virtualised LAN 1
Virtualised
LAN 2 Virtualised LAN 3
Virtualised LAN 1
Virtualised
LAN 2 Virtualised LAN 3
Virtualised LAN 1
Virtualised
LAN 2 Virtualised LAN 3
Virtualised LAN 1
ENTERPRISE NETWORK A ENTERPRISE NETWORK B ENTERPRISE NETWORK C ENTERPRISE NETWORK D
10.0.0.0/8 11.0.0.0/8 12.0.0.0/8 13.0.0.0/8
Internet
4.5 Worm Daemon
4.5
Worm Daemon
The V-Network testbed uses a worm daemon developed by Shahzad and Woodhead
(2014a) with the capabilities of facilitating a worm attack event using chosen worm characteristics. The worm system consists of both client and server modules capable of
sending and receiving UDP datagrams. The client module is used to initiate a worm attack against desired targets. The virtual hosts are made vulnerable by running the
server module, which listens on a specific UDP port and then, after receiving an “infec- tion” datagram, continuously transmits “infectious” UDP datagrams. Upon infection,
a vulnerable host will send its time stamp and IP address information to the logging server for record management. The logging server has been configured with a logging
daemon that keeps the details of infected host addresses and infection time. This process will continue until full infection is achieved based on the details recorded on the logging
server.
4.6
Configuration Scripts
The V-Network testbed uses utility scripts to manage the virtualised environment and
facilitate worm experimentation. The utility scripts can be used for services such as virtual machine start-up and shut-down, cloning virtual machines, resetting the virtual
environment to a baseline after experimentation and tearing down virtual machines on the ESXi hosts. To conduct an experiment, a base virtual machine is configured with the
correct worm daemon and then cloned to the required number of virtual machines. The V-Network implementation comprises a number of customised utility scripts to facilitate
large scale management of virtual machines. The utility scripts are detailed as follows:
Create-VMs: The Create-VMs script is used to create a number of virtual machine clones from a base virtual machine that has been configured with the correct worm daemon and network settings for experimentation. The script then places