honeytrap – A Dynamic Meta-Honeypot Daemon
Below is the output of honeytrap 1.1.0 (svn version):
honeytrap v1.1.0 - Initializing. Loading plugin magicPE v0.0.1 Loading plugin ftpDownload v0.5.3 Loading plugin tftpDownload v0.4.1 Loading plugin b64Decode v0.3.1 Loading plugin vncDownload v0.3 Loading plugin SaveFile v0.2.1 Loading plugin submitPostgres v0.1.1 Servers will run as user honeytrap (1004). Servers will run as group nogroup (65534). Loading default responses. Connections will be handled in mirror mode by default. Logging to /opt/honeytrap/honeytrap.log. Initialization complete. honeytrap v1.1.0 Copyright (C) 2005-2008 Tillmann Werner <[email protected]> [2009-04-10 16:33:56] ---- Trapping attacks via NFQ. ---- [2009-04-10 16:34:11] ---- honeytrap stopped ----</[email protected]>
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.
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.