Honeypotting with Solaris

Transcription

1 Honeypotting with Solaris Sakari Laitinen Helsinki University of Technology Abstract Attack is the best defence, it is said. This paper is about honeypots, which are good counter-measure to detect intrusions and abnormal activity in the Internet of these days. Since security in honeypots is a big concern, this paper is about Solaris 10 operating oystem, which claims to be the most secure OS in the world. This paper focuses on figuring out how Solaris 10 works when used to deploy a virtual honeynet. Solaris has very good features for server consolidation, which allows multiple workloads to run on the same system, has become very important way to improve the utilization and reduce costs in the increasingly growing data center needs. This paper introduces technologies that Solaris 10 provides for virtualization and system observation. These technologies are mainly designed to provide solutions for server consolidation projects and to find serious systemic performance problems on production systems. KEYWORDS: Honeypot, Honeynet, Solaris, Zones, Virtualization 1 Introduction Nowadays information security is increasingly growing concern. More and more stories are heard about threats from the Internet. Sometimes when computer system gets compromised, it is often quite a surprise. The attackers try to hide their tracks and leave the system looking like untouched, so usually the amount of analyzable data what is left behind is pretty small. These occasions do not teach very much. Who would be better example of the threats, that against the computer systems should be defended, than the attacker himself? The problem is, how to know when the attacker hits? While attackers are developing new method, it is not a reason for organizations to stand still and wait for an attack. Something have to be done to detect the malicious activity. This is where the honeypots step into the picture. Honeypots are decoy systems which are supposed to be attacked, and that information from the attack should be used as an advantage for organizations. Earlier work in this area has been done mostly about using User-Mode Linux as a honeypot. There has also been problems on many areas, such as the detectability of honeypot. This is very understandable thing, because there are no operating systems that would have been designed to honeypot usage. Before that happens, have to use the tools that are already available. Solaris 10 Operating System claims to be the most secure OS on the planet[16] and it includes good tools for virtualization and system observation built-in. Because the tools are already there, the implementation of virtual honeynet should be easy. But actually it is not. Usually software applications and operating systems provide as much information as possible or at least when the user requests for it. Therefore, it is hard to find ready-made solution which could work well and would not expose itself to the malicious attacker. The rest of this paper is structured as follows. Section 2 provides an introduction to honeypots and different honeynet types. Section 3 introduces what kind of virtualization technologies and system observation facilities exists in Solaris. Section 4 presents an example of honeynet deployment with Solaris and discusses the challenges, problems and some possible solutions what could be done to make the honeypot more undetectable. Summary and conclusions are given in section 5. 2 Background The Honeynet Project is an organization which has researched honeypots and honeynets since The project is answering to the question when the hit happens. The method is to setup tempting looking system and wait for the attack. Like a jar of honey waiting for some eager bear to eat, therefore the name honeypot. There is no strict definition what a honeypot system is. Honeypot can do everything from intrusion detection to measuring security threats organizations face. The Honeynet Project founder Lance Spitzner describes honeypots with the sentence: A honeypot is an information system resource whose value lies in unauthorized or illicit use of that resource[17]. 2.1 Honeypots Generally honeypot is a isolated and monitored computer system, which has not any production value. Because there are no normal interaction with the honeypot, any activity and network traffic is most likely illicit or unauthorized. From normal computer system is much harder to find the malicious traffic. It takes time to filter out the normal traffic and figure out the false positives from intrusion detection systems. Besides the smaller amount of logged data, it is usually easier to setup monitoring and intrusion detection systems to empty servers that do not have some business critical services running. Also the honeypots are often very easy to replace if the system gets compromised. Usually collecting the useful data to researches, copying a fresh disk image to the host and then the honeypot is back in business.

