I was recently asked about the network configuration I use for my honeyd sensor. I had thought I’d already written about this so initially went to find the article on honeyd configuration; but my memory was wrong and the original post only covered configuring the guest systems, not the honeyd host itself. So, as I now have a pretty(ish) network diagram showing my setup I may as well correct the earlier omission.
<DISCLAIMER: This may not be the best network design for running honeyd, this is merely how my environment is configured and it works for me as a research platform. As usual, your mileage may vary, especially if your use-case differs from my own>
As can be seen, the design has three distinct network segments:
- Publicly route-able IPs
- Internal network for honeypot hosts
- Virtual network for honeyd guest systems. These IP addresses sit on loopback interface on the host, with a static route on the firewall to pass all virtual traffic to the honeyd host.
Using a perimeter firewall with NAT/PAT capabilities allows easy switching between emulated systems and services if your public IP resources are limited; a large network of guests can be configured in advance and left static, then a quick firewall change is all that is required to expose different systems to the world.
Additionally, as much as honeypot systems are designed to be compromised and collect information of malicious attacks (or perhaps more correctly, because of this) , low-interaction systems like honeyd is designed to avoid full compromise. If something goes wrong and the host system gets fully compromised, a (sufficiently configured) perimeter firewall provides some control of outgoing traffic, limiting the attackers options for using the honeypot sensor to attack other systems.
Not much to it really; if you use an different setup and/or can suggest ways to improve the setup let me know, always looking to improve my systems where possible.
— Andrew Waite