Use of VNUML in Virtual Honeynets Deployment - dit/UPM

Use of VNUML in Virtual Honeynets Deployment Ferm´ın Gal´an M´arquez1 and David Fern´andez Cambronero2 1

Centre Tecnol` ogic de Telecomunicacions de Catalunya (CTTC) Parc Mediterrani de la Tecnologia Av. Canal Ol´ımpic s/n, 08860 Castelldefels, Spain [email protected] 2 Departamento de Ingenier´ıa de Sistemas Telem´ aticos (DIT) Universidad Polit´ecnica de Madrid (UPM) Escuela T´ecnica Superior de Ingenieros de Telecomunicaci´ on Av. Complutense s/n, 28040 Madrid, Spain [email protected]

Resumen A honeynet is a security tool whose purpose is to study the techniques and motivations of attackers when breaking into secured systems. It implements an exposed computers network (composed of servers, clients, switches, etc.) in order to be scanned, attacked and compromised by crackers worldwide on the Internet. It records and monitors the behaviours of the intruders for later analysis and study. Several deployment alternatives are based on virtualization software, configuring a “virtual honeynet”, with significant advantages in infrastructure and management cost, compared with the implementation using real equipment. After a brief introduction to honeynet concepts, architectures and related tools, this paper focuses on the use of VNUML (Virtual User Mode Linux) for honeynet deployment. VNUML is a free-software general purpose tool for network scenarios emulation, highly flexible and configurable. The advantages of this approach are discussed, showing a practical example of virtual honeynet architecture and VNUML configuration.

1.

Introduction

Nowadays, Internet has become a potential insecure environment. It was designed in the 60s as an open network of networks with little or none security considerations in mind. The openness and freedom have allowed an impressive exponential growing in the number of system connected during the past two decades. However, currently companies and organizations with presence on the Internet have to face several risks (for example, deletion or corruption of data, theft of sensitive information or damage to the corporative image) coming from the crackers connected to the Net worldwide. Although during the past years security mechanisms have been developed in order to avoid or reduce these risks (like cryptographic techniques or firewalls), the techniques and motivations of attackers are continuously evolving. Formerly,

Use of VNUML in Virtual Honeynets Deployment

601

the attacker’s profile was a person with high technical knowledge about operating systems and computer networks, able to write his own tools for breaking into specific systems (like banks or governmental organizations). Nowadays, almost anyone can download from Internet easy-to-use tools that exploits particular vulnerabilities of operating systems or services (like web servers), regardless his technical skills. In addition, the target of the attacks is rarely intentionally selected. Attackers use to scan Internet looking for “easy targets”with the particular version or configuration of an operating system or service, so they can exploit particular weaknesses with the tools that they are using. The conclusion is that everyone connected to the Internet (from the residential customer to the great multinational company) is exposed to security risks. Therefore, tools for learning about attackers’ techniques and motivations play a key role in the security management of any Internet connected organization. One of such tools is the honeynet, an improved variation of a honeypot, a system designed with the purpose of being attacked, monitoring the activity of the intruder in order to analyse his tools, methods and behaviour. Both honeypot and honeynet concepts are described later in this paper (section 2.1). However, honeynets are complex systems and, because of their purpose is to be attacked, they usually are broken by the intruders. So, the management effort could be very high if honeynet is implemented with real equipment (even higher than the equivalent production network). Therefore, it is usual to employ virtualization techniques to implement a virtual honeynet, in order to largely reduce the infrastructure and management costs. This paper goes one step further, describing the use of VNUML (Virtual Network User Mode Linux) in order to design a high-level description of the virtual honeynet and build it without deal with virtualization complex details. VNUML tool was initially developed as part of the Euro6IX3 research project to emulate and experiment complex next generation IPv6 based Internet scenarios, in particular the ones related with the new model of Internet Exchange Points (IX) [1]. However, VNUML has evolved as a general purpose tool that can be used to emulate general GNU/Linux based network scenarios (for example, computer network laboratories [2] or multimedia network platforms [3]), in particular the honeynet application described in this paper. The paper is organized as follows. First, honeynets are introduced (section 2), describing their basic concepts, functionality, architecture, related tools and the basic principle of a virtual honeynet. Later on, the applications of a honeynet will be described (section 3), with the aim to justify why an organization should use part of its security management assigned budged to implements a honeynet. The VNUML is briefly described in section 4, showing its ability to build a virtual honeynet with a practical example. Finally, section 5 summarizes the conclusions and presents some future research lines related to the work presented in the paper. 3

See Euro6IX project web server at http://www.euro6ix.org

602

2. 2.1.

Ferm´ın Gal´ an M´ arquez et alter

Honeynet Description Basic Concepts

A honeypot can be defined as a security tool designed for being scanned, attacked and compromised by crackers through a network connection, in order to record and monitor their actions. The basic principle of a honeypot is that is not a production system. Therefore, any traffic from or to the honeypot and any action executed there are due to attackers activity. There are two basic techniques to implement a honeypot. The simplest one (usually called low interaction honeypot) is to run a program that simulates a particular operating system or service (like a web or email server) that monitors accesses to it. This implementations use to be easy to install and manage. However, the information that can be obtained with these systems is limited due to only the accesses to the services are logged but not the actions of the intruder in the actual attack. The other honeynet implementation (usually called high interaction honeypot) is based on setting up an entire operating system (with the logging facilities installed in order to monitor the intruder’s activity). Attacker’s behaviour should be the same as in an attacked production system due to that there are no simulated services. These high interaction honeypots are more complex to install and manage than the low interaction ones, but the actions of attackers can be logged. However, there is an additional risk in these systems: the operating system that implements the honeypot could have vulnerabilities. There is always the possibility that an attacker could break into it and launch new attacks against other systems. Both types of honeypot share the same disadvantage which is that the information they provide is limited on attacks directed against themselves. Therefore, the security analysis would be bound to the set of services or operating system that the honeypot implements. A honeynet is a particular kind of high interaction honeypot that implements an entire network, instead of just a system [4]. A honeynet can be composed of any number or any kind of systems, including workstations, servers, routers, switches, etc. in order to being attacked (honeypots). A honeynet can mirror the configuration of almost any production network. The attack analysis covers more services and operating systems than a single honeypot does. On the other side, the installation and management of a honeynet is more complex, in proportion to the number and the complexity of its systems. In the following section, we will describe the main functionalities of a honeynet. 2.2.

Honeynet Functionality

A honeynet should implement three main functions: intruders control, activity logging and data centralization.

Use of VNUML in Virtual Honeynets Deployment

603

Figura 1. Complexity versus information quality

The intruders control is needed as a security measure to avoid the use of any honeypot of the honeynet in which the intruder had gain control as source of attacks to external systems. Therefore, connections made by the attackers from a broken honeypot must be monitored and filtered in the case they could be dangerous. The activity logging is the ability of the honeynet to record the activity related with the intruder actions, for later study and analysis. We distinguish four information levels: access level (when and how a honeypot is accessed), network level (the network traffic generated by intruder actions), system level (commands executed by the attacker, modified files, etc.) and postmortem level (to analyse a honeypot once it has been compromised). The more information (and quality of this information) the honeynet can catch, the better the honeynet is. Due to the honeypots are themselves insecure systems, information can not be stored inside them: the attacker could delete (or even worst, modify) the information captured. So, it must be centralized in an external secure system, usually called log server. Other advantage of centralization is an easier management of the captured data. Although it is not mandatory, a honeynet should be stealthy. This means it should seems a production system, to avoid the intruder to realize he is actually in an environment setting up to record his activity (in which case, the attackers use to break the connection with the honeynet and no further information can be recorded). Next section will introduce the architectures that are used in order to achieve these functionalities.

604

2.3.

Ferm´ın Gal´ an M´ arquez et alter

Architecture

There are no standard architectures to build honeynets. Anyway, the Honeynet Project4 has proposed two architectures that are commonly accepted: First and Second Generation Honeynets.5 The First Generation Honeynet architecture is shown in Fig. 2. It is composed of two isolated network segments: honeypots network (where the honeypots are connected) and an administrative network (where the NIDS and log server are connected).

Figura 2. First Generation Honeynet The firewall protects the administrative network and performs the intruders control function, not allowing external connections from the honeypots to external systems beyond a given threshold (typically, in connections per day). Usually, it is necessary to allow certain degree of external connections, or the attacker could realize that he is not in a production system and, therefore, the stealthy broken. The function of the router is also related with the honeynet control and stealthy, so if the intruder analyzes the gateway from a honeypot he will discover the router but not the firewall behind. 4 5

http://www.honeynet.org The Honeynet Project has recently defined a Third Generation honeynet [5]. However, the main contribution is in the data model (out of the scope of this paper); from an architectural point of view, this new generation is quite close to Second one.

Use of VNUML in Virtual Honeynets Deployment

605

A NIDS (Network Intrusion Detection System) is a network security tool that passively captures (sniffs) and logs each packet in the network where it is connected. In the architecture, it implements the network level activity logging. The NIDS can not be compromised from the honeynet network if using a stealthy interface6 . The activity logging is performed by the firewall (at access level, logging connections attempts), the NIDS (at network level, recording all the traffic in the honeynet network that, because of the honeynet is not a production system only can be due to the attacker activity) and the honeypots (at system level, logging the actions using modified shell programs or even modified operating systems7 ). The data captured in the honeypots is stored in the log server, in order to achieve data centralization in a secure system. A mechanism needs to be provided so firewall, NIDS and honeypots can send information to the log server. The particular method depends of the tools used to implement these functionalities. Note that the logging service that runs in the honeypots accessing to the log server could involve a security risk, so the log server should strongly protected8 . Second Generation Honeynets are an evolution of First Generation ones, improving the intruder control and stealthy functions and easing the deployment and management of the honeynet. The main difference is that both intruder control and activity logging (except system level) are performed in a single system, called honeywall. The architecture is shown in Fig. 3. The honeywall implements a NIPS (Network Intrusion Prevention Systems). It is similar to a NIDS, but with active functions to detect attacks originated in the honeypots (based on traffic patterns), rejecting or modifying packets to block them. Anyway, the NIPS is based in configurable traffic patterns and, therefore, it does not prevent new unknown attacks. Thus, the external connections are also restricted (although the threshold is higher than in a First Generation honeynet). In this architecture, production systems can be connected to the honeypots transparently through switches, so not only external threats but also inner ones are considered. The inner interfaces of the honeywall are configured in bridge model (without IP/MAC addresses associated) so it is harder to be detected (in other words, the honeynet is more stealthy). In the following section we will briefly introduce some tools that are commonly used to implement honeynet functionalities.

6

7

8

A tampered network device that “listens”traffic in the network but can not send packets. Attackers should be very security-conscious, and use to access to compromised system with encrypted protocols (like SSH). Therefore, commands executed in the honeypot can not be deduced at network level from captured traffic. The NIDS can record log network traffic, maintaining a backup copy of the log server, just in case it would be compromised.

606

Ferm´ın Gal´ an M´ arquez et alter

Figura 3. Second Generation Honeynet

2.4.

Related Tools

As it has been seen previously in the architectures description, several tools are needed to implement the honeynet. In this section we analyse some of them. The firewall technology is quite mature nowadays. There are several efficient and reliable alternatives, like CheckPoint Firewall, ipfilter (BSD), ipchains (Linux 2.2) or iptables (Linux 2.4 or 2.6). As NIDS the Snort [6] free-software tool can be used. Snort is a very efficient sniffer, flexible and configurable with facilities for logging to a remote log server, suiting very well in the honeynet architectures. Snort-inline [7] is a variation of Snort that implements a NIPS. Not only it logs sniffed traffic but also modifies packets to make innocuous the dangerous flows. The analysis is based on the database of attacks patterns that uses Snort. It works together with iptables. For honeypot remote logging, syslog (or the more advanced syslog-ng [8]) can be used in UNIX systems. For honeypot running other operating systems (like MS Windows), auxiliary tools are needed (like Eventlog to Syslog, that sends a copy of the Windows event log to a syslog server). But logs could be very verbose, so a log processing tool (like Swatch [9]) is very convenient (for example, for generating alerts in real time that are sent to the honeynet administrator). The intruder’s activity can be logged at key stroke level using Sebek [10]. This is a tool that runs client software in the honeypot (usually integrated with the kernel as a module, so it is very difficult for the attacker discover and disable it) that logs actions of the intruder and sends them to a correspondent server. That communication does not use TCP/IP and it is hidden at kernel level.

Use of VNUML in Virtual Honeynets Deployment

607

Respecting post-mortem analysis, Tripwire [11] is a system that allows detecting modifications made by the attacker on key files of the honeypots. Other tool is The Sleuth Kit (TSK) [12], a set of command-line tools that allows low level filesystem analysis (it can also be used through Autopsy, a graphic front-end). 2.5.

Virtual Honeynets

As can be seen for the previous section, a honeynet is in general a complex system made of several different devices. A virtual honeynet is one that uses virtualization techniques for implementing their components, instead of using real equipment. Ideally, the entire honeynet will be implemented in a single computer. In general, virtualization techniques consist on running a process unit –a single program, an operating system or even an entire box– inside a program environment –usually called jail or sandbox– which is running in a physical machine named the hosting machine or simply the host. By means of these techniques, a powerful enough hosting machine can be used to start a set of virtual machines interconnected by one or more virtual networks, creating a virtual system (a honeynet, in our case) that closely emulates the behaviour of the same scenario implemented with real equipment. The main advantage of this approach is that the processes running in these virtual machines behave almost exactly as if they were running on a real environment. In this sense, the most execution transparency achieved, the better the virtualization technique is. Complete virtualization transparency is very difficult to reach, due to the fact that virtualization layers introduce some overhead. Anyway, given the maturity of the current virtualization techniques and being the present hardware used in standard personal computers (the ones typically used as hosting machines) powerful enough, this is not problematic, at least not for the honeynet application presented in this paper. We will go deeply into the advantages and drawbacks in section 4.3, applied to the VNUML virtual honeynet application presented in this paper.

3.

Application

Differing from other security related tools whose purpose is clearly understood (like a firewall), the reasons of an organization for implementing a honeynet need to be explained. A honeynet could be use for attacks prevention. This could be an application for organizations with high Internet presence and exposed to attacks quite often. First, the time that attackers spend trying to break into the honeynet is time that they are not treating production systems. Furthermore, using hot zoneing [13] suspicious traffic can be distinguished of the rightful one and directed to a honeynet, where it cannot cause any damage. In addition, the information obtained with the honeynet could be used to learn about the attacks and improve

608

Ferm´ın Gal´ an M´ arquez et alter

the security of the production systems. Moreover, if the use of honeynets by a particular organization is well-known, attackers would be reluctant to attack systems in that organization. The other application of a honeynet is related with attacks response. This could be interesting for security consulting companies or research laboratories. The information obtained is used to learn about tools, techniques, motivations, trends, psychology, etc. of the crackers community. In addition, the vulnerabilities discovered in operating systems and services leads to fix the bugs and, therefore, to improve the software quality. The use of a honeynet as an active response system (identifying attackers and getting information about them that allows legal pursuit) is matter of controversy, but, in general is wide accepted that the purpose of a honeynet is just learning about attackers.

4. 4.1.

VNUML-Based Honeynet The VNUML Tool

This paper analyses the use of VNUML9 in virtual honeynets implementation. Among the available virtualization alternatives, that range from process virtualization –like FreeBSD jails [14]– to virtual machine hardware emulation –like VMware [15]–, VNUML is based on User Mode Linux (UML [16]), an operating system virtualization environment that allows running completely functional Linux kernels as conventional user processes inside a standard Linux box. UML is based on a modification to the standard Linux kernel that allows it to run as a conventional user process on top the Linux kernel running in the hosting machine. Several UML processes can be executed simultaneously on a host, each one being a virtual machine with its own resources and its own running processes. The functionality included in these virtual kernels is basically the same than the one that can be found on a standard Linux kernel (for example, IPv6 or multicast support can be enabled on virtual machines), with the exception mentioned before about the performance penalty caused by the overhead introduced by the virtualization layers. Apart from providing the functionality to create virtual machines, UML provides the mechanisms to interconnect virtual machines using virtual networks implemented at operating system level. The virtual networking techniques used are very flexible: they allow the interconnection to be configured at level 2 (bridge) or 3 (host acting as a router), as well as the transparent interconnection of the emulated scenario to external equipment using the physical network interfaces of the host. Moreover, VLANs (Virtual Local Area Network [17]) are supported, allowing the creation of several simultaneous scenarios independently interconnected to external networks. 9

A complete description of VNUML and all its functionalities, as well as the tool itself, can be found at http://www.dit.upm.es/vnuml.

Use of VNUML in Virtual Honeynets Deployment

609

As an example, Fig. 4 shows the process space of a hosting machine executing two interconnected virtual machines (each one executing two processes) using UML.

Figura 4. Process space using UML

UML is a powerful but complex tool: it is generally difficult to manage medium-to-big size scenarios “by hand”. VNUML tool was designed to allow the easy creation of UML based network scenarios hiding the user all the underlying UML complex details. VNUML allows the users to enjoy the advantages of the virtualization without having to deal with the advances topics in GNU/Linux administration that raw-UML requires (like virtual bridges, tap devices or UNIX sockets). VNUML is a free software tool made of two components: a simple descriptive XML-based language that allows specifying in a text file the scenario to be emulated; and an application that interprets the language and builds and manages the scenario inside the hosting machine, hiding all the complex UML details to the user. VNUML users have to write the specification of the desired emulated scenario in a text file. The XML-based language used is very simple and descriptive. That allows the user to just concentrate on his problem, for example, in our case, on the design and implementation of the honeynet, detaching from low level implementation details. A sample of VNUML specification language is provided in the Appendix at the end of the paper. The VNUML application is a parser that reads the scenario specified in the text file and automates all the tasks needed to build and manage the emulated network environment, for example, copying files from the host to the virtual machines, starting and stopping process inside, running command scripts, etc. No in-depth knowledge about GNU/Linux or UML is needed to use it.

610

4.2.

Ferm´ın Gal´ an M´ arquez et alter

Example of Usage

In this section we analyse the honeynet implementation presented in Fig. 5, using VNUML. It is composed of four virtual honeypots (wk01, wk02, wk03 and wk04) that run in the hosting machine, acting as honeywall. VNUML uses a virtual network (Hnet) to interconnect these systems through the external interface transparently. The specification file for this scenario (shortened) is shown in the Appendix at the end of the paper. The firewall is implemented by iptables, with two different functions: intruders control at the forward chain (blocking the external connections attempts of the intruders beyond the threshold) and strongly secure the access to the honeywall itself at the input chain (just two ports should be enabled, SSH for remote administration –port TCP 22– and syslog –port UDP 514– for honeypot logging). In addition, the firewall logs perform the function of activity logging at connection level. In order to implement the activity logging function at network level, Snort can be used as NIDS, silently sniffing the traffic that pass thought the virtual bridge. To implement a pure Second Generation Honeynet, Snort-inline can be used as NIPS, working together iptables. The Fig. 5 shows both alternatives, although just one should be used, to avoid replying functionality.

Figura 5. VNUML honeynet implementation Honeypots log are sent to the honeywall using syslog. Keystrokes are silently recorded and sent to the hosting machine, thanks to a tty logging facility that

Use of VNUML in Virtual Honeynets Deployment

611

UML implements10 (therefore, additional tools, like Sebek, are not necessary). The intruder’s session is sent without using the network and the logging functionality is implemented at kernel level. Therefore, it is very difficult for the intruder to detect he is being spied. Post mortem analysis on compromised systems can be performed analysing the modifications on the host file that implements the honeypot virtual hard disk respecting the original one. Using UML COW (copy-on-write) mode, the changes are saved on a separated file and it is easier to analyze them. Although this example only shows four honeypots, any number can be added supposing enough hardware resources in the hosting machine. Each one of these virtual machines runs a UML Linux kernel. The filesystems can be based on any desired GNU/Linux distribution (Debian, Red Hat, Slackware, etc.). 4.3.

Additional Considerations

The main advantage of virtualization techniques when used to build honeynets is the significant reduction in equipment and management costs, compared to the equivalent real honeynet. First of all, only one device (the hosting machine) has to be used to implement the entire honeynet, saving the cost of all the real equipment and infrastructure (wire, hubs, spare room, etc.) needed to create it. But also, the administration of the whole honeynet is highly simplified, as all the configurations of its components are now centralized in files stored on the hosting machine. The honeypots hard disk (virtual) are stored in long files in the hosting machine, so it is very easy to take a backup of a honeypot (as simple as copying a file), to add new honeypots to the honeynet based on that filesystem or to restore a compromised honeypot. It could be argued that one of the disadvantages of a virtual honeynet is that attackers can detect that the compromised system is not a real environment and interrupt the interaction with it. In the case of UML environment, the most clues comes from the /proc hierarchy. Anyway, a system running in a virtual environment does not mean that the system is not a production system. More and more, organizations use virtualization in order to reduce infrastructure and management cost in a wide range of applications (network servers, hosting, etc.). Even so, certain features have been developed in UML to “camouflage”the virtual machine as a real system, in particular, the HoneyPot ProcFS (hppf, which allows customizing a “fake/proc) and Separate Kernel Address Space (SKAS, which implements a process address space that emulates a real kernel) [18]. Another disadvantage is that the hosting machine is supporting the entire implementation. Therefore, it a fail happen (for example, due to vulnerabilities in the virtualization software that allow access to the hosting machine with root privileges), the whole honeynet environment is compromised. However, current virtualization techniques in general (an UML in particular) are robust enough 10

See http://user-mode-linux.sourceforge.net/tty logging.htm for details.

612

Ferm´ın Gal´ an M´ arquez et alter

in order to assume the risk this could happen is low (at least, as low as in a conventional host, not running a honeynet environment). Regarding the reason to choose UML as virtualization backend for VNUML (among other alternatives like Xen, Microsoft VServer or VMware), UML allows to set up the capabilities of the virtual machines and virtual networks at booting time (for example, the memory and disk filesystem of each virtual machine, along with the number of network interfaces and how they are interconnected between them). No tool-focused GUIs are required. In addition, UML virtual machines run stand-alone (no management daemons are required) and can be accessed out-of-band and managed from command line. Given these characteristics, UML integration in VNUML parser is quite direct and easy and make it the preferable back-end among other virtualization alternatives. However, comparing with VMWare [15] in particular (this virtualization tool is often used for virtual honeynet implementation [13]), UML is a freesoftware tool, so the cost of purchasing a license (up to thousands of Euros) is avoided. On the other hand, WMware allows implement a wide range of virtual machines types (MS Windows, GNU/Linux, FreeBSD, . . . ) while UML only allows to implement GNU/Linux systems. Therefore, with UML only GNU/Linux vulnerabilities and exploits can be studied.

5.

Conclusions

The paper has shown how the use of virtualization tools and techniques can reduce significantly the cost and management effort invested in deploying and managing a honeynet, in special when free-software virtualization software (like UML) is used. The virtualization infrastructure saving can be carried to the extreme if distributing the entire honeynet in just a DVD-ROM with all the required software to be installed and configured in just a computer. With respect to the honeynet application, there are two kinds of potentially interested users. First, security researchers or consulting enterprises, whose purpose is to learn from attackers. On the other hand, organization with strong presence on the Internet, exposed to security risk quite often, with the purpose of preventing attacks. Due to a honeynet is, in general, a complex system, small organizations should give priority to basic security infrastructures (like a firewall), although the virtualization approach reduces the step of adopting the honeynet technology in an organization. Among others, current working lines on VNUML honeynets include enhance the tool with virtual machines using backends different from UML, like VMware (that allows emulate MS Windows or FreeBSD systems). Although UML has proved to be a flexible virtualization technology (as argued in section 4.3), extending to other backends would increases the range of operating systems and services vulnerabilities that could be studied with the honeynet. In addition, the VNUML tool itself has several minor features (like the inclusion of a management interface, that could imply an insecure backdoor to the

Use of VNUML in Virtual Honeynets Deployment

613

host machine) that needs to be tuned in order to made honeynets more secure and stealthy. As an additional working line, the VNUML honeynet application presented in this paper should be implemented in an hosting machine exposed to Internet threats, in order to complete the work of this paper with statistics and measures extracted from the data captured and analyzed by the honeynet. For example, type and frequency of the attacks, the most exploited vulnerabilities in the honeypots, etc.

Referencias 1. D. Fern´ andez, F. Gal´ an, T. de Miguel, “Study and Emulation of IPv6 Internet Exchange (IX) based Addressing Models”, IEEE Communications Magazine, vol. 42(1), pp. 105-112, January 2004. 2. F. Gal´ an, D. Fern´ andez, J. R´ uiz, O. Walid, T. de Miguel, “A Virtualization Tool in Computer Network Laboratories”, 5th International Conference on Information Technology Based Higher Education and Training (ITHET’04), Istanbul, June 2004. 3. F. Gal´ an, E. Garc´ıa, C. Ch´ avarri, M. G´ omez, D. Fern´ andez, “Design and Implementation of an IP Multimedia Subsystem Emulator Using Virtualization Techniques”, 13th HP OpenView University Association Workshop (HP-OVUA), Nice, May 2006. 4. The Honeynet Project, “Know Your Enemy”, Addison-Wesley, 2nd ed., 2004. 5. E. Balas, C. Viecco, “Towards a Third Generation Data Capture Architecture for Honeynets”, IEEE Workshop on Information Assurance and Security, West Point, NY, June 2005. 6. M. Roesch, “Snort: Lightweight Intrusion Detection for Networks”, Proceedings of LISA’99: 13th Systems Administration Conference, pp. 229-238, November 1999. 7. Snort-Inline, http://snort-inline.sf.net, last checked 24th April, 2006. 8. Syslog-ng, http://www.balabit.com/products/syslog ng, last checked 24th April 2006. 9. Swatch, http://swatch.sf.net, last checked 30th January 2006. 10. Sebek, http://www.honeynet.org/tools/sebek, last checked 24th April 2006. 11. Tripwire, http://www.tripwire.com, last checked 24th April 2006. 12. The Sleuth Kit & Autopsy, http://www.sleuthkit.org, last checked 24th April 2006. 13. E. Gallego, J. E. L´ opez, “Honeynets: Aprendiendo del atacante”, IX Congreso Nacional de Telecomunicaciones y Movilidad, February 2004 (in Spanish). 14. P. Hope, “Using Jails in FreeBSD for Fun and Profit”, Login: The Magazine of Usenix & Sage, n. 3, vol. 27, June 2002. 15. J. Nieh, O. C. Leonard, “Examining VMware”, Dr. Dobb’s Journal, August 2002. 16. J. Dike, “User Mode Linux”, Proceedings of 5th Annual Linux Showcase & Conference, Oakland CA, 2001. 17. “802.1q: Virtual LANs”, IEEE 802.1Q Working Group, IEEE, 2001. 18. C. Carella, J. Dike, N. Fox, M. Ryan, “UML Extensions for Honeypots in the ISTS Distributed Honeypot Project”, IEEE Workshop on Information Assurance, pp. 130-137, West Point, NY, June 2004.

614

Ferm´ın Gal´ an M´ arquez et alter

Appendix: VNUML Specification The following code shows a shortened (for briefness) VNUML specification file (let name honeynet.xml) for the example of section 4.2. A brief explanation follows. /var/vnuml/red-hat-8.0 192.168.0.100 default /var/vnuml/debian-3.0 192.168.0.101 default /var/vnuml/suse-9.0 192.168.0.102 default /var/vnuml/suse-8.2 192.168.0.103 default 192.168.0.150 default /home/hnet/honeynet_start.sh /home/hnet/honeynet_stop.sh

Use of VNUML in Virtual Honeynets Deployment

615

The Hnet virtual network is specified in the net tag. The network is external and the attribute (eth0) specifies with physical interface is connected to. Each virtual machine is described in a vm tag (network configuration is described for each interface with if tags). The filesystem tag specifies the file that will be used to implement the virtual hard disk. The if and route tags provides network configuration. Note that if one of the filesystem is compromised, it can be easily replaced (previous saving of the original for post-mortem analysys, for example: mv /var/vnuml/red-hat-8.0 /var/honeynet/morge), taking a new copy of the “master” (master filesystem are clean instances, never used directly), for example cp /var/honeynet/master/red-hat-8.0 /var/vnuml/. Note that the effort to do the same replace operation in a real-based honeynet would be much higher. The hosting machine configuration is described in the host tag. The start and stop tags specifies commands that needs to be executed when the honeynet is started or stopped, respectively. The detailed actions of the honeynet start.sh and honeynet stop.sh (to enable/disable iptables rules, start/stop the syslog server, start/stop Snort, etc.) scripts are not included, for the sake of briefness. In order to build the entire honeynet from the scratch (providing that redhat-8.0, debian-3.0 and suse-9.0 files exist and are in the right place) the administrator would execute the following two commands in the host: vnumlparser.pl -t honeynet.xml vnumlparser.pl -x [email protected] This can be compared with building the virtual honeynet “by hand¨ using plain UML, which would involve a lot of long, complex and error-prone command line invocations.