A practical and light-weight data capture tool for Xen virtual machine

Transcription

1 A practical and light-weight data capture tool for Xen virtual machine NGUYEN ANH QUYNH, YOSHIYASU TAKEFUJI Graduate School of Media and Governance, Keio university 5322 Endoh, Fujisawa, Japan JAPAN Abstract: Honeypot is a common solution to investigate attacker s activities, but the data capture tool, one of the key components of high-interaction honeypot architecture, faces a major difficulty: it is very hard to hide its presence. For example Sebek, the de-factor data capture tool, suffers from this problem: the intruder can easily uncover it even without privileged access right. This paper presents a design and implementation of a light-weight camera software in Xen virtual machine environment: the camera can be put into the virtual machine honeypot to gather necessary data about intruder s action. The camera tool is named XenKamera, which aims to collect TTY data from consoles of observed honeypot, then replays the collected data in on-line or off-line manner as the administrator wishes. Simply put, XenKamera allows us to watch the intruder as if we were looking over his shoulder while he is typing. In order to prevent the intruder from discovering XenKamera, a special architecture is proposed, so the data recording process becomes stealth, hard to detect and circumvent. To protect the gathered data, the TTY logging is secretly transferred to a separate virtual machine and safely kept there. Experiments demonstrate that XenKamera is effective and reliable. Besides to serve for honeypot purpose, XenKamera is designed to be so light-weight that it is practical and can also be used in the production systems to record the working sessions, and the administrator can rely on the logging data to investigate and trouble-shoot administration. Key Words: Xen virtual machine, Linux, honeypot, data capture tool, stealth communication, keylogger, TTY logging, computer administration. 1 Introduction Honeypot ([1], [2], [3], [4]) is a computer system with the purpose: to lure attacker in order to gather information about threats. These collected information is used to better understand threats, how they are evolving and changing, in order to counter those threats in the best way possible. If applying the honeypot technology properly, we can discover the novel attack patterns and unknown security holes. Honeypot also helps to study the attacker s motives. The high-interaction honeypot consists of 3 key components: Data control: this component is used to contain the intruder s activities and ensure that he does not cause any harm to other production systems outside the honeypot. Data capture: a honeypot must capture all the activities within the honeypot, including the information entered and left the system. Data collection: the gathered information got from the capture component must be securely and secretly forwarded to a central data server. This allows data captured from various honeypot sensors to be centrally collected for analysis and archiving. Sebek ([5]) is a de-factor, widely-used tool in current honeypot technology. Sebek architecture consists of 2 key components: a kernel module run on the honeypot system, and a central server to collect data. The first component, Sebek kernel module, serves as the data capture tool, and can capture intruder s activities in the honeypot. It also serves as a part of the data collection component: the collected data is then transferred by this module to a Sebek server (sebekd) running on a central machine, and then analyzing process is taken there with some utilities provided with Sebek package. One of the vital requirements of the data capture component is: it must be as covert as possible, so the intruder never knows that he is under watch eye. To satisfy that demand, Sebek kernel module applies many tricks borrowed from the black-hat community. Unfortunately these tricks are still not good enough to cover Sebek: researchers have pointed out many