2 Honeypots are used for production purposes or research[11]. The ones used for production purposes are usually preventing and detecting attacks to real systems. The research honeypots only collect information for studying attackers. Usually honeypots are used for production purposes as intrusion detection systems, because it is enough to know about the ongoing malicious activity and protect the real systems from attackers. Research honeypots have no other purpose than to be attacked and hopefully get compromised to create as much interesting information as possible. Problem with the security threats are, that usually the attackers are one step ahead finding new attacking methods and security gaps. Research honeypots try to reveal these and maybe even find out who the attacker is. The Honeynet Project non-profit organizationg specialized in reseaching honeypots and collecting data around the world. The basic honeypot implementation types can be divided to two category, low-interaction and high-interaction honeypots Low-interaction honeypots Low-interaction honeypots usually emulate services or operating systems. The dummy services normally give some real-looking answer to connection attempts, but nothing else. For example, fake telnet daemon can ask for a combination of login name and password, and then close the connection. There is no real server to compromise, but the data of the login attempts and connection sources are still the same. Low-interaction honeypots are easier to maintain, because the risk of really get compromised is smaller. Several implementations of these emulated services exists, such as Honeyd. Honeyd is a low-interaction honeypot which has lots of features to emulate different services and operating systems[10] High-interaction honeypots High-interaction honeypots usually involve real computers, applications and operating systems. These honeypots have much higher risk to be used as further malicious activites, such as zombie hosts in distributed denial of service attacks. These honeypots need much more attention and deployment needs more configuration, because the applications are real. Also the possibility for further attacks from the honeypot host have to be blocked. Even though high-interaction honeypots need more effort, there are also some benefits. The responses to attack attempts are real and the possibility to get some research data from the attacking methods, motives and possible security holes in the server software are revealed. Generally high-interaction honeypots can give much more information than low-interaction honeypots. Usually low-interaction honeypot can imitate many servers, but the services in high-interaction honeypots are divided to many servers, forming a honeynet. 2.2 Honeynets Honeynet should be an environment where the tools and the attacked systems would be kept isolated from everything else. Honeynets have some requirements that would be good thing to fulfill. Honeynets should be able to control the inbound and outbound traffic. There should not be known network activity inside the honeynet, so every unknown incoming connection is malicious. Also outbound traffic must be able to restrict because of possible compromisation. Honeynets should be able to capture and log the activity inside the honeynet without exposing it to the attackers and also be able to transfer the collected data to some secure place waiting for analyzement[12] Honeynet architecture Implemented honeynets often have transparent bridging firewall working as gateway to the honeynet and doing data control by firewalling. The data capture is done in the gatewayfirewall, honeywall and of course in the different honeypot hosts. Data collection from the different hosts might be difficult to do secretly. There are some tools for that purpose, such as hidden kernel modules which can log the user activity in the honeypot and transmit the data secretly to some data collector. One example is Sebek[14], which has hidden kernel module client that captures data from the attackers actions and sends it to the collecting Sebek server Virtual honeynets Virtual honeynets are very similar as normal honeynets. Only difference is that the whole honeynet deployment has been done by virtualizing the honeypot hosts on single computer. Virtualization removes the need to have separate computers filling data center, but it also changes some things. The deployment might be easier, if it is possible just clone the virtual machine several times and then do the needed configurations. The virtualization can also bring some problems, depending on the implementation. For example, some disadvantages are that the virtual machine can be easier to detect as honeypot than normal server, because the virtualization is not always so well hidden, but even the normal server can have some revealing kernel modules or software. Also the host machine will become a single point of failure, if something breaks up, the whole honeynet goes down. One possibility is to make a hybrid honeynet, which consists of both virtual and physical machines. Virtual machines usually have lack of stealth and it is pretty easy to figure out if you are inside of virtual machine. 3 Solaris The Solaris operating system (Solaris OS) from Sun Microsystems has evolved very much since the release of Solaris 2.0 in With the release of Solaris 10 the evolution process took a quantum leap. Solaris Zones made a big change in OS virtualization. Solaris used to be a commercial and closed-source product, a majority of the codebase has been open-sourced by Sun Microsystems. After the open source announcement some of the new technologies in Solaris 10 has been ported to many other operating systems. For example DTrace, the dynamic tracing facility and ZFS file system has been ported to Mac OS X and FreeBSD.

