A sweet solution: honeypots distract hackers from valuable networks. (Internet).

All war is deception, said Sun Tzu. And, indeed, for thousands of years, military leaders have deceived their opponents in order to win battles. The same techniques used in traditional warfare can also be applied to defend networked assets from today's savvy attackers.

Thanks to the Internet, attackers now have a common, automated knowledge base that they can leverage to wage a new kind of war on the enterprise. For example, attackers can use the Internet to calmly research new vulnerabilities. Or, by downloading an automated exploit, a novice attacker can appear to have the skills of an expert: Even information about circumventing firewalls and intrusion detection systems (IDS) can be found with the click of a button. In addition, automation means that attackers can effectively spend months looking for holes in defenses without any interaction that might otherwise gain attention. And finally, the interconnected nature of the Internet means attackers from all over the world can strike any system they choose.

An attack need only succeed once. Security professionals, however, must defend against all current and future attacks and attackers. They must find and fix all vulnerabilities before an attacker acts- without affecting any operational network services. And they must immediately detect and respond to any suspected compromise. Even a false alarm consumes large amounts of time. What's more, responding to a successful attack is nearly impossible without first determining what the attacker was after and how deeply he penetrated the network. Finding this information after the fact is a long and error-prone effort, especially considering that the average corporate security professional is already multitasked with daily system administration, end-user problem resolution and the installation of myriad security applications that do not provide interoperability. All in all, these discrepancies give the attacker a serious advantage.

Traditional security techniques attempt to block attacks (firewalls) or detect them as they happen (IDS). Both of these techniques are critical, but they have their limits (see Figure 1). Given enough time and information, an attacker can learn to circumvent a firewall. Once circumvented, the firewall offers no further protection. An IDS will only provide information once an attack has begun. Often this does not leave enough time to adequately secure all vulnerable systems. In addition, an IDS cannot determine if a new attack succeeded or if it would succeed against other systems. Using only firewalls and IDS is analogous to a medieval city defending against the barbarian hordes with only high walls and unarmed sentries. Eventually, the city will fall.

A successful countermeasure would substantially delay the attacker while giving the defender enough information about his enemy to prevent the attack from causing damage. Successful use of deception accomplishes these goals. By deceiving the attacker, the defender feeds him false information and forces him to waste time in fruitless assaults, thereby blunting future attacks. In addition, a good deception will give the defender information about the attacker's means and motives without the large cost of a successful exploit. This information can then be used to enhance existing security measures, such as firewall rules and IDS configurations.

The Evolution of Network Deception

The first deployments of network deception, known as "honeypots," are not a new idea. Researchers and security professionals have been using different forms of honeypots since computers were first interconnected. Much like an actual pot of honey used to attract and trap insects, a technological honeypot can be deployed to present an attractive target to an attacker.

Using a honeypot has numerous advantages. First, it wastes the attacker's time. Depending on the depth of the deception, an attacker can spend large amounts of time attempting to exploit and then exploring the honeypot--and any time spent attacking a honeypot is time not spent attacking a real machine. Second, it gives the attacker a false impression of the existing security measures. He or she may spend time finding tools to exploit the honeypot that may not work on a real system. And third, the existence of a honeypot decreases the likelihood that a random attack or probe will hit a real machine.

Many attackers scan large blocks of computers looking for victims. Even attackers targeting a specific organization will scan the publicly accessible machines owned by the organization looking for a machine to compromise as a starting point. Using honeypots decreases the chance an attacker will choose a valuable machine as a target, and they will detect and record the initial scan as well as any subsequent attack.

Unlike other intrusion detection measures, there are no false positives with a honeypot. IDS products produce false positives to varying degrees. This is because there is always a chance that valid traffic will match the characteristics the IDS uses to detect attacks. This is not the case with a honeypot. Any communication with a honeypot is suspect simply because the device is not used for any purpose other than detecting attacks. In other words, there is no valid traffic to produce false positives.

