|
|
Honeytrap is a low-interaction honeypot that also aims to collect malware in an automated way. It uses an approach similar to nepenthes: The main idea is to trick an incoming exploit to send its complete payload, which can then be analyzed automatically or via a human. It works for TCP services and collects information regarding known or unknown network-based attacks. Honeytrap strictly distinguishes between data capture and attack analysis. The process of capturing information related to attacks is completely done within the core system. Further attack analysis, like automated checking for attack patterns, is accomplished with plug-ins, which can be loaded dynamically during runtime. This strict distinction guarantees easy expandability without the need of shutting down or even recompiling the software — one of the limitations of nepenthes.
Honeytrap was written by Tillmann Werner. It is licensed as open source software under the GNU General Public License (GPL). The project is hosted at Sourceforge, and you can find more information about it at http://honeytrap.sf.net. In addition, there is a mailing list on which you can subscribe at https://lists.sourceforge.net/lists/listinfo/honeytrap-devel.
There is also a public subversion repository that gives you access to the latest development version. You can reach this subversion repository at
$ svncohttps://svn.sourceforge.net/svnroot/honeytrap/trunkhoneytrap-svn.
In the rest of this section, we describe honeytrap and its mechanisms in more detail and show you how to install and configure it.
A classic approach in honeypot technology is to emulate services or even well-known vulnerabilities in services. We introduced this in the section on nepenthes. However, this does not work if you want to observe unknown attacks, so-called 0days. Nepenthes needs a vulnerability module to emulate a vulnerability in a service. This signature of the attacks is not available for a 0day attack, so nepenthes cannot handle this kind of attack. Honeytrap takes a slightly different approach by dynamically reacting on incoming data. The tool opens TCP ports dynamically at the time of incoming connection requests. Thus, servers act on demand each time an exploit tries to attack the honeypot. Via this generic approach, it is possible to respond to most network-based attacks.
If honeytrap detects a connection request to an unbound TCP port, it starts a server process to open this TCP port and handle incoming data. This makes it possible to handle attacks right when they occur, whether they are identified by then or not. It is not necessary to keep thousands of ports open to make sure that new attacks are caught. Instead, honeytrap extracts TCP connection attempts from a network stream by using so-called connection monitors. Two different kinds of connection monitors are available:
A network sniffer based on libpcap, a packet-capture library, searches for RST packets with a sequence number of zero generated by the local host. These packets indicate a rejected connection request. This means that there was a connection request on a TCP port, but this port is currently closed. Thus, we need to open this port to handle incoming requests in the future. Normally — particularly in the case of automated attacks by malware — the remote system will try again to attack us and be successful. This is the default monitor because it is portable on different operating systems.
For Linux systems, it is possible to use the ip_queue interface of the netfilter/iptables subsystem of the Linux kernel to intercept incoming connection requests. We can create an iptables rule to deliver SYN packets related to new connections to honeytrap. This monitor has the advantage of being able to handle the first request to a TCP port. We can catch an attack the first time it hits our honeypot sensor. The drawback is that it is not as stealthy as the other monitors: All connection requests result in an open TCP port.
With these two connection monitors, honeytrap can dynamically open TCP ports. In addition, the honeypot also needs to handle incoming data. If a connected host transmits no data for some period of time, it presumably waits for an answer from our honeypot. Therefore, we need to send some data back to the attacker and hope that the data sent by us makes the attack continue. The responses sent by honeytrap can be grouped into four different categories:
Service emulation: Similar to nepenthes, honeytrap offers service emulation. The emulation is a bit simpler than nepenthes; the author of honeytrap refers to it as "poor man's emulator." Honeytrap can read default responses for specific ports from files. These files contain responses captured by sniffing a session from a real service and are all stored in a specific directory. Adding a new service emulation is therefore very easy: You must capture a response from a real service (e.g., by using netcat or similar tools) and store the sniffed data in a file located in the response directory.
Mirror mode: This mode is an interesting feature of honeytrap. All incoming data is sent back to the attacker, so honeytrap acts like a mirror. This means that honeytrap tries to establish a TCP connection with the attacking host on the same TCP port as the incoming data. Responses from this mirror connection are sent back to the initial connection and vice versa. Thus, all incoming data is relayed back to the source, which means that the attacking machine is effectively attacking itself! This works in practice because if a machine is infected by some kind of malware that tries to propagate further, this machine is also vulnerable. If we mirror the exploit back, we receive valid answers that we can send back on the initial connection, thus making the attacking machine believe that it successfully exploited us. We can then analyze the received data and extract information from it.
If no mirror connection can be established, this mode falls back to normal mode, which includes basic service emulation.
Proxy mode: In this mode, all incoming data is relayed to a different machine or service, so honeytrap acts as a proxy. In addition, honeytrap captures all traffic and stores it for later analysis. This can be useful if you want to relay traffic to a real machine and observe how this system reacts to an incoming exploit.
Ignore mode: All incoming requests are ignored, and honeytrap does not react to requests against this specific TCP port. You can use this to block access to certain TCP ports if these should not be processed by honeytrap.
The different modes can be configured individually for each TCP port. Interestingly, in practice these simple response options are often enough to trigger an incoming exploit. The different modi allows a setup of honeytrap as a meta-honeypot. Connections that will be handled by other honeypots or real services can be proxied to them, and others can be mirrored back to the attacker or handled in normal mode. We thus have a very flexible and modular mechanism.
All data processed by honeytrap is stored in the filesystem. This observed data can be processed with several different plug-ins for automatic analysis. For example, it can be parsed automatically to detect download commands. In addition, plug-ins enable honeytrap to recognize FTP and TFTP commands and automatically download the additional ressources. Many attacks take place in multiple steps. Often, additional malcode is downloaded to the compromised host after successfully exploiting a service. This additional malware is used to launch further attacks or to open backdoors that allow the intruder to have easy access to the system. To get as much information as possible about an attack, honeytrap uses plug-ins to save and analyze collected data. The following plug-ins are available:
Basic module that stores the complete attack data in the filesystem for external analysis with additional tools.
Parser for FTP download commands and client-side protocol implementation to perform downloads that tries to be similar to MS Windows, which basically showed to be the most successful concept. Nepenthes uses the same approach. Downloaded files are stored in the filesystem.
Parser for TFTP download commands and client-side protocol implementation to perform downloads. Downloaded files are stored in the filesystem.
Parser for HTTP URLs in attacks against weak VNC servers. Files can be downloaded by invoking external tools like curl or wget.
Plug-in that recognizes and decodes some base64-encoded exploits to conduct further automated analysis.
Unfortunately, at the time of this writing no precompiled honeytrap package is available. Therefore, you need to compile honeytrap yourself. Compiling a honeytrap is very easy if you have done it before. Autoconf is used to detect your environment and customize a honeytrap to your machine. First, you must choose one of the two connection monitors introduced in the previous section. This is done via the --with-[type]-mon option, where [type] is one of the following two options:
As an additional security feature, the author of honeytrap recommends that you enable the Electric Fence malloc debugger by passing the --with-efence option to the configuration script. This adds additional security checks and makes the operation of honeytrap more secure.
With the following commands, you start the configuration script and then compile and install honeytrap:
$ ./configure --with-efence --with-pcap-mon $ make $ sudo make install |
If libraries or additional tools are missing on your system, the configuration script will give you an error message and details of how to fix this. Please follow the instructions and then start the compilation process.
Once the installation process is finished, we need to configure honeytrap. The main configuration file honeytrap.conf is, by default, located in the folder /etc/honeytrap. For each TCP port, you can configure how incoming data should be answered. We introduced the four different possibilities, and the following example shows their usage for four different TCP ports:
port = 80,normal port = 135,mirror port = 443,proxy,example.com:443 port = 1433,ignore |
This configures the following behavior:
1. | Port 80 (HTTP) is in normal mode, so honeytrap answers requests via predefined answers stored in files in the response directory. |
2. | Port 135 (Windows file sharing) establishes a mirror connection back to the attacker and relays incoming traffic and receives answers between both connections. |
3. | |
4. | Port 1433 (MS-SQL) is ignored. This TCP port is commonly used by SQL slammer, and we are not interested in this traffic. |
The configuration file contains a detailed explanation of all possible configuration possibilities. You can normally use the defaults and only customize it to your needs if necessary. A typical honeytrap.conf could look like this:
pidfile = /var/run/honeytrap.pid logfile = /var/log/honeytrap.log response_dir = /etc/honeytrap/responses attacks_dir = /var/spool/honeytrap/attacks dlsave_dir = /var/spool/honeytrap/downloads user = honeytrap_user group = honeytrap_group read_limit = 10485760 |
response_dir, attack_dir, and dlsave_dir configure the three different directories that honeytrap uses during its operation:
response_dir points to the directory that contains the responses sent by honeytrap when answering in normal service emulation mode.
attack_dir points to the directory that stores all the information collected about attacks against honeypot. This data can be used for a more detailed analysis by the plug-ins.
dlsave_dir points to the directory in which all downloaded malware binaries will be stored. This is used by the plug-ins that are able to download files based on parsing of attack logs.
The read_limit line configures honeytrap to process attacks only up to a size of 10 MB to prevent memory exhaustion due to very large amounts of data sent by an attacker.
There are two additional, configurable features: If you want to have a mirror mode as the default behavior of honeytrap, add the keyword mirror on a single line in the configuration file. Honeytrap will then act on all TCP ports in mirror mode. When using the pcap-based connection monitor, you can configure honeytrap to put network interfaces into promiscuous mode by adding the keyword promisc on a single line in the configuration file.
Now that honeytrap is configured, we can start using it. Honeytrap first passes an initialization phase after startup to configure itself. This contains loading of plug-ins that are normally located in /etc/honeytrap/plugins. In addition, it loads default responses for service emulation in normal mode by loading the content of the directory specified in response_dir (default is /etc/honeytrap/responses). The following runtime options are available:
Code View: -a <ip address> : watch for rejected connections to certain IP address. This is normally not needed because honeytrap tries to get the corresponding address for interface automatically. -g <group> : change the group ID of dynamic server processes to <group> after initialization. -h: print usage information to standard output, then exit gracefully. -i <interface> : watch for rejected connections on interface. -l <listen timeout> : Terminate dynamic servers after the specified number of seconds. Default is 30. -m : run in mirror mode. Mirror incoming connections back to remote hosts. -p : put interface into promiscuous mode. -r <read timeout> : Terminate connection handlers after the specified number of seconds. Default is 1. -t <log level> : log verbosity (0-6). Default is 3, 0 is off. -u <user> : run as <user> after initialization. -v : print version number to standard output, then exit gracefully. -C <configuration file> : read configuration from configuration file. -D : don't daemonize. -L <log file> : log messages to log file. -P <pid file> : write process ID of master process to <pid file>. expression : to recognize rejected connections, honeytrap uses a berkeley packet filter (bpf) to sniff TCP reset packets sent to a remote host. The filter can be restricted by adding a bpf expression. |
honeytrap must be run by root or installed setuid to root, to bind to privileged ports. Always use the -u and -g flags to drop privileges early, and switch to an unprivileged user and group as soon as possible.
The documentation of honeytrap also gives an example of how to use it:
$ sudo honeytrap -C /etc/honeytrap.conf -i eth0 -u nobody -g nogroup
-L /var/log/honeytrap.log -t 5 -DThis example reads configuration from /etc/honeytrap.conf, run on eth0 as nobody/nogroup and log to /var/log/honeytrap.log. Set the log level to LOG NOISY (-t 5) and stay in foreground (-D). Honeytrap will then act on an incoming connection request and answer in the way you configured it.
The author of honeytrap maintains a website on which he publishes all findings and the binaries he captured with the help of the tool. You can find this website at http://honeytrap.sourceforge.net/sample_attacks.html.
|
|