Honeynets: Implementation and testing of a honeynet to

verify a network’s security condition

Project - CSC/ECE 574
Panos Kampanakis, Michael Kallitsis, Professor Douglas Reeves
Dept. of Electrical and Computer Engineering
North Carolina State University
{ pan_kamp, mgkallit }@ncsu.edu

Abstract
Computer networks are so widely used in everyday life that it is almost certain that they will

continue to be so popular for the years to come. This makes network security very significant for the

safe continuation of network systems and the services they provide. To ensure it, many different

Intrusion Detection Systems (IDS) and techniques have been developed the past decade. At the same

time, there is also the useful Honeynet Project that could always provide network engineers with

further knowledge and information about different ways malicious users could come up with in order

to misuse network systems. Not to mention the educational value of Honeynets. Thus, we could say

that IDSes and Honeynets should be used in parallel to complement each other and help us built

sophisticated techniques of protecting our networks. In our approach we will implement a

demonstrative virtual Honeynet and use it in a network to collect some useful attack data.

Keywords
Honeynet, honeystick, honeywall, Sebek, data analysis, open source
Introduction
Below we will present a general overview of Honeynets. We will provide the background and

then give basic information about the implementation we have done in our project. Afterwards we

will be able to present our project in more detail.

Background
Computer networks have indisputably changed communications worldwide. There are

numerous examples someone could use to argue that advances in network technology have changed

the way people communicate and keep up with their everyday responsibilities, like video

conferencing, e-banking and many others. On the other hand, a number of different attacks and

possible ways of exploiting systems’ vulnerabilities have been invented by crackers in order for them

to achieve their goals. Since then, there has been an everlasting battle between the two “parties” to

outperform each other. Network Engineers have come up with various ways to protect their systems

and make sure they are secure whereas intruders try to overcome the new obstacles each time. This

led to the invention of various Intrusion Detection Systems (IDSes), used to prevent malicious users

from messing with network resources without being noticed.

The best way to defend ourselves from an enemy is to find out how that enemy acts and what

the possible attacks he can launch are. Therefore, should we want to defend our networks and our

systems from malicious attacks, we have to find a way to identify what these attacks could be. A

clever and efficient proposal to achieve that is to deploy a Honeynet.

The last five years a Research Project is taking place in many countries and Universities

(including UK, Spain, Greece and Georgia Tech Univ.) called The Honeynet Project. The idea behind

it is to have a few low cost computers, called Honeypots, in a network called the Honeynet. These

nodes play no role; they aren’t used by anyone and are there only to attract possible attackers.

Besides, they are behind a Honeywall which makes sure that the Honeypots aren’t exploited for

malicious purposes. Every Honeypot runs a “transparent program” called Sebek [2] client that collects

data and sends it to the Honeywall Sebek server to be analyzed. The important issue is that any kind

of traffic created from the Honeypots is suspicious because Honeypots serve no purpose. Every day,

2
the project stuff makes sure it spends time analyzing the data and understanding what attackers have

done or tried to do. The advantage is that the attackers can’t see Sebek (or at least it is hard to do so)

and so the analyzers can use the data collected to find out possible approaches of how systems can be

forged. In that way, we can constantly get information and be able to improve our systems by

watching what vulnerabilities intruders take advantage of. There is a lot of serious and hard work that

has been done in the Honeynet Project and many brilliant means of attack have been observed.

However, it is beyond the scope of our proposal to present them [1].

The Honeynet Project has an open-source philosophy and has no purpose of incriminating and

catching the attackers. On the contrary, they believe that they can learn from them and so they try to

use their knowledge to improve our systems. What’s more, the information gained can and has to be

used and published by everyone. Only then will we be able to help others and by helped by them to

create more secure networks.

Implementation
In this project we built and tested our own virtual Honeynet. Our goal was to implement and

use it to attract the so called “black hats”, i.e. the deleterious crackers that want to hijack our system.

Having information about the crackers and their tools would help us build a better security mechanism

for our home network. This constitutes our ultimate destination; proof that our local network is under

continuous attack and finally identification of these attacks so as to help us defend ourselves against

crackers. At the same time, we will have the opportunity to gain experience on identification of

attacks, intrusion detection and network security.

Since there was lack of resources we decided to use a virtual machine to deploy the Honeynet.

So, we used one personal computer and installed VMWare Workstation on it. The VMware

Workstation is a software package that gives its users the opportunity to create virtual machines that

constitute virtual networks interconnected with each other. Thus, we created the Honeynet as a virtual

network seen from the outside world as an independent network. Attackers could locate the Honeypot

and attack it. The Honeypot was transparently connected to the Internet through the Honeywall which

in turn intercepted all outbound and inbound traffic. Therefore, malicious traffic targeting the

3
Honeypot (inbound) or malicious traffic generated by the compromised Honeypot (outbound) was

available to us from the Honeywall for further analysis and examination. What’s more, the Honeywall

prevented the crackers from attacking machines of the outside world by limiting outbound

connections, closing ports and decreasing connection data rates. In that way, we managed to have

attackers in a virtual machine without worrying about them harming other machines too.

After successfully implementing the network, we decided to leave it connected to the Internet

for a considerable amount of time in order to collect attack data. Of course, we checked on it

periodically to make sure that the network is working properly, that the Honeywall serves its purposes

and to examine the data collected. After two weeks, we were able to make some conclusions about the

intruders, their means of intrusion and also the vulnerabilities of the Honeypot Operating System.

Moreover we tested our only Honeypot by visiting some web sites, pinging some machines and

observed these pre-planned actions in the Honeywall log. In addition we used Walleye, the

Honeywall’s web graphical user interface to analyze data.

Overall we can say that the project provided us with very useful security experience. Not only

we learned how to configure a basic Honeynet but we also gained experience in analyzing malicious

data, identifying attacks and we came across with some of the common vulnerabilities of operating

systems that attackers exploit worldwide.

Implementation details
Below we present the details of the implementation and configuration of the Honeynet. After

introducing and describing the network architecture we go into the details of how we set up the

connections and the nodes.

Architecture
The architecture of our Honeynet is shown in the figure below. As we have already

mentioned, the whole Honeynet was implemented using VMWare Workstation on a single Pentium3,

512MB RAM personal computer running Windows XP SP1. The operating system of that personal

computer is referred as host operating system in Figure 1. The host machine was connected to our

home router and accessed the Internet through it.

4
 We created two virtual machines in VMWare, called Honeypot and Honeywall. The

Honeypot booted from an iso-image of Damn Small Linux (DSL), which provides a basic Linux

environment, with the options:

dsl 2 ssh ldp ftp nfs syslog monkey

Besides, we added a host-only Ethernet NIC on it. This card will connect it seamlessly to the

Honeywall and will look like the interface that takes it through to the outside world. Its IP

address/mask and gateway information are shown in Figure 1.

local router

24.x.x.x 192.168.0.1/24

192.168.0.199/24
Host Operating System
Internet

bridged
192.168.0.198/24
eth2 gw: 192.168.0.1

192.168.0.189/24
bridged gw: 192.168.0.1
eth0 eth1 eth0

Honeywall Honeypot
Fedora core 3 Damn Small Linux

Figure 1: Our Honeynet Architecture

As far as the Honeywall is concerned, it also boots from an iso-image. Its operating system is

a Fedora Core 3 stripped by the Honeynet Project to serve as a GenIII Honeywall. It has three

Ethernet NICs, two if which (eth0 and eth1) are bridged to the host computer’s NIC and the other one

(eth2) is host-only. Eth0 is the interface that will transparently capture traffic before reaching the

Honeypot. Eth2 is the interface for the remote management of the Honeywall. Finally, eth1 is

connected to the Honeypot and forwards traffic heading for it to it. The IP configuration can be

observed in Figure 1.

It is also worth mentioning that we used our router to put the Honeypot’s IP in the

demilitarized zone (DMZ) of our network. That’s because, since we are using a router-firewall/NAT

in our LAN it would have been difficult for the attackers to break into the Honeypot if it wasn’t

5
outside in the DMZ. What’s more, we are using port forwarding to make the Honeywall Management

Interface accessible through the Internet.

Configuring the Honeynet

After setting up the VMWare environment we booted both the virtual machines. In Figure 2

we can see how our Honeypot looks like. As we have previously discussed, our Honeypot runs a

Damn Small Linux operating (DSL) system. DSL was chosen because it has limited capabilities and

