According to the Honeynet Project and Research Alliance, a honeynet is a tool that can be used to learn about targets, and methods and tools used by intruders to attack a system. It has a network of systems that are designed to be compromised.

Conceptually, honeynets are very simple networks. These contain one or more honeypots. Since honeypots are not production systems, the honeynet itself has neither production activity nor authorised services. As a result, any interaction with a honeynet implies malicious or unauthorised activity. Any connection inbound to the honeynet is most likely a probe, scan or attack. Any unauthorised outbound connection from honeynet implies that someone has compromised the system and initiated outbound activity.

Fig. 1: Honeynet Generation-III architecture
Fig. 1: Honeynet Generation-III architecture
Fig. 2: Honeywall components
Fig. 2: Honeywall components
Explore Circuits and Projects Explore Videos and Tutorials

A honeynet is an architecture. This architecture creates a highly controlled network, which can control and monitor all the activity that happens within it (Fig. 1). The system administrator places target systems, or honeypots, within the architecture. In many ways, a honeynet is like a fishbowl. It is an environment where anyone can watch everything happening inside it.

Honeynets are used to build anti-virus signatures, spam signatures and filters, identify compromised systems, assist law-enforcements authorities in tracking criminals, hunt and shutdown botnets, collect and analyse malware, and detect zero-day attacks.

To successfully deploy a honeynet, it is necessary to correctly deploy the honeynet architecture. The key to the honeynet architecture is a honeywall. This is a gateway device that separates honeypots from rest of the world. Any traffic going to or from a honeypot must go through the honeywall. Gen-III honeynets implement a new data model independent of the data source—according to the paper ‘Towards A Third Generation Data Capture Architecture for Honeynets’ by Edward Balas and Camilo Viecco presented at Proceedings of the Sixth IEEE Information Assurance Workshop in June 2005.

Tracking hackers’ activities using honeynets
To monitor and track malicious activities, a system or networked environment is needed where at each place from the network to the host system every activity is gathered. Honeynets are used because no other honeypot solution can gather more information about an attacker. As a high-interaction technology, honeynets gather information not only on attacks but the attackers themselves. Honeynets can gather every information concerning the attackers, from their tools to their keystrokes.

58Z_box

Honeynets are not limited to a single operating system or software solution. According to the requirement, any system (software or hardware) can be placed within the honeynet architecture. Administrators can place a Linux Web server, Windows fileserver or Mac OSX desktop within a honeynet and monitor it. Honeynet architecture has very few limitations. Also, honeynets can create an actual network. A system administrator can place as many systems as he wants, creating an actual networked environment.

READ
Smart Engineering, Driven By Consumer Needs

Honeywall
Fig. 1 shows where a honeywall is usually placed in the honeynet architecture. The honeywall can be considered as the main point of entry and exit for all the network traffic for all honeypots. It allows complete control and analysis of all the network traffic to and from a honeynet system.

A honeywall does not have any IP address. Hence it works in hidden mode to the Internet cloud. Most hackers want to know as much as possible about a network, mainly to figure out whether any firewall or intrusion detection system is detecting their movements. If the honeywall has an IP address, the hacker will know that there is a firewall, intrusion detection system or honeywall in front of the bait systems. In third-generation honeynet architecture, the honeywall works in a bridged environment in which a remote hacker would have no idea that traffic is passing through a honeywall.

Fig. 2 shows the various components of a honeywall

Data control. Its main purpose is to ensure that the honeywall goes un-noticed and protects rest of the Internet from compromised honeynet ‘bait’ systems. The challenge is implementing data control while minimising the chance of it getting detected by an attacker or malicious code.

Various mechanisms can be implemented to protect against a single point of failure, especially when dealing with new or unknown attacks. Also, data control should operate in a fail-closed manner. This means, if there is a failure in the administrator’s mechanisms (process dying, hard drive full, misconfigured rules), the honeynet architecture should block all the outbound activity.

Bridging. As discussed earlier, the honeynet has to be as anonymous as possible to the remote hacker. To achieve this, honeywall is kept hidden by not assigning any IP address to it.

Data capture. It is the monitoring and logging of all of the attacker’s activities within the honeynet. The captured data is then analysed to learn the tools, tactics and motives of attackers. The challenge is to capture as much data as possible without the attacker’s knowledge. It is critical to use multiple mechanisms for capturing the data.

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.

READ
Lightning has a very specific waveform, it is very important to know its characteristics to design circuit protection

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 (https://projects.honeynet.org/hflow).

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

READ
The new standard IECQ HSPM 80000 is an ideal approach to adopt system-level compliance

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

LEAVE A REPLY