paper 2010 scenario management platform

8/3/2019 Paper 2010 Scenario Management Platform

1/23

Security Management Platform -Documentation

Network Security in Practice - Winter Term 09/10

Franz Goerke, Arvid Heise, David Jaeger, Conrad Popke, Stefan Reichel


2/23

1

Abstract. In order to learn about network security and threats, stu-dents need to have the possibility to explore realistic networks and ex-ploit them without harming others. Therefore, we present the prototype

of the Scenario Management Platform which configures a complete vir-tual network from an abstract scenario description for different operationsystems and virtualization solutions. Additionally, it keeps track of thestudents actions through a sophisticated monitoring technique and helpsto evaluate their performance. The teacher can manage the scenario de-scriptions and the results through a web interface which also informs thestudent of his current tasks.


3/23

Table of Contents

1 Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

3.1 Overall Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43.2 Scenario Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53.3 Virtual machine management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73.4 Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83.5 Web front-end . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

4 Prototypical Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124.1 Overall Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124.2 Scenario Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

4.3 Virtual machine management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124.4 Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144.5 Web front-end . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

Bibliography . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17A Manual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

A.1 Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18A.2 Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19


4/23

2

1 Introduction

In order to obtain profound knowledge about computer and network security, itis of utmost importance to practically explore, evaluate, and research existingflaws and exploits. Nevertheless, students rarely have their own infrastructure fortesting these exploits. However, directing the attacks against third-party hostsis impossible due to ethical, economical, and legal reason. Ideally, students havetheir own sandboxes with different challenges for experimenting and gainingknowledge without harming others. Supervisors might additionally evaluate theundertaken actions and give feedback or help if the students are stuck on aspecific challenge.

However, such security labs require great administration effort because of thegreat number of different technologies. First, the target hosts are usually virtualmachines which must be prepared to have the desired vulnerabilities. Prominentvirtual machineplatforms are VMware, Xen, or KVM, all having different advan-

tages and disadvantages. As a result, a mix of multiple pieces of virtual machinemanagement software are required. Second, the network must be set up, possiblysimulating additional components such as routers, switches, or firewalls. Thesecomponents must either be configured in the virtual machine management soft-ware or represented by another virtual machine. Third, monitors have to recordand potentially evaluate the actions of the students without interfering with theactual experiment setup. A straight-forward solution would be to employ Snortfor network and host-based intrusion detection. Finally, it might be desirable toinform the student about the goals and the evaluation of his performance in anautomatic way such as a web interface. It is obvious with only these exemplar-ily named technologies that the wide range of involved technology impose greatchallenges on the conductors of the experiments.

To ease the work of experiment conductors, we present the Scenario Man-

agement Platform which is an all-in-one solution for setting up, executing, andevaluating security experiments for students. The system is designed thoroughlyto support a wide range of virtual machine technologies, a sophisticated scenarioand goal description, network-transparent monitoring of students, and a web in-terface for role and experiment management. We implemented an extensibleprototype in Java and Grails on top of VMware.


5/23

3

2 Related Work

Jorg Keller and Ralf Naues implemented a virtual security lab on VMware wherestudents should secure a computer according to given tasks[KN06]. Interestingly,the virtual network is accessible over the Internet and secured through an ex-ternal firewall and multiple virtual sub-networks. However, the students perfor-mance is not tracked during the exercise but only evaluated through manuallytriggered scripts testing the final configured VM. Also, this lab solely focuses onLinux and does not consider automatic VM provisioning.

Similarly, Vassilis Prevelakis provides OpenBSD VMs running on VMwarefor his students[Pre07]. These VMs are executed at students work stations whichallows the students to process the tasks individually. Nevertheless, distributingthese VMs at the start causes a major network traffic as every VM is clonedfirst. As a work-around they use non-persistent virtual disks which in turn oftenleads to to the problem, that careless students lose their data. Finally, students

