Honeynet Clusters as an early Warning System for
Production Networks
Sushan Sudaharan, Srikrishna Dhammalapati, Sijan Rai and Duminda Wijesekera
Information and Software Engineering, George Maoson University, Fairfax, VA 22030-4444
Abstract. Due to the prevalence of distributed and coordinated Internet attacks,
many researchers and network administrators study the nature and strategies of
attackers. To analyze event logs, using intrusion detection systems and active
network monitoring, Honeynets are being deployed to attract potential attackers
in order to investigate their modus operandi. Our goal is to use Honeynet
clusters as real-time warning systems in production networks. Towards
satisfying this objective, we have built a Honeynet cluster and have run
experiments to determine its effectiveness. Majority of the Honeynets function
in isolation, not sharing information in real time. In order to rectify this
deficiency, we built a federation of cooperating Honeynets (referred to as a
Honeynet cluster) that shares knowledge of malicious traffic. This paper
describes the methods in building a hardware assisted Honeynet cluster and
testing its effectiveness.
1 Introduction
Currently, numerous intrusion detection and prevention mechanisms exist to dissuade
and monitor malicious traffic. One mechanism to study intruder actions monitors
network probes and attacks using a single system, commonly referred to as Honeypots
[8]. Honeypots are stand-alone software/hardware tools that share knowledge off-
line; the information obtained from such a collection of Honeypots must be correlated
manually. Currently, the Honeynets do not retaliate in real time and share each others
attack information.
In order to use Honeynet outputs for real-time counter actions (defensive or
ffensive), we built a hardware-assisted Honeynet cluster using a collection of
routers, firewalls, and servers, running various operating systems. Honeynet clusters
are a collection of distributed and cooperating Honeynets that function autonomously.
An intelligence-gathering module that will issue online alerts that can be fed to
security appliances of production networks to mitigate operational risks is also
deployed. Risk mitigation will be dependent upon the certainty and the severity of
alerts. It ranges from defensive actions, such as limiting access by dynamically
switching to more restrictive filtering policies at the border gateways, to offensive
actions as attacker tracing and/or counterattacking on identified targets. In order to
measure the effectiveness and turnaround time of our countermeasures, we calculate
the time it takes from attack detection, to notification to the subscribed Honeynets to
Sudaharan S., Dhammalapati S., Rai S. and Wijesekera D. (2005).
Honeynet Clusters as an early Warning System for Production Networks.
In Proceedings of the 3rd International Workshop on Security in Information Systems, pages 77-83
DOI: 10.5220/0002569700770083
the retaliation, i.e. the system logs the total time from attack detection to notification
to retaliation by the Honeynet.
The advantage of this approach is its ability to share knowledge about ongoing
attacks as an early warning system for multiple production networks. Our research
enhances existing work on distributed IDS systems, active networks, and sharing
knowledge (obtained from streaming data and defensive/offensive measures against
network attacks. Our goal is to study the degree of coordination necessary to identify
and respond to undesirable behaviours in networks, while simultaneously
altering/warning the production network about this behaviour.
The paper is organized as follows: Section 2 describes the design and functionality
of our Honeynet; Section 3 describes the software modules developed for our
Honeynet and preliminary experiments; and Section 4 summarizes the paper.
2 The honeynet
Fig.1. Honeynet
The physical design of our Honeynet is shown in Figure 1. The following are the
basic hardware components:
1. Cisco products (one each): 7204 VXR router, 2950 Switch, PIX 515E – Firewall &
VPN and PIX 501 – Firewall
2. Ten Gateway 935 series servers, four 1U Penguin Computing servers and 2 Sun
ultra spark servers
3. One Arbornet network traffic generator and one terra byte storage server.
As shown in Figure 1, the Internet is directly connected to the Cisco PIX 515E.
The DMZ (DMZ 1) on the Pix is connected to a Cisco 2950 switch. DMZ 1 hosts all
applicable servers. Two ports on the Cisco 2950 are configured as a Span port. The
server hosting Snort is connected to the Span port. This port is also shared by the
Dell Terra byte storage server. The Arbornet traffic generator is located behind a
second firewall (Cisco Pix 501) and will be generating simulated traffic on the DMZ.
Services and transactions are all simulated, and multiple web servers will generate a
high volume of transactions in order to make tempt an intruder even more. In
addition, several email servers with IMAP and other mail protocols are as a number of
attacks are carried out through email and related services.
The Cisco PIX 501 Firewall, shown in Figure 1, is configured to send traffic only
outside the system, masking the traffic generator behind the firewall. The PIX 515
Firewall uses 3 interfaces as described below:
1. The first interface used is for DMZ 1. Logging and monitoring is performed
through the span port connected to the Cisco 2950 switch. The information from
this port is parsed and passed to our monitoring system. SNORT [1] Tcpdump
[2], and various other tools are then used to analyze the network traffic.
Analyzing this traffic, and the actions taken in response to it, is described in
Section 3.
2. The second interface is connected to the existing lab that consists of two functional
areas. The first functional area consists of personal computers connected to the
internet. The second functional area is relegated to other experiments and is
separated by a firewall which isolates it from the rest of the network.
3. The outside interface is connected to the internet.
4. Traffic flow policies are implemented using different filtering rules on the
firewalls. For example, in the current design, the policy we implement is as
Allow HTTP, SMTP, ICMP etc. to enter into DMZ 1 on the Pix 515E
• Only allow established traffic into the Inside interface of the Pix 515E
• Do not allow any traffic into the Pix 501 from outside
The experiment will measure the effects of multiple policies on different hardware
devices and how they dynamically switch according to specific security requirements.
In this manner, the Honeynet can be customized dynamically. Dynamic changes in
policies can be used in response to the traffic that is already in the Honeynet or
contained in data received from external resources.
A Linux server connects the Internet to the Honeynet. The decision maker box
detects the attack and sends notification to remote system. A smart algorithm
integrated into the decision maker box accomplishes the notification task. A
communication system required to collect data has also been developed to
communicate between distributed entities (either between Honeynets or from a
Honeynet to a production network) using Java.
The test first calculates the timing delays in the data sharing mechanism that alerts
a client system, instating a new policy to safeguard itself. This is accomplished by
sending a flag through a VPN connection. PIX 515E firewalls can sustain traffic
associated with a small office environment. A flushing mechanism implemented at
the firewall base, addresses the undetected flooding attack causing the Denial of
Service (DOS or clog) on the system. In order to solve the DoS problem, as
suggested by the test and review material from Cisco and other router vendors, we use
the clear arp command to flush the ARP cache [3] in the PIX 515 firewall. Our initial
tests with one DoS Attack tool (using our Arbornet Traffic generator) support this
proposal. We have tested this architecture and quantify its ability to withstand DoS
attacks by devising mechanisms that flush them during high traffic periods.
3 Modules
Fig. 2. Honeynet cluster with notification facilities
Since the primary objective is to use the data, obtained from the Honeynet, to
secure production networks, we developed a number of modules to support the
Honeynet infrastructure to collect, understand and react to ongoing traffic in the
Honeynet. Figure 2 shows how they are connected to the Honeynet through the span
port on the Cisco 2950 switch. This allowed us to capture all traffic on the Honeynet
segment, with two data collection points.
3.1 Data Collection and Analysis Module
Independent of the physical technique and the physical location, network traffic
comes in the Pcap [4] format. The libpcap [5] library is able to read data in this
format. TCPDUMP [2] is popular software used to read Pcap data streams;
TCPDUMP can be redirected to another application or stored for forensic analysis.
Alternatively, many analyzers have their own libpcap-based packet capture capability,
for real-time analysis. We used TCPDUMP data for flow-based analysis and real-
time packet capture using the Snort [1] intrusion detection engine for signature and
anomaly detection.
Signature Based Analysis: Snort [1] is a popular open-source, easily extendable
network traffic analysis engine. The distribution includes a fairly broad set of rules
(i.e. signatures), and provides flexible language for custom rule generation. Snort
includes its own packet capture interface that can take the Ethernet feed off of the
switch’s span port, or can be configured to read a TCPDUMP data file. It also suits
the physical architecture. The rule set and configuration of the Snort engine is
managed from a remote console, and alert data is used in our reactionary module
3.2 Reaction Module
The purpose of this reaction module is to react to signals received from the Honeynet.
The setup is described in steps below:
1. A remote network was setup with a Cisco PIX 515E as the front-end firewall.
2. VPN sessions were established from our Honeynet to the remote site.
3. Attacks and probes were initiated against the Honeynet and different response
times were monitored. Once the attack was in session, it was monitored through
the span port in the Cisco 2950 switch.
4. The controlling software runs in the decision maker box sending out the signal
through the VPN tunnel to the remote listening agents.
5. The decision maker box located on another production network, analyzed the code,
made a decision, and initiated appropriate actions.
6. This experiment was repeated numerous times with multiple network parameters,
and host based vulnerabilities.
7. The latency of the whole transaction was measured under different conditions, and
was optimized.
3.3 Even Handling Module
In order to manage the online alerts and reaction modules, an agent system using Java
is implemented. This system uses Java Message Server (JMS) to send messages
between systems. All the Detecting Agents send notifications to the Java Decision
Maker (JDM). This JDM is highly configurable so that it is possible to setup the JDM
to respond to various alerts differently. The primary function of the JDM is to send
JMS Messages to the JMS Server. Currently we are using OpenJMS, which is an
open source implementation of JMS specification. It will be easily replaceable with
other JMS implementations in the future.
Finally, Java Listening Agents (JLA) completes the response process. The
JLAlistens on the JMS server for anomaly events. These events are classified based
on different queues and topics to which they are sent by different JDMs. The JLAs
communicate with the JMS through the VPN connection and are guaranteed by the
JMS to receive the messages they are interested in. The JLAs process these messages
differently depending on their setup parameters. For example, a JLA that is intended
to change firewall settings in response to a particular alert will change the
configuration on the system it is running on.
3.4 Java Module
Event handling module process data streams from the Honeynet, will also process
data from more than one Honeynet. We developed a collection of Honeynets as a
source of warning systems and data collection points to expand the capabilities of our
decision-making unit to support information gathered from a cluster of Honeynets.
The following set of instructions then measures the time (represented by To….Tn)
taken from detecting an attack to notifying the subscribed Honeynet group:
1. ICMP packets of varying sizes transmitted from the loopback interface ( on
the 2621 router in the “internet” to the “target box” ( Initially, all ICMP
packets delivered without any problem.
2. The “attack box” ( started the DoS Attacks (targa and cyclone)
against the “target box” at T0. This disrupts services to the target box, and the
ICMP from could no longer reach
3. Once the attack begins, the “snort box” on the inside network detects attack in real-
time and responds to it by informing the java decision maker at T1. The JDM
looks at the attack signature and informs the clients (i.e. JLA) through the java
message servers.
4. JLAs sitting at the remote location receive this message. It processes the message
and takes appropriate actions at T2. In this attack case, it starts a counter attack
(cyclone) on the “attack box”, thus, disrupting it. This allows the “legitimate”
traffic to proceed without hindrance.
For example, a time measurement was initiated at T0 and terminated at T1. Some
crude recording indicate a time of 0.95sec. Another time measure was initiated at T1
to T2; this recording is about ~ 1 sec. The whole turnaround time from attack to
notification to subscribed clients was 3.5sec. The sample timings were recorded in
the lab while performing real time logging.
4 Conclusions
In addition to network based and host based intrusion detection, Honeynets have been
used to collect information about malicious behaviour. We create a novel design of
Honeynet clusters, which we demonstrate, through its robust architecture and sample
experiment, as being viable as an early warning system for networks that require a
high degree of assurance. Our initial results show that under low loads we can react
in approximately 3.5 seconds.
To further understand the full functionality and capabilities of our unique system,
we are also experimenting with other add-on features to enhance the performance of
the Honeynet system. This includes modules that use the collected data to perform
data mining to detect the presence of new trends, as well as an intelligent agent that
allows the system to learn and be adaptive to recognize such events. One application
could be for the detection of new bots that crawl throughout the internet collecting
sensitive data.
An additional study may investigate the legal ramifications of un-consented
monitoring of transactions and implementations of possible hack-back rules. Our
cluster architecture automatically monitors traffic by parsing header information.
However, the reaction modules may need to take this activity beyond the headers,
perhaps involving tracing back to the offending traffic’s origin or hacking back.
Currently, all hacking back (or any activity against the intruder) has been performed
within the confines of a closed system. As outlined in [7], crossing legal boundaries
for the purposes of investigating or reacting depend upon inter-state and/or
international agreements. We are querying appropriately populated databases to keep
track of the legality of crossing network and political boundaries. As a secondary
objective, we parameterize invasive procedures so that the algorithms that enforce
them would succeed only if the calling instances result in legal combinations.
1. http://www.snort.org
2. http://www.tcpdump.org/
3. http://www.cisco.com/en/US/products/sw/secursw/ps2120/products_configuration_guide
4. http://www.tcpdump.org/pcap.htm
5. http://www.tcpdump.org/changes/2003-11-13.02:21:40.html
6. http://richie.idc.ul.ie/eoin/SILICON%20DEFENSE%20-
7. Wingfield, T. C. The Law of Information Conflict: National Security Law in Cyberspace.
Falls Church, Va. Aegis Research Corp., 2000.
8. http://honeypots.sourceforge.net/