Focus: Honeypots

Honeypots are currently the most popular of all traps and deceptive measures. Accordingly, we'll take a detailed look at some of the main issues related to honeypots and their use. The meaning of "honeypot," however, is not universally agreed upon, so we'll start by exploring what kinds of implementations might be called honeypots.

Deception Servers Versus Deception Hosts

Earlier in this chapter, we proposed a definition of a honeypot. In his previously cited paper on honeypots, however, Douglas Moran propounds that the term "honeypot" is ill-advised. First, according to Moran, "honeypot" is an inadequately defined term in that it can mean almost anything. Additionally, in many people's minds, the term "honeypot" conjures the impression of entrapment, something that is highly undesirable. He instead prefers to use the terms "deception server" and "deception host."

According to Moran, a deception server emulates one or more network services, delivering protocol-level interactions without the actual content normally provided during such interactions. Different platforms, such as UNIX, Linux, NetWare, and Windows NT/2000, can be emulated. It is also possible to use scripting to provide realistic responses when attackers connect to deception servers. Trojaned commands, according to Moran's definition, are one type of deception server.

In contrast, Moran defines a deception host as a normal host that has bogus content (for example, files with interesting names and content such as bogus personnel files) as well as monitoring capabilities. A deception host, for example, can store treasures, data or applications that motivate attackers into staying connected to that host. A virtual jail environment, according to Moran, would thus really be something that is within or part of a deception host.

Despite the eloquence of Moran's definitions, we will continue to use the term "honeypot" in a broader sense than Moran does. We will use "honeypot" to refer to decoy systems designed to attract attackers instead of distinguishing between deception servers and deception hosts.

How Legal and Ethical are Honeypots?

How legal are honeypots? This question has, to the best of our knowledge, never been tested in a court of law. If set up properly (as explained shortly), honeypots do not appear to violate any law in any country. The best thing to do, however, is to consult with your organization's legal department.

What about ethics and privacy issues? Critics of honeypots are often quick to point out that these measures potentially invade people's privacy ‚ they capture every keystroke of people who essentially have been tricked. Worrying about ethics is admirable, but these critics too often forget that law enforcement often uses sting operations to solve difficult cases. Little protest occurs except on behalf of criminals who have been caught red-handed.

Much of the answer to this ethical dilemma actually depends on how the honeypot is set up and run. Honeypots can and should, for example, display the same warning banner as other systems ‚ a warning banner that cautions would-be users that everything they do will be monitored . Goading or inviting would-be attackers to connect to honeypots, on the other hand, not only is likely to be viewed negatively in a court of law, it also presents serious ethical problems. Examples of honeypot deployments that are ethically controversial include recording chat sessions on a bogus chat server that anyone might in good faith visit, setting up bogus financial transactions in which credit card numbers can be entered (because people expect privacy and safety in the use of credit card numbers ), and running programs that create reverse connections to read files on the perpetrator's computer(s). Remember from Chapter 3 that being attacked does not justify subsequent counterattacks on your part. No matter what you do, unfortunately , invasion of privacy is always a potential risk, but this risk is by no means limited to the use of honeypots.

Initial Considerations

As you can see by now, successfully deploying traps and deceptive measures requires anticipating and resolving many issues long before these measures are deployed. Setting up honeypots, in particular, requires a considerable amount of planning. Let's now turn our attention to the many initial considerations with which you will have to deal if you want to successfully deploy honeypots.

Policy

Throughout this book, we have emphasized the importance of policy in incident response. The relationship of policy to deploying honeypots is particularly important. Policy considerations potentially apply not only to computer and information security policy but also potentially to human relations and legal policy provisions. In the case of computer and information security policy, it is particularly important for any provisions to be understood and followed. For example, an organization's computer and information security policy is likely to require that all systems owned by the organization display a warning banner for each login. Any host used for traps and deceptive measures must therefore display such a warning banner. Additionally, a computer and information security policy might prescribe certain safeguards and archiving requirements for log data. If so, these safeguards and archiving procedures must be put in place for all data harvested from traps and deceptive measures.