2 methods to detect Sebek s presence, and some of them to uncover and defeat. Here are 8 outstanding problems of Sebek: are not even required privileged access. Another potential problem of Sebek is that the (1) Unprivileged local user can run a simple command that generates big input or output data, such data collection component run on the central server must expose to the network to capture data forwarded as the dd-attack method proposed in [9], then from honeypots, so this server must be protected at all checks to see if the network performance is decreased with ping command. The reason is that cost. Otherwise the attacker will bring it down, then he can do anything he likes to the honeypot he broken the data captured from all the input and output are in without worrying that he is being observed. secretly forwarded to the central sebekd server via This paper proposes a novel approaches to eliminate these problems of Sebek. A design and imple- network stack, and this activity may lead to congest network if the data is enormous. mentation of a light-weight data capture tool named XenKamera, which works in Xen virtual machine ([6], [7]) environment, will be presented. XenKamera focuses on capturing only TTY data of the honeypot, and is able to function much more stealthily and quietly than Sebek. All the recording data are not saved on the local honeypot, but secretly transferred to a central server and safely kept there. This leaves absolutely no chance to the intruder to find out or delete the previous logging data. Meanwhile, the collection logging daemon is not necessarily exposed on the network, and that improves the security of the whole honeypot architecture. To make the solution more practical, XenKamera is designed so the overhead is very negligible and overall it makes almost no impact to the system it runs on. Consequently, XenKamera can be also used for production systems to transparently record the working sessions, so the administrator can rely on it to investigate and carry out forensic process to recover broken system made by mistaken operations. The rest of this paper consists of 4 sections: The 2nd section outlines some problems with current capture tools (specifically focus on Sebek). The 3rd section proposes XenKamera architecture. The next section discusses some issues in XenKamera design and an experience we had while experimenting it. Section 5th summaries related works, and finally conclusion closes this paper in the 6th section. 2 Sebek s Problems As mentioned above, Sebek is the de-factor, widelyused data capture tool in honeypot technology ([8]). The reason is obviously: being inside the kernel, Sebek has the opportunity to capture all the necessary data including keystrokes, input and output data from file system or network socket, while it can control the whole system as it wants. Sebek even patches the kernel to hide its presence from system users, so the intruder would have hard time to discover its existence. Unfortunately while many efforts are put on Sebek to make it more stealthy, Sebek is still rather easy (2) Though Sebek tries to patch the network stack to hide the actual network statistics when using network layer to send data, we can still compare the internal statistics got from inside the kernel with what the system shows to user-space ([9]). The difference will disclose the presence of Sebek. (3) Sebek inserts a kernel module into the system, and this module could be listed in the kernel module list (with lsmod command on Linux). Though we can try to hide it with another kernel module (like the clean method proposed by adore-ng [10]), Sebek module can still be found with a brute-force scanning technique [11]. (4) Sebek replaces some system-calls with its own functions. Paper [12] exploits this fact to propose another way to discover Sebek: we just need to check if the address of these system calls are at abnormal places in the memory. If that is the case, chances are Sebek is present in the kernel. (5) Sebek replaces some system-calls with the code that packs the data into UDP packets and send them out to the sebekd machine. This change significantly increases the time to complete the system-calls, and the difference (more than 3 times in the case of read() system-call [12]) can be easily recognized from user-space by unprivileged user. (6) After detecting Sebek, the intruder can remove it by recovering the original system call (for example with unsebek.c tool in [13]). The fact that Sebek is a kernel module makes it easier to do that. (7) Sebek sends the captured data to the central server via network. If the intruder has a sniffer (such as tcpdump [14]) installed at the right place in the network, he will see these data and easily figure out that the system he has penetrated is a honeypot. (8) The central server must expose to the network to receive data sent from the honeypot. That will