have to answer quizzes after each stage of the exercise to enable the teachers totrack their results.A more dynamic lab has been proposed by Hu et al.[HMS04] which maintains

a pool of generic VMs using user-mode Linux[Dik00]. Whenever a student logsinto the system through a VNC browser plug-in, Perl and PHP scripts initialize afresh VM according to the currently conducted experiment. As a side effect, thestudent can immediately get a new VM with the so-called connection transitionif he completely crashes his VM. The students progress is tracked by the VMsthemselves and exchanged with the master server through cookies in the usersbrowsers when the student exits the VM. While it has common goals with theScenario Management Platform, the solution is different as Hu et al. empowersthe individual VMs to configure themselves with scripts and to observe the users.In contrast, we try to keep the requirements on the VMs as low as possible and

have the evaluation logic on a separate server. Therefore, we can easily supportmultiple operation systems.

Finally, Harry Bulbrook developed a security lab on VMware which alsosupports Windows systems[Bul06]. However, the VMs have to be configuredmostly manually by the students to notice the effect of proper configuration orgiven attacks but they do not explore the virtual networks themselves. Hence,the progress of the students is not tracked. Nevertheless, the exercises can beperformed on any computer which empowers the student to work off-site.

Concluding, few of the discussed virtual labs configures the VMs or the virtualnetwork automatically. Most of them have been prepared either by teachers or byusers. Besides, the monitoring is very basic: quizzes have to be graded manuallyafter each experiment and no solution actually tracks the progress continuouslyat runtime.


6/23

4

3 Design

In this section, we describe the design of the Scenario Management Platform,

highlight important design decisions, and discuss relevant design alternatives.First, we give an overview over the general architecture and then we individuallydiscuss the different sub-components which result more or less directly from themain goals of the Scenario Management Platform:

Allow teachers to create, read, update, or delete scenario specifications (CRUDoperations).

Automatically load existing or provision new virtual machines when a sce-nario is executed based on its specification.

Manage the complete life-cycle of involved virtual machines. Monitor hosts in order to track students activities. Provide a comprehensible web user interface for both teachers and students.

3.1 Overall Architecture

Scenario Management Platform

AdminstrativeWeb

Interface

R

Teacher

Student

VirtualMachineManager

R

Scenario VMs

ProgressMonitor

R

R

Student WebInterface

Scenario Manager

R

Fig. 1: Scenario Management Platform allows teachers to provide security scenariosfor students and monitor their progress. Students may view the descriptions of theircurrently running scenarios and access the loaded virtual machines to actually performthe experiment.

Based on the goals, we inferred the following sub-components (see Figure 1):

Scenario Manager implements the CRUD operations of scenarios, interpretsscenario specifications, and translates specifications into dispatchable com-mands for the Virtual Machine Manager;


7/23

5

Virtual Machine Manager executes life-cycle operations on virtual machines,configures virtual networks, and provides high-level API functions to accessthe virtual machine;

Progress Monitor tracks activities of students, matches important actions tospecified goals, and generates attack graph which documents the performedattacks;

Role-based Web Interface manages users and their rights, offers access toCRUD operations on scenarios, triggers scenario execution, and displays stu-dents performance.

3.2 Scenario Management

The Scenario Management Platform allows the user to build own scenarios orto modify existing scenarios. A scenario covers multiple aspects in three classes,the scenario description, the virtual machine specification, and the monitoring

configuration.We can consider two aspects as part of the virtual machine specification. The

specification of the network topology and the specification of virtual machinesthat are used in the scenario. Due to the nature of vulnerabilities, the virtualmachine specification has to be fine-grained in order to allow unambiguously allkinds of configurations.

The Scenario Management Platform is used in an educational environment.This leads to the need of some meta information describing the scenario andhighlighting the educational focus of the scenario. Hence, the scenario descrip-tion defines what the student can learn by solving the scenario, what informationhe gets to solve the scenario, and so on.