Dealing with human relations and legal policies is likely to prove even more complex. An employee-oriented company, for example, might expressly forbid the use of deception in dealing with employees . Could something like a honeypot nevertheless be used? The answer depends on the judgment of managers, most likely managers from the human relations and legal department. Again, just as in the case of almost every other matter related to incident response, obtaining the input, buy-in, and (often) permission of the human relations and legal departments is necessary.

Purpose

It is also important to clearly define the purpose and objectives of deploying honeypots long before any honeypot is ever deployed. The case study presented earlier in this chapter concerning the compromise of a honeypot shows what happens when objectives are not clearly defined. Behind every honeypot should be a written, clearly described statement of mission. One possible mission might be to discover new attacks before they become widespread. Another might be to obtain information about suspected insider attacks that have been occurring recently. The statement of mission should also include an estimate of how long the honeypot will be deployed as well as where it will be deployed, issues that we will consider in more detail shortly.

Approvals

After a statement of mission for each honeypot is in place, each honeypot should be approved by the management of any department or function (for example, legal) that has partial or full jurisdiction over activities involving honeypot deployment. Be careful ‚ an unauthorized honeypot deployment can be extremely career limiting! Approval should be written, as should be any restrictions imposed on the use of honeypots.

Procedures

As in the case of other facets of incident response, having written procedures to govern activities related to honeypot deployment is essential to the success of any honeypot effort. The following are some areas that procedures should address:

• Data access and reporting ‚ who gets access to honeypot data and what level of reporting to management is required.

• Monitoring ‚ how often honeypot data must be inspected.

• Data archiving ‚ any data archiving procedures.

• Inspection and maintenance ‚ checking the security condition of each honeypot.

• Longevity ‚ the maximum life of the honeypot and what must be done to clean up the honeypot when its life cycle is complete.

• Security administration ‚ how administrators will gain secure remote access.

• Testing ‚ what kinds of tests need to be conducted and how often.

• Incident response ‚ what to do if the honeypot itself is compromised. Before running a honeypot, you should define a process for determining when to terminate an attacker's access as well as who must be notified and under what conditions.

Deployment Considerations

After initial issues have been resolved, you need to consider where and how honeypots need to be deployed.The following sections deal with these critical issues.

What Type(s)?

One of the more difficult decisions is what type of honeypot (if any) to deploy. In other words, what kinds of services, data, and features will each honeypot fake? One of the easiest courses of action is to simply fake one or more of the following widely attacked services ^[6] :

^[6] It is essential, of course, that all systems house honeypots that run only the bare minimum of services needed. Any service running on any system can potentially be exploited to allow unauthorized access to the system, escalation of privileges, and so forth. This principle does not apply to "faked" services, however.A honeypot should run as many faked services as needed.

• systat

• ftp

• telnet

• dns

• gopher

• http

• sunrpc

• nntp

• locator (in Windows 9X,Windows NT, and Windows 2000)

• nbsession (in Windows 9X,Windows NT, and Windows 2000)

• imap

Alternatively, you might leave a host's configuration and services alone for the most part (after, of course, you have made it sufficiently secure) and instead assign that host an attractive name. The particular name assigned to the host will depend on numerous factors. Keeping the name contextually plausible is particularly important. If the names of other servers within a subnet are corp001, corp002, corp003, and so on, assigning a name of "sneezy" to a honeypot within the same subnet is probably not too smart. If, on the other hand, an insider has apparently been looking for potential targets of embezzlement, a name such as "financeserve" might be appropriate. The choice of a name is thus a matter of judgment (although "PeopleSoft" somehow always seems to work!). One nice thing about naming honeypots is that if one name does not work (that is, fails to attract sufficient attention) changing the name is generally trivial.

What Kind of Appearance?

What kind of appearance should a honeypot have? How should it look and feel to an attacker? The best answer is that the look and feel of a honeypot should be in accordance with the purpose of the honeypot. Some honeypots need to look very polished to avoid standing out among other systems with elaborate user interfaces, sophisticated graphics design, and so on. Others (for example, within a research and development organization) might need to look more roughshod to be credible. Note that if you implement a honeypot using commercial honeypot software or a honeypot toolkit, much of the look and feel of the honeypot is likely to be predetermined by the software or tool used.