In this way, a honeypot can detect more attacks than any other IDS solution. New vulnerabilities can be found and analyzed because all actions an attacker takes are recorded. Since all communication with a honeypot is suspect, new attack tools can be detected based on their interaction-even so-called "layer eight" attacks, or attacks against the information flow rather than the programs or protocols. These can include feeding false information into a service or database, or using compromised credentials to gain unauthorized access. Finally, a honeypot can detect and record incidents that may last for months. These so-called "slow scans" are difficult to detect using an IDS as the time involved makes them appear to be normal traffic.

Classification of Honeypots

Honeypots can be classified into three primary categories: sacrificial lambs, facades, and instrumented systems.

The first honeypots to ever be developed, sacrificial lambs are simply computers designed with the sole purpose of being attacked. A sacrificial lamb usually consists of an off-the-shelf system placed in a vulnerable location and left as a victim. It provides an excellent target for attackers--but, unfortunately, extracting attack data about an attack has proven to be time-consuming, and the sacrificial lamb itself can be used by an attacker to attack other machines.

The next advance in honeypot technology removes the security threat posed by a compromised honeypot by only emulating network services instead of allowing the real machine to be attacked. These facades generally have the vulnerabilities of sacrificial lambs, but they do not provide such a rich set of data. Facades provide easier access to the recorded attack data and therefore make it more difficult for attackers to avoid detection. A facade is the most lightweight form of a honeypot and usually consists of some type of simulation of an application or service in order to provide the illusion of a victim system.

The newer instrumented systems build on the strengths of both sacrificial lambs and facades. Like the sacrificial lambs, they provide a highly believable system for attackers to compromise, and, like facades, they are easily accessible and difficult to evade due to their logging of attack information. Furthermore, an advanced instrumented system provides a means to prevent the attacker from using the system as a base for further attacks. An instrumented system honeypot is a stock system with additional modification to provide more information, containment, or control.

The technology used in sacrificial lambs and network facades is somewhat restrictive and can be a limiting factor for detection, while an instrumented system addresses many of the issues faced by both of these tools to provide an integrated intrusion detection solution.

While many honeypot implementations may function well in single deployments with dedicated administrative efforts, larger deployments (a.k.a. "enterprise deployments") require additional functionality to be effective solutions. An organization that wishes to deploy honeypots should have an overall computer security policy that states what the threats are, what the main goals for an attacker might be, where the high-value systems are, and how potential targets will be protected. In essence, the security policy should dictate what the strategy of honeypot deployment will be.

The following sections describe a few different deployment strategies. These strategies, or combinations of them, can be used together with firewalls and IDS to form a cohesive security infrastructure to protect an organization.

Minefield Deployment

In a minefield deployment, honeypots are installed among live servers, possibly mirroring some of the real server data. The honeypots are placed among external servers in the DMZ to capture attacks against the public servers and/or in the internal network, or internal attacks (which either originated from an internal or an external source, through penetration of the firewall and the use of internal machines as launching pads to attack other systems).

Attacks are rarely restricted to a single machine. Many manual and automated network attacks follow the same pattern: Assuming a successful attack has taken place on one machine in the network, that machine is then used to scan the network for other potential targets, which are subsequently attacked. For manual attacks, this takes some time, whereas worms will normally execute the. scan just seconds after the first infection. Stealth scanning can be performed in a manner that specifically avoids setting off IDS (e.g., through "slow scans"), but honeypots in a minefield will be alerted.

For example, if a network has one honeypot forevery four servers, then the chances of hitting a honeypot with a random, single-point attack is, theoretically, 20%. In reality, however, the chances are significantly better than that because, in most cases, an entire block of network addresses will be scanned. When this happens, it is practically assured that the honeypot will detect the intrusion shortly after any machine on the network has been compromised.

Even though the intrusion detection aspect alone is important, another feature of using honeypots is to see what the attack tools are and what the purpose of the attack is. With good security practices on the production machines (e.g., good password policies, no plain text passwords over the network, machines running the latest vendor patches, etc.), slightly decreasing the security on the honeypots themselves may increase the chance that they will be some of the first machines that are attacked. A well-designed honeypot will then have the information about the services attacked, how that service was attacked, and--if the attack was successful--what the intruder did once inside. Having the honeypots configured exactly the same way as the regular servers, however, has other advantages. It increases their deception value slightly, and it also means that when a honeypot has detected a successful attack, that attack is likely to succeed also on the production hosts.