The monitoring configuration specifies which information has to be gatheredduring the scenario, e.g., which machines have to be observed and what has to be

monitored. More specifically: events and thresholds can be defined that triggernotifications or log entries.

Data Model The Data Model (see figure 2) allows the modeling of all imag-inable scenarios while the process of modeling is easy to understand. Therefore,we focused on two aspects of the data model: completeness and simplicity.

A scenario consists of a number of components which covers the virtual ma-chine specification. Components are network devices like hosts, bridges, switches,or hubs. Each router or host can have one or more interfaces; each of them havea MAC address, an IP address, a subnet mask, and a connection attribute. Theconnection attribute allows the modeling of the network topology as it speci-fies that a host is connected to a hub/switch. The virtual machine specification

contains description of:

Hardware including RAM size, HDD space, number of CPUs and CPU speed;Operating System and its version;Programs and their version;


8/23

6

Fig. 2: The Data Model

Users with their password and rights;Files copied to the VM and optionally executed to support configuration scripts.

Next to the components, there exists the level part of a scenario specification.A level is applicable to the monitoring configuration. Thus, the scenario can be

divided into several stages and in each stage triggers can be specified. Thesetriggers are visible to a student or not. Besides the visibility, a trigger can be themain goal of a stage meaning that the trigger is sufficient to complete a stageor scenario. There are multiple types of triggers specifying:

Processes to observe;Files monitored for read/write access;Heartbeats sent by responding/active machines;Users observed if they log in or if their credentials/rights have been changed;Thresholds for special performance counters like CPU usage, RAM usage and

network traffic.

All defined triggers specify notifications and log entries which can be evalu-

ated. The scenario description is obtained by special description flags which canbe set for the scenario, the stages, the components and the level.

Alternatives We considered integrating a dedicated network section whichwould allow a graph-based modeling of the network topology into the model.


9/23

7

However, this would lead to redundancies and possibly to inconsistencies. In ouropinion, it makes sense to model the network topology in the virtual machinespecification part because the configuration of a host is closely linked to itsnetwork embedding.

Another controversial aspect is that there currently is the possibility to spec-ify the attacker machine. This allows us to give the student a suitable virtualmachine, which can perform all necessary attacks. Several reasons lead to thisdecision. First, often special software that is hard to configure is required. Sec-ond, a distinctive operating system and so on is sometimes needed to perform anattack. Finally, giving the students a prepared attacker VM allows students toget an overview of available attack tools and discover tools suitable for certainsituations. Nevertheless, it is still possible to plug in an own PC into the VMinfrastructure.

3.3 Virtual machine management

To obtain the functionality of the Scenario Management Platform, virtual ma-chines have to be cloned, started, stopped, configured, and managed. This func-tionality is provided by virtual machine management systems. Due to the com-plexity of virtual machine management, we decided to look for existing virtualmachine management systems that are stable and fulfill our requirements. In along-term research phase we found two interesting open source projects; Open-QRM and OpenNebula.

OpenQRM OpenQRM is an open source management suite for heterogeneousdata centers. Its base features are software distribution, image maintaining andmonitoring of images via nagios. OpenQRM can manage physical as well as vir-tual machines and supports VMware-Server, VMware-ESX, Xen, Linux-VServer,

Qemu, and KVM. It offers a Web interface and can be extended by variousplug-ins, e.g., there is a centralized storage management that supports Netapp,Equallogic, NFS, iSCSI, ZFS, and proprietary LVM based storage solutions.OpenQRM isolates hardware completely from server images making it possibleto change the hardware without changing the image.

OpenNebula Like OpenQRM, OpenNebula supports the on-demand deploy-ment of virtual machines and the rapid building of clouds. OpenNebula is alightweight solution for virtual machine management that supports cloning andtransferring of virtual machines. It can be controlled via command line interfaceor XML-RPC. OpenNebula also supports Xen, KVM, and VMware. It can buildup isolated networks containing multiple virtual machines allowing complex sim-