Should all honeypots that an organization deploys have the same look and feel? The answer once again is that it depends. Some organizations roll out complete honeypot farms (honeypots that have distributed functionality) using honeypots that all have the same look and feel. The rationale is that an organization's servers often have a similar look and feel, so attackers who reach honeypots that are similar in this manner are more likely to be deceived. Others feel that having the same look and feel can help tip off attackers that they have reached bogus machines and/or services, and thus you should deploy honeypots with a range of different appearances and behaviors.

Quality of Deception

In his classic paper on honeypots, Douglas Moran proposes ways of measuring the quality of honeypot deception. For a given deception host, he says that the quality of deception depends on "convincing content, variable content, and faithful representation of the platform." "Convincing content" is a function of how hard or how long the attacker will search for information that interests him. Attackers are likely to use grep and other commands to locate files of potential interest, but they are not likely to devote much time to most files that simply contain a single word of interest but no other interesting content. Better deception translates in part to the fact that attackers take the time to read files or execute applications on a honeypot because they appear to be what the attackers are looking for. "Variable content" is similar, except that the variety in content from file to file on a honeypot is instead what keeps attackers on the honeypot. "Faithful representation of the platform" means that a honeypot system and its services work in the same way that the faked system/service/application typically works, even though the environment is a fake one.

What Platform(s)?

Another important deployment issue is deciding what particular platform (UNIX, Linux,Windows NT,Windows 2000, Novell, or whatever) to use. Unfortunately, any issue that concerns the choice of an operating system usually quickly deteriorates into a "religious war" ‚ one in which facts are ignored and emotions run rampant.

All things considered , we believe that UNIX is generally most suitable for honeypot deployment due to its combination of security, performance, and modifiability. Major flavors of UNIX such as Solaris and HP-UX have become markedly better in their security capabilities over the years . The vendors , too, have become more responsive in developing security solutions (including patches). In contrast, many other operating systems (such as Windows NT and the various flavors of Linux) are not as mature; security vulnerabilities have historically been more numerous (even though patches usually become available not too long after these vulnerabilities are discovered ). Additionally, UNIX (and to some degree Linux) offers performance advantages if implemented on a suitable hardware platform. Finally, UNIX (and also Linux) offers a high degree of modifiability. Not only it is possible to obtain the source code for many tools and routines that can be useful for traps and deceptive measures, Unix also offers a rich set of functions and system calls that programmers can use during development. These things said, it is also important to understand that if a honeypot is supposed to look and act like a Windows 2000 server, there really is no other practical way ^[7] to achieve the desired look and feel than to deploy a Windows 2000 platform.Additionally, certain honeypot tools run only on certain platforms (for example, Solaris).

^[7] Some might disagree with this statement; it is possible to use a tool such asVMWare to run Windows NT on a Linux platform.

You need to harden the operating system you use as much as possible. ^[8] Although a discussion about hardening UNIX (or any other operating system) is outside the scope of this book, at a minimum, you will need to delete unnecessary services (in /etc/services in some flavors of UNIX, /etc/inetd.conf in others), modify the /etc/inittab file to run your host no higher than runlevel2 (in most UNIX systems), and delete all passwords except for the root password and the unprivileged account(s) to which root users must first log in before using su to obtain a root shell. You can then install the tools or routines needed to implement the honeypot.

^[8] The same principle applies to any other operating system you might use. SANS (www.sans.org) publishes step-by-step guidelines for hardening Solaris, Linux,Windows NT and Windows 2000.

How Many?

In principle, security needs should be the main driver of the number of honeypots to be deployed. Suppose, for example, that a business has been losing a considerable amount of money due to multiple attacks and that the "crown jewel" servers are highly at risk. The most logical first step, of course, is to tighten the security of these servers (for example, through carefully configured packet filters). In this example, however, it might be wise to deploy many dozens of honeypots throughout the company's network to provide reconnaissance concerning the nature of possible malicious activity and the degree to which it might be occurring. In another case, a company might want to place only one honeypot in a demilitarized zone (DMZ) to determine the kinds of externally initiated attacks that are likely to occur.

The quantity of honeypots needed also depends on many other variables, one of the biggest of which is the cost of the platforms that house the honeypots. Sometimes you can get by with older hardware platforms that nobody wants (and that are thus cheap or possibly even free), but sometimes you can't. Certain commercial honeypot implementations require higher ended (and thus more expensive) hardware, for example. Additionally, relevant variables that affect the number of honeypots deployed include the cost of any commercial software needed; the personnel costs associated with creating, installing, maintaining, and monitoring each honeypot; the availability of IP addresses; and possibly others.