Shield Deployment

In a shield deployment, each honeypot is paired with a server it is protecting (see Figure 2). While regular traffic to and from the server is. not affected, any suspicious traffic destined for the server is instead handled by the honeypot shield. This strategy requires that a firewall/router filters the network traffic based on destination port numbers, and redirects the traffic according to the shielding policy. For instance, consider a Web server deployed behind a firewall. Web server traffic will be directed to the Web server IP address on TCP port 80. Any other traffic to the Web server is considered suspicious and can be directed towards a' honeypot.

The honeypot should be deployed in a DMZ, and to maximize the deception value, it may replicate some or all of the non-confidential content of the server it is shielding. In the example of the Web server, this is merely a matter of mirroring some or all of the Web content to the honeypot.

In conjunction with the firewall or router, honeypots deployed in this fashion provide actual intrusion prevention, in addition to intrusion detection. Not only can potential attacks be detected, but they can also be prevented by having the honeypot respond in place of the actual target of the attack. Take note that a honeypot shield cannot protect a mail server from SMTP exploits, nor a Web server from HTTP exploits, since normal traffic must be able to reach its target. However, because live servers generally need very few open ports, it is reasonably easy to find the point of an attack--both for prevention and forensic purposes--and all other ports lead straight to the honeypot, where the attack can be analyzed in detail.

A shield deployment is an example of how honeypots can protect a high-value system where attacks can be expected.

Honeynet Deployment

In a honeynet deployment, a network of honeypots imitates an actual or fictitious network. From an attacker's point of view, the honeynet appears to have both servers and desktop machines running many different types of applications on several different platforms. Another term for this deployment is a "zoo," as it displays a variety of honeypot species.

A honeynet is an extension of the honeypot concept in 'that it takes multiple deception hosts (single honeypots), and turns them into an entire deception network. A typical honeynet may consist of a mix of facades (because they are lightweight and reasonably easy to deploy), some instrumented systems for deep deception, and possibly some sacrificial, lambs. In order to provide a reasonably realistic network environment, some sort of content generation is necessary. On a host basis, this involves 'simulating activity on each deep honeypot, as well as generating network traffic to and from' the clients and servers, so that the network itself looks realistic from the outside.

As an example, a DMZ that contains a Web server and a mail server could deploy two honeypots that act as shields to the servers. Any traffic to the Web server that is not HTTP traffic will be directed to the Web server's shield. Any traffic to the mail server that is not SMTP will be directed to the mail server's shield. By adding a few more honeypots, another dimension can be added to this deception; all traffic to unknown IP addresses can be directed to honeypots, instead of simply traffic to known hosts. The strength of the honeynet shield is that it shields an entire network instead of a single host. Similarly, honeynet minefields represent the scenario where each mine is an entire network, as opposed to just a single honeypot.

Honeynets can be useful in a large enterprise environment and offer a good early warning system for :attacks. A honeynet may also provide an excellent way to figure out an intruder's intention, by looking at what kind of machines and services are attacked, and what is done to them. The Honeynet Project (http://project.honeynet.org) is an excellent example of a honeynet used as are search tool to gather information about attacks on computer infrastructure.

Deception devices represent important, emerging security technology. Deception provides the defender with both the time and information needed to effectively respond to a wide variety of threats. Commercialy available solutions have evolved the honeypot concept of intrusion detection to a third generation and provide a very effective security application unlike the first-generation technology concepts. Combining early detection, advanced reporting and analysis, and an easy-to-deploy security solution provides a cost-effective defense mechanism powerful enough to prevent internal, and external intrusions--and one that should be a component of any successful security solution.

www.recourse.com

[FIGURE 2 OMITTED]

Brian Hernacki is chief scientist at Recourse Technologies (Redwood City, Calif).