Caught in the Net
How a honeynet uses low and high interaction honeypots to
better monitor attackers. by Dario Forte
Every type of incident has its own management process. Some are "publicly"
discussed while others are highly privileged, partly due to the public relations
policies of the infected targets. In incident prevention and response, we are
beginning to see the first examples of systems that monitor the behavior of
malicious hackers within specific real or simulated realms-otherwise known as
A honeynet is a modular system composed of honeypots. Each honeypot can simulate
one or more environments (operating systems, daemons, or services) and operate
on different platforms. The module is there to be compromised, but only to allow
the pot owner to monitor the hacker's actions and perform a detailed behavioral
analysis. A honeypot will require varying amounts of RAM and CPU capacity, depending
on the type of simulation and number of services and active processes. It is
cheaper to deploy one on Linux (no graphics required), but Windows-based products
are also available.
Why a honeynet?
The real value in this type of solution is that you can limit the number of
false positives much more effectively than with a conventional IDS. This is
known in the industry as noise reduction, and it means lower consumption of
logging resources, which translates into less analysis time since there are
fewer events to evaluate.
But this sort of tool is not without risks. As opposed to Distributed Intrusion
Detection Systems (DIDS), indicated for distributed capture of suspect packets
and patterns across the entire network segment, honeypots are mainly host-based
and only pick up activity directed against the machine on which they are installed.
Hence, a more articulated and granular deployment is needed to achieve the same
results as a DIDS, with which the pots interface in 80% of the cases. Another
risk is the use of honeypots by attackers as stepping stones to attack other
systems. This could be a problem in certain legislative contexts, such as Italy,
and even in the US there appears to be legal complications (see sidebar).
There are, however, many benefits from honeypot systems, ranging from the ability
to handle "new generation" IP traffic such as IPv6 (which is not always
recognized by IDSs) to the ability to accumulate and aggregate information on
ongoing attacks in a much simpler way than an IDS. No special algorithms are
required and the flexibility of these tools significantly reduces the problem
of false alarms and false positives.
There are different kinds of honeypots. They differ in the level of interaction
with the rest of the public network, whether they are free or commercial, and
in the type of simulation carried out. Generally, a honeypot can operate at
a low or high level of interaction, and it depends on the level of activity
granted to attackers once the machine has been compromised. Low interaction
honeypots, for example, handle single operating systems and/or single services.
This means that once an ftp server is "called up", the only commands
allowed to an attacker are those related to that service. It is clear that this
type of pot is useful only for basic investigative operations that are low risk.
The main disadvantage in this case is that only some of the attacker's activities
is logged. If the attacker is skilled, he may be able to figure out the origin
of the apparent anomaly and abandon the target. This type of setup would seem
to be justified for a broad deployment, or allow users to get a grasp on how
such a behavioral analysis tool works. It is thus preferable to flank this type
of pot with high interaction services, which are more complex and fundamentally
without emulation. This means that the attacker has a complete target at his
disposal and there is a greater possibility of monitoring the attacker's actions,
including those that are totally new.
Most honeypots installed on complex architecture and having complex functions
are based on high interaction systems. One of these is Symantec's DecoyServer,
which fakes e-mail traffic to fool attackers. Its defenses include automatic
shutdown of the entire honeynet in the event of a sudden increase in attacker
activity-a technique known as "frequency-based policies".
Traffic monitoring is also important. The new generation of high interaction
honeypots provides accurate reporting that can be used by both management and
technicians. The purpose is to prioritize events to proactively resolve potential
Furthermore, we are beginning to see the first examples of stealth monitoring
and containment, as well as real-time attack analysis. The main objective is
to have both host-based and network-based intrusion detection without tipping
off the attacker about the surveillance. And with the need to centralize management
and consolidate reporting functions, a good graphical interface greatly facilitates
the use of the product, even by non-experts.
There are also low interaction honeypots, which are useful when its maintainers
are not able to guarantee that the process will be excluded from the rest of
the network activity during an attack. Put simply, low interaction is recommended
for non-experts not wanting to risk being used as a launch pad.
One of the most frequently used low interaction examples is Honeyd. It is an
open source daemon for Unix systems, although a version for Windows was recently
The main function of Honeyd is the monitoring of unused IP space. It intercepts
calls to IP addresses not related to machines located in a specific subnetwork,
and begins to simulate traffic (as if it were a truly functioning target). The
tool can also simulate individual services and ports, and this may be useful
for observing the behavior of an attacker during and immediately after the illicit
access phase. Another interesting aspect is the ability of some honeypots to
simulate operating systems as well as single services. For instance, there are
emulators for Windows XP, Linux and Cisco IOS. The bottomline determining the
quality of a honeypot is the spoofare, a special operating system stack. A well-crafted
honeypot can emulate not only the individual services but also fake the operating
system, whereas others might raise suspicions during the targeted scanning phase.
A practical example is the fake daemon httpd that runs on Windows.
When to use what
Generally, one opts for a honeynet comprising high and low interaction honeypots.
This is to guarantee an attacker a certain operating autonomy without being
Another important concept is the honeywall. This is a gateway through which
all the connections to and from the honeynet are routed. Generally, a high percentage
of inbound and a limited amount of outbound traffic are allowed, especially
when the outgoing packets have a negative payload, i.e., serving the attacker's
purposes. Honeypots can be used in a variety of ways. While their intrinsic
value as a research tool into new attack patterns is not yet fully determined,
one of the most effective practical examples is protection from automated attacks
(e.g. those based on worms) that may use complex scanning techniques. There
are also 'sticky' honeypots that slow an attack via a series of TCP-based techniques,
such as the use of Windows Zero Size. Sticky honeypots fall into the category
called "no interaction honeypots", which extinguish or slow the attack
to the point where it is rendered harmless. Since the input is generated by
an automated tool, there is no risk that the attacker will know what is happening.
Another example of a low interaction honeypot is the Deception Toolkit. It deviates,
right from the active fingerprinting phase, an attacker who uses mixed social
engineering and information gathering techniques.
Honeynet implementations provide solutions for almost any need. The software
is highly modular and allows step-by-step implementation.
The management of the type of composite architecture described in this article
requires four full-time staff, and may also have to coordinate with the worldwide
honeynet project, which has very rigorous access parameters.
This article first appeared in Network Computing Asia.