honeytrap project trap attacks against tcp services.
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 which can be loaded dynamically during runtime. This guarantees expandability without the need of shutting down or even recompile the software.
A classic approach in honeypot technology is to emulate services or even well-known vulnerabilities in services, pursued by lots of excellent tools (e.g., nepenthes – have a look). However, this does not work if one is interested in being able to also trap totally unknown attacks.
If the honeytrap daemon detects a request to an unbound TCP port, it starts a server process to handle the incoming connection. This makes it possible to handle attacks right when they occur, no matter if they are by then known or not. There is no need to keep thousands of ports bound 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 currently available:
· A 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 try it again and then be successful. This is the default monitor because of its portability.
· On Linux systems it is possible to hook the ip_queue interface of netfilter/iptables and create an iptables rule to deliver SYN packets related to new connections to honeytrap. This monitor has the advantage to catch an attack the first time it hits, but it is not as stealth as the pcap approach.