Detection of a Honeypot
Is it possible to detect a honeypot from the intruder's side? Unfortunately, yes. We are all human and all make mistakes.
honeyd is accessible to everyone, and with its source code available, it is possible to find several unique properties that separate
honeyd from the real systems which it emulates. In other words, you can create a fingerprint for any honeypot system. It's just a question of time. However, there are some effective ways to resist this by changing the default configuration and modifying the source code. All of the honeypot scanner fingerprints identify the web published versions of honeypots, so any irregularity may break a fingerprint scanner such as
nmap. To do that, slightly modify some minor feature, such as a network packet's TTL value.
As mentioned earlier, scripts emulate all network services. These scripts can contain mistakes and security holes too! This is unpleasant because
honeyd normally must work with root privileges and the scripts often work with the same privileges. If an intruder can access the emulation script and learns how to run commands, expect nothing good. With that in mind, I recommend running
honeyd with the
systrace command, to avoid some problems. However, describing
systrace is out of the scope of this article.
Another rational step is to have in your firewall forbid all incoming connections other than those you really use and have configured for
honeyd. All of these measures help limit your risk.
You can also inspect your own honeypot network by using the
nmap scanner. This is an open source utility for network exploration or security auditing created by Fyodor.
nmap uses raw IP packets to determine such things as: what hosts are up, what services they offer, the operating system, and what filters are in use on a packet filter. Here's an example of running
nmap on a
# nmap -sS -p 1-100 192.168.x.x. -O Starting nmap V. 2.54BETA31 ( www.insecure.org/nmap ) Interesting ports on (192.168.0.50): (The 97 ports scanned but not shown below are in state: closed) Port State Service 22/tcp open ssh 23/tcp open telnet 80/tcp open http Remote operating system guess: Windows XP Professional SP1
As you can see, this is exactly what the example configuration wanted to emulate (WinXP, although running on FreeBSD).
honeyd has two different logging modes. The syslog facility logs connection establishment and termination including other relevant packet events. The second way of logging network activity--using the
honeyd to log all received packets in a human-readable format. For UDP and TCP connections,
honeyd logs the start and end of a flow, including the amount of data transferred.
For the best protection, don't blindly run the emulation scripts. If you emulate WinXP, then before running something like smtp.sh to emulate a mail daemon, look at its code. It may be emulating an old Sendmail STMP daemon that was a Unix-only service. Of course, an attacker may realize that a WinXP machine would not run a Sendmail like that. Connect to the example emulated service (IIS at port 80) and see what appears in the logfile:
$ telnet 192.168.0.50 80 Trying 192.168.0.50... Connected to 192.168.0.50. Escape character is '^]'. GET / HTTP/1.1 HTTP/1.1 400 Bad Request Date: Tue, 08 Aug 2006 12:19:02 GMT Server: Microsoft IIS 5.0 (Windows XP Professional SP1) Connection: close Transfer-Encoding: chunked Content-Type: text/html; charset=iso-8859-1
It's important to know that there are some
honeyd logfile viewers such as honeyview that provide a graphical overview of the collected data. Many users prefer using a special log viewers because the raw packet logfile, even when made human-readable, can be hard to read:
2006-08-08-11:36:58.9832 tcp(6) - 252.214.169.203 2064 192.168.0.50 22: 48 S [MacOS 8.0-8.6 OTTCP] 2006-08-08-11:46:40.6209 tcp(6) - 244.233.22.102 61891 192.168.0.50 22: 60 S [FreeBSD 5.0-5.1 ] 2006-08-08-11:48:30.5612 tcp(6) S 192.168.0.50 33395 192.168.0.50 80 [FreeBSD 5.0-5.1 ] 2006-08-08-11:48:41.8329 tcp(6) S 10.173.240.67 22110 192.168.0.50 23 [Windows XP SP1]
The bold code above is a log of the connection attempts to the emulated IIS service at port 80. The first field in the log entry contains the time that the event happened in sub-second resolution. The second field lists the protocol, for example
icmp. The third field may be
S, which indicates the start of a new connection,
E the end of a connection, or
- if a packet does not belong to any connection. For
honeyd logs the amount of data received and sent at the end of the line. The next four fields represent the connection four tuple: <src ip, src port, dst ip, dst port>. For TCP packets that are not part of a connection,
honeyd logs the packet size and TCP flags after the colon. Comments such as the operating system identification via passive fingerprinting appear at the end of the line.
honeyd easily checks the fingerprints of a FreeBSD 5.0 system.
Peter Mikhalenko works in Deutsche Bank as a business consultant.
Return to O'Reilly SysAdmin