3 Key areas of Solaris development has been reliability, performance and scalability, manageability, observability and resource management. Solaris has downward binary compatibility guarantee by Sun Microsystems[1]. That has made Solaris always really reliable operating system, because you can be sure that the software from the previous version works after upgrade. For performance and scalability, Solaris have always been well-suited for symmetric multi-processing and the scalability should not be an issue, because the absolutely same Solaris 10 operating system works from the desktop systems to high-end mainframe class servers. 3.1 Virtualization in Solaris The analysts from IDC say that conventional server utilization is between 10-15% range, meaning that even 90% of the capacity is wasted[7]. Goal would be to clean up data centers and increase utilization of equipment. Solaris supports many different technologies to do system consolidation. Some of the technologies need more from the underlying hardware than others. For OS virtualization the Solaris Zones work very well. The Zones work on any server as the normal Solaris installation. Zones are also very flexible, create very little overhead and are quite easy to deploy, so those are often a good solution in server consolidation. Solaris is also capable of doing hypervisor-based virtualization. Logical Domains need support from the hardware to work well and are mainly designed for multicore server utilization. The xvm is not yet in the official Solaris 10 release, but already in OpenSolaris, so it will be coming from there some day. The mostly used techniques are the Solaris Zones and Logical Domains which will be introduced next Solaris Zones Solaris Zones is not a real virtual machine environment, but it could be defined like this: "Zones is a software partitioning technology that enables the creation and management of multiple virtualized operating system execution environments within a single instance of the Solaris kernel[9]." The management and system infrastructure administration, such as physical devices or routing, can be only done from the global which encloses all other s. The global always exists and is comparable to a normal Solaris operating system instance which has all processes, privileges and devices available. The s facility provides an isolated environment, a sandbox or a jail. Processes running in a are prevented from interaction between processes in different s and the physical attributes of the system with abstraction layers. Access to network interfaces, file systems, devices and the privileges available within a are restricted. The virtual platform in Figure 1 is the layer that provides the access to virtual devices for the s, such as virtual network interfaces. Each is assigned a name and numeric id, which will be used in the process isolation. Only processes with the same id number are visible within the. For each active there are two system processes to manage the virtual platform and application environment. admd Figure 1: Zones Server Consolidation Example [19] is system daemon responsible of managing the s virtual platform and resource management. This daemon is also does the setup and teardown of the application environment. The admd starts the other important process, zsched. zsched is kernel process, which mostly keeps track of the per- kernel-threads. The admd is also responsible for tasks including setting up the, initializing devices and mounting file systems. Even though all s share the same Solaris OS instance, each running runs its own set of core services, has its own process environment and their own restricted file systems. Since the privileges and user namespaces are also virtualized, it is possible to safely delegate the administration to user within the. One of the new features of Solaris 10 update 4 was the Branded Zones[3]. Normal installations are native s which use the same Solaris OS as the global. It is also possible to brand to something else and install a different operating environment inside of a non-global. The BrandZ framework extends the Solaris Zones infrastructure to enable non-native s and alternative sets of operating environments. The BrandZ infrastructure would allow wide range of operating environments, but currently Solaris is capable to run Linux and Solaris 8 userlands with the Solaris 10 kernel after installing proper operating environment to the. Solaris 8 Migration assistant helps in server migration from old Solaris 8 to Solaris 10. BrandZ/lx[4], also known as Solaris Containers for Linux Applications enables user-level Linux applications run unmodified on Solaris kernel and even do dynamic tracing to the lx branded with the DTrace, which will be introduced in the section Logical Domains While the Zones is OS virtualization technique in the Fig. 2 [18], there also exists virtual machine possibility to run different operating systems in parallel. To divide one server to multiple separate systems on SPARC architecture there is technology called Logical Domains (LDoms)[8]. LDoms include the hypervisor which is a thin software layer between operating system and hardware. Hypervisor is not itself an

