Development and Implementation of the Honeynet on a University Owned Subnet

Erin L. Johnson, John M. Koenig, Dr. Paul Wagner (Faculty Mentor) Department of Computer Science

University of Wisconsin - Eau Claire Eau Claire, WI 54701

{johnsone, koenigjm, wagnerpj} @ uwec.edu

Abstract

Honeypot/net technology utilizes computers whose sole purpose is to be attacked so the tools, techniques, and modus operandi of attackers can be studied. Our project was to implement a honeynet with limited resources in such a way as to not endanger the University of Wisconsin - Eau Claire (UWEC) network. At the same time we wished to provide a project that other undergraduates at UWEC could participate in.

1

1. Introduction In the field of computer security, a major question is whether to focus on studying and developing defensive techniques based on preexisting attacks and known methodologies or to study the approaches used by attackers on live systems via observation and logging. In The Art of War, Sun Tzu states "If you know yourself but not your enemy, for every victory gained, you will also suffer a defeat" [1]. We feel it is essential to study the techniques used by attackers directly, in order to help understand their approaches, techniques and motives. One way to do this is to use a technology called honeypots which allows malicious activity to be observed and logged, all without the attacker's knowledge. To the attackers, honeypots appear to be unsecured computers ripe to be attacked and in actuality serve no other purpose but to be attacked [2]. Because of this, all traffic can be considered malicious, thus nearly eliminating false negatives and false positives. This also means that honeypot technology can be placed in research and/or production environments and can be used as a warning device as well as to detect previously unknown exploits, tools, and attack techniques [3].

Honeynets, which are networks of honeypots, take these concepts one step further and provide a much more robust environment for an attacker to interact with. This increases both the volume of data that can be gathered, as well as the potential for more complex attacks to be captured.

The focus of our research project is to implement a honeynet at the University of Wisconsin Eau Claire (UWEC) according to the stipulations set forth by the Honeynet Research Alliance (HRA) while operating within our resource boundaries. Thus far, at the university level, HRA members have traditionally been Tier One research schools. Unlike larger universities, UWEC lacks large government funded computer science research and in the past has geared its curriculum towards industry. Our initiative is two- fold. First we wish to profile malicious activity on our university owned class C subnet and submit this data to the HRA upon our acceptance into the Alliance. Second, we wish to provide an extensible project by which undergraduates at UWEC can participate in and gain research experience.

2. Background Security tools, from intrusion detection systems (IDS) to virus scanners, are primarily rule and signature based technologies. For example, if a black-hat hacker executes actions XYZ, an IDS will look to its database of known attack patterns, also called signatures, and determine if he or she is attacking the system. This database is comprised of information gathered by professionals and the public alike, through internal research and public lists such as Bugtraq [4], rather than by the attackers themselves. The honeynet's ability to let researchers study attackers directly enables said researchers to develop better tools and security paradigms. There are various ways a honeynet can be implemented; however, the HRA has issued a set of guidelines and it is by these guidelines that we implemented our honeynet. This architecture requires that data

2

control, data capture, and data collection mechanisms be implemented. To meet these requirements, we decided to use the open source tools honeywall and Sebek ([5], [6]). While the honeywall is a standalone tool, Sebek consists of a server and clients. One benefit to using the honeywall is that the Sebek server built into it. For a typical implementation of a honeynet with a honeywall reference Figure 1.

Figure 1: Honeynet Implementation with the Honeywall

The honeywall is a tool maintained by the Honeynet Project and acts as a bridge between the Internet and the honeynet. This allows the honeywall to passively collect all honeynet traffic, throttle connections, throw attack warnings via snort-inline, and also provide researchers with a data analysis capabilities via Walleye [5]. When our project began, the current version of honeywall was 1.0, which was nicknamed Roo.

Sebek is a data capture tool that collects all sys_read calls such as keystrokes and files copied to the honeypot. Sebek is comprised of two components: the server and clients. The clients use root kit techniques to hide in kernel space. Once the client has data to report to the server, it sends Sebek packets to an IP while the server is configured to collect all packets directed at that IP. One advantage to using Sebek is that it is able to circumvent session encryption. This ability is due to the client residing in kernel space, capturing data post decryption. Due to the strict division between kernel space and user space, attackers are then unaware of the capture [6].