ulations of networks.

Comparison In contrast to OpenNebula, OpenQRM offers a lot of functionalitywith an easy-to-use Web interface. Its virtual machine management and moni-toring capabilities are massive in comparison to OpenNebula which offers just


10/23

8

rudimentary features. Both solutions are highly scalable and extensible. Referto Figure 3 for a comparison of different virtual machine management solutionswhich shows that OpenQRM delivers state of the art features.

Fig. 3: Comparison of available Virtual Machine Management Systems based onwww.clouduser.com

But OpenNebula offers the possibility to specify virtual networks which canbe very important for the Scenario Management Platform. Next to this interest-ing feature, OpenNebula is much more stable and supports Windows. This lastfeature was essential and could not be provided by OpenQRM which did notsupport Windows at all. Furthermore, the VMware and NFS driver had serious

bugs which prevented the usage of the advanced life-cycle features. Due to thesereasons, we decided to use OpenNebula, even if OpenQRM offers in theory muchmore functions for image creation, monitoring, and configuration.

3.4 Monitoring

The architecture of host-based monitoring has been subdivided into three majorcomponents, i.e., sensors, collectors, and evaluator.

Sensor Sensors are deployed on each virtual machine of a scenario and areresponsible for the monitoring of incidents occurring on its virtual machine.Sensors must be installed onto the virtual machine before it is actually used

within an experiment. In our prototype, we have prepared three kinds of sensorsmonitoring different aspects of a system.

File Sensor The file sensor monitors all kind of actions in relation to file access.For this, we have implemented a mini-port driver which installs a hook on


11/23

9

the file functions in the Windows kernel. In contrast to file integrity checkersavailable in host-based IDSs, which recognize file manipulations by check-summing all relevant files of the file system, we are able to additionally senseread access on files. Furthermore, the workload on the machine is lower aseventing is used instead of a polling approach for integrity checkers. Themonitored file actions are finally written to a local CSV file. Although thiskind of file monitoring is platform dependent, we are convinced that kernelhooking can also be applied for all kind of Unix-based systems.

Network Attack Sensor For the detection of malicious actions of a remoteattacker, we decided to use Snort as a NIDS. Snort monitors all traffic cominginto the host it is deployed on and checks for suspicious network packets onthe basis of a given rule set. If a suspicious action has been determined, analert is generated and written to a file on the local file system.

Process Listing The listing of running processes is not a real sensor but israther a built-in functionality provided by the operating system. It can either

be invoked regularly by a locally deployed tool on the virtual machine or canbe triggered from outside at certain points of interest.

Collector Collectors can be considered as the counterpart of sensors. Theycollect the information provided by sensors by regularly contacting the virtualmachines. Therefore, collectors are not deployed on each virtual machine but areresiding on the scenario management server.

The communication with the virtual machines is preferably established usingthe virtual machine engine. For VMware products, this can be accomplished withthe so called VIX API provided by VMware[VMW]. However, other virtualiza-tion products provide similar libraries to access its virtual machines directly. Thesignificant advantage achieved with the direct communication is the preventionof a verbose network communication. By exchanging messages over the network,an attacker could obtain hints of existing hosts in the scenario simplifying thephase of host discovery. Also, a student might disturb the message exchange tointerfere with the progress monitoring rendering the complete mechanism unre-liable.

When the communication with a virtual machine is possible, the sensorsdeployed on the virtual machines can be accessed and monitoring traces can beobtained. In the case of the file and network attack sensor, traces are availableas files in the local file system. The VIX API allows the direct access to thefile systems and enables the copying of files on the virtual machine to the hostusing the VIX API. As a consequence, the monitoring traces are copied from thevirtual machines to the scenario managing host. For the process listing, VIX alsoprovides a dedicated function to list all running processes in a VM, encompassing

the process id, its name, and the owner of the process.

Evaluator When monitoring traces have been obtained from the several virtualmachines, the traces are filtered, and transformed to a unified format. Thisformat contains following fields:


12/23

10

Type The type indicating the sensor, which has created this trace.Issue A name for the event captured by the sensor, e.g., read access to a certain

file or existence of process on the system.Perpetrator An instance which caused the creation of a trace, e.g., owner of a

process, process accessing a file, or IP address of a network attacker.Priority The importance of the captured trace. The smaller the number, the

more important the trace. 1 is the highest priority and there is no upperbound for priorities.

Capture Time A time stamp of the moment at which the trace has been cap-tured by the corresponding sensor.

Raw Trace This piece of information bears the trace as it was captured by thesensor. It can be used to obtain information on an event beyond the fieldsof the unified trace format.

When all the traces have been unified, they are persisted to the database. In

order to find the origin of a traces, they are associated with their virtual machineand experiment.For each sensor, there is a separate collector. Each collector is managed by a

monitoring manager which requests the collectors to refresh the trace informationin the database regularly. The collector then triggers its sensor in all virtualmachines for new monitoring data. The changes in the monitoring data aresubsequently persisted to the database.

Output is based on the unified traces provided by the collectors. Whenever auser requests the overview of traces, the trace instances are requested from thedatabase. The priority of the traces is then used to highlight important tracesin the output.

3.5 Web front-end

The web front-end offers specific operations for the different user groups

Admin manages users and assigns them roles;Teacher creates and maintains scenarios, instantiates new experiments for stu-

dents, and monitors their progress;Student sees his currently assigned experiments and their main objectives.

The roles have only a limited scope of tasks to enforce a clean design ofactions. However, every user can belong to multiple groups allowing a specificteacher to manage users and scenarios at the same time.

Grails As our implementation is only prototypical, we decided to use Grailsfor our web front-end for fast results and less maintenance. Grails is a Groovy-based, high productive web framework and builds upon proven technologies suchas Spring and Hibernate. While using Grails is technically not a design decision,it meets our requirements for the web framework in our design. It provides a


13/23

11

Security Model restricting the actions of users according to their roles;External Interface enabling external applications to access and modify data

through well established protocols such as SOAP or REST;Persistence of Domain Model storing and restoring of domain data.

Every web framework fulfilling these requirements can substitute Grails.However, Grails additionally supports prototypical and agile development throughfollowing principles:

Model View Controller pattern separates domain model, presentation logic,and domain logic;

Dynamic Persistent Methods transparently adds the basic life-cycle opera-tions (CRUD) to every domain object;

Coding by Convention reduces configuration overhead by implicit code con-ventions;

Scaffolding generates views for listing, adding, displaying, updating, and re-moving instances of domain models automatically;

Grails Object Relation Mapping transparently creates the hibernate map-ping of domain objects even for complex n:m relationships.

Incoporating Designer While Grails allows basic creation and modification ofscenarios, the final design ofScenario Management Platform includes a graphicalscenario editor. A suitable candidate would be theOryx [DOW08] which is aJavaScript-based editor with a strong focus on business modeling. However, itcan be extended with stencils to completely new domains. The integration inthe Scenario Management Platform could be implemented by using REST andXML as we already provide a REST interface and an XML importer.


14/23

12

4 Prototypical Implementation

After explaining the fundamental design of the Scenario Management Platformin section 3, we briefly outline our prototype in this section. Analogously, eachsub-component is covered in individual sub-sections.

4.1 Overall Architecture

All components have been implemented in Java or Groovy depending on howstrongly they are connected to the web interface. As we always wanted to retainthe option to change from Grails to Java-only web framework such as JavaServer Faces, all important parts are written in Java. Only the domain model,the UI controller, and the adapters to the Java parts are written in Groovy.

4.2 Scenario Management

For scenario specification, we developed a XML-Scheme after the data modelintroduced in the design part. For the import of such scenario files, a Groovy-based XML parser is integrated into the web interface and the parsed informationis stored in a MySQL-database. Due to the integration ofHibernate as the object-relational mapping (ORM) technology in the Grails framework, a flexible andsimple persistence management could be achieved.

