For the security conscious, there is always room for another weapon against attackers. Firewalls, intrusion detection systems, packet sniffers — all are important pieces of the puzzle. So too is Honeyd, the “honeypot daemon.” Honeyd simulates the existence of an array of server and client machines on your network, including typical traffic between them. The phantom machines can be configured to mimic the signature and behavior of real operating systems, which will trick intruders into poking at them — and revealing themselves to your security staff.
Current versions of Honeyd can imitate the appearance of more than 1,000 OSes and their variants, and the profiles used to mimic the targets are gleaned from the Nmap security scanner. That does not make them indistinguishable from reality, but it is as close as you can come; Nmap sets the gold standard for OS detection and fingerprinting. Honeyd’s creators say they have tested the program with a phantom network of 65,536 virtual hosts running on a single machine. You probably won’t need that many unless you run a gigantic enterprise network, but it is nice to know the program has been thoroughly stress-tested.
In practice, Honeyd trips up attackers in two ways. First, it slows them down by vastly increasing the amount of work they must do to correctly identify the real target machines on your network. The Nmap scans and traffic logs will be much larger, and take much longer to sort through. Think of this as akin to the way medieval castles were built with multiple rings of walls, with the gates at different positions around the perimeter. The more you slow down the attacker, the better your chances of catching him or her through your other methods.
Second, each of the Honeyd virtual servers is a “honeypot” in the sense that it attracts real attacks even though it is not a real machine. No legitimate user on your network will ever need to probe a Honeyd virtual server, because they do not offer real services. Therefore any probes or connection attempts are automatic red flags. Obviously, a misconfigured program on another machine could generate false positives (as could an uninformed-but-curious new admin), but by and large the honey attracts ne’er-do-wells.
Installation and Configuration
Researchers use Honeyd on Internet-facing networks to trap and catalog malware and viruses “in the wild,” but for protecting your own home or office network, it runs just as well in a LAN environment. Most modern Linux distributions provide Honeyd packages through their package management system, but if you wish you can grab the source from the project’s downloads section. The most recent version is 1.5c, from 2007 (don’t worry; the core functionality has not evolved much lately, but you might want to update the OS emulation capabilities by grabbing updated emulation scripts from the Honeyd forums).
Honeyd’s configuration file resides at /etc/honeypot/honeyd.conf — although in practice you can have multiple config files as pass the one you want to run to honeyd at startup time. The format is essentially plain text, with comment lines denoted with a hash character at the beginning.
You may need to include a routing section at the beginning of the file, depending on the virtual “network layout” you wish Honeyd to emulate. One way or another, you will need to get the packets headed for your phantom honeypot IP addresses to the machine on which Honeyd is running. You can do this by adding specific routing rules to your router, so that traffic addressed to the specific IPs or IP range you are using for your honeypots is routed directly at your Honeyd machine, or you can use an external tool like arpd. Either way, you use route entries in your honeyd.conf file to describe how the network should appear.
For example, the default config file comes with:
route entry 10.0.0.1
route 10.0.0.1 link 10.2.0.0/24
route 10.0.0.1 add net 10.3.0.0/16 10.3.0.1 latency 8ms bandwidth 10Mbps
route 10.3.0.1 link 10.3.0.0/24
route 10.3.0.1 add net 10.3.1.0/24 10.3.1.1 latency 7ms loss 0.5
route 10.3.1.1 link 10.3.1.0/24
This defines a gateway at the IP address 10.0.0.1, and sets up links to three subnets: 10.2.0.0/24, 10.3.0.0/24 and 10.3.1.0/24. It also defines the connections between the subnets (the add net lines). As you can see, you can specify the bandwidth, latency, and packet loss over these phantom connections — remember, since the entire network is virtual, Honeyd can essentially control every aspect of it.
With this framework in place, you will next need to define some virtual machine templates. Most configurations begin with a “default” stanza that (as with firewall rules) establishes a baseline drop-unknown-packets behavior:
create default
set default default tcp action block
set default default udp action block
set default default icmp action block
Templates can have any name you choose, so pick a descriptive one. After its create TEMPLATENAME line, use set to assign it an OS “personality.” The list of emulatable personalities is found in /etc/honeypot/nmap.prints. After the personality line, you can add as many network behavior scripts as you want the virtual machine to simulate. The Honeyd package installs its scripts in /usr/share/honeyd/scripts/ and sorts them by OS. For example, to create a virtual file-server, you might include:
create linuxfileserver
set linuxfileserver personality Linux 2.4.20
set linuxfileserver tcp port 21 "sh /usr/share/honeyd/scripts/unix/linux/ftp.sh"
set linuxfileserver tcp port 21 "sh /usr/share/honeyd/scripts/unix/linux/suse8.0/ssh.sh"
You can also simply leave a port open with set linuxfileserver tcp port 445 open, or assign a MAC address with set linuxfileserver ethernet "01:23:45:67:89:ab". You can even add system statistics to the mix, such as set linuxfileserver uptime 51840000. Define as many templates as you like, using as many OSes as you like, but to actually put any of them into rotation, you will need a bind line:
bind 10.3.0.1 bigciscorouter
bind 10.3.1.101 linuxfileserver
You can bind as many IP addresses as you want to the same template; each one will function independently. The Nmap OS fingerprints tell Honeyd how to respond to basic TCP, UDP, ARP, and ICMP packets, as the ever-so-slightly-different replies are how Nmap — as well as nefarious network scanners — differentiate between systems. The various scripts emulate application servers, allowing you to mimic SSH, HTTP, HTTPS, IMAP, DNS, and other typical services on your machine.
Unfortunately, the scripts are one of those areas where Honeyd’s official documentation is sorely lacking, so the only reliable way to sort out their capabilities is to dig in and read through them. Generally they just echo the proper generic responses to connection requests, rarely going so far as to emulate making a connection. After all, you do not need to catch the attacker in the act to know he or she is accessing the virtual host for illegitimate reasons: these are hosts with no valid user accounts.
Collecting Data and Responding
That brings us to the last step in setting up a Honeyd honeynet: collecting intel and raising the red flag when necessary. Standard syslog logging is used to log normal setup and teardown events, and scripts called by the virtual hosts can write messages to syslog by using stderr.
The more detailed logging facility is activated by Honeyd’s -l switch. Start Honeyd with sudo honeyd -d -l -f /the/path/to/your/honeyd.conf. This will log all of the connections and packets received by Honeyd, to a file in the directory where you launch Honeyd. The log entries contain seven to nine fields, in the order timestamp protocol connection_state source_IP source_port destination_IP destination_port [TCP_info] [comments].
The connection_state field is S for starting new connections, E for ending connections, and - for existing connections. The TCP_info field includes packet size and flags, and is logged only for packets not part of an existing connection. The comments field can include OS fingerprints and the total amount of data received for connection-ending (E) packets.
Apart from constantly monitoring the Honeyd log file, your best bet for triggering an alarm when someone starts kicking around your virtual host network is to use an external utility such as incron, which can run scripts based on file events, such as a change in modification time.
You will still need to resort to other security tools (such as Nmap) to locate and stop your attacker. However, Honeyd can assist in this effort as well with some advanced options. The tarpit option, for example, allows you to slow down any connections made to the templates you assign it to. Note that this can be helpful in malware or worm situations, but is not applicable to human attackers searching for vulnerabilities.
Honeyd does support conditional behavior through “dynamic” templates, which you can use to better ensnare intelligent attackers. You can have Honeyd respond with different templates at different times, based on where the attacker is located, or even the OS fingerprint detected. When combined with a different set of scripts, you can build a more flexible net.
The project also supplies some analysis tools that will prove helpful, including Honeycomb, a plug=in that creates signatures for the Snort intrusion-detection system, and Honeyview, a graphical data charting tool.
Sadly, the Honeyd project makes it difficult for interested users to get together and discuss strategy or exchange scripts and other tools. The first place to go is the Honeyd forum, where there are still active users around every day — even though the maintainers of the code have largely moved on to other projects. If you are serious about learning Honeyd, however, there is no better place to start. Just be prepared to ask questions in other places, such as security and pen-testing lists.