4 DTrace allows for many tens of thousands probe points and also can instrument almost the whole kernel, including subsystems, such as scheduler and synchronization facilities[5]. The actions and predicates in DTrace are described in specific C-like language, namely "D". The scripts in D-language make the tracing easy, because you can use the same scripts over and over again. D-language is rahter versatile script language, even though it does not include syntactic structures, such as loops or branches. For example, it is not hard to write a "hello world" program with the D. #!/usr/sbin/dtrace -qs Figure 2: LDom vs. Zones difference operating system, but it makes the machine hardware virtualized and isolates the operating system from the register level. The hypervisor provides stable virtualized sun4v architecture to the operating system. Logical Domains technology is a partitioning capability to create full virtual machines which each has own identity, independent operating system and dynamically configurable subset of resources. Each logical domain can be installed, configured, rebooted or destroyed independently, without interfering other logical domains. Protection and isolation between the domains is done by using hardware and hypervisor firmware combination xvm On x86 architecture there is xvm, which is port of Xen open source hypervisor to run with OpenSolaris. xvm is the hypervisor layer to enable possibility to run virtualized operating systems. Some of operating systems have not been paravirtualize or those are closed source, so the paravirtualization has been impossible. The goal is to get operating systems work without modification. To make it possible, some new processor features are needed, such as support for hypervisors, some traps for unsafe instructions and better memory access. Full emulation solutions can be found already, such as Bochs[2], but the performance is not so good, because the emulation is done on all instructions through software. 3.2 Dynamic Tracing in Solaris Solaris 10 introduced a new facility for dynamic instrumentation of production systems. This facility is called DTrace[13] and it has been integrated into solaris. DTrace is mainly aimed for system administrators, software developers and operating system developers. DTrace is built on flexible observability framework and is really flexible system to dynamically instrument user-level and kernel-level software. DTrace is integrated into Solaris kernel and is always ready to use without any software restarts or system reboots. When DTrace is not in use, it has no effect for the system performance at all. It is just as it were not present at all. BEGIN { printf("hello World!\n") ; exit(0) ; } Almost as easy task is to use syscall-probe from kernel and trace what system calls the httpd-processes perform in the WWW-. #!/usr/sbin/dtrace -qs syscall:::entry / execname=="httpd" && name=="www" / { printf("pid %d called %s\n", pid, probefunc); } For those, who do not want to reinvent the wheel, there exists such thing as DTraceToolkit[6]. It is a big collection of D-scripts for many purposes. Lots of things can be done with those directly or with a little modifications for own purposes. To be able to run DTrace without restrictions and trace everything, the tracing must be done from the global. For example, it is really easy to use DTrace to snoop inside of a what files the user opens, what syscalls are done or what kind of input shell commands in the specific get and what is the output. It is also rather easy to use DTrace only as a part of your tracing tool. For example, using the DTrace as a data collector for Perl script which processes the data for some suitable format. 4 Deploying a honeynet This section describes the experiment of deploying a small honeynet with Solaris 10. Section 5.1 describes the actual test system that was implemented and Section 5.2 discusses about the experiences, challenges and problems that arise. 4.1 System description The experiment system was basic installation of Solaris 10. With an empty system to start with, it was not hard to continue the honeynet experiment. After creating one and given it basic configuration, it was easy to clone it to couple of more instances. Soon after configuring the services in the different s, the honeynet looked like something. At least