3 tempt the intruder to attack this server to bring Xen community is working hard to gradually down this fundamental component of our honeypot. This is not a theory, but the actual threat: every Linux users. The process is expected to start push Xen into Linux kernel, so it will be available for Paper [15] proposes such a method, in which sebekd will be taken over if it uses a libpcap library from kernel with Xen version 3.0. with buffer overflow bug. Xen Architecture As we see, there are too many problems with the current Sebek, and they all make honeypot less attractive solution for security practices. 3 XenKamera Solution Traditionally, honeypots have been physical systems on a dedicated network, with multiple physical machines to monitor and collect logging data from the honeypots. The requirement resources posed by honeypot prevent it become a common network security solution. The advent of virtual machines such as Xen has made setting up honeypots far easier. Instead of a set of physical machines, the honeypot is now the Xen virtual machine with the host filtering and monitoring network traffic and collecting logs. Even better, one Xen host can have multiple honeypots running on it, and those honeypots can be configured in a realistic virtual network, with each plays a specific role: data control, data capture or data collection. Our solution XenKamera is based on Xen, and take some advantages provided by Xen to address the outstanding problems which Sebek currently experiences. Because XenKamera is made to work in Xen environment, we will first take a brief look at Xen technology, and then discuss more about XenKamera s design and implementation. 3.1 Xen Virtual Machine Xen is a virtual machine monitor initially developed by the University of Cambridge Computer Laboratory and now promoted by various industrial monsters like Intel, AMD, IBM, HP, RedHat, Novel and by the whole open source community. Being released under the open source GNU GPL license, Xen can be used to partition a machine to support the concurrent execution of multiple operating systems (OS). Commodity OS (now officially Linux, FreeBSD, NetBSD are supported) can run on Xen with small changes to the kernel. Xen is outstanding because the performance overhead introduced by virtualization is negligible: the slowdown is around 3% only ([16]). Various practices take the advantages offered by Xen, such as server consolidation, co-located hosting facilities, distributed services and application mobility. Basically, Xen is a thin layer of software above the bare hardware, and Xen exposes a virtual machine abstraction that is slightly different from the underlying hardware. In Linux, Xen introduces a new architecture called xen, which is very similar to x86 architecture. The virtual machine (VM) executing on Xen are modified (at kernel level) to work with xen architecture. All the accesses of DomUs to the hardware and peripherals must go through Xen, so Xen can keep the close eye to those VMs and control all the activities. Running on top of Xen, VM is called Xen domain, or domain in short. A privileged special domain named Domain0 (or Dom0 in short) always runs. Dom0 manages other domains (called User Domain, or DomU in short), including jobs like start, shutdown, reboot, save, restore and migrate them between physical machines. Because all the domains run on the same machine, they can share physical resources such as memory, hardware interrupt, and peripherals. Note that all of those sharing must be approved by Xen after all. 3.2 XenKamera Design Goals and Approches XenKamera is designed with the aim to overcome 8 problems experienced by Sebek we discussed above. 1. The first goal of XenKamera is to be the capture data tool for the honeypot architecture. Regarding this, we see that Sebek tries to capture all the I/O data in the system, including the I/O data from console, file-system and network socket. In some experiments we have carried out, we found that in many cases, we were most interested in the session data generated by console, which shows us what the intruder had typed at his console when he broken in the honeypot. These information will disclose quite a few things about the goals, motives and attitude of the intruder. This observation leads us to a decision: XenKamera should focus on capturing only the data from console sessions, but not the data from file-system or network socket like Sebek does. These I/O data from consoles show us not only what the intruder types in, but also the output data returned by the system, exactly as what he receives on his screen. In Unix-derived systems,

