- Lance Spitzner, SANS Institute
Today, Honeypots are still in their infancy, developed and used primarily by researchers and security enthusiasts. A handful of commercial products are available, and organizations are beginning to deploy open-source honeypots and their more robust iterations, such as Honeyd. But honeypots are not widely deployed.
In the near future, honeypots will "learn" your network on their own and dynamically configure themselves.
Yet, honeypot technology is moving ahead rapidly, and, in a year or two, honeypots will be hard to ignore. New developments will advance the lab technology with the catchy name to a full-fledged, enterprise-level security tool.
In particular, look for advances in three areas:
Detection. Honeypots, by definition, see only "bad" traffic. Look for convergence with existing technology to help transform the intrusion detection crapshoot into a good bet.
Honeypot farms. A honeypot here, a honeypot there--not exactly scalable security. But in the near future, clustering will enable organizations to easily and quickly deploy honeypot technology globally.
Dynamic configuration. In the near future, honeypots will be able to "learn" about networks and configure themselves, making them a lot easier to deploy in large numbers.
Honeypots can fill the growing gaps left by conventional IDSes, which suffer from false positives and a lack of alert intelligence. As a result, we're going to see much wider deployments in the next few years. That's not to say honeypots will replace IDSes. Each technology has its strengths and limitations. What we're likely to see is a marriage of the two, dramatically improving intrusion detection.
In this scenario, both technologies will log to a central database, correlating information. The honeypot will reduce false positives by identifying attacks for which the IDS doesn't have signatures. On the other hand, IDS sensors address the fact that honeypots can't monitor all network activity.
We are already beginning to see this technology. Symantec's honeypot, Decoy Server, works with the company's IDS solution, ManHunt. Decoy Server is an advanced honeypot that doesn't emulate services; instead, it creates multiple instances of real operating systems. Attackers then interact with these real operating systems and applications. This information is fed into a central system, where it's combined with data from ManHunt.
Let's take a closer look at honeypots' unique detection capabilities to understand how they will complement IDSes:
IDSes and honeypots differ fundamentally in the way they attempt to detect malicious traffic. IDSes have the advantage of monitoring all traffic, flagging threats through a combination of known attack signatures and statistical anomalies. The flip side of this is the sheer volume of information IDSes produce--gigabytes of data. Some large organizations may have to deal with more than 100,000 alerts a day, many of them false alarms.
Hackers can slip through network defenses by using encryption or IPv6 tunneling. IDSes are useless against this kind of traffic. But it's a different story if hackers connect to a honeypot using, say, SSH, IPv6 or the encoded (and not yet commonly used) Network Voice Protocol. First, you know they're up to no good, because nice people don't connect to honeypots. Once inside, you can capture every action, including toolkits, keystrokes and communications. As more and more legitimate traffic is encrypted and uses IPv6 tunneling, organizations will begin to turn to honeypots to complement their IDSes.
Honeypots are less comprehensive, but more discerning. Honeypots only report the connections they receive--and most of these will be real attacks. This means your organization has far less, but more precise information to analyze, allowing you to more quickly identify and respond to attacks.
Honeypots detect and capture new attacks or methods. That means regardless of the tactics used, honeypots will most likely detect and capture the activity. Examples of these attacks discovered by honeypots include the Solaris dtspcd and Samba exploits.
There's a downside to all this. Honeypot deployment can be complex and time-consuming. Because each honeypot addresses only the relative handful of connections it receives, few, if any, organizations have the time or the resources for large-scale deployment.
One solution being developed is the open-source Honeyd (see Figure 1), which monitors unused IP space, instead of a single IP address. Any traffic or connection attempt made to an unassigned IP address is most likely unauthorized or illicit activity. This exponentially increases a honeypot's ability to detect unauthorized activity.
When someone attempts to communicate with an unused IP, Honeyd--which is installed on a single computer--creates a virtual honeypot that interacts with the attacker. Honeyd also has the capability to detect activity on any TCP/UDP port, even if the connection is encrypted or uses IPv6 to tunnel traffic.
While developments such as Honeyd address the scalability issue to some extent, honeypot farms promise to be a breakthrough technology.
In the future, organizations won't deploy honeypots on their networks. Instead, they'll simply deploy a hardware device that monitors unused IP addresses, similar to Honeyd, and redirects all attacker traffic to a single cluster of honeypots (see Figure 2).
Centralizing the hardware solves the problem of deploying and maintaining honeypots on the network. In fact, we're likely to see this offered as a service, with managed security service providers (MSSPs) maintaining farms for clients.
Honeypot farms will simplify administration--all your honeypots will be in one location, where they can be monitored. Let's say, for example, a major auto manufacturer wants to deploy honeypots on all of its networks around the world. That's a logistical nightmare. But with farms, all the honeypots are physically located at the company's headquarters and maintained by security specialists. Admins will simply deploy devices on the local networks to redirect unauthorized traffic to the farm.
Instead of bringing the honeypot to the attacker, attackers in the future will be directed to the honeypot.
We're already seeing this in such commercial solutions as NetBait. NetBait provides a service where it will deploy redirectors on your internal network. Attackers are then redirected to NetBait's honeypot farm, where their every action is detected and recorded. Or, if an organization prefers, it can maintain its own honeypot farm, using the NetBait solution to redirect attackers.
The technological challenge isn't so much the farms themselves, but the redirection. How do you redirect the attackers to the farm without tipping your hand? You probably wouldn't redirect attackers using proxies, because a skilled attacker may detect that the proxy is intercepting and break off the probe.
Instead, more stealthy methods will be used. One example is the use of a Layer 2 VPN appliance. These black boxes can be deployed anywhere on your network. When the attacker probes a monitored IP address, the appliance will simply redirect the connection to the honeypot farm. There's no routing, hence no time to live (TTL) decrement of the IP packet, and no proxying. At the most, there may be some latency, which would be difficult to detect.
These farms could be highly sophisticated. Instead of deploying software (such as Honeyd) that emulates computers and services, the honeypots could be real computers running real applications. For example, Honeyd's virtual computer will emulate a service, such as FTP or HTTP. An attacker may be able to figure out which services are emulated--it's very difficult to provide the full functionality of an FTP server without an actual server. The real computers in a honeypot farm will be far more difficult for an attacker to figure out.
Further, security personnel can learn a lot more if they give the bad guys real OSes and apps to play with. For example, instead of just detecting an employee scanning internal networks for file shares, a honeypot on a farm could identify the person doing the scanning, what files they are looking for and perhaps even what they intend to do with those files. The honeypot farms could be highly customized based on the type of threats you're concerned about.
Honeypot technology, like most security technologies, can be time consuming to install and configure. What if you didn't have to configure at all? In the near future, honeypots will "learn" your network on their own and dynamically configure themselves.
This will be a quantum leap from the early honeypot implementations, such as Honeyd or Deception Toolkit, which are distributed in source code and have to be compiled and manually installed and configured. Point-and-click GUIs in Windows-based honeypots, such as NetSec's Specter and KeyFocus' KFSensor are making the job easier, but getting honeypots up and running is a lot of work. You have to configure, for example, which IP addresses you want to monitor, what operating systems you want to emulate and which services you want the honeypot to detect activity on. Future honeypots will dynamically make these decisions for you.
Imagine a honeypot appliance you simply deploy on your network. You connect the power plug and network cable (or wireless card) and let the honeypot do the rest. Using techniques such as passive fingerprinting, the honeypot appliance will monitor all the traffic on your network, learning what IP addresses are active--and which are unused--what systems are bound to those IP addresses, what services are being used, and by whom. The honeypot could determine not only the operating system of each computer on your network, but potentially the patch level and applications on each system--Apache Web server version 1.28 on a Linux 2.4.18 kernel, or, perhaps, Windows XP Pro running IIS 6.0.
Once the appliance identifies the makeup of your network, it would dynamically configure virtual honeypots across your unused IP space. These honeypots would mirror the makeup of your network, blending into your environment, whether you're a Microsoft shop with Win2K systems or running nothing but Solaris. It could even emulate devices such as routers, switches or wireless access points.
As your organization changes, so would the virtual honeypots. For example, if you add Linux servers to your Win2K network, the honeypot appliance could detect these changes and dynamically change the behavior and appearance of the virtual honeypots. By dynamically adapting to your environment, honeypots not only become harder to detect, but easier to maintain.
Each of these technologies will advance the state of the art on its own. But when we figure out how to make them work together, honeypots will really hit the sweet spot.
More on honeypots
Imagine our honeypot farm, with an appliance redirecting scans of unused IP addresses. Now let's add dynamic configuration. But instead of configuring virtual honeypots, our appliance now configures real honeypots in the farm, mirroring our network environment.
The redirectors would have the intelligence to know what honeypots to direct the attackers to. For example, if your organization is made up mainly of Windows-based computers, the redirectors can detect and direct attackers to Windows-based honeypots. If your environment changes (perhaps with Linux servers deployed internally), the redirectors can dynamically identify these changes.
The data collected by these dynamically configured honeypot farms can be leveraged to enhance other security technologies. For example, honeypot logs can be correlated with other system logs, IDS alerts and firewall logs. This will produce a far more comprehensive picture of the activity within an organization, and dramatically reduce the number of false positives.
Granted, we're still talking about the future. In many ways, honeypots are where firewalls were six or seven years ago--new to the security community and still under active development. But as more robust firewalls came into the market, the technology exploded across the infosecurity landscape. It's not a great leap to imagine more functional and scalable honeypots doing the same.
Lance Spitzner is the founder of the HoneyNet Project and a senior security architect with Sun Microsystems. He is the author of Honeypots: Tracking Hackers (Addison-Wesley Professional, 2003) and coauthor of Know Your Enemy (Addison-Wesley Professional, 2002).