5 4.2 Experiences, challenges and problems HTTP Internet Self contained virtual honeynet Global SMTP FTP SSH NTP Telnet Figure 3: Self Contained Virtual Honeynet building the honeynet was easy. The experimental honeynet in Fig. 3 was self contained virtual honeynet, which had four hosts and some services on them, for example HTTP, FTP, SMTP, NTP, Telnet and SSH servers. Surprisingly, an Ethernet Bridge was missing feature and changed the plans of configure one to work as a transparent network gateway. The data control will be done by using the firewall from the global, so it cannot be noticed or changed from inside the. Snort[15] the intrusion detection system was also installed and configured in the global to listen to the network interfaces. All the internal filesystems of the s can be accessed from the global, so the normal logs from the daemons are easy to acquire without affecting the s. The next procedure was to add some DTrace scripts for monitoring the internal services. In the DTraceToolkit was script shellsnoop, which was almost ready for the usage. It needed only some little modifications to make the script trace the inputs and outputs of shellprocesses from s which are not global. This way it is easy to collect the user activity from the global without affecting the honeypot s. Also similar scripts can be set up to monitor network probes about TCP-connections or any other probe in the system. In the test installation, the listing of probes returned almost usable probes. Because this experiment was mostly just a proof of concept, no further experiments, like monitoring real network traffic, were done. The deployment of the test honeynet was really easy task. Only thing that could not be done this time was a surprise that Solaris does not have the Ethernet Bridge feature, yet. This feature is still under development and it can be found from the OpenSolaris, but not yet from the official Solaris release. So in this it was not possible to make transparent bridge gateway from one. If the attacker manages to access shell account somehow, it is really easy to figure out that he is inside a. Because the userland has the same system tools as the global with the all features, it is really easy to use some commands to check if the s name is global or not, such as name or ps -Z. So Solaris really have this kind of lack of stealth. The extensions for User-Mode Linux were made to fix some of stealth problems in UML, but similar work has not been done for Solaris. 5 Conclusions Solaris has really good tools for system adminstration. The deployment and management of the s is very easy, if compared to installing new server to be each node in the test honeynet. It works very well for running virtualized lowinteraction honeypots, because then the detectability is not problem. It is also good at high-interactive honeypots until the point, where the attacker somehow would gain shell access to the. The current system tools and utilities show too easily hints about being inside some other than the global. If you happen to get shell access, then it is too obvious that you are inside of. The fact is that Solaris was not designed to be undetectable honeypot. But, actually the detectability does not seem to be as a big problem as before. Because the data centers and server rooms include more and more virtualized systems, even though attacker might have noticed being in virtualized system, how does the attacker know, if he got in a real production machine? The trend is that big organizations consolidate their big data centers to more economical solutions, because usually they make big savings in the process. Therefore, it feels like it will be harder to find the non-virtualized system than some virtual machine. References [1] Solaris binary application guarantee program. Available on: solaris/guarantee.jsp. Accessed: 2007, Nov 16. [2] Bochs. Available on: sourceforge.net/. Accessed: 2007, Nov 16. [3] Solaris branded s. Available on: http: // brandz/design/. Accessed: 2007, Nov 16. [4] Solaris containers for linux applications. Available on:

6 community/brandz/brandz_overview.pdf. Accessed: 2007, Nov 16. [5] B. Cantrill, M. W. Shapiro, and A. H. Leventhal. Dynamic instrumentation of production systems. In USENIX Annual Technical Conference, General Track, pages 15 28, [19] Zones server consolidation example. Available on: /6mhahuooa. Accessed: 2007, Nov 16. [6] Dtracetoolkit. Available on: opensolaris.org/os/community/dtrace/ dtracetoolkit/. Accessed: 2007, Nov 4. [7] Idc white paper: Virtualization across the enterprise. Available on: datacenter/consolidation/docs/idc_ SystemVirtualizati%on_Aug2007.pdf. Accessed: 2007, Nov 16. [8] Sun logical domains (ldoms). Available on: coolthreads/ldoms/datasheet.pdf. Accessed: 2007, Nov 16. [9] R. McDougall and J. Mauro. Solaris Internals: Solaris 10 and OpenSolaris Kernel Architecture. Prentice-Hall Inc, 2nd edition, [10] I. Mokube and M. Adams. Honeypots: concepts, approaches, and challenges. In ACM-SE 45: Proceedings of the 45th annual southeast regional conference, pages , New York, NY, USA, ACM. [11] T. H. Project. Know your enemy: Honeynets. Available on: papers/honeynet/, Accessed: 2007, Nov 4. [12] T. H. Project. Know your enemy: Genii honeynets. Available on: org/papers/gen2/, Accessed: 2007, Nov 4. [13] J. M. Richard McDougall and B. Gregg. Solaris Performance and Tools: DTrace and MDB Techniques for Solaris 10 and OpenSolaris. Prentice-Hall Inc, 1st edition, [14] Sebek. Available on: org/tools/sebek/. Accessed: 2007, Nov 16. [15] Snort - network intrusion detection system. Available on: Accessed: 2007, Nov 4. [16] Solaris security features. Available on: security.jsp. Accessed: 2007, Nov 16. [17] L. Spitzner. Honeypots. Available on: spitzner.net/honeypots.html, Accessed: 2007, Nov 4. [18] Virtualization & consolidation : Sun virtualization solutions. Available on: virtualization/. Accessed: 2007, Nov 4.