Article

sep2003.tar

How to Build a Honeypot

Kristy Westphal

The wave of interest behind honeypots has grown to epic proportions recently. Besides the significant information that can be gained from them, honeypots have gained notoriety because some of the consequences of deployment have been brought into the limelight. Not only can there be downstream liability issues, but the standard of due care may also be in question with the use of a honeypot. In this article, I will look at all aspects of honeypots: what they are, how to deploy them, and what should be considered before deploying them.

According to Webopedia.com, a honeypot is: "An Internet-attached server that acts as a decoy, luring in potential hackers in order to study their activities and monitor how they are able to break into a system." Other terms that are associated with honeypots are honeynets (decoy networks), and honeytokens (decoy information hidden in areas like databases). This article will concentrate on honeypots.

Uses and Types

There are many uses for honeypots, including pure research. Many new types of attacks and malware can be studied in isolation on these systems, unbeknownst to attackers. Another use is as a decoy system on a production network to divert an attacker from the true information assets within your network. Other uses include a version of an intrusion detection system, a forensic tool for dissecting attacks after the fact, and a tool to fight spam.

A honeypot can be almost any type of server or application that is meant as a tool to catch or trap an attacker. However, a further distinction within honeypots is the honeypot vs. the virtual honeypot. The former is typically a hardware device of some sort, whereas the latter is a software implementation.

Honeypots 101

Many tools are available, both in freeware and commercial packages, with which to build a honeypot on Unix. A good listing of tools can be found at the Network Intrusion Web site listed in the Resources section. Tools that will be covered in this article include LaBrea Tarpit, Tiny Honeypot, and Honeyd.

An interesting feature of honeypots is that most of the available packages differ greatly, offering you many options in your honeypot pursuit. For instance, LaBrea Tarpit is more of a diversion tool, making it appear that there are more devices on a network than there really are, whereas honeyd is an OS deception tool that can obscure the true operating system and confuse attackers. Details on each of these are listed later in this article.

Considerations

Before you set up a honeypot, you must consider what you want out of it. If you want a toy, then I recommend not setting up a honeypot on your company's network. If you are purely interested in the research aspect of honeypots, again, I don't recommend trying this at work unless research is a part of your job. Further, if you wish to purposely trap intruders for the purpose of pursuing legal recourse, I suggest you reconsider using a honeypot at all. If, however, you need another layer of security to help mitigate risks within your company, then a honeypot might just the right thing.

Once you determine the goal of your honeypot, the answer to the next consideration becomes readily apparent: how should the network environment of the honeypot be established? It can be very dangerous to leave an intentionally fake system called "Investment" or "Payroll" in your network DMZ with the other servers that exist there. If the honeypot is revealed for its true purpose and is compromised, then you run the risk of compromising the other systems within your DMZ, or worse, ultimately your corporate network.

Out of this consideration, the "honeynet" concept was born. A honeynet is actually an isolated network that holds your honeypot. If the honeypot is compromised, then the danger of anything of value being accessible is lessened. If a honeynet is not possible to implement, then you can lock down the honeypot host itself using such tools as firewalls, chroot jails, and host-based intrusion detection.

The key to implementing a honeypot correctly is to ensure that its architecture is carefully thought out, and to ensure that your honeypot meets the requirements of your information security policies. Even when implementing a honeypot on your home network, you should strongly consider a secure architecture because you could possibly violate the Acceptable Use policies of your ISP by having your compromised honeypot attack its other customers. The lesson here: do your homework and implement wisely. Honeypots are not to be taken lightly.

Legal Issues

Before implementing a honeypot, you must understand the legal issues involved as well. Unfortunately, in addition to becoming popular, honeypots have also come under a lot of criticism recently. Two of the packages discussed in this article have been subject to distribution limitations because of U.S. state law adoption of the S-DMCA legislation, defining unlawful communication devices as "any communication device which is capable of... facilitating the disruption... of a communication service without the express consent or express authorization of the communication service provider..." (see the Hackbusters Web site). Niels Provos, creator of honeyd, had to move all of his research on the topics of steganography and honeypots to a location outside of the United States because of Michigan state laws put into effect this year. Tom Liston, the creator of LaBrea Tarpit, who is a resident of Illinois, stopped distributing his software for the same reason.

