eWEEK content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
The era of purely static, passive network defenses is slowly coming to an end. Certainly, firewalls and authentication tools will remain a critical part of any sound security strategy for the foreseeable future, but it is clear that they are no longer enough. Given the amount of internetworking demanded by modern applications and the potential for insider attacks and social engineering, there are simply too many ways through even the strongest defensive perimeter. Given all the possible avenues available to an attacker, an effective defense must be able to react and adapt, which in turn requires some capacity to detect and monitor attacks in progress. Hence, the emergence of the intrusion detection system (IDS).
Given that real-time intrusion detection was until recently considered almost impossible, network- and host-based IDS development has seen an almost meteoric rise; most security specialists, however, still consider it a promising but immature technology.
Perhaps the biggest weakness with current IDS packages is what is known as “the tuning problem.” Because attacks can hide amidst legitimate network traffic and masquerade as common anomalies and errors, it can prove almost impossible to “tune” an IDSs sensitivity such that it can catch attacks without a large number of false alarms. In most environments, overworked network administrators choose to turn off or ignore a deployed IDS rather than attempt to separate the wheat from the chaff.
One increasingly popular response to this problem is to supplement an IDS with carefully constructed decoy hosts to fool intruders. These machines, known as “honeypots,” appear to be normal, functional hosts, but actually have no legitimate users, and generate and receive no legitimate network traffic. They exist solely to serve as targets for attack, and thus strip the attacker of the “cover” they are accustomed to hiding behind. As a result, they are extremely unlikely to trigger a false alarm; any activity on a honeypot is a sign of something seriously amiss.
Honeypots are also adept at detecting certain kinds of attacks that often slip past IDSs. Technically savvy insiders can often fool an IDS, for example, but have no way of tricking a honeypot unless they are aware of its true nature. Similarly, honeypots can detect newly devised attacks for which no IDS signature yet exists; many of the first reports of the “Code Red” worm came from honeypots.
Perhaps even more significantly, honeypots are extraordinarily effective for collecting detailed information about an attack and an attacker; once theyve set their sights on a honeypot, all the intruders moves are essentially under a microscope. Indeed, security specialists often use honeypots as research tools. While commercial users are often unconcerned about the details of an attack so long as they can block it, such data is extremely valuable to those with the resources to make use of it. In the event of an insider attack, for example, reliable forensic data may be necessary in order to terminate and/or take legal action against the perpetrator(s). More generally, specific information on methodologies and intended targets can prove instrumental in strengthening defensive measures.
According to Marcus Ranum, chief technology officer of IDS developer NFR Inc., “Honeypots are a very useful tactic, and a great complement to a good IDS. I wouldnt be surprised to see them become much more common.”
Sacrifice Play
There are two basic types of honeypots. The “sacrifice box” offers attackers a fully functional operating system and suite of applications while recording their activity and limiting their ability to use it as a staging point to attack other systems. These kinds of machines create particularly attractive and convincing targets; indeed, if well executed, they can fool even skilled attackers into wasting hours or days that might otherwise have been spent compromising real systems. By encouraging intruders to interact with them over a relatively long period of time, they also maximize opportunities for data collection. On the other hand, they can prove expensive to deploy, maintain, and use, and if poorly implemented can introduce new security risks.
The simplest kind of sacrifice box is just a standard production host placed within the target network. By placing such a host behind a firewall modified to allow inbound traffic while filtering outbound traffic—the opposite of what firewalls normally do—a network architect can effectively isolate the sacrifice box from the rest of the network while allowing it to appear normal. System administrators can then use remote logging tools, sniffers, file integrity checkers, and/or keystroke loggers to monitor the sacrifice box for any activity.
“Do-it-yourself” sacrifice boxes offer a number of advantages. They require very limited processing power, and can be deployed on inexpensive, surplus, or obsolete hardware. They also allow for a great deal of flexibility with regard to operating systems and applications, and can easily be made almost indistinguishable from customized production machines on most networks. Because they can be completely compromised by an attacker, however, they must be deployed with great care so as not to create a threat to other systems. Moreover, given the different tools needed, they can be tricky and time-consuming to administer and monitor. For those who want to deploy sacrifice boxes but dont want to “roll their own,” Recourse Technologies offers its Mantrap product, which consists of a centralized management console controlling a number of ready-made, extremely secure Solaris-based sacrifice boxes.
Mantrap is exceptionally powerful and a pleasure to use—in many ways the Lamborghini of honeypot tools. Recourse has made subtle modifications to the underpinnings of the Solaris operating system to make it almost impossible for attackers to detect that they are, in fact, being monitored, while allowing administrators to deploy and configure any Solaris application on the various sacrifice boxes. These modifications even make it possible to deploy multiple Solaris environments (known as “cages”) on a single machine, making them appear to an attacker as entirely separate hosts. The management console provides easy access to a range of different monitoring and alerting options.
Like a Lamborghini, however, Mantrap offers more power than many users need, at a significant price. “Most of our customers are primarily interested in learning as much as they can about attackers—their methods, as well as what theyre after,” says Brian Cameron of Recourse.
Most businesses, however, are primarily interested in deploying honeypots as “burglar alarms,” and are uninterested in devoting the resources necessary to analyze different types of forensic data that Mantrap can collect. Software licenses are relatively expensive and hardware requirements relatively steep, and installation can prove tricky—Recourse insisted on sending out one of their technicians to make sure our testing deployment went smoothly.
Just Faking It
The second type of honeypot is the “service simulator.” Unlike a sacrifice box, a simulator does not allow an attacker any access to operating system functions or genuine applications. The simulator is itself an application that watches for incoming network traffic, and generates responses designed to mimic those of an actual functioning server. Simulators are extremely cheap and easy to deploy, and require relatively little administrative overhead. Because they strictly limit access, simulators present a low risk of being compromised and used by an attacker. They are much easier to detect than sacrifice boxes, however, and will not hold an attackers attention for as long. Their information gathering capacity is also relatively limited, as is their ability to decipher new or unexpected attacks.
The premier simulation product currently available is Specter 5.5, developed and sold by Swiss security consulting firm NETSEC. Specter is very simple to deploy and configure, with a straightforward installation process and user-friendly GUI. Alerting and log analysis tools are similarly easy to use, and are readily decipherable by non-security specialists. At the same time, Specter offers a wide variety of configuration options, allowing it to simulate 11 different operating systems and an almost infinite number of services and Trojan horses. It also includes “intelligence gathering” tools that automatically trace back and gather information on the source of an attack, as well as the attack itself.
While it lacks the sheer data collection power of Mantrap, it almost perfectly meets the needs of many business users looking for a cheap and simple burglar alarm. Its biggest weakness is its lack of a centralized management console; while NETSEC does offer a remote management tool, administering multiple hosts can be inconvenient, particularly across a large enterprise.
Perhaps the best known of all commercial honeypot tools is PGP Securitys Cybercop Sting. First shipped in July of 1999, Sting is clearly showing its age; in our tests it only ran reliably on Windows NT 4, lacks a management GUI, and offers only a bare-bones simulation of handful of services. Indeed, PGP has placed it on “maintenance” status, offering limited support with no public plans for further development. Nevertheless, it merits notice because it remains the only available honeypot product that allows the simulation of entire subnets on a single machine, complete with Cisco routers, NT servers, and Sun workstations. Separate machines can even be linked into these subnets to act as partial sacrifice boxes.
A number of free and/or open-source service simulators are available, including NFR Inc.s BackOfficer Friendly and Fred Cohens Deception Toolkit. These tools are extremely cheap and require very little processing power; they can typically be installed on actual production machines to mimic unused services without seriously impacting non-security performance. The tools we were able to test, however, are not suited to significant business deployments and are easily detected by an attacker.
Make It Count
In order to make the most of their strengths and maintain the deception upon which they rely, a honeypot deployment should be carefully planned. Understanding what data you are trying to protect, what threats are of primary concern, and what you hope to gain from a honeypot is key to choosing your tools and placing your traps.
Most businesses are best suited by scattering honeypots throughout their internal networks, where they can catch attackers that manage to breach their perimeters. The most important facet of such a deployment lies in making sure each honeypot presents an attractive but believable target. If a host appears to be impervious to attack or to have no valuable data, attackers will simply avoid it; if it appears too valuable or too easy, however, an attacker may be tipped off to its real purpose. Ideally, a honeypot should be indistinguishable from the production machines in its environment.
One of the greatest strengths of an internal honeypot deployment is its effectiveness against insider attacks; this effectiveness, however, requires keeping it secret from your own employees, including most of your IT staff. This can prove extremely tricky, particularly in environments with large numbers of tech-savvy personnel. Limit knowledge of a deployment to key trusted employees, and impress upon them the importance of maintaining secrecy. Consider implementing policies limiting innocent scans or monitoring of your network by IT staff and/or curious employees that may set off false alarms or blow your cover. If all else fails and the existence of honeypots within the network becomes common knowledge, keep your deployment flexible enough to disguise which machines are real and which are decoys.
According to Recourses Cameron, almost half of all Mantrap users deploy honeypots on their perimeter, where they are accessible from the public Internet. While this strategy allows the collection of huge amounts of data on outside attackers, it should be approached with caution. The vast majority of activity these honeypots are likely to detect consists of casual scans, probes, and automated attack tools. While these are not exactly false alarms—they are unauthorized access attempts, after all—they are not usually worth the attention of an administrator. It is also important to avoid attracting unwanted attention to your network by exposing apparently vulnerable hosts.
Additionally, you should be prepared with a response plan appropriate to the type of deployment and likely threats. A service simulator is not likely to hold an intruders attention for long, and skilled attackers may quickly realize that theyve been spotted, so “burglar alarm” deployments should be accompanied by rapid response plans. On the other hand, the extensive data collected by a sacrifice box will go to waste without the time, expertise, and resources to analyze it; this capacity is particularly important in dealing with insider attacks and other circumstances in which legal action is called for.
As there is no way to construct a perfectly secure network, the goal of those responsible for network security should be to find new tools to enhance the options available to them, rather than a “silver bullet” solution. You should realize that honeypots do not address every security risk, but they are a very promising addition to your arsenal. Take a look.