3. Implementation Due to variances in resources and the nature of integrating two different technologies such as the Honeywall and VMWare, several approaches were attempted before a valid solution emerged [7]. For the most part, several components, such as our hardware and network configuration, have remained the same.

3

3.1 Hardware

Due to hardware rotation at UWEC we were fortunate to receive two Dell Poweredge servers for use in our Honeynet. Below is a brief listing of the hardware:

2 – Dell Poweredge 1750

- 2 2.3 GHz P4 Processors

- 2 GB of RAM

- 2 16 GB hard drives configured using RAID 0

- 2 100 Gb Onboard NICs

A switch was also lent for our exclusive use to better manage the security risk to the UWEC domain.

3.2 Network Configuration

In order to implement our honeynet on the UWEC network we first had to address the issue of campus security. We were given a class C subnet that, though routing, was isolated from the UWEC network with the exception of SSL and SSH connection capabilities from the other UWEC subnets into our honeynet. These exceptions allowed us to remotely manage the honeynet. This isolation however was not without a cost. As an orphan subnet we needed to register a domain as well as be responsible for own DNS resolution. Thus, it was necessary to make one of our honeypots a DNS server and direct our honeywall to OpenDNS [8]. The reason for using OpenDNS was that if we were to have the honeywall connecting to a honeypot within the honeynet, the integrity of our implementation would be compromised according to HRA guidelines [9]. Figure 2 shows a general graphical representation of our network setup.

4

Figure 2: Network Diagram

3.3 Phase I

Due to only having two computers we decided to implement a hybrid virtual honeynet as per Gómez’s classification [10]. We were fortunate in that our donated equipment consisted of two servers which we named Prometheus and Daedelus. Initially the host OS for Prometheus and Daedelus was Debian 3.1 with VMWare GSX server installed. The computational power of these servers enabled us to install several Windows XP and Windows Server 2003 virtual honeypots on Daedelus while Prometheus only hosted a virtual Roo honeywall 1.0 (Figure 3). For security reasons we disabled the IP stack on the host operating systems so that we could better assert their integrity. If the IP stack was not disabled it would have been possible for an attacker to compromise Prometheus, the honeywall, and our data.

It was at this point we also added a third NIC to Prometheus to exclusively handle honeywall management interface traffic.

5

Figure 3: Phase I

The honeywall allows users to specify which IPs can connect to its management interface. There is the capability to allow all IPs to connect to the interface, however the IP of our management interface exists within the same subnet as our honeynet. This would mean that anyone examining our subnet would instantly see that it is a honeynet. Thus, rather than opening up our honeywall to all IPs we installed a Damn Small Linux virtual machine, called IQ, on a server within the UWEC production space and added IQ’s IP to the allowed list [11]. By doing this, we can SSH into IQ and then connect to the management interface and add the IP of our workstation to the allowed connection list.

Original plans included adding virtual severs for both Sebek and the honeywall database back up. However, we quickly ran into conflicts between Debian and VMWare. These complications included installation and configuration problems on Debian as well as network interface issues on the virtual machines. For these reasons we decided to switch the host operating systems to Windows Server 2003 in hopes that the Windows environment would prove to be more compatible with VMWare.

3.3 Phase II

During this transition to Windows 2003 Server we acquired an additional server, a Dell Poweredge 2450, which we named Icarus. The intention was to install several more virtual workstations so that we could better mimic an actual subnet (Figure 4). However, this was only temporary due to the donating party requiring the return of Icarus.

6

Figure 4: Phase II

The loss of Icarus was not our only setback. Once we installed the Sebek client on the virtual Windows honeypots, a non recoverable blue screen of death would occur at boot. This was directly related to a flaw in the WIN32 version of the Sebek client. Not being able to use Sebek would prevent us from being able to observe encrypted network traffic, actual system activity, and utilize Sebek’s flow diagrams. This flaw forced us to reconsider our guest operating systems. Due to the recent popularity of Ubuntu and the stability of the Linux Sebek client, we replaced our Windows honeypots with Ubuntu counterparts [12].

3.4 Phase III

