Creating and Deploying a Honey Pot
David Endler A honey pot or trap system, was first described in the book The Cuckoo's Egg, in which astrophysicist Clifford Stoll used decoy computer information to trap a computer cracker at Lawrence Berkeley Labs. Bill Cheswick and Steven Bellovin at AT&T describe a similar method to trap and monitor their infamous cracker, Berferd, in the book Firewalls and Internet Security. Currently, there is no intelligible guide on how to design and implement your own UNIX honey pot. As the name suggests, the main idea behind a honey pot is to tempt crackers and intruders away from critical information with bait in the form of a seemingly vulnerable computer host. By doing this, we hope to glean information about the identity, motives, and skill of a potential perpetrator, which is sometimes more valuable than simply terminating his connection. Once an intruder gains access to the honey pot, it is useful to provide further bogus information to keep him logged in and occupied so that he might give himself away. Properly configured honey pot systems have the ability to observe new attacks and hacking methods without putting a production server at risk. However, there are obvious dangers involved with tricking a cracker and making a system seemingly vulnerable. There are also major legal considerations to keep in mind before you start monitoring traffic and possibly breaking the law. Hunting for Crackers Cliff Stoll's The Cuckoo's Egg is an entertaining read, as well as an informative narration of how crackers operate. Stoll worked as a computer manager for Lawrence Berkeley Labs in Berkeley, California. In 1987, while routinely looking through accounting data, he noticed a 75 cent discrepancy in the two files used to store users' computer time. The logs suggested that a computer user had used 75 cents worth of computer time and erased it from one of the files. This was significant for two reasons. First, to do this, someone must have achieved unauthorized root access. Second, this person was using the Berkeley systems to attack other research and military computers, but was unaware there were two accounting files. Stoll deleted the user's account, but the cracker logged in under another username and again erased his accounting information causing another discrepancy. During that period in the electronic age, there wasn't as much legal red tape involved with monitoring computer systems. Stoll had the computer print out the cracker's keystrokes on boxloads of paper, rigged the computer system to alert him when the cracker logged in, biked from home to monitor the activity, and sometimes even slept under his desk. Whenever the cracker seemed about to disclose information or danger university resources, Stoll would cause some sort of explainable system failure to prevent this from occurring. The problem was that it took incredible devotion and inconvenience for Stoll to be present every time the cracker logged in. This left the Berkeley systems in danger if the cracker decided to get nasty when Stoll was not supervising. Finally, Stoll decided he needed to keep the cracker logged in long enough so that authorities could establish a successful phone trace. His solution was to create a bogus secret military project with a make-believe staff. He created “sensitive” emails and files to keep the cracker occupied while the traces were being conducted. Eventually, through a long series of wiretaps, the cracker was tracked to Hannover, West Germany, and busted by the local police. Ultimately, the German authorities found out that the cracker had been selling U.S. military information to the KGB -- serious indeed. In today's real world, where millions of dollars are stored in databases, would a 75 cent error actually cause many corporations to sound the alarm? Another example of a cracker hunter is Bill Cheswick of AT&T, who in 1991 wrote the enlightening paper, “An Evening with Berferd.” He describes how he and co-worker Steve Bellovin trapped an Internet cracker who tried to mail himself a password file through the famous Sendmail debug hole. Cheswick decided to play along with the cracker and created a booby trapped user account named “Berferd” with limited commands and functionality -- a kind of filesystem chrooted “jail.” He then mailed the cracker a bogus password file with the Berferd account password intentionally weak and crackable. To secretly monitor the cracker's activity, the pair used the network sniffing program, tcpdump, to reassemble his keystrokes and commands. Cheswick and Bellovin traced the cracker's activities for several months, while also developing many useful tools that were eventually integrated into a trap system. They subverted the ftp, telnet/login, SMTP, rlogin/rsh, and finger services with replaced functionality to better detect the intrusive actions of their cracker. For instance, whenever the cracker would finger the user account Berferd to check whether his target was actually logged in, a message would alert Cheswick in the logs. Cheswick and Bellovin further developed the idea of the honey pot system with their modified versions of popular target services (telnet, SMTP, etc.), but eventually concluded that the monitoring effort was tedious. A more detailed account is included in their book, Firewalls and Internet Security. Building a Honey Pot There are two main schools of thought on how to prepare a UNIX system as a honey pot -- I will mention both but only elaborate on the second one, mostly because it is more interesting. The two methods are:
• Method 1: A non-rigged honey pot computer as bait and another host acting as a monitoring station. • Method 2: A rigged honey pot system with built-in monitoring -- a virtual environment that appears to the user as an ordinary UNIX host but actually captures important information about the intruder.
These methods are shown in Figure 1. The first method involves understanding that if a skilled cracker gains a UNIX shell account on your system, there's a distinct possibility the attacker may eventually find a way to gain administrator root access. With this in mind, the best way to deploy a honey pot system is to put a regular, non-rigged computer outside the firewall with actual security holes and an unpatched operating system. Then, place another hardened monitoring host running a network sniffer on the same segment. The monitoring host could run off a CD-ROM with a few modifiable files located on a floppy disk, minimizing the potential damage to the monitoring station. This technique also makes it easy to deploy several images of a monitoring station on CDs simply by updating the pertinent system files stored on the floppy disks. With this method, however, your monitoring can be defeated if the cracker installs or uses a form of encrypted traffic to access the honey pot such as ssh (Secure Shell -- information available at http://www.ssh.fi/). The cracker can also defeat the monitoring station by inserting extraneous packets into the data stream to make sure no one is listening in on his connection, making it tedious to separate and reassemble the intruder's network datagrams. If your honey pot system is compromised, it is important to obstruct all outbound traffic on the firewall from the honey pot in order to prevent a lawsuit against your organization. If you think a cracker may get wise to the fact that he is unable to use your honey pot as a staging ground for other attacks, you could open up a few services to belay suspicions. A few outbound services you could open up on the firewall are DNS, ftp, and finger. Today, it is fairly common for company intranets to block most outgoing traffic to protect the flow of confidential information. Method 2 involves fortifying and rigging a honey pot computer system so that it logs information on the cracker. The monitoring in this method takes place on the honey pot itself, but the cracker is also tracked using a network sniffer on the firewall host system. The firewall provides a layer of redundancy by logging incoming connections as well as all outbound attempts. The remainder of this article focuses on Method 2. Rigging the Honey Pot The most effective method for deploying a honey pot is to create a virtual environment that appears to the intruder as an ordinary UNIX host, but secretly logs information and reports on the intruder's activities. This method, (Method 2 in Figure 1) is typically accomplished through phony services on the honey pot machine. A phony service is usually a service that the cracker will want to access in order to carry out an attack (such as finger or telnet). The phony service accepts input and displays output in a way that is indistinguishable from the service it is intended to mimic, but it has additional, hidden functionality that records information and masks details of the actual configuration. The most effective honey pot systems can be built with a minimum of hardware and software (see sidebar “Choosing the Hardware and Operating System”). All of the software can be found on the Internet for free as public domain. With regard to most of the public domain software mentioned here, I first recommend installing the public domain tool tcp wrappers, which provides a finer level of granularity over how services are invoked and logged. Tcp wrappers is a program package that provides tiny daemon wrapper programs that can be installed without any changes to existing software or to existing configuration files. The wrappers record the client host name of incoming telnet, ftp, rsh, finger, etc. requests and provides security options including access control per host, detection of host name spoofing, and traps to assist with deceiving an intruder. After installation, you are ready to start rigging your honey pot with phony services. For instance, suppose you wish to booby trap the finger service on your honey pot. You want to first log any user being queried, then track the source and identity of the person initiating the query, and finally be able to control the results. Look at the /etc/inetd.conf file after installing tcp wrappers and notice the line:
#finger stream tcp nowait nobody /usr/sbin/tcpd in.fingerd Replace the normal finger services with another finger daemon -- one that won't show actual finger information, such as if the root user is currently logged on. There are several publicly available tools, such as cfingerd and sfingerd, but I prefer a simple one written by Mike Shanzer available at ftp://ftp.foobar.com/pub/fingerd.tar.gz. This version is capable of logging and showing different finger output based on the username queried. After you have compiled the source code, the new fingerd, executable should be placed in /usr/sbin under the name new.fingerd and the line in inetd.conf should be uncommented and changed to:
finger stream tcp nowait nobody /usr/sbin/tcpd new.fingerd Restart inetd with a kill -HUP pid to initiate the changes. Instead of a cracker seeing something like this:
% finger root@honeypot.com [honeypot.com] Login Name TTY Idle When Where root root pts/7 <Sep 2 09:47> server4 you could custom tailor the fingerd access logs so that he sees:
% finger root@honeypot.com [honeypot.com] SUPER SECRET FILE SERVER This is a privately owned computer server. Unauthorized access is prohibited and illegal. Use of this system assumes consent to monitoring. Login Name TTY Idle When Where root root pts/7 <Jan 1 12:47> console The finger attempt will be written to syslog and look like this (depending how you configure your tcp_wrappers and fingerd):
Sep 12 22:58:29 honeypot fingerd[8444]: from=evil@cracker.com to=root stat=OK Notice that the from=evil@cracker.com will only show up if the cracker has foolishly enabled the identd services on his computer. Most of the time, the username will be unknown but it's always worth a try to identify him. Inevitably, a cracker will try to connect to your honey pot and gain access to a UNIX shell. There are two ways to rig telnet/rlogin access to trace the intruder's activities. The first is to simply drop the user into a bogus login program that doesn't let the him log into the system, but does record his attempts. I've included a program that I slapped together to accomplish this (see Listing 1: telnet_plugin.c). Notice the login banner shows the system to be Solaris type, although I am actually running RedHat Linux; sometimes it's good to keep the crackers guessing. Change the script as you like, mileage may vary. Once you compile it, you can rig the telnet service by rewriting the line in inetd.conf again. For instance:
% gcc telnet_plugin.c -o new.telnetd % mv new.telnetd /usr/sbin % vi /etc/inetd.conf then edit the appropriate line in inetd.conf file to read:
telnet stream tcp nowait root /usr/sbin/tcpd new.telnetd and finally restart inetd:
% ps -ef | grep inetd
root 140 1 0 Aug 26 ? 2:36 /usr/sbin/inetd -s
% kill -HUP 140
Now when anyone tries to telnet to the honey pot:
% telnet honeypot.com UNIX(r) System V Release 4.0 (honeypot) login: root Password: Login incorrect login: the attempt gets logged to syslog as something like:
Sep 12 22:58:36 honeypot telnet_plugin[9567]: Someone tried to access telnet port with username:root and password:qwerty The second technique is riskier but can be more interesting and informative to implement. This involves letting the cracker gain access to your honey pot system and explore a UNIX shell. This can be dangerous, depending on the skill of your intruder and whether you can successfully create a jail environment, much like Cheswick and Bellovin's. I have developed many variations of a chrooted jailed environment and have found that the most convincing ones have been the most simple. The most successful jailed environment had few functional commands, and the ones that worked were trojanized so as not to reveal the monitoring programs on the system. Ironically, the most effective tools I have found in creating these “cracker traps” have been in the rootkit distributions widely available on the Internet. A good place to start is www.rootshell.com and searching for the word “rootkit” -- there should be a few Linux versions and a Solaris version as well. In a nutshell, a rootkit is a group of files and hacking tools that an intruder can install on the system to leave backdoors, install password sniffers, and subvert and replace commands like ps, ls, finger, top, inetd, etc. to hide his tracks. These Trojan horse commands are extremely useful in the creation of a virtual environment for the cracker. For instance, I have a honey pot system with a rootkit version of ls, which will display in my rigged account:
% ls /var/spool calendar cron locks lp mqueue pkg when the actual contents of the directory are:
%/usr/bin/real-ls /var/log calendar cron locks log lp mqueue pkg This is accomplished through a simple file of names (usually something called /dev/ptyr), and each named is parsed and filtered out of the corrupted ls output. For example, here a few of my file words that I prevent the intruder from seeing:
ptyr real-ls log real-ps real-top real-finger shadow .hidden syslog sulog hosts.deny hosts.accept Similar Trojan horse binaries are available for many other information gathering tools, such as ps, top, etc. By studying the implementation of a jailed login account, and purposely leaving files around that contain the type of interesting bait mentioned earlier, you can start to get a better sense of how a honey pot works. The probability of a cracker eventually breaking through your jail is pretty good, so be wary. You might want to back up an image of your final honey pot design on CD so that it can be quickly restored and deployed. I have demonstrated a couple of services for which you can rig traps, but there are many more tools. A few more system services that may be of interest to a cracker and would be worth your while to booby trap are listed here.
• The r* commands rsh, rexec, and rlogin can be trapped with a useful program called rsucker.pl, available at:
http://www.rootshell.com.
• The SMTP port is a cracker's favorite to telnet into, to see if you are running the most currently patched version of Sendmail. Would you believe some script kiddies still look for the old debug hole? A useful interactive Trojan server could be written using the telnet_plugin.c code in this article as a guide, with the same sort of method to install in it inetd.conf. • The ftp server that ships with most versions of UNIX (wu-ftp) still has vulnerabilities published once in a while, so it might be interesting to see what sort of activity you can trap here. Again, another useful server here could be written from the skeleton of the telnet_plugin.c code. • Miscellaneous port connections and probes can be detected with a combination of tcp wrappers and klaxon.
I hope this gives you a good idea on how to replace common services with monitored equivilents that act similarly. Remember that the goal is to monitor an intruder stealthily, or risk being discovered and incurring the wrath of a cracker and his online friends on other parts of your network. Monitoring Behind the Scenes To preserve the clandestine nature of observing the cracker at work, the monitoring aspect of your honey pot method must be invisible on the network. As shown in Figure 1, the firewall system in method 2 is meant to capture the network traffic travelling inbound from the Internet to your trap system. In addition to the normal amount of connection logging a firewall is capable of, I have also installed a packet sniffer to have a complete transaction, keystroke by keystroke, of any intruder's sessions. It is generally a good idea to have a layered and redundant monitoring scheme in case any aspect fails. The easiest to use and most configurable network sniffer for Linux is sniffit (search for it at rootshell.com). It stores the recorded sessions in easy to read and organized files based on the IP address of the originating connection. For instance, the following telnet session to a BSD-ish looking honey pot:
Connected to honeypot.com
Escape character is '^]'.
BSDI BSD/OS 2.0.1 (honeypot.com) (ttyp1)
login: dave
Password:
Last login: Mon Sep 13 05:04:36 from localhost
Copyright 1992, 1993, 1994, 1995, 1996 Berkeley Software Design, Inc.
Copyright (c) 1980, 1983, 1986, 1988, 1990, 1991, 1993, 1994
The Regents of the University of California. All rights reserved.
BSDI BSD/OS 2.1 Kernel #1: Mon Nov 24 20:30:47 EST 1997
You have new mail.
% ls
Mail Private Files .cshrc
%
would be recorded in two files, the first file would hold the incoming traffic to the honey pot:
dave password ls and the other file would be the outbound echoing of the terminal back to the intruder:
BSDI BSD/OS 2.0.1 (honeypot.com) (ttyp1)
login:
Password:
Last login: Mon Sep 13 05:04:36 from localhost
Copyright 1992, 1993, 1994, 1995, 1996 Berkeley Software Design, Inc.
Copyright (c) 1980, 1983, 1986, 1988, 1990, 1991, 1993, 1994
The Regents of the University of California. All rights reserved.
BSDI BSD/OS 2.1 Kernel #1: Mon Nov 24 20:30:47 EST 1997
You have new mail.
%
Mail Private Files .cshrc
%
This is a simple way to track everything happening on the honey pot and, as you can see, the sessions are easy to combine. Also, the sniffer logs should be pretty safe on the firewall itself. The only problem left to solve is what to do with these log files accumulating on the honey pot. It is usually a bad idea to keep your log files on the same host that you are monitoring, in case a cracker does see through your smokescreen and deletes all traces of his actions. Remote logging of syslog traffic would probably clue a cracker in to the true nature of the trap if he were to sniff the data going across the network. Here are a few ways to safely record and transfer the information off the honey pot:
• Use a one-way serial connection to upload the files to another storage system. • Use a secure form of syslog to transfer the files to the firewalled monitoring host (ssyslog by CORE-SDI and syslog-ng by BalaBit Software are both free). • Follow Cliff Stoll's example and cause all output to be printed to hardcopy in addition to one of the above methods. • Attach an electronic write-only device (apart from a printer) and funnel the data through this channel. Response and Termination Once an intruder has taken the bait of the honey pot and broken in through weak access controls, what should you do next? It is only a matter of time after gaining root access that the cracker will figure out he is on a honey pot. The best advice is to track him for as long as possible, teasing him with the best formed bait you can. After you feel you have exhausted the realm of phony information and rigged services and think the intruder has done quite enough on your network, you can reboot the honey pot under the guise of system maintenance and repair the damage. After you have combed over the log files and looked through all the recorded sessions, you might have a better idea of the cracker's motives and skills. Hopefully, you can then prevent the same things that happened on your honey pot from happening to your real servers, which may be just as vulnerable to attack. In judging the amount of penetration that occurred on your system, you should consult with your organization's legal department to decide whether prosecution is feasible. If you think you may have enough evidence collected to litigate, be sure that you and your organization understand the implications of going public with this information. Also, make sure that you have followed all the proper legal guidelines and procedures so that the cracker cannot escape on a loophole. Conclusion Network Associates has developed a commercial “sting” product that can emulate different operating systems. Fred Cohen also developed a free software package called the Deception Toolkit that has most major services rigged for monitoring, and it installs nicely on most platforms. It seems that people are starting to take notice of the benefits of deception information technology. Obviously, we have surpassed the day that firewalls and border controls were enough to protect an organization from attack. Unfortunately, many security architectures still blindly focus on their perimeter protection while neglecting the systems within their networks. Once an intruder has penetrated through the outside defenses, he can have his way with a multitude of unprotected servers and hosts, causing millions of dollars of possible damage and information theft. The objective of using decoys and trickery on the exterior is to better fortify your exposed interior machines from attack. In doing so, you will also gain a better understanding of the psychology of your network intruders. Happy baiting! Bibliography Amoroso, Edward. Intrusion Detection, Intrusion.Net Books, 1999. Cheswick and Bellovin. Firewalls and Internet Security, Addison-Wesley, 1994. Cheswick, Bill. “An Evening with Berferd,” 1991. Flynn, Jeff. “How to Trap the Network Intruder,” in Information Systems Security, Winter 1998. Icove, Seger, and VonStorch, Computer Crime, O'Reilly and Associates, Inc., 1995
Spitzer, Lance. “To Build a Honeypot,” 1999. http://www.enteract.com/~lspitz/ \ Tools and Resources Fred Cohen's Deception Toolkit: http://www.all.net IDS mailing list: send an email to majordomo@uow.edu.au with the body “subscribe ids” Mike Shanzer's fingerd: ftp://ftp. foobar.com/pub/fingerd.tar.gz Open source security tools: http://www.opensec.org Rootshell.com: http://www.rootshell.com Tcpdump and other tools: http://ciac.llnl.gov/ciacToolsUnixNetSec.html. Tcp wrappers: ftp.porcupine.org/pubsecurity.
About the AuthorDavid Endler is a consultant for Deloitte & Touche LLP in the E-Business Technology and Security group. He has his BS and MS in Computer Science from Tulane University. Currently, he is writing a book on intrusion detection and welcomes comments at: dendler@dttus.com. |