Operating System and tools
Pick an operating system with which you’re comfortable. A lot of *nix junkies out there will heckle you about which distro is best, especially when it comes to running security tools; and whilst I agree with the principle that a good solid distro will improve your machine’s robustness and prevent a malicious attacker from turning your security tools against you, let’s be realistic: there isn’t a single distro, operating system or device out there that can’t be exploited. This is not always due to the shortcomings of the developer, or administrator, or what have you: it is the result of a complex balance between security, functionality, communication and logistics. So what I say is, pick *one* distro and get to know it very well. Make sure it can patched on a regular basis and that any remote communication you set up with it is secured (encrypted, with a long password or certificate for authentication). For this example, I’m going to use an Ubuntu box, honeyd, swatch and ruby to set up the honeypot and monitoring systems.
I would strongly recommend starting with a fresh install of your distro on the system. You don’t want to leave any unexpected services running on your box as it will increase its vulnerability. Install the bare minimum — if you’re comfortable with a barebones system with a simple shell and no xwin, go for it; just make sure that you can handle the config under stress.
Once the OS is installed, I’d test it right away to make sure no superfluous services are running on it. Start with several nmap scans; begin with a simple scan, use the -P0 flag, scan all ports consecutively, use the –send-ip flag… The works. I’d check out all the processes on your machine as well, to see if anything could be removed. Then use nessusd as a final test.
Next, install honeyd, farpd, rrdtool, rails, swatch and, optionally, snort. If you’re using APT, then the startup scripts and config files for honeyd and farpd will be setup (in /etc/init.d and /etc/default). These will not run automatically on startup – amongst other things, you’ll need to specify the interface and IP addresses on which these tools will listen.
To give you a bit of background, farpd was developed by Dug Song as part of dsniff (a collection of tools for network auditing and pentesting). What it does is reply to ARP requests, effectively directing traffic to your host. Whilst it can be used for nefarious purposes, in this case it allows your honeypot to capture traffic for multiple IP addresses. Rails is the tool I’ll be using for scripting — it’s just a preference. One could use anything from a simple bash script to a compiled mono exec; just remember that you want to be able to modify it fairly quickly and painlessly. The scripts in question will be for emulating services (such as IIS) but also for monitoring purposes (such as sending mail). As for swatch, it’s a tool that allows you to quickly set up monitoring of log files; it’s nifty because you can set all sorts of thresholds, filter the log by keyword, and send out alerts via e-mail or script. Finally — the pièce de résistance — honeyd is the tool you’ll be using to simulate other systems. It’s easily configurable and simulates machine profiles and network topologies. It uses rrdtool for this, so make sure that’s on your machine.
Configuring honeyd and swatch
The first thing to do is to make a copy of /etc/honeypot/honeyd.conf, which you’ll rename to honeyd.conf.orig. This will serve as a reference for your config. The configuration is super straight-forward and gives examples for a virtual network and several hosts. For each host, you’ll need to define the OS profile as labelled in the nmap.prints file, set up the services and bind an IP address. For each service, you indicate the port, transport protocol and action; the latter can be a command, such as “echo You’ve been 0wned get outta Dodge” or something a bit more complex like “ruby /opt/scripts/my_iis_emulator.rb” — check out honeyd’s site for a useful list of service scripts. Alternatively, you can set up the port to proxy a service running on another machine (including the source IP’s, using $ipsrc). If you’re feeling particularly nasty, you could fathomably proxy a malicious server running exploits — but I wouldn’t recommend that as it could seriously backfire on you…
In order to get logging going, you’ll have to change ownership of the /var/log/honeypot directory, using a command like ‘sudo chown -R honeyd.honeyd /var/log/honeypot’. You’ll need to perform a chmod on . and honeyd.log, something like ‘sudo chmod 777 /var/log/honeypot/.;sudo chmod 777 /var/log/honeypot/honeyd’ (I would say 766 is better). If honeyd.log does not exist, create it using touch. If this doesn’t work, you could chown it to nogroup.nobody.
Swatch is also fairly easy to set up. It needs a config file, which you’ll create from scratch. Place it somewhere logical, i.e. /etc/swatchrc. You’ll want to read the man file very carefully, but in essence you can set up the alerts very quickly using syntax like:
The example above watches for the values ‘tcp’, ‘udp’ and ‘icmp’ as honeyd is wont to output, limits swatch to trigger a maximum of once every 90 seconds and sets the action to run a ruby script of your choice.
Setting up the startup scripts
The scripts are pretty much set up; if you’re using ubuntu even the honeyd user is created for you. You’ll need to edit the /etc/default/farpd and /etc/default/honeyd files so that they know which interface and ip addresses to use. Note that to specify IP addresses, enter them in separated by spaces.
The swatch script will need to be created by making a copy of the template init.d script (/etc/init.d/skeleton) and modifying it to execute /usr/bin/swatch with the -c (config file path) -t (honeyd.log path) flags set. Sounds more complicated than it actually is, but if you’re having trouble, google ‘init.d skeleton startup script’
Running the services for the first time
Easy: start up a terminal session and type ‘sudo /etc/init.d/farpd start;sudo /etc/init.d/honeyd start;sudo /etc/init.d/swatch start’. You should get no errors and if you run ‘ps aux’ you should see all processes running.
Testing your machineFirst thing to do is ping the fake machines; if that works, the next step is running nmap with the –send-ip flag (note that from the LAN this is absolutely necessary). Finally, try a few telnet sessions to open ports to make sure that honeyd works and swatch triggers correctly.