Honeypots: Security

The Internet threat environment that now exists outside the firewall is chaotic and confusing to internal intrusion detection systems (IDS) and the individuals charged with administering them. To use a military analogy, it is much like defending an encampment with a jungle surrounding the outside perimeter. Outside the sentry posts after sunset, the animal nightlife is alive and noisy, with a blowing wind adding to the din. Wide-eyed and terrified, sentries strain to detect any enemy, spending adrenaline, energy and their sanity attempting to detect potential attackers. This is what engineers call a signal-to-noise ratio problem. There is so much noise that any valid signal is masked. Back in the computer network, that noise translates to false positives and repeated notification of attacks that turn out to be harmless.

The newest concept to surface in the scheme of layered security is the honeypot, which was pioneered by a group of virtual developers (http://www.honeynet.org). The honeypot concept is based on the idea of a “baited” network to draw hackers into divulging their toolkit of vulnerability exploits outside the periphery of a production network. The idea is to have the attacker reveal his tools prior to the invasion on the true IT infrastructure. This information can therefore be used both to validate internal attack signatures and also provide security personnel some time to detect real attacks, and devise strategies to repel those real attacks on their networks.

Returning to the military analogy, the base commander has now cleared the jungle to naked earth for a two-kilometer radius around the camp. To attack, the enemy must now show itself. The noise floor has been lowered and any real attacks are clearly evident against a muted background. On the internal network, an alarm is raised only if an event correlation process demonstrates that a specific attack profile was detected in the external honeypot, and then also detected on the internal network. Further reduction in false alarms can be had if the correlated attack actually changes data on a host machine (host intrusion detection).

Honeypots are placed on a network layer outboard (closer to the Internet) to the internal IT infrastructure. Against the contrast of naked earth, these outboard host machines present targets of opportunity and reveal real future threats to the inboard (real) network.

Three categories of honeypots

There exist three major categorizations of honeypot implementations. The first is an actual network of older machines simulating an IT environment of servers and workstations. The second is a single machine running an Open Source (freeware) simulation of a network. The third is commercial implementation of a network (e.g. – the Symantec ManTrap product).

Regardless of their pedigree, the intent is to draw hackers into tipping their hand by revealing the specific tools they employ to compromise IT networks. If an observed exploit in the honeypot is subsequently detected in the internal network, then the probability of a real attack is validated and serves to qualify the signature as a real attack in a sea of probable false positives.

Detecting “zero-day” attacks

Another advantage of honeypots is that they have the potential to detect new and previously unknown hacker exploits for which a signature has not yet been published and distributed. These new exploits are referred to as “zero-day” attacks. The significance of repelling new, unknown attacks is that no reliance on external parties to provide a signature is required.

Honeypots are hacker “flypaper” and are universally reviled by the hacker community. This is not unexpected, as a properly deployed and monitored honeypot is indistinguishable from a real target to the hacker, who is unwittingly drawn out onto the naked earth to display his “warez” to the potential victim. In a counterculture where recognition and bragging rights are king and hacked sites are trophies, being caught like this is the ultimate embarrassment.

Honeypot liabilities

The fact that shareware honeypot technology has been commercialized is a testament to its value, but honeypots are not a panacea. Their deployment comes with a requirement for legal due diligence and a careful weighing of their pitfalls versus benefits. There are several facets to consider.

Honeypots are not “set-and-forget” devices, like mousetraps. Activity within the honeypot must be continuously monitored if it is to realize its potential as an early warning system. This is especially true if their “zero-day” capabilities are to find utilization.

The other technology consideration is egress monitoring and throttling. In order for the honeypot to convince a hacker that it is a real system, it must be able to transmit packets on the Internet. In the beginning, a hacker expects responses to his probes. What happens, though, when the hacker succeeds in executing malicious code on the honeypot that targets a third-party system?

Although Honeynet’s second generation (GenII) includes throttling provisions that would prevent the launch of a wholesale Denial of Service (DoS) attack on a third party, not all exploits result in a barrage of Internet traffic. A third party impacted by an exploit launched from your honeypot may have legal recourse against you. This is a serious downstream liability issue that has delayed industry acceptance of honeypot technologies.

Sticky legal issues

U.S. law enforcement has been grappling with interpretation of law with respect to honeypots. The most common issue is that a honeypot intercepts Internet traffic destined for a computer network, regardless of intent. This is in violation of U.S. wiretap law and is an indictable offence for the owner of the honeypot. There are a handful of other laws that render the honeypot owner at legal risk.

The latest challenge to honeypots lies in the application of new DCMA (Digital Millennium Copyright Act) legislation. In an effort to protect the music recording industry, many U.S. states are responding to the DCMA by enacting legislation that makes it illegal to intercept any communication or conceal its origin. Intended to provide a tool to fight P2P networking like Kazza and to impose penalties for sharing MP3 music files, its very general nature renders honeypots illegal (see ” Use a Honeypot, Go to Prison“- http://www.securityfocus.com/news/4004).

In Canada, honeypot legality remains unclear. With no case law or precedents to look to, there is no definitive legal opinion. Section 342.1 of the Canadian Criminal Code states: “Everyone who fraudulently obtains, directly or indirectly, any computer service, by means of an electro-magnetic, acoustic, mechanical or other device” is guilty of a crime. Therefore, a honeypot, by deceptively mimicking a real system, is operating fraudulently.

Regardless of criminal prosecution issues, it remains clear that the principal liability for honeypot owners is that in order to dupe the hacker, it must behave like a real target. It must be capable of responding to the hacker. So, if the intruder successfully infiltrates a machine and launches a zombie (DoS) attack, the owners are liable for whatever damage ensues. Although Internet traffic can be “throttled back” and controlled by some honeypot implementations, the downstream liability remains the single largest impediment to widespread corporate adoption of this valuable technology.

Honeypots have burst on the scene as a natural, evolutionary solution to the IDS bane of unacceptably high rates of false alarms. While other technologies are also being developed, including next-generation heuristics and network behavior profiling, the real allure of the honeypot is that it provides a rare opportunity to observe a hacker plying his trade, keystroke-by-keystroke, script by script. That window into the “dark side” has significant cloak-and-dagger appeal to most people while offering knowledge to security professionals who rarely see very far into that jungle.

The dark side of honeypots to their owners is in the form of legal and monetary risk. So the best advice is to follow legal developments, always check with your corporate counsel, and be very, very careful. It’s a jungle, and it can bite!

Tom Slodichak is Chief Security Officer of IT security provider WhiteHat Inc. He is a Certified Information Systems Security Professional, and an active member of the Computer Security Institute and the Information Systems Security Association. For more information, visit www.whitehatinc.com