Where Should You Place Each Honeypot?

The best answer (not intended to be frivolous) to this question is that honeypots should be placed where they are needed. In general, if externally initiated attacks are currently the major impetus for honeypot deployment, you should place the honeypot(s) on a DMZ ‚ preferably an external DMZ (in front of the firewall), as shown in Figure 12.1. If the major interest concerns activity within an internal network, honeypots can be dispersed throughout this network, perhaps one in every subnet (if subnets are used). In general, we have found that dispersing honeypots works better (in terms of the number of hits that each honeypot receives), but like everything else, this is not always true.

Figure 12.1. Possible placement of a honeypot to trap external attackers.

Additionally, it is important to ensure that any honeypot . . .

• Is router-addressable. (Otherwise, it will be reachable only by hosts within the same local network.)

• Has a static address. (Otherwise, it will be difficult for attackers to stumble onto the honeypot and return to it afterward.)

• Does not remain in any single location too long, unless being in that location results in a satisfactory number of hits."If at first you don't succeed, try, try again."

Security of the Honeypot Itself

As mentioned earlier in this chapter, any honeypot is also a potential victim. It thus must be sufficiently secure in all ways except in the functions that must be open to attackers. These functions must be self-contained so that attackers cannot break out of them and gain access to a system and its resources. Security, of course, can never be absolute. You must therefore assume that, sooner or later, a dedicated attacker can and will break any honeypot's defenses. Accordingly, it is important to avoid placing critical or sensitive services, applications, and data on the same physical platform as a honeypot. It is best to devote each physical platform on which a honeypot resides to honeypot functionality. In other words, secure the honeypot as well as you can but avoid taking unnecessary chances with the things that are most valuable .

Finally, ensure that any log data that honeypots produce is well protected. Giving log files obscure names and making them into hidden files might help a little, but both of these measures are little more than examples of efforts designed to achieve "security by obscurity." Assigning strong permissions (for example, so that they are not accessible in any way, especially via read and/or write permissions, only by the superuser) is a better measure. Frequently harvesting the data is probably the most effective measure (so that if anyone alters or deletes log data, you already have him or her), but make sure any remote connections to honeypots for the purpose of data transfer are via an encrypted channel (for example, a virtual private network or secure shell). An organization might want to place IDS engines around a honeypot to assess its security, as one would place these engines around a firewall.

Getting Honeypots Noticed

You might or might not want to get a particular honeypot widely noticed. A reason for not wanting a honeypot to be widely noticed is to obtain some realistic data concerning the severity of the threat to hosts within your network. If you refrain from giving any special clues to potential attackers, any attacks that occur are likely to represent a realistic level of attack activity rather than one that results from drawing attention to systems within your network. Another reason is that a very deceptive honeypot might generate entirely too much activity. The result might be a massive network clog. Additionally, it is probably not even necessary to advertise the presence of a honeypot to get it attacked. Josephine Schwabel, Nick Rohring, Mike Hall, and Eugene Schultz ^[9] placed a Linux-based honeypot in a university network without doing any advertising of the presence of the honeypot whatsoever. The honeypot soon started receiving scores of attacks anyway. Remember, there are individuals who are desperately in need of a life! They appear to do little more each day than to scan and then attack systems indiscriminately.

^[9] Schwabel, Josephine, et. al."Lessons learned from deploying a honey pot." Information Security Bulletin , 2000,Vol. 5, Issue 10, pp. 23 ‚ 36.

Plan B is to deliberately draw others' attention to the honeypot(s). The motive, in this case, often varies from attracting a number of attackers for the purpose of conducting a network trace on each connection, to identifying a range of attack signatures or tools, to identifying the presence or attack signature of one particular person. One way to ethically draw attention to honeypots is to briefly install a web browser in the honeypot and then visit a variety of web sites. With all the sniffers over the Internet, you'd be surprised to learn how many attackers will pick up the honeypot's IP address. Another way is to post to newsgroups with content such as "I don't understand very much about security, but I need to secure my server ‚ can you give me some advice?" Still another way is to do a cleartext remote login into a bogus account on the honeypot from several locations. It is important, however, to refrain from inviting, challenging, or taunting anyone into attacking the honeypot ‚ to do so is not only ethically questionable but also possibly against the law.