4 the communication layer that allows users to access the local and remote physical/virtual devices is the TTY subsystem. By hooking to TTY subsystem and capturing TTY data, we can gather the I/O user data even if the session is encrypted (for example when the intruder logs in via SSH service). The other benefit is that only dealing with TTY data (instead of capturing everything like Sebek does) makes XenKamera very light-weight, since the amount of data produced by console layer is usually pretty small. Moreover, as we choose to put the capture code at the TTY layer, but not in the critical path like Sebek does (Sebek gets the data by patch the systemcalls which leads to very high overhead), the performance impact of XenKamera is very negligible. Consequently the problem (5) of Sebek mentioned above is much more mitigated. Besides that, since we no longer patch the systemcall, our solution defeats the problem (4) of Sebek. In order to capture the console data, we must modify the DomU s kernel in TTY layer. TTY layer is the subsystem that manages all the input and output data concerning console sessions. Patching at the right place makes XenKamera support most type of TTYs: virtual console, BSD console, unix98-style PTYs (xterm/ssh), serial, ISDN, etc. 2. Another target of XenKamera is to secretly send the logging data to the collection machine. In contrast with Sebek, which exploits network stack to transfer data out, we will instead take the advantage of Xen to send the data out via shared memory. Since all the domains run on the same physical machine, they can share memory with each other. Thanks to Xen intercommunication mechanisms, we can establish a shared memory between DomU, the virtual machine we are trying to run XenKamera on, and Dom0. DomU puts all the gathered data from TTY layer in the shared memory, then notifies Dom0 to pick up them. Obviously with this scheme, data is no longer sent out through the network stack, thus the process becomes more quietly, stealthily, and subsequently XenKamera can defeat the problems (1), (2), (5) and (7) Sebek currently suffers. In addition, there is one more merit of this solution: data is sent via shared memory (but not network stack), the overall reliability and efficiency is significantly increased. 3. With the strategy of exchanging data between DomU and Dom0 via shared memory, we run a daemon process in Dom0 to pick up logging data forwarded out by DomU. Because all the communication is done via shared memory and other Xen communication mechanisms, the whole process is not carried out on the network. Consequently the daemon process is not necessarily exposed on the network like sebekd does, thus our approach does not face the problem (8) of Sebek. Because Xen provides strict isolation between DomU and Dom0, even if the intruder knows that he is under observation, he cannot access or modify the logging data kept in Dom0. This advantage still stands even if he somehow gains the ultimate privileges of root user. 4. Besides a small patch at the right place of TTY layer of DomU, we propose that XenKamera is applied in a whole as a patch to the DomU s kernel, but not as a kernel module like Sebek s approach. With this trick, we are not worried any more about hiding kernel module as Sebek does, and it is also more difficult for the intruder to remove XenKamera from kernel. Therefore, the problem (3) of Sebek is addressed with our approach, while the problem (6) is much more relieved (we will discuss further on this later). 5. The final goal is XenKamera must be flexible, so the administrator can disable or enable it as he desires at run-time. All of those goals and approaches lead us to the architecture for XenKamera as followings XenKamera Architecture XenKamera consists of 3 main components: The camera device in DomU, which plays as a data capture tool (kamerau); the camera recorder in Dom0, which plays as a data collection daemon (xenkamerad); and camera utilities in Dom0 (including camera player, keystroke extractors and others). The overall architecture of XenKamera is outlined as in Figure 1. Camera device in DomU: kamerau is a kernel code XenKamera put in kernel-space of DomU. This code patches and hooks into the TTY core layer of DomU to capture TTY data. The captured TTY events are open (new console is opened), deinitialized (a console is cleaned up before closing), read (there is data to input), and write (there is data to output) events. The collected data together with event information is delivered to Dom0 via a shared memory between DomU and Dom0. To be flexible, kamerau can be disabled and enabled by an instruction sent from Dom0 s user-space. When inactive, it costs no overhead in the DomU.

