O'Reilly    
 Published on O'Reilly (http://oreilly.com/)
 See this if you're having trouble printing code examples


Managing a Honeypot

by Peter Mikhalenko
09/28/2006

It's no secret that many intruders choose their victims by scanning large chunks of addresses and searching for services vulnerable to existing tools and exploits. This can be an effective approach, although there are still some problems for intruders. People employed in IT security must trace bug trackers and the appearance of new exploits. Even open source code cannot guarantee that the good guys will find vulnerabilities before the bad guys do.

However, the good guys have another tool--a honeypot. This is a system designed in such a way that an unsophisticated hacker will want to crack it immediately--like fake diamonds in a glass case in a jewelry shop. First, a quick story. A famous and rich man bought a super safe made of ferro-alloy. He boasted to everyone about his safe and claimed that nobody could crack it. After about a week of this, burglars came in the night and spent two hours cracking the safe with strong acid and explosives. When they opened the safe, they found nothing; the valuables were elsewhere and the burglars were caught.

What Is a Honeypot For?

A honeypot emulates a server with serious security holes. The intent is to attract network intruders so that they will spend their time on a useless job. Honeypots are closely-monitored network decoys that serve several purposes: they can distract adversaries from more valuable machines on a network, provide early warning about new attacks and exploitation trends, and allow in-depth examination of adversaries during and after exploitation.

There are two general types of honeypots: production and research. Production honeypots are easy to use, capture only limited information, and are in use primarily by businesses. Research honeypots are complex to maintain, so their usefulness is primarily in security research, military, or government organizations. With such honeypots you can easily capture a private shellcode used to crack a previously invulnerable service, learn new methods of intrusion, and, most importantly, develop intrusion-resistance methods.

Principles Inside and Legal Issues

The main principle if a honeypot claims that any attempt to connect to a non-existing IP address is prohibited a priori. It's a reasonable assumption, if no law-abiding user will deliberately connect to a non-existing service. As long as users know of no such service, you can assume that any connection to the service is the start of an attack. A big advantage of a honeypot is that you can emulate any operating system on any hardware you want. If a service runs on FreeBSD, you can fool the attacker into thinking he is looking at a glitchy ancient Cisco or a modern enterprise Linux distribution. Such emulation is OS fingerprinting. However, sophisticated intruders can detect this, since any emulator may also have its own fingerprint. Even if the developers have hidden all unique features, theoretically, overlooked bugs may appear. With a honeypot, you also have a significantly smaller volume of logfiles, reducing the probability of false alarm to almost zero. When something strange occurs, it's generally easier to watch 200Kb of logs instead of 1Gb.

Questions that inevitably arise in most organizations include: are honeypots illegal? What do the laws say about such fraudulent services?

"There are some legal issues, and they are not necessarily trivial and easy," says Richard Saldago, senior counsel for the U.S. Department of Justice's computer crime unit, speaking at the RSA Conference in San Francisco. The main problem is that U.S. criminal law calls honeypot monitoring "interception of communications," which is prohibited and may lead to imprisonment for up to five years. Fortunately for honeypot operators, there are exemptions to the Federal Wiretap Act that could apply to some honeypot configurations, but they still leave many hacker traps in a legal danger zone. One exemption permits interception of a communication if one of the parties consents to the monitoring. Salgado suggested that honeypots display a banner message warning that about monitored use of the computer.

Yet most attack attempts don't penetrate a system through the front door -- telneting in or surfing to a web page -- and if they never see the banner, they haven't consented to monitoring. The consent exemption might apply without a banner if a court determines that the honeypot itself is one of the "parties" to the communication, Salgado said. Another relevant exemption was passed in the USA PATRIOT Act in October 2001, but only applies to cases where the government steps in to do the spying.

There is a third "provider exemption" that may be the most promising legal justification. This allows the operator of a system to eavesdrop for the purpose of protecting their property or services from attack. In this case, Salgado favors configurations that invisibly reroute an attacker to a honeypot after beginning an attack on a production machine. "The closer the honeypot is to the production server, the less likely that it's going to have some of the legal issues that we're talking about," he said, because the monitoring becomes part of the normal process of protecting the production machine. Despite the legal issues, Salgado praised honeypots as a valuable tool. He also cautioned attendees to consult with their company legal departments before deploying them.

How to setup a honeypot

There are many honeypot systems available, some commercial and others open source. A few good ones are Tiny Honeypot, Single-honeypot, KFSensor, APS, LaBrea. The last one refers a famous set of tar pits in Los Angeles that contain many bones of lost animals.

honeyd is a good honeypot implementation, because it is open source, cross-platform, and BSD-licensed. It is under active development and provides many exciting features.

To install honeyd under Unix, first download the source files:

