UK Honeynet Project 

I recently came across an interesting paper by researchers at Vrije University in Amsterdam (the hosts for last month’s WOMBAT workshop). It details a project they call “Eudaemon” (a good spirit from Greek mythology) which borrows from the heavily instrumented system-wide dynamic taint analysis approach of the Argos honeypot but instead ports Argos’s dynamic taint analysis engine to a user-space emulator called SEAL. Individual suspect processes within a high interaction honeypot can be marked for “possession” by Eudaemon, are temporarily frozen then are passed into SEAL for dynamic taint checking (by transparently pre-loading the emulator library into the memory space for every process and using ptrace to attach to the frozen process) and can be subsequently released cleanly once detailed instrumentation complete. Their initial benchmarks show significant performance improvements over Argos’s system-wide approach (which typically slows down a running virtual machine by an order of magnitude or more), and this appears to be the first security system that allows fully native applications to be switched into emulated operation mid-process. Definitely worth a read from a high interaction honeypot perspective (particularly for client honeypot applications), and I’m looking forward to seeing working code.

For Phase Two of our Global Distributed Honeynet Project (GDH) I’ve been continuing to explore how to extend our sensor deployment footprint at minimum cost. Mixed High and low interaction nodes will always require real server / PC hardware, but for a number of years I’ve been interested in using “plug and play” low interaction-only honeypots such as Nepenthes malware collectors via bootable or embedded devices. These devices are much easier to mass produce and distribute to project members, and with consumer device price levels continuing to fall it has become practical to distribute such sensors on a larger scale internationally (ie hundreds rather than tens of live sensor nodes).

Deployment options are generally based around two models:

1. Local sensor, with honeypot software running locally on the sensor.
2. Gateway sensor, with no honeypot software running locally and instead some form of tunnelling solution (GRE, IPSEC, OpenVPN, Honeymole, etc) being used to transparently bridge IP traffic to a central honeyfarm.

I won’t go into too much detail here at this stage, but as we plan to roll out an expanded data collection system along these lines during 2008 you can expect to see more information here in the future.

As part of the background research into building reliable low cost low interaction honeypots, I’ve recently needed to port a number of tools such as Nepenthes to various embedded devices for testing. As this turned out to be a little more time consuming than originally expected, I’ve posted a HOWTO guide for building Nepenthes on the OpenWRT embedded platform. Hopefully this information might help anyone else interested in similar research save a few hours of confusion.