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

Fence list
This module is meant to provide implementers with a means to reduce risk to production systems or networks of a critical nature. The file /etc/fencelist.txt should contain IP addresses or network ranges that honeypots within the honeynet cannot communicate with at all.

Whitelist
This feature is meant to provide implementers with a means to allow specific flows to enter or leave the honeynet without being logged or monitored by the honeywall. This is typically reserved for trusted applications and/or connections that have very little value here beyond presenting realism within the honeynet, while reducing the amount of traffic to be analyzed by the implementer’s analysis team. For example, the whitelist could include a network’s domain security services, such as antivirus, host monitoring, asset management software, and/or any other type of network service that could be used to increase the realism of a honeynet.

Blacklist
This feature is meant to provide a network with the ability to implicitly deny access while logging all attempts made by a specific IP address or network range that is known to be malicious or poses a threat to the honeynet.

Rate limiting
This feature is meant to serve as a
throttle
for network traffic. Primarily, this was meant to prevent DOS attacks against systems external to the honeynet. It is capable of allowing traffic based on a period of time and/or a defined variable amount of traffic.

These features are typically configured during the initial setup of the honeywall and/or through the /etc/honeywall.conf file, which is where all of the honeynet environment variables are stored.

As we said earlier, the function of data control within a honeynet is by far the most critical component. If data cannot be controlled, data cannot be captured effectively. The most important item to remember is that you can never rely solely on data control to remove risk when implementing honeynets.

Data Capture

The data capture component of the honeynet logs all activity at the network and host level of the honeynet and honeypots. The honeywall is the primary network-based data capture component, and Sebek is the host-based (session-based) network capture component. These components combined are capable of providing implementers and analysts with in-depth information regarding specific flows and events within a honeynet. These components provide the ability to monitor and log all of the malicious activity within the honeynet.

It is the analysis of this captured data that provides details on specific tools, tactics, and motives of attackers. The most challenging effort when implementing honeynets is the ability to capture as much data about the activity without the attacker detecting the data capture components. The data is captured and presented in layers in order to simplify the data capture and analysis processes and procedures. Layering data also protects the overall data set by preventing any single point of failure of the honeynet. The more layers that are made available during the analysis processes, the more information an analyst can learn from the attacker.

The activities of attackers are hard enough to detect over operational networks due to the ability to obfuscate their methods within operational traffic. However, when these activities are captured within a honeynet, the analyst will have a clear picture of the attacker’s events and will be able to apply that information to the rest of the production network in order to quickly identify if that attacker has already penetrated protected assets.

It’s possible that attackers will be able to detect they are operating within a honeynet, so when implementing a honeynet for optimum data capture, there are several considerations that should be addressed. The following are critical items that must be addressed prior to implementing a honeynet’s data capture components:

Placement
The placement of a honeynet is important in order to ensure the data capture is done while allowing for optimum access by an attacker and also that it is completely perceptually consistent with the rest of the production network.

Types
The type of honeypot is important in order to maintain perceptual consistency from the attacker’s perspective. It is also critical to ensure that if your network is Microsoft-based, Linux-based honeypots are not deployed. In doing this, your “intelligence loss” is increased, as the data is not useful to network defenders.

Modifications
Planning prior to deployment must be holistic, as each time a honeynet is modified, this increases the possibility of attackers realizing their activities are occurring within a honeynet.

Data storage
When planning and configuring a honeynet, ensure the captured data is not stored locally on the honeypot and/or the local honeywall. Data will always be stored on the honeywall, but when implementing an operational-based honeynet, you should not perform analysis directly on a sensor. It should be performed offline to avoid increasing the likelihood of an attacker detecting the honeynet.

Content
In order to entice an attacker to remain on a honeypot for any extended period of time, it is necessary to employ
content staging
and
content filling
within your honeynet, which will be discussed in greater detail later in this chapter. You must ensure accurate and appropriate content for your honeynet is put in place prior to deployment.