as a result it is not a “heavy” operating system. Otherwise, the VMWare workstation (installed on a

PC with only 512MB RAM) would not be able to run both the Honeywall and the Honeypot. After the

boot process we used the Netcard config tool of DSL to set the IP, the mask, the DNS server and the

default gateway of the system.

Figure 2: Damn Small Linux virtual machine

On then other hand, when the Honeywall is booted we have to configure it first. So we follow

the regular procedure described in the literature [6]. We start by setting the IP addresses, the masks

and the DNS servers of the Honeypot and Management Interface of the Honeywall. Then we

configure ssh access of the Management Interface, the connection and port limitations, inbound and

outbound, snort inline, computers that have access to the Management Interface, others that will be

allowed or blocked towards the Honeypot, DNS limitations for the Honeypot, Sebek parameters, and

also the alerting scheme(we set it to send e-mails to our e-mail address).

Some snapshots of the initial configuration of the Honewall are seen below.

6
 Figure 3: Honeywall configuration

Right after it is configured we log on to it as root and set the IP, mask and default getaway using the

commands:

ifconfig eth<i> <IP address> netmask 255.255.255.0

route add eth<i> default gw 192.168.0.1

So, at this point we have our Honeynet configured. The connections are made accordingly,

the Honeyot and Honeywall are set up and we can wait for attackers to arrive. Then we left the

network intact for more then a week and we just observed its captured traffic data and made sure of it

being functional. After almost two weeks had passed we started examining the data more closely

trying to analyze intrusion attempts.

7
Testing
As long as our environment is set up properly we are ready to monitor traffic and observe

others trying to use our resources, hack our machine or make it crash. As mentioned above, since the

Honeypot is serving no purpose and is used by nobody, any kind of traffic going to it or coming from

it is suspicious. In more detail, inbound traffic equals to attempts to attack and use the Honeypot and

outbound traffic means that our machine has been compromised.

We used the Honeywall’s web interface in order to check the inbound and outbound traffic.

First we set our home router to forward https traffic to the Honeywall’s management interface

IP(198.168.0.198). So, then by using a browser and writing https://24.x.x.x (where 24.x.x.x is the

public IP address given from Internet Service provider, see Figure 1) we were able to see the log-in

welcome screen of the Honeywall.

Figure 4: Log in screen

Then we logged in and we got the screen showing the Honeywall and an overview of the

activity so far. The connections of the last hour and last 24 hours, a graph showing the outbound

malicious activity in general and a search utility that will provide a query on the packets captured

according to our criteria (Figure 5). Results will be provided in an Ethereal file we can store for

further investigation.

8
 Figure 5: General overview of activity

We also have the opportunity to examine all the flows per day for any day we want (Figure

6). In the relevant screen you can see the different IP addresses, the alerts, the number of packets and

bytes. So we can make out the IP addresses that were more active against the Honeypot.

Figure 6: Aggragated results for one day

Moreover we can focus on one flow for a particular IP address (Figure 7). There we can

observe the packet sequence and their information.

9
 Figure 7: Detailed information for a flow concerning a particular IP

Besides the aforementioned utilities, the Management Interface provides us access to the

Honeywall configuration (Figure 8). So, all the settings we saw on the previous section can be

updated from the web too. There we can check the status of the system, set the parameters, see the

alerts, change Sebek and Snort rules, see the active connections and running processes and many

more.

Figure 8: Honeywall configuration screen

Data Analysis
So, after we became familiar with the user interface we started analyzing traffic. An important

fact is that we could observe attacks only after a few minutes (approximately 5min) our Honeypot

entered the Internet, which proves what we expected, that our computers are constantly under attack.

10
Malicious nodes continuously scan for IP addresses and move against them all the time. Thus,

security for our machines is of great importance and not trivial in any case.

We examined the IP addresses of the attacker nodes and we found out that they were

constantly changing. This means that in some cases the packets arriving that were trying to impose a

threat might be spoofed so as not to be able to identify the attacker. But even if they weren’t spoofed

we can’t be sure that the attacker is using his computer to crack or he has take over another pc and

using this as his fortress. The most common activities were UDP and TCP port scans. They were

probably from intruders trying to check for certain vulnerabilities of OSes. Other attacks included

TCP SYN flooding, MS-SQL buffer overflow and MS DoS attacks.

The basic attacks we observed from the pcap files were analytically:

