3.4. Tiny Honeypot

The Tiny Honeypot (thp) is a creation of George Bakos. It follows a very simple concept:

The underlying assumption is that intruders might believe they have been lucky and leave interesting commands. For example, the first action an intruder might take is to download her toolkit on the compromised machine. As we see where the toolkit is being downloaded from, we can retrieve and study it. These toolkits often contain a number of exploits and backdoors. For some protocols, like FTP and HTTP, thp provides simple emulations. The integrated web server supports serving files from a flat filesystem, and the FTP servers supports uploads both in active and passive modes.

The technical details behind thp are fairly simple, too. Thp binds a single port using xinetd and then uses the built-in firewall to redirect traffic for all ports to the port that xinetd is listening on. The only exception is portmap — the Unix service that maps RPC services to local port numbers. Tiny Honeypot registers a number of interesting services and allows remote intruders to look up the port number to which they should connect for a given service. If you have router access, the router can be configured to forward traffic for multiple IP addresses to a single host running Tiny Honeypot.

3.4.1. Installation

The installation is somewhat complicated and requires that you know how to change your firewall configuration. Thp does not come with a configure script and assumes that your system runs with xinetd and netfilter/iptables. Make sure that your system supports both facilities before continuing with the installation.

At this point, you can start watching the log files in /var/log/hpot/. If you were able to point multiple IP addresses to the Tiny Honeypot, you should get some interesting connection attemps pretty soon. There are three different log types that are of interest to us.

Now we will inspect the log files in more details.

3.4.2. Capture Logs

Tiny Honeypot logs a summary of each connection to /var/log/thp/captures. Looking at this file gives you a good idea of the total traffic distribution that your thp installation is receiving. The summary contains information about when a connection was initiated, how many bytes were transferred, and how long it lasted. There are two different modes in which connections can be logged: single-line or multiline. The single-line format is easier to postprocess by scripts, but it has the drawback that a connection can be logged only after it is completed. The multiline format, on the other hand, contains a separate log line for connection initiation and termination. The multiline format is similar to Netflow or Honeyd's connection logs; see Section 4.8.1.

Let's take a look at an example log line in single-line format:

Mar 27 16:50:02 SID=6ADEADCAFFE10.http PID=32767 SRC=127.168.10.2 SPT=47123 \ ET=00:10:13 BYTES=12762 Mar 27 17:20:02 SID=BEEF12D10A930.http PID=13767 SRC=192.168.31.5 SPT=24691 \ ET=00:01:27 BYTES=513

A connection log in multiline format looks like this:

Mar 29 07:34:13 SID=442AA8F516658.shell PID=32767 SRC=127.168.10.3 SPT=47123 \ ET=00:10:13 BYTES=12762 Mar 29 07:37:17 end thp SID=442AA8F516658.shell - elapsed time 00:03:04 - total 1293 bytes

The first timestamp indicates when the connection was started. This is actually the time that thp received an established connection, which can be different from the time reported by Netfilter. The end time marks either the closing of the network socket or a timeout from thp.

The session ID (SID) is a unique identifier for this particular session. It is based on the current time and monotonically increases. The extension after the session corresponds to the name of the response script that thp invoked to handle this connection. The current possibilities are shell, ftp, http, mssql, smtp, or pop3.

The process ID (PID) corresponds to the Unix process ID of the responder and does not really provide much useful insight, but it could be helpful for debugging. For example, if you notice that a thp responder process is running for a long time, you can use the process ID to grep through the capturelog for more information.

ET stands for elapsed time and tells us for how long a network connection was active. We usually do not expect connections to stay around for a very long time. BYTES, as the name indicates, tells us how much information was transferred in a session. If you need more connection information, you must match up the capturelog with Netfilter logs in /var/log/messages.

The multiline format is easier to read but more difficult to parse for post-analysis. Script-driven analysis of the multiline format would have been easier if the elapsed time and total bytes transferred were reported on the same line as the session termination information.

If per-second granularity of the timestamps is not sufficient for your analysis, you can extract timestamps with finer granularity from the session IDs. A session ID is created by concatenating Unix time in seconds and the number of elapsed microsecond in the current one-second interval. For example, Wed Mar 29 07:34:13 PST 2006 corresponds to 442AA8F516658.

Figure 3.4. Sample session log from a thp containing the full payload sent to the honeypot by an adversary.

GET /show2.php?id=11413&bid=18032|HTTP/1.1 \ Host: www.leetexchange.com \ User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1;)

3.4.3. Session Logs

Session logs contain information about the payloads received by a responder script. That is, all the information that an adversary sends to you is neatly captured in a separate file for each session. The session logs are also written to /var/log/thp and use the session ID and extension as filename — for example, /var/log/thp/442AB20C9A44D.shell.

Over time, many session logs are going to accumulate in this directory. Unfortunately, the Unix filesystem has been designed under the assumption that the number of files per directory is rather small and performance is going to degrade unless you clean this directory occasionally. Although current Linux kernels have many optimizations to speed up access to directories with thousands of files, you probably want to keep the number of files in this directory below 10,000 or so.

3.4.4. Netfilter Logs

Because thp uses netfilter/iptables for traffic redirection, you may also find information pertinent to your honeypot's activity in /var/log/messages. Every incoming connection that is not established already is going to create a log entry for you. The netfilter configuration that is shipped with thp annotates the logs depending on the type of activity.

For activity that really ends up hitting your honeypot, you probably want to grep the log file for HPOT_DATA.

The output from netfilter contains detailed information from the IP and TCP headers of the redirected packets. This information may be interesting if you are curious to find about strangely formatted probe packets that are sometimes used to fingerprint honeypots.

3.4.5. Observations

Tiny Honeypot is easy to set up and can get you interesting data quickly. It is a low-interaction honeypot that comes with a small number of responder scripts. We do not know how well Tiny Honeypot performs on very active networks. The current design requires that each responder is started in its own process. That is, each connection might potentially require a process of its own that limits the total number of connections you can serve at a given time. The main problem with starting a new process is that each process requires memory that cannot be shared with other processes. For example, if your system had 1GB of memory and each responder script required about 60KB of memory each, Tiny Honeypot could handle maybe 15,000 connections at once. However, your operating system will probably have run out of file descriptors before then, and context switching overhead will have slowed your system down to a crawl. Still, for a network where you expect to handle only a small number of connections at any given time, Tiny Honeypot is a good way to quickly gain experience about what low-interaction honeypots can achieve.