5 memory, and it works in asynchronous way. Consequently the user/intruder never see any difference while working on a XeKamera-powered system. In contrast, our measurements on Sebek in the same set of tests show that Sebek cost up to nearly 950%: the reason is Sebek choose to patch the system-calls (but not the TTY layer as XenKamera does) to capture data, and the system-calls are especially sensitive to any change. This is also a major problems of Sebek: the intruder can easily figure out that Sebek is running with some simple benchmarks. Our evaluation demonstrates that XenKamera is a much more effective solution as a keystroke/tty logger than Sebek. While XenKamera is able to observe DomUs, we do not intend to watch the control domain (Dom0), because Dom0 is the trusted domain. The administrator must protect the Dom0 at all cost, as if the intruder Figure 1: XenKamera architecture takes over Dom0, the game is over: he can do anything he likes to other DomU. Normally it is a good idea to run Dom0 without network address, so the outsider Camera recorder: xenkamerad runs in user-space of Dom0 to record TTY data sent from kamerau. This daemon process patiently waits for the notifications on the new data from kamerau. If it detects that the new data arrived, it gets the data from the shared memory between Dom0 and DomU above, then saves the have less chance to attack it. XenKamera provides patches for DomU in 2 places: TTY hooks and kamerau. These codes are applied on DomU s kernel as built-in, so they are not shown in the kernel module list (with lsmod command), and consequently we cut down one chance for data into separate logging files for each domain respectively. the intruder to detect XenKamera s presence. This Camera utilities: Once having the TTY logging data from camera recorder in the above step, we need to replay it or analysis these data. XenKamera provides 2 key tools: a player (ttyreplay) and a keystroke extractor (xkeys). With the player, the administrator can replay the data in on-line manner, when the intruder is typing at his console, so the administrator can follow the intruder lively. On the other hand, the administrator can also replay TTY logging data in off-line manner by picking up any off-line logging file and replay it later, when the intruder has already gone. In case the administrator is only interested in what the approach also makes it harder to remove XenKamera from the memory if the intruder wants to do that. There might be one more place the intruder can investigate to discover XenKamera s presence: kernel binary and kernel symbol files. Fortunately, in Xen architecture DomU is run by loading the kernel from Dom0, so we will not need to have kernel binary file, together with kernel symbol files in DomU s file system. Last but not least, all the path to the kernel memory should be prohibited, as the intruder might somehow get the root access in DomU and use that privilege to access the kernel internal and modify intruder typed (not the output screen, which shows the it to disable XenKamera. In order to prevent this result of the command the intruder runs), he can use the keystroke extractor to extract the keystrokes from the logging data. With this tool, the administrator can problem, DomU s kernel should be compiled with /dev/{kmem,mem,port} removed ([17]), and the ability of loading kernel module at run-time should be quickly take a look and figure out what the intruder is eliminated, too. This can lead to some objections: doing or already done to the honeypot. the honeypot becomes too restrictive, and the attacker might suspect. But we argue that this kind of harden environment is increasingly popular, and it should be 4 Discussion expected by the attacker on any production systems. In the current solution, Dom0 has a difficulty in We have done some experimental with XenKamera and found that its impact is very negligible: on average the overhead is around only 19% when the data is input or output to the console. The reason is obvious: XenKamera forwards data to Dom0 via shared understanding the domain-level semantic data in the TTY logging files it records. For example, TTY logging data saves meta-information about user-id, who opens and generates the console data. But the userid is only meaningful in the domain that produces the