# cd /usr/src
# wget http://www.citi.umich.edu/u/provos/honeyd/honeyd-1.5a.tar.gz
# tar xzf honeyd-1.5a.tar.gz
# cd honeyd-1.5a

Before you can do the usual configure and make dance, you must install some additional packages, such as libevent, libdnet, and libpcap. In some cases (on FreeBSD especially) there may appear some problems even after installing appropriate libraries, and you may need to point the configuration script explicitly to installed libraries. For example, for libevent, I used:

# ./configure --with-libevent=/usr/src/libevent-0.9/ --prefix=/path/to/honeyd

To get fully-featured honeyd (to enable ARP-spoofing), you also need an arpd daemon. It installs very easily:

# wget http://www.citi.umich.edu/u/provos/honeyd/arpd-0.2.tar.gz
# tar xzf arpd-0.2.tar.gz
# cd arpd
# ./configure
# make
# make install

Using honeyd

What can you do with honeyd installed? First of all, it can detect any network activity: if someone makes an attempt to connect to a service via UDP or TCP or sends an ICMP packet, honeyd will immediately document those attempts into logfiles. It's very important to understand that there is no need to create a dedicated service for that, or to listen on a port--honeyd does everything. You can easily emulate any network service, for example, a Cisco telnet daemon or a buggy version of Sendmail. Most interestingly, every emulated service is a script written in Perl or the Bourne shell. It is very easy to create service emulators, but there is often no such need because the honeyd web site contains everything you need for emulating almost any service.

honeyd also emulates any operating system at the network stack level, so if an intruder attempts to detect your operating system with a tool such as nmap, honeyd will deceive him and provide bogus information that you have created. (This requires using the same tables for OS fingerprinting--tables from a set of properties of particular systems--that are used in sophisticated security programs).

With that in mind, I bet you want to configure your honeypot and wait for the first client! Before you can do that, you have to understand how the special networking works. First of all, it's important for honeyd to have its own address space. If you run honeyd for a C-class network, say 206.37.77.0, it will work nicely to emulate many computers and services. But you do not have to use the whole network; instead, create one fake computer. You definitely cannot run honeyd on an already existing IP address and port. The important question is: if a packet is addressed to another computer, then how can honeyd intercept it? The solution is to use an arpd daemon or add to ARP table the corresponding record:

# arp -s 192.168.0.50 MAC-address pub

After such mapping, all packets addressed to 192.168.0.50 will go to the network interface identified by a given MAC-address. honeyd will handle the traffic. If you decide to use arpd, it is very simple to use:

# arpd 192.168.0.50

Now start honeyd:

# honeyd -p nmap.prints -f honeyd.conf -l logfile.log 192.168.0.50

The -p flag points to files with signatures of different operating systems--it appears to be an nmap fingerprint table. This invocation also uses a honeyd.conf configuration file, logs everything into logfile.log, and emulates a machine with the address 192.168.0.50. Here's honeyd.conf:

create winxp

set winxp personality "Microsoft Windows XP Professional SP1"

set winxp uptime 319671

add winxp tcp port 80 "perl scripts/iis5.net/main.pl"

set winxp default tcp action reset

create cisco

set router personality "Cisco 1601R router running IOS 12.1(5)"

add cisco tcp port 23 "perl scripts/router-telnet.pl"

set cisco default tcp action reset

set cisco uid 32767 gid 32767

set cisco uptime 1327650

Most of this config file contains descriptions of virtual machines to emulate. These descriptions are patterns or templates. This example creates two new patterns (using the create command): WinXP and Cisco. The first one emulates a server under Windows XP, allowing connections only to port 80 and sets scripts/iis5.net/main.pl as the main handler of all connections. It will emulate Microsoft IIS 5. The personality property sets which operating system to emulate, and the whole set of OS properties will come from nmap tables.

For each UDP or TCP port, you can set a behavior model. It can be a local model for particular port, or a global model for all of them. The WinXP example uses the default behavior:

set router default tcp action reset

This means that the honeypot will refuse all connections to ports without any previously set rules by sending a packet with the RST flag. You can also set the open option (send an ACK for a connection attempt) and block (ignore any TCP or UDP request).

Port 80 for the WinXP profile has a script handler. After describing some patterns to use, the configuration binds patterns to IP addresses:

bind 192.168.0.50 cisco

If someone now attempts to connect to 192.168.0.50, he will connect to honeyd emulating an old buggy Cisco router. An important point is that there always exists a default pattern. It handles all of the connections not configured in any described patterns. You can override this pattern and set a behavior such that other addresses will not handle any connections at all.

honeyd supports many other features; the documentation does a good job of describing them. After you run the daemon, honeyd will catch all packets addressed to non-existing addressees and log all connection attempts. It's worth noticing that honeyd itself does not log too much, but the emulation scripts do log quite thoroughly.

