honeytrap

The applied model strictly distinguishes between data capture and attack analysis. The process of collecting information related to attacks is completely done within the core system. Further processing like automated analysis can be done with plugins.

A classic approach in honeypot technology is to emulate services or well-known vulnerabilities, pursued by lots of excellent tools (e.g., nepenthes, have a look). However, this does not work for completely unknown attacks which might occur on random ports and make use of unknown protocols. However, there is no need to keep thousands of ports bound: Honeytrap extracts incoming connection attempts from the network stream by using so-called stream monitors. If such a monitor detects a request to an unbound port, a server process is started to handle it. This permits the handling of attacks right when they occur, no matter if they are known or not. Three different kinds of connection monitors are currently available:

• A libpcap-based sniffer catches locally generated RST packets with a sequence number of zero indicating a rejected connection request. Normally – particularly in case of an attack – the remote system will issue a retry and be successful. The pcap stream monitor is the default for its portability.


• On Linux systems it is possible to hook the ip_queue interface of netfilter/iptables and create an iptables rule to deliver packets related to new connections to honeytrap. This monitor has the advantage of catching the first try.


• Alternatively, the netfilter_queue interface (previously known as nfnetlink_queue) could be used on recent Linux kernels. Again, iptables rules define which packets are delivered to honeytrap. This stream monitor is the preferred one on Linux systems.

Although service emulation is not in the main focus of the concept, honeytrap has a "poor man's service emulator", some basic emulation capabilities. If a connected host sends no data for some time, sending a response often makes the attack going on. Honeytrap can read default responses for specific ports from files which basically contain captured messages from original services. The default response (i.e., when no template is available for a port) is a single newline charachter, a simple but surprisingly successful approach.

A neat thing is the "mirror mode" in which all incoming data is mirrored back to the attacker. For every incoming connection honeytrap establishes a "mirror connection" back to the remote host on the requested port. Responses from the mirror connection are mirrored to the initial connection and vice versa. One can think of honeytrap in mirror mode as a generic tcp proxy, arranging an attacker to attack himself. Thus service emulation is no longer necessary. :-) A connection handler automatically falls back to normal mode (including the "poor man's service emulator") if no mirror connection could be established.

An attack can also be processed in "proxy mode" to relay incoming connections to a different host or service and at the same time record the whole communication. Ports can also be explicitly configured to be handled in "normal mode" or in "ignore mode". In the latter case connection to that port are simply not handled by honeytrap. The appropriate mode can be set individually for any TCP or UDP port.

The presence of different modi allows for a setup of honeytrap as a meta-honeypot: Connections that shall be handled by other honeypots or real services can be proxied to them, others can be mirrored back to the attacker or handled in normal mode.