Although the XML-specification is very versatile, we also provide a simpleweb form based editor in the Web interface. This editor allows an easy modifica-tion of existing scenarios. Although the creation of new scenarios is possible by

using the editor, it isnt very straight forward. At least for creation, the editorshould be replaced by a visual Oryx-based editor.

4.3 Virtual machine management

The virtual machine management is done by OpenNebula installed on an Ubuntusystem. As we decided to use the VMware Server in version 2.x as our pri-mary virtualization solution because it offers the WebService SDK required byOpenNebula in comparison to VMware Server 1.x. Currently, we have to createthe images directly with VMware. However, we expect near-future versions ofOpenNebula to fully support dynamic creation of images. Right now, it is notpossible to create images based on the specifications automatically. Neverthe-

less, modifying existing images, e.g., changing the number of CPU cores, andcreating virtual networks works well. Customization of existing images, such asuser management or program installations, can be achieved by scripts or overthe VIX API. Thus, base images of different operating systems could be easilyadapted to any configuration that is needed.


15/23

13

OpenNebula Templates OpenNebula uses templates for image configurationand deployment. There are two types of templates, the Virtual Machine templateand the Network template. The Virtual Machine template is used to configureVMware images and contains (a) name of the VM, (b) memory size, (c) num-ber of CPU cores, (d) Network Interface Component(NIC) configuration, and(e) virtual disk access.

For each NIC section in a template, a new network interface is added tothe virtual machine and the old VMware interface is being replaced by theseinterfaces, i.e., Mac and IPs addresses as well as Networks can be set. Due toa current bug in OpenNebula, the old network interface isnt replaced properly.Therefore the IP specification is not working at the moment and has to be doneeither manually, by script, or by DHCP. In near-future versions of OpenNebulathis deficit will be solved.

While the Virtual Machine template configures a single machine, the Networktemplate

is used to configureOpenNebula

-specific, isolated networks. Networkspecific settings influence all machines that are connected to the same network.An example for such a network configuration is shown in Figure 4. Furthermore,this template specifies whether a network consists of a fixed set of IPs and whichphysical network interface is connected/bridged to the virtual network.

Fig. 4: VM with 2 isolated NICs

As all mandatory information are specified in the scenario specification, thetemplates are generated by using this data model. The template generator isimplemented in Groovy but could be easily translated into Java if needed. Avirtual machine template could look like:


16/23

14

NAME = vm-example

CPU = 1

MEMORY = 512

DISK = [source = "/local/xen/domains/etch/disk.img",

target = "sda",

readonly = "no" ]

DISK = [

type = swap,

size = 1024,

target = "sdb",

readonly = "no" ]

NIC = [ mac="00:ff:72:17:20:27"]

These templates are used by OpenNebula during the deployment process.This process is managed by the OpenNebula Adapter.

OpenNebula Adapter While OpenNebula is managed via its XML-RPC API,we have encapsulated the provided functions into a separate layer. This layer al-lows us to hide some complexity of the API and provides easier access to Open-Nebulas functions. The OpenNebula adapter establishes the RPC-Connection toOpenNebula and provides an interface that allows an easy communication withthe OpenNebula process. Additionally, this abstraction layer makes it possibleto exchange the virtualization solution if needed.

4.4 Monitoring

For the prototypical implementation, we focused on Windows VMware VMs.Therefore, the file sensor is currently only available for Windows. Also, the pro-

cess listing and the collectors use the VIX API from VMware to directly accessthe files. However, we are convinced that both ideas are portable to another VMexecution environments as well as other OS.

