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. 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

1
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.

2
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.

3
 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.

4
 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.

5
 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

6
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.

7
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].