While it is still unclear and untested that honeypots in fact violate the law, it is important to keep in mind that these restrictions may apply to you, depending on where you live. To inquire about which laws may apply to your particular situation, you should start with your legal department. Furthermore, please refer to the resources area for a link to the Electronic Frontier Foundation to assist you in this clarification.

Other areas that may apply when implementing a honeypot include:

Possible violation of the "standard of due care". Businesses today are expected to apply some level of security in order not to be a bad Internet neighbor. A honeypot might be considered a bad neighbor type of behavior.
Peripheral attack -- where your compromised honeypot is used to attack others (i.e., denial of service or virus infection).
Honeypots can also be considered a means of entrapment.

To ensure that you're covered, implement the most verbose log servers available. The best scenario is a secure, remote log server, with whatever honeypot that you choose, to properly preserve any evidence that might be needed. This, of course, will help you in your research of the attack, so the log server serves two purposes.

LaBrea Tarpit

The LaBrea Tarpit is a freeware honeypot created by Tom Liston that will run on any flavor of OpenBSD, Linux, Solaris, or Windows. I installed LaBrea on a Red Hat 7.3 Intel platform. On its Web site, LaBrea describes itself as a "sticky honeypot", where LaBrea borrows unassigned IP addresses on the network it resides in and acts like hosts on those address that will respond to connection attempts. LaBrea uses a technique to slow the connection attempts so the attacking machine becomes "stuck". The general focus of this honeypot is to slow down hackers and worm viruses by keeping the connections alive for indefinite periods of time.

Before you install the LaBrea distribution, you will need to install the libnet library found at:

http://www.packetfactory.net/libnet

To build it, simply gunzip and untar the download, then configure, make, and make install.

To get started with LaBrea, you can find the latest release at:

http://labrea.sourceforge.net/labrea-info.html

Follow the link to download the latest version. There are two files: the source itself and the signature file (this has the md5 checksums so that you verify the validity of the download). The latest stable version is 2.4. Gunzip and untar the two files:

Gunzip LaBrea2_4-unix-stable.tar.gz
Tar xvf LaBrea2_4-unix-stable.tar

You will now have a directory called: LaBrea2_4. Cd into this directory, then run the make command. It is then recommended that you closely read the LaBrea.README file to understand the features of this distribution. LaBrea works by monitoring ARP requests and replies. When LaBrea detects no replies for an address, it sends an ARP reply with a spoofed MAC address. Then, once the ARP reply has satisfied this request to whatever routing device requested it, the router sends along the SYN packet to the LaBrea server to start the TCP/IP three-way handshake. LaBrea finishes the handshake and sets up a session with the requestor as a virtual machine.

There are many options available with LaBrea, which are specified in detail in the LaBrea.README file. I wanted to test the tarpit before letting it loose on my network, so I used the following options:

./Labrea -t 5  -l  -T  -b

These options translate into the following:

-t -- This is the option to throttle the connection size in bytes. The default is 10.
-l -- Logs any transactions to the syslog file (messages for Red Hat).
-T -- Puts the daemon in test mode.
-b -- Logs the bandwidth usage to syslog.

Following is what is shown on the screen when running in test mode:

You're missing the "-z" flag. See the docs.
LaBrea will attempt to capture unused IPs
LaBrea will log to syslog
Interface to be used: eth0
/etc/LaBreaConfig not found
Network number: 192.168.0.0
Netmask: 255.255.255.0
Number of addresses LaBrea will watch for ARPs: 255
Range: 192.168.0.0 - 192.168.0.255
Full internal BPF filter: arp or (ip and ether host 00:00:0F:FF:FF:FF)
Throttle size set to WIN 5
Rate (-r) set to 3
Test mode run complete... LaBrea is exiting.

What is the mysterious "-z" flag? Mr. Liston wanted to make sure you actually read the README file, so I suggest that you do so to find out.