File Sensor The file sensor is build upon FileMon 4.28 from Systems Internalswhich was the last open source version of FileMon. When started, it checksfor includedFiles.txt and excludedFiles.txt for file name patterns, e.g.,pass.file or c:\Windows\*. These patterns are checked against the file namesof recent I/O activities. If an inclusion and no exclusion pattern matches the filename, the I/O operation is logged in access.log.

Following information are stored tab-separated in a row: event time, accessingapplication, I/O event type, complete path, and return value of the operation.

This file is retrieved periodically every 30 seconds and parsed by a file sensorcollector.

VIX Wrapper We implemented an abstraction layer of the VIX API, toease the development of VM specific operations such as retrieving files from


17/23

15

the VMs. The implementation builds upon Hudson[Hud] and uses Java NativeAccess [JNA] to invoke the C functions of the VIX API. Additionally, the abstrac-tion layer can be extended to support other VM hypervisors without modifyingthe sensors.

4.5 Web front-end

As already stated, we used Grails to implement the web fronted. Using the SpringSecurity plug-in, we could easily implement different access rights for user roleswith annotations which can be placed in front of methods or class names e.g.:

@Secured([ROLE_TEACHER, ROLE_STUDENT])

class ExperimentController {

...

These annotations are automatically interpreted by the plug-in at runtime.Further access to the annotated actions is intercepted and prevented if the cur-rent user is not in one of the annotated roles. Additionally, when an anonymoususer tries to access a secured action, a log-in screen appears.

Currently, we create the following Users on start up in BootStrap.groovy:admin, teacher, and student. Each of them has their name as password and isonly part of their respective roles.


18/23

16

5 Conclusion

We presented the Scenario Management Platform, an integrated security labwhich supports the teacher in conducting security exercises for students. It au-tomatically configures VMs and virtual networks from scenario specificationsfor different operation systems and programs. Ideally, the teacher can createand manage these specification in a visual designer.

The Scenario Management Platform is highly extensible as it builds uponOpenNebula which abstracts from the actual employed virtualization technique.Furthermore, our monitoring system is modularly structured allowing the ad-dition of new sensors on the VMs and collectors on the evaluation server. Webroke fresh ground in the way we exchange messages between VMs and monitorserver: instead of unsafe network traffic, we directly communicate with the VMsthrough APIs of the hypervisors.

However, there is still some work to do. First of all, a visual designer of

scenarios is needed. Second, even though we support multiple users, we currentlydo not account for parallel use. Third, the system might be extended for remoteaccess if parallelization is implemented. And lastly, the objectives of exercisecould be specified more fine-granular to allow a hint systems which little bylittle reveals more short term goals.

Altogether, Scenario Management Platform is a secure learning environmentfor network security students and eases the life of the teachers.


19/23

17

References

[Bul06] Harry Bulbrook. Using virtual machines to provide a secure teaching labenvironment. Technical report, 2006.

[Dik00] Jeff Dike. A user-mode port of the linux kernel. In ALS00: Proceedingsof the 4th annual Linux Showcase & Conference, pages 77, Berkeley, CA,USA, 2000. USENIX Association.

[DOW08] Gero Decker, Hagen Overdick, and Mathias Weske. Oryx - an open modelingplatform for the bpm community, 2008.

[HMS04] Ji Hu, Christoph Meinel, and Michael Schmitt. Tele-lab it security: an ar-chitecture for interactive lessons for security education. In SIGCSE 04:Proceedings of the 35th SIGCSE technical symposium on Computer science

education, pages 412416, New York, NY, USA, 2004. ACM.[Hud] Hudson continuous integration. http://hudson-ci.org/.[JNA] Java native access. https://jna.dev.java.net/.[KN06] Jorg Keller and Ralf Naues. A collaborative virtual computer security lab. In

E-SCIENCE 06: Proceedings of the Second IEEE International Conference

on e-Science and Grid Computing, page 126, Washington, DC, USA, 2006.IEEE Computer Society.

[Pre07] Vassilis Prevelakis. Supporting a security laboratory. USENIX ;login: Mag-azine, 32(3):4046, June 2007.

[VMW] VMWare. Vmware vix api. http://www.vmware.com/support/developer/vix-api/.


20/23

18

A Manual

A.1 Deployment

Requirements To build a WAR for deployment Grails 1.2.0 or higher is re-quired.

Database configuration To configure the database which is used by the webapplication the production environment in the DataSource.groovy file needsto be modified. Currently it is configured for our test server with an MySQLdatabase which is used as an persistent database and never dropped.

Listing 1 shows the part of DataSource.groovy where the database is con-figured for deployment.

1 ...

2 production {3 dataSource {4 driverClassName = com.mysql.jdbc.Driver5 dbCreate = update6

7 username = root8 password = PASSWORD9 url = jdbc:mysql://localhost/grailsDB10 }11 }12 ...

Listing 1: Database configuration for deployment from DataSource.groovy

To change the database please refer to the Grails documentation:http://grails.org/doc/latest/guide/3.%20Configuration.html#3.3%20The%

20DataSource

WAR generation Open a command line and switch to the project folder ofthe SecurityLab. To create a WAR execute following command:

>> grails prod war FILE_NAME.war

Glassfish application server Currently we have an Glassfish server runningon the test server. The administration web interface can be accessed troughport 4848. Figure 5 shows the administration web interface with an opened web

application interface where the WAR can be deployed.In case that the Glassfish server is not running or has to be restarted, log in

as root and perform following command:

>> /opt/glassfish/glassfishv3/bin/asadmin start-domain


21/23

19

Fig. 5: Web application web interface for deployment and management

Known deployment issues The following error can be thrown on deployment:

An error has occurred

There is no installed container capable of handling

this application com.sun.enterprise.deploy.shared.FileArchive@1e46947

There a two solutions to fix this:

Manually removing all and everything from Bundle-ManifestVersion: 2 up toand including the blank line that precedes Name: Grails Application withinMANIFEST.MF

Commenting the section that follows // OSGi bundle headers within GrailsWar.groovyAfterwards the war will deploy.

A.2 Usage

Anybody how wants to use the security framework needs to have a user account.Each user account get one or more of three roles assigned. These roles are Admin,Teacher and Student. After log in the user can use the framework depending onhis assigned roles. The welcome screen shows the main overviews for his role.The following management possibilities are provided by the framework for eachrole.

Admin Users which are Admins will get access to the user management screen.See Figure 6 for a screenshot of the welcome page with an user overview. A newuser can be create using the above menu and details of users can be accessed.Figure 7 shows the details of a user. In the detail screen of the user editing anddeletion can be performed. A users roles can be changed in the edit screen too.


22/23

20

Fig. 6: Overview of all registered users

Fig. 7: Detailed overview of a user with assigned roles

Teacher For a Teacher three major concepts are important. There are scenarioswhich describe an experiment while the experiment is a running instance of thescenario. Stages describe for a scenario the goals which need to be reached by astudent.

There are two ways to create scenarios. First it is possible to load XML files

where the scenarios are specified and which were edited by another tool such asOryx. On the other hand all objects which are needed by a scenario and its subobjects can be created after the CRUD paradigm.

All of the mentioned objects can be created, edited and deleted when aTeacher is logged in. For each of them an overview is provided where the different


23/23

21

Fig. 8: Detailed view on a images with menu for sub ob jects

Fig. 9: Detailed overview of the experiments of a Student

available objects are displayed. Sometimes one object needs to have sub objectsspecified such as an image which needs to have an OS and hardware objectspecified. The menu shows depending on the current view the necessary menuoptions to create these sub objects. Such a menu for an image object is depictedin Figure 8.

Teachers have additionally access to the monitoring views. They get anoverview about the currently running experiments and can inspect the log en-tries, called traces, of the monitors.

Student Student users see just an overview of experiments which are assignedto them. Figure 9 shows the experiments of a user.

paper 2010 scenario management platform

Documents