The term “honeypot” or, as it sometimes appears, “honey pot,” came to computer security from the world of espionage, where it referred to an agent who would be sexually available to a target. If all went as planned, the target would be compromised, either by sexual blackmail or because the relationship led the target to share secret information.
In general, then, a honeypot invokes the mechanism of a Venus flytrap: a seemingly friendly interaction that hides an ulterior motive. Lure your unsuspecting visitor with a tantalizing promise, but use him for your own purposes once he has taken the bait.
That is exactly the point of a computer honeypot, which turns the typical approach to security on its head. Most systems, after all, are armored against attack from the outside. They are password-protected, sometimes with multiple layers of verification. They ask security questions before granting access. They deploy challenge-response tests, including the Completely Automated Public Turing test to tell Computers and Humans Apart (CAPTCHA) that tries to distinguish between human and machine visitors.
For all the sophistication of the tools used to secure machines and networks, attackers keep up with the state of the art, finding new weaknesses and varying their approaches, and they often succeed. Security professionals must constantly plug holes and build new defenses, but they are always just a small step ahead of their adversaries. Clearly, the more they know about those adversaries and their methods, the better they can address the vulnerabilities of their own systems.
Clifford Stoll took this approach when he worked as a systems administrator at Lawrence Berkeley Laboratory (LBL) in 1986, creating the first known honeypot. An error in an accounting system led to the detection of an intruder in the LBL system and, rather than denying the intruder access, laboratory staff decided to monitor his activity in the hope of understanding his motives and tracing his whereabouts, all while allowing the intruder to think that his work had gone undetected.
The issue was sensitive because LBL, though not involved in classified projects itself, was connected to government, military and scientific networks that dealt in all manner of classified material. With the help of those networks, LBL was able to keep a constant watch on the intruder, isolate classified material from his incursions and, ultimately, track the source of the attack to a man named Markus Hess, a German citizen who was working for the KGB.
As Stoll noted in an article published after the intrusion but before Hess’s arrest, the honeypot served an important purpose in addition to the capture of Hess: “Had we closed up, how could we have been certain that we had eliminated the intruder?”
Those purposes are still at the heart of the honeypot rationale, but the method has evolved since Stoll’s day.
Today, honeypots come in several different flavors.
A production honeypot is typically deployed by an institution that is not part of the specialized computer-security sector. It is placed within a company’s production network and can consist of a single server used to monitor and track attempts to attack the system. Given the expense and complication of deploying a full-scale honeypot, one that mirrors an entire production system, these are typically “low-interaction” honeypots that might be limited to those services known to be most attractive to intruders.
A low-interaction honeypot typically does not allow access to a production system beyond log-in, and it poses little danger to the actual production system since it serves only to emulate that system.
A research honeypot is a more robust alternative, used by security researchers, government and the military. Unlike a production honeypot, it can gather information about threats across a broad range of activities beyond those that might be the focus of a production system.
Research honeypots tend to be high-interaction. They can provide access to a wide range of services within a full-blown operating system or, at least, an imitation of such a system. Since they give an attacker extensive access to a full system, high-interaction honeypots require careful management.
To be successful, a honeypot must prevent an intruder from penetrating the real system behind the decoy, of course, but it must do more:
• It must provide a convincing simulation of the system that the intruder thinks it has penetrated, with no evidence of an ulterior motive.
• At the same time, it must capture and maintain the intruder’s attention, by posting false information that appears legitimate, for example, in order to have sufficient time to gather information about the intrusion.
• Steps must be taken to prevent an attacker from using the honeypot itself as a launch point for further attacks. In this scenario, a honeypot might be installed behind a firewall that stops outbound traffic.
Of course, in the arms race between attackers and defenders, hackers have equipped themselves with their own tools to detect honeypots. Security professionals have, in turn, responded with a variety of methods designed to thwart those tools, and the struggle goes on. The balance may never reach complete equilibrium, but honeypots are valuable security options now and are likely to remain so for the foreseeable future.
Check out our honey pot training class or visit the main cyber security training page for more info on other courses.