• UDP port scan

Port scanning usually means scanning for TCP ports. Nevertheless, there is also UDP

scanning. In this case the attacker sends empty UDP datagrams. If a port is listening, the service

should send back an error message or ignore the incoming datagram. If the port is closed, then most

operating systems send back an "ICMP Port Unreachable" message. Thus, you can determine which

ports are open. Such scans are more useful in case of services that are “hidden” in undocumented

ports higher than 32270. Indeed in the attacks we observed malicious users scanned ports in that

range.

• TCP SYN flooding

This is the well known attack where many packets are sent to a server to open many connections and

cause it to crash. Many attackers tried to implement this to the web service of our Honeypot by

sending TCP SYN packets, retransmission requests and duplicate acknowledgements.

• Microsoft-ds

That was a DoS attack against Microsoft’s Win2000 and Win2000 Server. The way it works

is by sending malformed packets to the microsoft-ds port (TCP 445) where kernel resources are

allocated by the LANMAN service. So, many such packets would be a significant burden for the

machine. The consequences of such an attack could vary from the Windows 2000 host completely

11
ignoring the attack to a blue screen. A very self-explanatory example of such an attack can be found

in http://www.securiteam.com/windowsntfocus/5YP0J206UQ.html and it includes the following

remark: “It would frequently be possible to cause the system service to enter a state where it

constantly uses 100% of its CPU time. A PC was left in this state over the weekend, to see if it would

recover on its own. It did not recover.”

• Epmap port scan

Epmap is similar to the previous attack. It has to do with port 135. This port is essential to

the functionality of Active Directory and Microsoft Exchange mail servers, among other things. It is

the number one most common attack point for virus and worm attacks world wide. Someone can use

regedit and connect to our server’s registry with no need to authenticate themselves if the remote

registry service is running. They can also connect to our disks if just port 135 is open. If they can

guess a password, or use a null session, they can actually do a lot. As we can find in

http://isc.sans.org/port_details.php?port=135 the epmap service is used from RootKits, RPC bug

exploiting worms, Blaster32 worm for propagation etc. So, checking epmap can be very important for

crackers that want to use it. Some of the consequences of an open 135 port can be buffer overflow and

DoS by causing two threads to process the same RPC request.

• MS-SQL

There attacks were on port 1433. It is the port used from MS SQL Server. So, if a machine

has SQL server installed it can receive a worm like SQLSnake which installs without a password an

SQL Server that can run batch files and command line programs. Besides that, this port has many

reported vulnerabilities like buffer overflows and incorrect permission on SQL Server service account

Registry Key (see more in http://isc.sans.org/port_details.php?port=1433)

• MS Messenger blaster, msn spam

In this attack, crackers were taking advantage of a service provided from Windows

Messenger. This service was originally intended to be used for broadcasting messages to many users.

Attackers using this kind of attack are called Messenger Spammers because they are trying to

advertise their products through that messenger service.

12
 So, attackers send a Messenger Protocol packet at any destination to port 1026 and they

include their spam message in the payload of that packet. Usually that message looks like the

following: "Critical System Error - Windows Registry appears to be infected. Go to regfixes.com and

download RegistryCleaner or Stop! Windows requires immediate attention. Windows has found

critical system errors. Run Registry Repair from fixwin32.com." If the victim runs Windows

Messenger on his PC, then that message will be displayed on his monitor. However, if the victim

doesn't run Messenger (as in our case with Damn Small Linux) an ICMP destination unreachable

packet is sent back to the initiator implying that the Messenger service was not available at the target

PC. Not to mention that there are cases where a patch from Microsoft is said to be wanted and the

message forwards us to a website that seems to be legitimate. Though, some case were reported where

the claimed patch was a Trojan horse (see http://isc.sans.org/diary.php?storyid=3).

• Zero window

There were also many cases where the supposed http server received a zerowindow message

from a client that had established a connection with it. In that way, the malicious user was trying to

waste resources on the server. By advertising the zerowindow, he asked from the server to wait

without closing the connection for a period of time until the client sends a new window size. Thus,

many collaborating clients could in that way waste the resources from the server by making him wait

and having the connection in idle state.

• Ping of Death

With this attack a malicious user can crash or reboot a large number of machines running

different operating systems. All he has to do is to send a ping message of a certain size from a remote

machine. This attack is so simple but yet so powerful. It exploits a common vulnerability of many

systems; these systems do not like being pinged with a packet greater than 65536 bytes. As we know

that kind of packet needs to be fragmented in order to be sent to the destination. When the fragments

are reassembled at the destination to form the complete packet, it will overflow the buffer on some

systems causing these systems to reboot or hang.

13
 Despite all the attacks we have described, there was no case where our Honeypot was

compromised. No outbound traffic was identified. This is probably because Damn Small Linux has

basic functionality. It doesn’t provide vulnerable services, so it isn’t that attractive to attackers.

What’s more, the VMWare environment is detectable; attackers do not like the idea of compromising

just a virtual machine. The solution for the latter is Costya’s (French Honeynet Project) patch which

hardens VMWare making them transparent (i.e. camouflage it) to crackers.

Following we have some snapshot of the Ethereal files that we used to monitor attacks. We

can see for example many port scans (Figure 9).

Figure 9: Ethereal file

14
The MSN spammer in purple messages is shown in Figure 10.

Figure 10: MSN Spammer

Cases where our computer is taken as WWW server and they are trying to deploy TCP SYN flooding

attack can be seen in Figure 11:

Figure 11: TCP SYN flooding, port scan

DoS attacks on port 445 (Microsoft-ds port) are identified in Figure 12.

Figure 12: DoS attack against Microsoft-ds service

Cases where the attacker is trying to waste resources by “pausing” the supposed server, the Honeypot

can be seen in Figure 13.

15
 Figure 13: Zero window

One of the alerting e-mails that we received at the end of one day was the following:

- traffic_summary.py 0.17(2005-07-20)

Report Settings:
- Honeynet: 192.168.0.0/24
- Starting Date: 20060414 (inclusive)
- Ending Date: 20060415 (exclusive)
- Number of days: 1
- Output file: /tmp/.sum.QgI12945

Total pcap records processed: 2,891

Total snort records processed: 33,379

========================================
Summary
=======

Remote IP Count: 199

Ports Scanned: 53

Connection Packets Packets Bytes Bytes

Type Count In Out In Out
-------- --------- --------- --------- --------- ---------
Inbound 300 698 130 109691 0
Outbound 54 204 204 132263 132263

Total Snort SIDs: 14

Total Snort Alerts: 33379

========================================
Top 10 Snort Alerts
===================

Count SID Alert Description

----- ------ ---------------------------------
32591 1384 MISC UPnP malformed advertisement
461 402 ICMP Destination Unreachable Port Unreachable
158 384 ICMP PING
78 408 ICMP Echo Reply
39 1917 SCAN UPnP service discover attempt
18 1653 WEB-CGI campus access
12 382 ICMP PING Windows
6 525 BAD-TRAFFIC udp port 0 traffic
4 16 (spp_stream4) TCP CHECKSUM CHANGED ON RETRANSMISSION (possible
fragroute) detection
3 2050 MS-SQL version overflow attempt
3 2004 MS-SQL Worm propagation attempt OUTBOUND

========================================
All Snort Alerts
================

16
Count SID Alert Description
----- ------ ---------------------------------
4 16 (spp_stream4) TCP CHECKSUM CHANGED ON RETRANSMISSION (possible
fragroute) detection
12 382 ICMP PING Windows
158 384 ICMP PING
461 402 ICMP Destination Unreachable Port Unreachable
78 408 ICMP Echo Reply
2 449 ICMP Time-To-Live Exceeded in Transit
1 486 ICMP Destination Unreachable Communication with Destination Host is
Administratively Prohibited
6 525 BAD-TRAFFIC udp port 0 traffic
32591 1384 MISC UPnP malformed advertisement
18 1653 WEB-CGI campus access
39 1917 SCAN UPnP service discover attempt
3 2003 MS-SQL Worm propagation attempt
3 2004 MS-SQL Worm propagation attempt OUTBOUND
3 2050 MS-SQL version overflow attempt

========================================
Top 10 Remote IPs:
==================

Remote IP Packets Bytes Conns

--------------- --------- --------- ---------
24.172.132.166 91 0 29
24.172.226.224 71 0 26
204.16.208.104 32 11616 13
24.172.161.186 36 0 12
193.216.54.115 20 1600 11
239.255.255.250 29553 8542950 11
24.172.95.206 27 0 10
67.72.8.94 119 50732 10
152.1.3.31 90 4770 9
4.79.24.30 43 7123 7

========================================
Top 10 Scanned Ports:
=====================

Port Packets Bytes Conns

--------- --------- --------- ---------
udp/1026 90 80189 85
tcp/445 156 0 53
tcp/135 87 0 27
tcp/139 71 0 24
udp/137 16 800 19
udp/61226 69 4566 18
udp/1027 13 4619 10
tcp/1433 17 0 5
icmp/0 1 48 5
udp/1434 4 1504 4

17
Another e-mail indicating malicious traffic (ping of death) is:

Apr/27/2006 02:03:57

Ping of Death Detect src:81.245.180.120:32951 dst:24.172.255.187:32459

Packet Dropped

Apr/27/2006 00:43:35

Ping of Death Detect src:81.245.180.120:33761 dst:24.172.255.187:32459

Packet Dropped

Apr/26/2006 23:57:55

Ping of Death Detect src:81.245.180.120:33539 dst:24.172.255.187:32459

Packet Dropped

As we can easily see, the preceding e-mails include the Remote IP addresses, the port scans, the Snort

alerts meaning the malicious activity reported by snort rules and more. Between the reported

information are of course the attacks we have previously analyzed from the Ethereal files. So, it is

some verification that what we made out from the captured traffic is consistent with what Snort

discovered.

Conclusions and possible future work

At this report, we have described how we implemented our own Honeynet. The purpose of

Honeynets is to discover the ways attackers use to crack our systems. From our personal experience in

this project we can say that Honeynets are necessary for IDSes. They provide very important

information and will certainly improve Security mechanisms in the future. Moreover, they will help to

improve security breaches and vulnerabilities of Operating Systems. They act in the attackers’ side

without him noticing, thus there is no reactive characteristics in them. They are purely preventive and

cost free to deploy. Overall, Honeynets, especially since they are constantly evolving and becoming

more functional and harder to detect, will undoubtfully be very useful in the future.

In this project we saw some of the most popular attacks, like TCP SYN flooding, MS-SQL

buffer overflow and port scanning, against OSes (mostly against Microsoft Windows). Another very

interesting fact is that a soon as a machine enters the Internet it is automatically susceptible to attacks

18
and compromisation. Unfortunately, since our Honeypot didn’t have full functionality/vulnerabilities

of an ordinary OS and wasn’t perfectly camouflaged we didn’t have as many intrusions and intrusion

attempts as we would expect. It was probably because intruders could be able to detect that they were

acting on a virtual machine or maybe because DSL doesn’t run all the vulnerable services other

Operating Systems like MS Windows run.

As future work, we would propose to further extend the project by implementing a real GenIII

Honeynet with full functionality (Sebek tools, Snort inline). This would help us identify and observe

some more severe and important attacks. We believe that a university like NCSU should definitely

implement its own Honeynet. Besides that, a close cooperation with the members of The Honeynet

Project would also be beneficial. In that way new susceptibilities of our systems could be shared

among these members and as a result our defense against crackers would become more and more

resilient. On the other hand, in addition to its ordinary use the Honeynet could also provide a good

practice experience for Security Information to the University’s students.

Acknowledgements
We would like to thank our friend Haris Volos from the University of Wisconsin - Madison for his

valuable support on issues regarding operating systems.

References
[1] The Use of Honeynets to Increase Computer Network Security and User Awareness – March

2005, available online: http://www.ece.gatech.edu/research/labs/nsa/papers/use_of_honeynets.pdf

[2] The Honeynet Project, “Know Your Enemy: Sebek,” – 17 November 2003, available online:

http://honeynet.org/papers/sebek.pdf.

[3] Know Your Enemy: Honeynets in Universities - 26 April 2004, available online:

http://www.honeynet.org/papers/edu/

[4] Honeystick HOWTO by David Watson available online:

http://www.ukhoneynet.org/honeystick.htm

[5] Installing a Virtual Honeywall using VMware by Diego González available online:

http://www.honeynet.org.es/papers/vhwall/

19
[6] Virtual Honeynet: Deploying Honeywall using VMware Faiz by Ahmad Shuja, available online:

http://www.honeynet.org.pk/honeywall/roo/

20