LaBrea will detect the default interface if your system has only one. However, if you have a system with more than one, you will need to use the "-i" option to specify the correct interface. Further, if you want to exclude certain unused IP addresses from the reach of LaBrea, then you can set up an /etc/LaBreaConfig file to specify the address(es) you want to exclude. LaBrea will not overtake the address of a system that is being used, so these will not need to be included.

Before I started LaBrea, this is what an nmap -sP 192.168.0.0/24 returned:

Nmap run completed -- 256 IP addresses (3 hosts up) scanned in 43 seconds

After turning on LaBrea, a noticeable difference was seen:

Nmap run completed -- 256 IP addresses (34 hosts up) scanned in 199 seconds

In my messages file, each IP address that it assumes is logged like:

May 11 15:06:52 localhost ./LaBrea: Responded to a PING: 
  192.168.0.3 -> 192.168.0.251
May 11 15:06:52 localhost ./LaBrea: Additional Activity: 
  192.168.0.3 38745 -> 192.168.0.251 80 *

And magically, you begin to quickly fill up your network.

Tiny Honeypot

Tiny Honeypot (a.k.a., thp) by George Bakos, is similar in concept to LaBrea and works as an addition to the intrusion detection software Snort. With a simple drop-in replacement of your Linux system's xinetd and iptables files (back up the originals before you install!) and some Perl scripts, thp will listen on ports that are not in use and respond with spoofed information. As the author says, it isn't meant to be foolproof, just to provide enough confusion to cloud the issue.

I installed thp on my Red Hat 7.3 server. Installation requires some copying files and creations of directories:

gunzip and untar the file (I downloaded the latest distribution of 0.4.4)
chown nobody:nobody /path-to-thp/thp-0.4.4
cd into the directory (thp-0.4.4)
cp ./xinetd.d /etc/xinetd.d
vi /etc/xinetd.d and change the disable parameter to equal no
Update any preferred paths in the thp.conf and iptables.rules files
./iptables.rules
/etc/rc.d/init.d/portmap start
pmap_set < ./fakerpc
/etc/rc.d/init.d/xinetd start

Then, all traffic that thp encounters will be logged in a file called "captures".

Honeyd

Honeyd is a versatile, freeware honeypot that pretends to be other operating systems at the TCP/IP stack. Other features that it includes are the simulation of many virtual hosts concurrently, simulation of operating system services, as well as simulate various routing topologies. You can even set up fake Web or ftp servers in a virtual environment. Honeyd is lightweight and runs as a daemon on the operating system of choice (*BSD, GNU Linux and Solaris).

Honeyd, by Niels Provos, can currently be found at:

http://freshmeat.net/releases/81199/

With honeyd, I used a Solaris 8 Sparc platform. As a precursor to installing honeyd, you will need to download and install the following three libraries:

libdnet -- http://libdnet.sourceforge.net
libevent -- http://www.monkey.org/~provos/libevent
libpcap -- http://freshmeat.net/releases/71900/

For this article, I used version 1.7 of libdnet, 0.7a for libevent, and version 0.7.1 for libpcap.

Note that I attempted to install the latest version, 0.5a, but ran into problems with the compiling process. I had an older version (0.2) available and tried that instead. The compile worked smoothly then, so I used version 0.2 instead of the latest. Regardless of the version that you use, the procedure is very much the same: gunzip and untar the distribution, then change directories into the newly created honeyd directory.

Standard build commands can be used at this point:

./configure
make
make install

Additionally, you will need a component called arpd to work in conjunction your honeyd daemon. Arpd actually replies to any arp request of the IP address that you set for your NIC card. The installation is the same as the honeyd daemon. The version that I used was 0.1, but version 0.2 is available at:

http://www.citi.umich.edu/u/provos/honeyd

Once this step is complete, you will be ready to fire up your honeyd honeypot.

To get everything to work, arpd should be started first so that you can get honeyd to work from the proper fake MAC address. In my case, I did the following:

arpd -i dmfe0 192.168.0.200

