How to Comprehend the Buzz About Honeypots

Everyone in security wants to know how criminals do their work – but everyone in security would rather watch cybercriminals' handiwork while it plucks apart someone else's computing infrastructure, not their own. Understanding your adversary is, after all, key to countering attacks, but most organizations are reluctant to enlist their production servers and networks for research.

So, instead, they turn to honeypots.

What Is a Honeypot?
A honeypot is a set of data or pieces of network infrastructure that appear to be vulnerable, legitimate production components but are, in fact isolated from the rest of the network. So attackers are attracted to them, but attacks can be studied without endangering the enterprise.

Honeypots have increased in importance as the cybersecurity battlefield has grown more dynamic. Rui Lopes, engineering and technical support manager at Panda Security, explains that honeypots are critical tools of "counter-espionage" in cybersecurity, delivering key intelligence on attackers.

Analysis of honeypot activity can, he says, bring early awareness of new forms of attacks. "In the age of malwareless and sophisticated cyberthreats, attack telemetry and its analysis becomes critical in customizing a protection model that fits the organization, its assets, and its strategy rather than a turnkey approach that will simply not work in the long run," Lopes says.

Ideally, a honeypot is isolated, robust, easily monitored, and easily rebuilt when it has been successfully compromised by a criminal. For many, if not most, organizations, the combination of requirements is best met by virtual machines hosted on an isolated server.

But regardless of whether the honeypot is set up on a virtual machine or an isolated physical operating system instance, most will be set up with specific environmental variables, systems, or applications to attract particular criminals interested in specific targets.

Different Flavors of Honey
All honeypots are not created equal. It makes sense, since not all honeypots have the same purpose. While every honeypot is available on the Internet and vulnerable to one or more attack plans, the first major fork comes between honeypots serving the needs of production IT security teams and those serving the needs of security researchers.

Honeypots set up by enterprise IT teams tend to have a straightforward purpose: They gather information on the attacks being launched against the organization's systems and applications. In most cases, that means a honeypot set up within the organization's network address space, with some (or all) of the organization's APIs and services exposed to the Internet.

The point of the enterprise honeypot is simple: It will allow the enterprise security team to see which ports and APIs are most frequently targeted, which username/password combinations are tried most often in credential-stuffing attempts, where the attacks are originating, and other basic but critical attack factors. Honeypots aren't intended to be open-ended research devices, and in general they aren't highly interactive. In particular, they aren't intended to keep attackers engaged for long periods of time through highly interactive traps.

When security researchers set up a honeypot, they tend to have aims much different than those of enterprise security professionals. Research honeypots may be used to gather data on particular strains of malware or specific attack vectors, or they may provide data on more general trends in offensive cybersecurity.

At one extreme, research honeypots may have limited services, ports, or APIs open to the Internet so that they will be attractive to attackers searching for targets. At the other extreme, a research honeypot may duplicate a full enterprise server, complete with Web interface, enterprise applications, and faux database. These full-featured research honeypots may also be quite interactive, allowing attackers to go through several layers of the applications and services with appropriate responses from the honeypot.

These highly interactive honeypots are quite a bit more complex to set up and monitor than are the noninteractive or minimally interactive honeypots that gather data on more limited activities. Beyond the expense and complexity of setting up these highly interactive honeypots, there's a risk as well. The longer attackers remain engaged with a honeypot, the more likely they will find a flaw that either reveals the honeypot to be a research project or allows them access to a production network.

Pulling Data From the Honeypot
Building a great honeypot is of no value if useful data isn't returned to the security staff or researcher. The honeypot build process has to include processes and technology for safely gathering and reporting the captured data.

The first layer of data gathering can come from the logs of the firewall, intrusion-detection system, or other security components that sit between the honeypot and the Internet. Together, they will provide information on the application and network traffic that are part of the attacks.

Next, server system logs will bring system-level data to the proceedings. In addition, monitoring and analysis tools can be used to provide more detailed records of network traffic and packet contents. The total data set from the various sources, correlated and analyzed, will give the security team or researchers information required to do detailed forensic analysis of the attack and its effects on the system.

Safety First
When a honeypot is successful, an attacker will compromise its facilities, whether a single port or complete admin privileges. The complete plan for a honeypot must include steps to take when it is successful — how to regain control of the server, remove any artifacts left by the attacker, and (most important) prevent the attacker from using the honeypot as the first step in breaching the total enterprise network.

The first two can be accomplished with a "golden image" of the honeypot that can be reapplied to the physical server or server image on a virtual machine. The third is accomplished by a server that is on an entirely separate network, on a network segment logically separated from the production network, and with full network security between the honeypot and the rest of the enterprise.

One very real question, though, is whether, when the research is complete, the security team or researchers shut down access to the honeypot in a way that allows attackers know they've been duped. In most cases, the best solution is to keep attackers in the dark, shutting down the honeypot with a "maintenance required" or similar message that excuses the shutdown with a reason not having to do with security.

There are a wide variety of software packages, both free and commercial, for setting up a honeypot. Most of them are for honeypots intended for a specific goal, and none makes it easy for a novice to safely set up a honeypot on or related to a production network. Reading through the documentation, the discussion pages on GitHub, or community conversations should go a long way, though, toward helping anyone understand precisely how the honeypot works and why it's such a valuable tool for cybersecurity pros.

Related Content: