Previous Page Next Page

3.4. Tiny Honeypot

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

1.
Present a login banner and a root shell to any connection on any port.

2.
Collect all the data that you get.

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.

1.
Become root: su -. If you have sudo installed on your system, you can avoid using root by just prepending sudo to all commands.

2.
Choose a directory under which you want to install thp and change your directory to it. In this case, we ran cd /usr/local.

3.
4.
Unpack the tar file with tar -xzf thp-0.x.x.tgz and create a convenience symlink via ln -s thp-0.x.x thp.

5.
Create a directory where thp can store its log files: mkdir -p /var/log/thp.

6.
Now copy the files from thp/xinetd.d to the global configuration directory of xinetd: cp thp/xinetd.d/*/etc/xinetd.d/. This installs the configurations for the generic listener and emulations for FTP and HTTP.

7.
Enable the services by replacing disable = yes with disable = no for each file in /etc/xinetd.d/.

8.
Change the configuration of thp.conf and iptables.rules to fit your system. For example, you might want to edit thp.conf to change the greeting back to fortune or specify a different IP address.

The configuration of iptables.conf is much more complicated. You probably want to change the networks to match your own environment.

9.
Push the iptables configuration with ./thp/iptables.rules.

10.
Enable the portmapper if it does not run yet: /etc/rc.d/init.d/portmap start.

11.
Install the fake service translations using pmap_set < ./thp/fakerpc.

12.
Start xinetd with /etc/rc.d/init.d/xinetd start.

13.
Everything should be set up now.

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.

1.
/var/log/thp/captures: This log file contains a summary for each connection. You can specify in the configuration if you would like connections to be summarized on a single line which makes it easier to postprocess the data, or in a multiline format, which is easier to read.

2.
/var/log/thp/<sessionid.protocol>: Each session gets its own log file that contains more detailed information about the interaction with a thp responder.

3.
/var/log/messages: This file contains log messages from all system services including netfilter, which is used to redirect traffic to the Tiny Honeypot. Netfilter logs the occurrence of redirects for packets that get forwarded to the honeypot.

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.

1.
HPOT_DATA: This log type is used for connections that are being redirected to thp. The log entry contains additional information contained in the IP and TCP headers.

2.
FRAG_UDP: Logs the occurrence of fragmented UDP packets that are dropped instead of being forwarded to the honeypot.



Figure 3.5. Sample log entry from netfilter when redirecting a connection to thp.

Mar 27 09:12:31 htp kernel: HPOT_DATA:IN=eth0 OUT= MAC=1e:de:ad:ca:ff:e0 \
SRC=172.162.10.1 DST=192.168.1.1 LEN=60 TOS=0x00 PREC=0x00 TTL=50 \
ID=32412 DF PROTO=TCP SPT=37954 DPT=80 SEQ=1277457921 ACK=0 WINDOW=5840 \
RES=0x00 SYN URGP=0 OPT (020405B40403040B1F32881A0000000001030200)

3.
FRAG_ICMP: Logs the occurrence of fragmented ICMP packets. They are dropped, too, instead of being forwarded.

4.
BADTHINGS_IN-limit: Logs the occurrence of FIN scans, and so on.

5.
BADTHINGS_IN: Logs the occurrence of anything else that is being dropped instead of being forwarded to the honeypot.

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.

Previous Page Next Page