Detection of a Honeypot

Is it possible to detect a honeypot from the intruder's side? Unfortunately, yes. We are all human and all make mistakes. honeyd is accessible to everyone, and with its source code available, it is possible to find several unique properties that separate honeyd from the real systems which it emulates. In other words, you can create a fingerprint for any honeypot system. It's just a question of time. However, there are some effective ways to resist this by changing the default configuration and modifying the source code. All of the honeypot scanner fingerprints identify the web published versions of honeypots, so any irregularity may break a fingerprint scanner such as nmap. To do that, slightly modify some minor feature, such as a network packet's TTL value.

As mentioned earlier, scripts emulate all network services. These scripts can contain mistakes and security holes too! This is unpleasant because honeyd normally must work with root privileges and the scripts often work with the same privileges. If an intruder can access the emulation script and learns how to run commands, expect nothing good. With that in mind, I recommend running honeyd with the systrace command, to avoid some problems. However, describing systrace is out of the scope of this article.

Another rational step is to have in your firewall forbid all incoming connections other than those you really use and have configured for honeyd. All of these measures help limit your risk.

You can also inspect your own honeypot network by using the nmap scanner. This is an open source utility for network exploration or security auditing created by Fyodor. nmap uses raw IP packets to determine such things as: what hosts are up, what services they offer, the operating system, and what filters are in use on a packet filter. Here's an example of running nmap on a honeyd network:

# nmap -sS -p 1-100 192.168.x.x. -O

Starting nmap V. 2.54BETA31 ( www.insecure.org/nmap )
Interesting ports on  (192.168.0.50):
(The 97 ports scanned but not shown below are in state: closed)
Port     State     Service
22/tcp   open      ssh
23/tcp   open      telnet
80/tcp   open      http

Remote operating system guess: Windows XP Professional SP1

As you can see, this is exactly what the example configuration wanted to emulate (WinXP, although running on FreeBSD).

honeyd has two different logging modes. The syslog facility logs connection establishment and termination including other relevant packet events. The second way of logging network activity--using the -l flag--causes honeyd to log all received packets in a human-readable format. For UDP and TCP connections, honeyd logs the start and end of a flow, including the amount of data transferred.

For the best protection, don't blindly run the emulation scripts. If you emulate WinXP, then before running something like smtp.sh to emulate a mail daemon, look at its code. It may be emulating an old Sendmail STMP daemon that was a Unix-only service. Of course, an attacker may realize that a WinXP machine would not run a Sendmail like that. Connect to the example emulated service (IIS at port 80) and see what appears in the logfile:

$ telnet 192.168.0.50 80

Trying 192.168.0.50...
Connected to 192.168.0.50.
Escape character is '^]'.

GET / HTTP/1.1

HTTP/1.1 400 Bad Request
Date: Tue, 08 Aug 2006 12:19:02 GMT
Server: Microsoft IIS 5.0 (Windows XP Professional SP1)
Connection: close
Transfer-Encoding: chunked
Content-Type: text/html; charset=iso-8859-1

It's important to know that there are some honeyd logfile viewers such as honeyview that provide a graphical overview of the collected data. Many users prefer using a special log viewers because the raw packet logfile, even when made human-readable, can be hard to read:

2006-08-08-11:36:58.9832 tcp(6) - 252.214.169.203 2064 192.168.0.50 22: 48 S [MacOS 8.0-8.6 OTTCP]
2006-08-08-11:46:40.6209 tcp(6) - 244.233.22.102 61891 192.168.0.50 22: 60 S [FreeBSD 5.0-5.1 ]
2006-08-08-11:48:30.5612 tcp(6) S 192.168.0.50 33395 192.168.0.50 80 [FreeBSD 5.0-5.1 ]
2006-08-08-11:48:41.8329 tcp(6) S 10.173.240.67 22110 192.168.0.50 23 [Windows XP SP1]

The bold code above is a log of the connection attempts to the emulated IIS service at port 80. The first field in the log entry contains the time that the event happened in sub-second resolution. The second field lists the protocol, for example tcp, udp, or icmp. The third field may be S, which indicates the start of a new connection, E the end of a connection, or - if a packet does not belong to any connection. For E, honeyd logs the amount of data received and sent at the end of the line. The next four fields represent the connection four tuple: <src ip, src port, dst ip, dst port>. For TCP packets that are not part of a connection, honeyd logs the packet size and TCP flags after the colon. Comments such as the operating system identification via passive fingerprinting appear at the end of the line. honeyd easily checks the fingerprints of a FreeBSD 5.0 system.

Further Reading

Peter Mikhalenko works in Deutsche Bank as a business consultant.


Return to O'Reilly SysAdmin

Copyright © 2009 O'Reilly Media, Inc.