Evaluation

When each honeypot implementation is finished, take the time to evaluate the honeypot to ensure that it meets requirements before actually deploying it. Does it do what it is supposed to do? Does the implemented honeypot conform to your organization's computer and information security policy? Has the honeypot been implemented with adequate consideration for security? Is the honeypot credible? What are the current security-related weaknesses, and what (if anything) can be done to counter them? One of the main reasons many honeypots are less successful than anticipated is failure to perform an evaluation of this nature.

Testing

A final deployment consideration is testing. It is not a good idea to deploy any honeypot without testing it first. After all, the honeypot might have security-related vulnerabilities of which you are not aware. An attacker might be able to exploit these vulnerabilities to subvert your honeypot (and perhaps also your network and everything within it!). Running a vulnerability scanner such as Nessus or nMap is a good first step. If the honeypot passes a vulnerability scan, it is a good idea to next conduct some penetration tests against the honeypot. (We assume, of course, that anyone who conducts a vulnerability scan or penetration test will be wise enough to first obtain written permission from management.) It is important to view testing as part of the honeypot life cycle; hacking tools and attack techniques are constantly becoming more sophisticated. A honeypot that passes a vulnerability scan or penetration test today might not be able to pass in a few months. Additionally, new vulnerabilities, some of which could be exploited in honeypots, are constantly being identified.

Now that we have covered initial considerations and deployment issues, let's turn our attention on how honeypots are implemented. The next section addresses this issue.

Honeypots as Legal Evidence?

One of the most interesting controversies concerning honeypots is whether they can be used as evidence in legal proceedings . Considerable folklore but little fact surrounds this issue. To the best of our knowledge, there is no legal precedent concerning whether or not evidence gleaned from honeypots is admissible .

Suppose that no laws are broken in setting up and running one or more honeypot(s) and that the evidence from honeypots is gathered and handled properly. In theory, the evidence should be legally admissible. This speculation might be moot, however. Lance Spitzner, someone to whom we referred earlier in this chapter, believes that any discussion of issues concerning legal evidence from honeypots is irrelevant. He says that honeypots should not be used to apprehend attackers; rather, they should be deployed to discover what attackers are doing without them recognizing that they are being observed and studied. Others disagree, saying that the magnitude of the cybercrime problem is so great that any legal means to identify and convict computer criminals should be used.

Case Study: The Deception Tool Kit (DTK)

DTK ^[10] is one of the most widely known and used honeypot toolkits. The following section looks at DTK as an example of how to implement a honeypot.

^[10] This tool is available from a number of web sites, including www.all.net and www.packetstormsecurity.org.

About DTK

With DTK, you can build your own custom honeypot implementation. DTK runs "state machine" scripts ‚ that is, scripts that fake the various states involved in connecting to services ‚ on ports of your choice. Consider, for example, the nature of a Simple Mail Transfer Protocol (SMTP) connection on TCP port 25:

1. The sender sends 'HELO <server name>' as an introduction; the <server name> is a string identifying the name of the sender.

2. A 'MAIL FROM: <e-mail address>' that specifies the email address of the original sender of the message is then sent.

3. The sender sends 'RCPT TO: <e-mail address>', where <e-mail address> is the address of the email recipient.

4. The 'DATA' command followed by all the data in the email message, including headers appended to the message by intermediate servers as well as the text, is sent.

5. A 'QUIT' command is sent.

RFC-compliant SMTP implementations include these five states in the order shown here. DTK allows someone to create a fake mail service by implementing state files that emulate all of these states. Mail is not the only service that DTK can fake, however. DTK can also fake systat , chargen , ftp , telnet , time , domain , tftp , finger , http , pop-3 , exec , rlogin , rshell , nfs , and others.

Functionality

In addition to being able to fake services, DTK logs a considerable amount of data. It not only timestamps and records each connection attempt (whether or not it is successful), it also records every keystroke entered. Log data are sent by default to /dtk/log . Sample output appears in Figure 12.2.