Unfortunately the move to Ubuntu did not solve our connectivity issues such as no DNS resolution, and not being able to connect outside of our subnet. Intermittently the management interface would begin denying all attempted connections, and the Snort rules, along with several other packages, desperately needed updating. The former issue was a known bug in Roo 1.0 and the fix was a recommended update via yum, the package manager for Roo. We attempted to update the honeywall, however, this resulted in yet another bug in Roo where by the updating packages caused circular dependencies. After posting to the honeypot mailing list at Security Focus the maintainers of Roo released a statement regarding the yum issue as well as release announcement for a previously shelved version or the honeywall, Roo 1.1 [13]. This version fixed numerous bugs in Roo 1.0, however it is considered a stopgap measure until the release of 1.2.

We decided to take the chance and install Roo 1.1. We had a period of functionality, however much like previous periods, it was brief. Incoming connections were being allowed, but all outbound traffic was being denied. Also, the honeywall was logging all traffic on the subnet, including our connections to the management interface and classifying those connections as possible attacks. After spending a weekend studying the

7

iptables, which the honeywall uses to control connections, and finding no discernable reason for the traffic issues, we decided to narrow down our possible points of failure, by abandoning the virtualization of the honeywall. Thus, we made Prometheus exclusively a Roo 1.1 installation.(Figure 5).

Figure 5: Phase III

Finally, for the first time we began to collect viable data. We installed Sebek with no problems, were able to update Snort, and this is where we currently stand.

4. Concluding Remarks

This project has been a learning process and one that we will to continue to work on. Within the next few months we plan to apply to the Honeynet Research Alliance. We will continue collecting and analyzing data that will eventually enable us to characterize malicious activity on the UWEC network. Also, to help the project evolve we will be opening it up to other students at UWEC.

5. Acknowledgements We would like to thank our research advisor, Dr Paul Wagner, as well as Jason Wudi, Tom Paine, and Eric Stevens for their continued support.

8

References [1] Tzu, Sun. The Art of War (Shambhala Classics). New York: Dover Publications,

2002. [2] Spitzner, Lance. Honeypots: Tracking Hackers. Boston: Addison-Wesley, 2002. [3] Kary, Tiffany. "Analysts poke holes in security sector." CNET News.com, July 6,

2001. [Online] Available: http://news.com.com/2100-1001-269565.html. [Accessed: Sep. 7 2006].

[4] Bugtraq Mailing List. Security Focus. [Online] Available: http://www.securityfocus.com/archive/1. [Accessed: July 8, 2006].

[5] Honeywall. "Honeywall CDROM". Honeynet.org. [Online] Available: http://www.honeynet.org/tools/cdrom/. [Accessed: Aug. 26, 2006].

[6] Honeynet Project. "Know Your Enemy: Sebek". Honeynet.org, Nov. 17 2003. [Online] Available: www.honeynet.org/papers/sebek.pdf. [Accessed: Aug 26, 2006].

[7] VMWare Server. VMWare. [Online] Available: http://www.vmware.com/server. [Accessed: Jan. 11, 2007].

[8] OpenDNS. OpenDNS. [Online] Available: http://opendns.com/. [Accessed: March 9, 2007].

[9] Honeynet Research Alliance. "Honeynet Research Alliance Charter". Honeynet.org. [Online] Available: http://www.honeynet.org/alliance/charter.txt. [Accessed: July 2, 2006].

[10] Gómez, Diego González. "Installing a Virtual Honeywall using VMware" Spanish Honeynet Project, Nov. 14, 2004. [Online] Available: http://www.honeynet.org.es/papers/vhwall/. [Accessed: March 9, 2007].

[11] Damn Small Linux. DSL Information. [Online] Available: http://www.damnsmalllinux.org/. [Accessed: Marc 9, 2007].

[12] Shankland, Stephen. "Ubuntu carves niche in Linux landscape." CNET News.com, Sept. 30, 2005. [Online] Available: http://news.com.com/Ubuntu+carves+niche+in+Linux+landscape/2100-7344_3-5886194.html. [Accessed: March 9, 2007].

[13] "problems with yum and roo." Secuirity Focus, Feb. 1 2007. [Online] Available: http://www.securityfocus.com/archive/119/458720/30/0/threaded. . [Accessed: March 9, 2007].