6 logging, but not in Dom0. The reason is that the TTY logging data is collected from inside DomU s kernel, but the kernel is only aware of the user-id (which is a number), and user-name is something only available in user-space level. Consequently, the administrator who runs xenkamerad in Dom0 to gather TTY logging can only identify the logging user by his user-id, but not by his user-name. This problem can be solved by 2 solutions: either Dom0 keeps the user database of all the DomU (the /etc/passwd file of DomU is suitable for this purpose), or DomU should inform Dom0 the user-name instead of the user-id. But no solution is perfect: with the first method, Dom0 must always update the database, which can be changed dynamically. On the other hand, the second method requires DomU s kernel to read the data in user-space, and there is no good and clean way to do that. So at the moment, we are temporarily content with the current solution, and look to improve it in the future. As XenKamera is very light-weight, we also propose to use it to record the TTY working sessions. We made an experiment: in our test-bed Xen system, we run one Xen virtual domain with XenKamera. On this domain, we have an apache web server, which hosts documentations for local network. In 3 month, we collected 218 logging files, with totally 37906KB in size. These data consist of the logging files about all the console sessions generated when the administrators logged in via SSH to download/upload documentations and to reconfigure the apache server. During this time, once our web server had a problem: users could not find the documentations on the server any more. We replayed all the logging files of the previous day, and figured out the problem: in one SSH session, one administrator logged in, and used vim editor to open the apache configured file, then he changed one option of apache by mistaken. The error made apache looked into the wrong virtual directory for the documentations it hosts. The trouble was quickly examined and fixed. Obviously, this problem is hard to explain without XenKamera logging files. This experience shows us that XenKamera can be a good tool to trouble-shoot the administration. 5 Related Works Honeypot is one of the hottest topics on security research fields. Many papers focus on applying honeypot to improve defense system or to trap malwares. The honeypot can be broken down into 2 kinds: lowinteraction and high-interaction type. The low-interaction honeypots have limited interaction: they normally work by emulating services and operating systems. Attacker activity is limited to the level of emulation by the honeypot. Honeyd ([18]) can emulate TCP/IP stack and simulate network behavior, is one of the most popular honeypot of this type. The Honeynet ([2]) is the high-interaction honeypot, which is the main research topic of this paper. A honeynet may contain one of more honeypots, and Sebek plays a key-role in a honeypot, with the job is to capture the intruder s activities. Though Sebek is a popular tool in the honeypot community, there are very few papers that discuss the weak points of honeypot or propose methods to improve Sebek, which are related to the topic of this paper. In [13] and [15], J.Corey points out some problems with honeypot, especially with Sebek, and several methods were proposed to defeat it. M.Dornseif and T.Holz also presents few other methods to detect and exploit Sebek in [9] and [12]. Our paper tries to investigate all the current outstanding problems of Sebek, and proposes XenKamera as a solution to address or mitigate them. There are many attempts to capture keystrokes and TTY logging for either administration or security purpose. Basically we can divide them into 2 kinds: user-space-based and kernel-space-based solutions. The user-space solutions run in user-space, and they capture the keystroke either by poking at I/O port ([19], [20], [21]), or intercepting TTY file descriptor ([22]). They all have same drawbacks: easy to uncover and disable. Kernel-based solutions are favorable, because they are much harder to detect. They can even stay invisible, and usually only be detected by privileged users with special techniques. Two of the most famous keystroke and TTY logger kits are vlogger ([23]), and ttyrpld ([24]). vlogger is a Linux kernel-based key logger. It is a favorite tool of black-hat community, and is usually installed on a penetrated Linux system to steal information typed at console (user-name and password are the most wanted). vlogger intercepts TTY internal function to record keystrokes and either saved to local file system, or send them out to another machine. It also tries to evade the network level probes by patching the network stack. Nevertheless this kit does not give us the output screen-shots like TTY-based solution, and can be easily detected by a sniffer (like tcpdump) placed on separately independent machine in the same broadcast domain. Simply put, it shares many problems with Sebek. ttyrpld is the TTY capture solution for multiple Operating Systems (currently Linux, FreeBSD and OpenBSD are supported). Also based on kernel, ttyrpld is difficult to circumvent, and has ability to log any TTY type (including virtual console, bsd/unix98 pty, serial, isdn). Even better, the overhead impact to the