Figure 12.2. Sample DTK log data.

Additionally, DTK can provide an alert in the form of an email message, a pager signal, or a message written to a console, if an attack occurs.

How DTK Works

DTK is a Perl script implementation that runs on UNIX hosts (although it can be ported to other operating systems). It can run as a standalone background process (based on inetd , the inet daemon), or it can replace inetd with a special Perl script, listen.pl . It has at least one state-machine script for each to-be-faked port, but it can easily be modified to include more detailed emulation of services.

An Evaluation of DTK

The fact that we have discussed DTK in this chapter should not be construed as an endorsement of this tool, that we think it is the honeypot tool you should use. In the long run, it is generally best to buy a tried and proven commercial honeypot, one that not only offers high quality deception but that also is very difficult to compromise. DTK, however, is an excellent tool for getting started with honeypots ‚ to learn how to set one up, deploy it, and monitor the activity that occurs. Some of the positives of DTK include easy installation, the fact that it delivers only bogus services, its modifiability and extensibility (see the following sidebar), its low CPU consumption, its capability to log a considerable amount of information (including timestamped keystrokes), and the fact that Fred Cohen, the author/developer of this tool, has imposed very reasonable terms and conditions of usage.

DTK is not perfect. Disadvantages include portability problems (it is not as easy to port DTK as might be expected), the fact that creating warning banners is difficult, the fact that the log file ( dtk/log ) format is difficult to read, and the limited degree of realism that can be achieved with DTK. The last point is particularly important. When you set up a DTK server, it looks and feels like a DTK server. DTK is very simple and straightforward; experienced attackers are almost certain to detect that they are connected to a DTK server and thus make their exit quickly. DTK proponents respond, however, that by making other (non-honeypot) systems look and feel more like DTK, this problem can at least be solved to some degree.

An Example of DTK's Modifiability

DTK's modifiability is one of the best things about it. Suppose, for example, you want to expand deception capabilities to 100 hosts. The following script will cause DTK to monitor the first 100 addresses within a certain class C subnet. This script creates 100 new entries in the /etc/sysconfig/network-scripts directory.

 RANGE="128.0.0"  for I in 1 2 3 4 5 6 7 8 9 10 _ 96 97 98 99 100  do  echo "DEVICE=eth0:$(i)  IPADDR=$(RANGE).$(i)  NETMASK=255.255.255.100  NETWORK=$(RANGE).100  BROADCASE=$(RANGE).100  ONBOOT="yes" > /etc/sysconfig/network-scripts/ifcfg-eth0:$(i)  echo n "$(i) " 

Putting Honeypots into Perspective

Are honeypots a valuable tool in the war against cybercrime and computer misuse? Some say no. Critics often say that it is better to simply shut down services than to run on dangerous ports. Others say that honeypots are a form of "poor man's security," that they provide a way for an organization with few security controls to achieve at least some degree of security. Others view honeypots as a type of intrusion detection measure. Remember that most IDSs are not very proficient in detecting certain kinds of attacks, especially insider attacks. Honeypots, on the other hand, are well suited to detecting insider attacks. Still others view honeypots as measures that serve a security control function; they protect against undesired access to systems and networks or at least slow this kind of access down.

We are confident that honeypots are capable of meeting a wide range of needs. They can, for example, serve as both an intrusion detection measure and a kind of deterrent to attackers by slowing attackers' efforts. They might also be useful in reconnaissance efforts: learning what attackers are doing, what they are trying to attack, and how often and how hard they are doing it.We do not view honeypots as mainstream security-control measures, however, but rather as adjuncts to these measures. They do not really stop attacks, although they can deter and deflect attackers' efforts. They can also provide an early indication that attacks against systems and networks are occurring as well as information about the patterns of the attacks.

We would also like to once again emphasize that it is unwise to deploy honeypots without considerable planning. Setting up suitable precautions in the event that Murphy's Law prevails is imperative. What if attackers compromise the honeypot? What if bona fide users connect to the honeypot and become confused ? Consider also that a honeypot might provide conclusive evidence that someone in your organization, possibly even a senior manager, is involved in malicious or downright illegal activity. What should your next step be? It is critical to carefully analyze and solve these and other similar issues well in advance of any honeypot deployment.