Data is captured at various layers. The more the layers of information captured at both the network and host level, the more can be learned. One challenge of data capture is that a large portion of attacker activity happens over encrypted channels (such as IPSec, SSH and SSL).

Data analysis. The entire purpose of a honeynet is gathering information. Honeynets are worthless if they are unable to convert the collected data into information. Security analysts must have some means to analyse the data. Different organisations have different needs, and as such different data analysis requirements.

Data collection. It applies particularly to organisations that have multiple honeynets in distributed environments. Most organisations will have only one honeynet, called a standalone deployment. Organisations that have multiple honeynets logically or physically distributed around the world have to collect all of the captured data and store it in a central location. This way the captured data can be combined, exponentially increasing its value.

Data collection provides a secure means of centrally storing all of the captured information from distributed honeynets. Honeywall stores most of the fused data (refer Fig. 2) in the database called Hflow—according to The Honeynet Project (

Fig. 3 depicts components of a honeypot. A honeypot is a simple host where an attacker can interact through his malicious activities. To track the activities, data capture, including attacker’s logged-in session and keystrokes, is needed at this level too.

Tools for data capture
To track hackers’ activities, the analyst must understand honeynet data capture possibilities. Honeynet tools required for data capture at network and host levels are:

Data capture at network level. The hacker’s inbound and outbound traffic is gathered while monitoring his activities. The various tools required for network data capture are:

Full network packet data capture (inside/outside). It involves data capture at the bridge layer (or at span/monitored port).

Passive OS fingerprinting (pOf). It involves advanced passive OS/network fingerprinting utility for use in intrusion detection system environments, honeypot environments, firewalls and servers.

Network intrusion detection/prevention system. A network intrusion detection application that is commonly used is snort. The honeywall needs to prevent harmful traffic to the Internet while listening on the internal (honeynet side) interface. The common snort implementation uses the opposite methodology in which snort tries to detect harmful traffic coming from the Internet while listening on the external (Internet side) interface.

Another objective of the honeywall is to be proactive in stopping harmful attacks out to the Internet. It is important to reiterate that the honeynet objective is to let hackers in but not use a compromised system to attack Internet clients outside the honeynet. Because of this proactive requirement, a hybrid snort application named ‘snort_inline’ was developed. Snort_inline is referred to as a network intrusion prevention system.

Data capture at host level. Sebek is a data capture tool designed to capture the attacker’s activities on a honeypot, without the attacker knowing it. It has two components. The first is a client that runs on the honeypots. Its purpose is to capture all of the attacker’s activities (keystrokes, file uploads and passwords), then covertly send this data to the server. The second component is the server, which collects the data from the honeypots. The server normally runs on the honeywall gateway, but it can also run independently.

Tracking hacker’s activities—an example

Fig. 3: Honeypot components
Fig. 3: Honeypot components

Sebek data is correlated with data captured from the network traffic. The network activities are collected by the honeywall using tcpdump network sniffer. These events are processed by different tools: Snort intrusion detection system provides malicious traffic identification, pOf performs OS fingerprinting and Argus is used for flow monitoring. The data from all these sources is unified and correlated in a relational database. The data correlation is supported by an Hflow database and pcap application programming interface that is used for packet capture manipulation.

Roo Web-based graphical interface, known as Walleye, allows one to display and analyse all the data captured and correlated by the honeynet. Typically, an intrusion is initially discovered through the detection of suspicious network events.

Fig. 4 shows Walleye’s capabilities to display network traffic details detected by the honeywall. This example shows a Linux honeypot compromised through the ‘trans2open’ Samba buffer overflow. The incident handler should start the incident investigation with a network traffic analysis.

Fig. 4: Walleye snapshot of tracking malicious activities
Fig. 4: Walleye snapshot of tracking malicious activities

In this example, some interaction between system 192.168.X.X (owned by the attacker) and the honeypot at 192.168.Y.Y was detected. This network flow corresponds to TCP traffic with a source port of 1135 and a destination port of 45295. Several packets were exchanged in each direction and the traffic generated two different snort intrusion detection system alerts. The traffic seems to be related to process number 2340 on the honeypot.

Future work
Another likely benefit of the honeynet could be in the area of identifying new exploits and their signatures. Signatures could be developed for the intrusion detection system to protect against such exploits. To collect enormous exploits from different locations, an area for further research could involve the establishment of distributed honeynets across the country. A single honeynet system will not always be helpful in identifying routes of attacker. A distributed honeynet would greatly enhance the security capabilities of the honeynet. Also, this would help in identifying the routes and motives of the attacker more in-depth, which can lead to identification, monitoring and protection against distributed attacks.

The author is working in the Systems Engineering Group at Advance Data Processing Research Institute (ADRIN), Department of Space, as Scientist/Engineer ‘SC,’ developing applications in the fields of network security and secure programming language design and implementation



Please enter your comment!
Please enter your name here