Reverse Deception: Organized Cyber Threat Counter-Exploitation (72 page)

A honeynet is a grouping of honeypots. Honeynets are based around high-interaction sensors, which are simply real system servers, workstations, and network devices designed to look like legitimate production systems. Honeypots are customized with configurations that provide adversaries with interesting findings that could steer them to the honeypot versus an operational system. Through this high interaction, you can gain intelligence on threats, both internal and external to an organization.

Conceptually, honeynets are configured to host one or more honeypots integrated within production assets to serve as false targets to adversaries. Since honeypots are not production systems, the honeynet itself has no production activity and no authorized services. This state of the honeynet implies that any interaction within the honeynet/honeypot is unauthorized and malicious in nature. Through the use of honeynets, all unauthorized or malicious activity at the network and host/session level can be detected, analyzed, and acted upon, without risking production or critical system assets. This makes analyzing activity within your honeynet very simple.

With traditional security technologies, such as firewalls, IDSs, and IPSs, an analysis of the interaction needs to identify malicious activity hidden within normal and routine enterprise network traffic. This level of analysis can increase response times significantly to the point that it could take days or even weeks to identify potentially malicious activity. With a honeynet, all traffic inbound and outbound is considered malicious in nature, and can be quickly and cleanly analyzed. Honeynets increase an organization’s ability to identify and respond to malicious activity, and the clarity of information provides an extremely low number of false positives and false negatives.

Honeynets are an architecture operating within a tightly controlled network, which can be monitored and controlled locally or remotely. A honeynet is like a terrarium, where you can create a custom network environment and watch everything that is happening within the network. This clean view of the malicious activity is very helpful for prioritizing which events are higher level threats than others.

Honeypots can be made up of any type of networked system with applicable network services, user accounts, and content, which are used to interest adversaries and ensure they spend as much time on your honeypot as possible. Honeynets have a simple architecture by nature. However, when operating multiple honeynets across geographically dispersed locations, issues can arise due to the limitations of the currently available open source products. At this time, the available open source suites of honeynet technologies are in their third generation; the fourth generation is in the planning and limited development phases.

The sole purpose of a honeynet is to be compromised while keeping an adversary away from production or operational systems. This provides the honeynet operators with a full-impact analysis in a target-rich environment without threat to their operational systems. A honeynet’s main goal is to detect and monitor adversaries attempting to gain intelligence or extract critical information from a victim organization.

Honeywalls

To successfully deploy a honeynet, you must correctly deploy the honeynet architecture. The key to the honeynet architecture is what we call a
honeywall
, which is the accreditation boundary for honeynets. This is a gateway device that separates your honeypots from the rest of your production network. Any traffic going to or from the honeypots must go through the honeywall. This gateway is traditionally a layer 2 bridging device, meaning the device should be invisible (on a TCP/IP level) to anyone interacting with the honeypots.

Figure 8-1
shows a diagram of the honeynet architecture. Our honeywall has three interfaces. The first two interfaces (eth0 and eth1) are what separate the honeypots from everything else; these are bridged interfaces that have no IP stack. The third interface (eth2, which is optional) has an IP stack allowing for remote administration.

Figure 8-1
Generic honeynet

There are several core requirements that a honeywall must implement:

Data control
This defines how activity is contained within the honeynet without an attacker knowing. Its purpose is to minimize risk to production systems.

Data capture
This refers to capturing all of the attacker’s activity without the attacker knowing it.

Data analysis
This is the ability to analyze this data.

Data collection
This is the ability to collect data from multiple honeynets to a single source.

Of all these requirements, data control is the most important. Data control always takes priority because its role is to mitigate the risk associated with implementing honeynets. The following sections describe each of these requirements in more detail.

Data Control

The data control component serves to control inbound and outbound flows to the honeynet to reduce risk. The risk assumed by the implementer is the possibility of an attacker or malicious code using a honeypot to attack or harm systems that are not part of the honeynet. It is critical to ensure that all flows between the honeynet and external IP addresses are controlled in the event that an attacker or malicious code attempts to abuse the resources of the honeynet. Data control is performed using several features within the honeywall that are implemented together in order to attempt to mitigate risk.

The following are the primary data control functions of the honeywall:

Layer 2 bridging
At this layer, the honeywall bridges a honeynet to a production network, thereby obfuscating the extension of the production network to include the honeynet, as depicted in
Figure 8-1
.

Inline IPS
This module, better known as Snort inline, attempts to prevent malicious activity crossing the layer 2 bridge in and out of the honeynet. This IPS is an open source module and is only as good as the signature set it is currently running. It is implied that in order to provide the maximum amount of protection possible, the signatures need to be updated as regularly as possible.

Inline IDS
This module, better known as Snort, provides a passive data-control mechanism that enables implementers to simply identify and respond to malicious activity. This module also monitors the flows going through the layer 2 bridge, but it will not modify and/or prevent identified malicious activity