This will let arpd respond to arp requests from my Ethernet card with this address. If you find that you are having problems, arpd (as well as honeyd) also has a "-d" option that allows for debugging. Then, I start up honeyd:

honeyd -i dmfe0  -p nmap.prints  192.168.0.200

When I run nmap (the de facto port scanning tool) with the "-O" option, which tries to identify what operating system the scanner is running, the following appears:

TCP Sequence Prediction: Class=truly random
                         Difficulty=9999999 (Good luck!)
No OS matches for host (If you know what OS is running on it, see 
http://www.insecure.org/cgi-bin/nmap-submit.cgi).
TCP/IP fingerprint:
TSeq(Class=TR)
T1(Resp=Y%DF=N%W=3E80%ACK=S++%Flags=AS%Ops=)
T2(Resp=Y%DF=Y%W=0%ACK=S%Flags=AR%Ops=)
T3(Resp=Y%DF=N%W=3E80%ACK=S++%Flags=AS%Ops=)
T4(Resp=Y%DF=Y%W=0%ACK=O%Flags=R%Ops=)
T5(Resp=Y%DF=Y%W=0%ACK=S++%Flags=AR%Ops=)
T6(Resp=Y%DF=Y%W=0%ACK=O%Flags=R%Ops=)
T7(Resp=Y%DF=Y%W=0%ACK=S++%Flags=AR%Ops=)
PU(Resp=N)

Nmap run completed -- 1 IP address (1 host up) scanned in 96 seconds

When I shut off the arpd and honeyd daemons and run the same nmap scan, I get:

TCP port Interesting ports on blah.blah.com (x.x.x.21): (The 1598 
ports scanned but not shown below are in state: filtered)
Port       State       Service
22/tcp     open        ssh
2201/tcp   open        ats
22273/tcp  open        wnn6

Remote operating system guess: Solaris 8 early access beta through 
actual release Uptime 71.743 days (since Sat Mar 01 14:52:40 2003)

Nmap run completed -- 1 IP address (1 host up) scanned in 407 seconds

Note that in the 0.5a version, there are a few additional and very handy options: the -l option to save activity to a log file, and the -x option to handle xprobe style fingerprints, which are typically associated with ICMP fingerprinting tools.

Conclusion

As with any security tool that you implement in your environment, a honeypot must be continually monitored, and you must incorporate this aspect into your incident handling process. Monitoring the honeypot not only includes proactive monitoring, such as checking all log files, checking active connections, and looking at active processes for things out of the ordinary, but it also involves reactive measures. These must be outside the visibility of an attacker to ensure that they actually work. Types of reactive measures include alerts (visible and/or audible), email, or paging. Giving notice to an administrator in a timely fashion is imperative because you must be able to react quickly in the case of an incident, whether you want to observe behavior or prevent peripheral damage.

Honeypots are rapidly gaining a place in defense strategies, while they maintain an important status in the security research community. Before implementation, consideration of the goals for the honeypot must be thoroughly examined, and a cost/benefit analysis must be completed. Extreme care must also be taken when implementing a honeypot, and it should be treated like any other security device or system implemented on your network, with constant care and feeding to ensure that its standards are kept up to date.

Resources

Honeypots: Tracking Hackers, Lance Spitzner. Addison Wesley, 3rd Printing, December 2002.

Hackbusters (Tom Liston's Web site) -- http://www.hackbusters.net/

The Honeynet Project -- http://www.honeynet.org

Talisker's Network Intrusion Honeypot Listing -- http://www.networkintrusion.co.uk/honeypots.htm

Intrusion Detection/Honeypots/Incident Response -- http://www.honeypot.net

Honeypots: Tracking Hackers Web site -- http://www.tracking-hackers.com

Electronic Frontier Foundation -- http://www.eff.org/IP/DMCA/states/

Kristy Westphal, CISSP, is a versatile IT professional, skilled in information security, troubleshooting, and process analysis. Her experience in the Information Technology field has allowed her to become knowledgeable in several flavors of Unix and Windows, as well as various aspects of intrusion detection and disaster recovery planning. She is currently employed by Pegasus Solutions Companies as Information Security Officer.