7 system is quite low. In order to get TTY data, ttyrpld Sebek, a data capture tool widely-used in honeypot patches OS kernel and put some hooks in TTY core technology. We demonstrated that XenKamera can layer. On Linux, the hooks are taken advantage by a kernel module which attach its own functions to these hooks to gather TTY data. The information is then transferred to user-space via a software device (put at /dev/rpl). ttyrpld also provides a player named ttyreplay to replay the saved logging data, and the administrator be employed instead of Sebek for honeypot purpose in Xen environment, and if being installed in a strict manner, XenKamera is stealthier and harder to detect, even with privileged user. Our solution is also more flexible, effective and reliable than Sebek. Moreover, XenKamera is practical for production can watch those date in real-time or off-line system, because it causes very little overhead. We manner. Overall, ttyrpld is a very nice tool. Unfortunately, ttyrpld is not suitable for the purpose of secret watching the intruder, because there are too many clues about its presence: ttyrpld requires a process daemon (rpld) to run in user-space, and it also installs a device at /dev/rpl in the system. In addition, the kernel module of ttyrpld named rpldev can propose to use XenKamera to record working operations, and the data collected might help to troubleshoot daily administration. At the moment XenKamera only works for Linux-based DomU. We plan to provide support for other OSes such as FreeBSD, NetBSD once these ports are working stably on Xen. be listed with lsmod command. All of these evidences can be spotted even with an unprivileged user. Consequently the intruder will quickly realize that he is being observed. References: Last but not least, ttyrpld saves all the logging [1] Lance Spitzner. Honeypots: Tracking hackers. Addison-Wesley Professional publisher, data in the local file system (by default at /var/log/rpl/ directory), the intruder with privileged access can September delete all the valuable logging data to cover his footprints. [2] The Honeynet Project. Know your enemy: Our solution XenKamera is initially inspired by Honeynets. ttyrpld, but is able to address all the mentioned drawbacks of ttyrpld: XenKamera can record all the TTY papers/honeynet/, May data from the intruder s console like ttyrpld, but it [3] The Honeynet Project. Know Your Enemy: works quietly in kernel space of Xen domain and leave no trace for the intruder to be suspicious about its existence. GenII Honeynets. org/papers/gen2/, May XenKamera has no daemon process run in user-space, no device is necessary in /dev, while it [4] Edward Balas and Camilo Viecco. Towards a never send out any information via network stack like vlogger does. Finally, it never keeps any logging data in the local file-system. Third Generation Data Capture Architecture for Honeynets. In The 6th IEEE Information Assurance Workshop, June All of these characteristics make XenKamera pretty hard to discover, and suitable for honeypot purposeemy: [5] The Honeynet Project. Know your en- Sebek. Our paper somewhat shares the similar ideas with org/papers/sebek.pdf, November our previous work name Xebek project [25], but is different in the scope: while Xebek tries to capture all the I/O related data (similar to what Sebek does, but Xebek is able to fix almost all the problems of Sebek [6] Boris Dragovic, Keir Fraser, Steve Hand, Tim Harris, Alex Ho, Ian Pratt, Andrew Warfield, Paul Barham, and Rolf Neugebauer. thanks to its special architecture), the XenKamera tool focuses only on gathering TTY data. This approach makes XenKamera more light-weight, and practical for production systems. [7] Ian Pratt, Keir Fraser, Steven Hand, Christian Limpach, Andrew Warfield, Dan Magenheimer, Jun Nakajima, and Asit Mallick. Xen 3.0 and the art of virtualization. In Proceedings of the 2005 Ottawa Linux Symposium, Ottawa, Canada, July Conclusions This paper proposes the design and implementation of XenKamera solution for Xen-based systems, with the aim to eliminate some outstanding problems of [8] The Honeynet Project. Honeywall CDROM. cdrom/index.html/, May 2005.

8 [9] Maximillian Dornseif, Thorsten Holz, and [23] rd. Writing Linux kernel keylogger. Christian Klein. NoSEBrEaK - Attacking honeynets. In The 5th Annual IEEE Information As- p=59&a=14, July surance Workshop, June [10] stealth. adore-ng rootkit org/rootkits/, March [11] madsys. Advanced incident response tool. airt-linux/, August [12] Thorsten Holz. Detecting honeypots and other suspicious environments. In Proceedings of the 6th IEEE Information Assurance Workshop, June [13] Joseph Corey. Local honeypot identification. unofficial/p62/p62-0x07.txt, September [14] tcpdump project. org, October [15] Joseph Corey. Advanced honeypot identification and exploitation. org/unofficial/p63/p63-0x09.txt, January [16] E. Dow S. Evanchik M.Finlayson J. Herne J.N.Matthews B. Clark, T. Deshane. Xen and the art of repeated research. In Proceedings of the Usenix annual technical conference, Freenix track., pages , July [17] sd. Linux on-the-fly kernel patching. p=58&a=7, July [18] Niels Provos. A virtual honeypot framework. In The 13th USENIX Security Symposium, August. [19] Linux Key Logger. spine-group.org/tools/lkl tar.gz, August [20] Uberkey. nu/uberkey/uberkey-1.2.tar.gz, November [21] unixkeylogger. linuxsecurity.com/exploits/ rootkits/unixkeylogger.c, August [22] snoop. July [24] Jan Engelhardt. TTY logging daemon project. July [25] Nguyen Anh Quynh and Yoshiyasu Takefuji. A novel approach to secured and central logging data. In 4th WSEAS International Conference on Information Security, Communications and Computers (ISCOCO 2005), December 2005.