Saturday, June 16, 2012

Honeypot Design

I worked with Micah Kays over the past couple weeks on building a full-interaction honeypot. I bought a Dell desktop off Craigslist (80gb hard drive, couple GB of RAM, don't remember anything else about it's stats) for $100. The hardware was cheap.

Here is how we instrumented it to prepare to perform Incident Response and Digital Forensics (DFIR) against it:

The base operating system is an installed version of Security Onion (http://securityonion.blogspot.com/). This provides a full Network Security Monitoring (NSM) suite complete with the following:

  • Snorby and Sguil, front ends for Snort that integrate the full NSM suite into a single interface
  • Snort/Suricata/Bro - different detection engines for alerting on possibly malicious network traffic
  • OpenFPC/daemonlogger - provides full-packet-capture for Snorby/Sguil, respectively
So we have the network all configured. To gain access to the host's memory, we are running virtualbox in debug mode (--debug). After the incident, we will use .pgmphystofile, which will dump the memory. We installed Volatility (https://www.volatilesystems.com/default/volatility) to be able to work with the memory image and assist in the investigation.

To perform investigations on the hard drive, we're going to try our hand at a post hogfly made (http://forensicir.blogspot.com/2008/01/virtualbox-and-forensics-tools.html).

Both the memory and hard drive acquisition techniques are minimally intrusive to changing the state of the machine. We are going to test the difference between using those two methods, and then adding triage-ir (http://code.google.com/p/triage-ir/) into the mix. Expect future blog posts with comparison notes, but note that traige-ir is meant to gather log files quickly as hard-drive acquisition is often not viable for -every- incident investigation.

What's the attack vector? I took a suggestion from a fellow coworker and we allowed FTP and RDP to be accessible from the outside, both configured with the same weak username and password combination.

To be alerted to when we need to start responding, Micah set up a rule looking for successful FTP logins. This isn't a valid server, so no one will be using it for legitimate reasons.

In the future, we'll be posting about the compromises that occurred and how to use the different DFIR tools to assist in the investigation process.

Do you have any suggestions on how to better instrument this honeypot, whether it's in the way we are monitoring/responding, or the attack vector?

4 comments:

  1. Nice work! Is the current version of your honeypot based on the 10.04 or the 14.04 version of Security Onion? Would you consider making your VirtualBox appliance available for download (to spare us the heavy lifting you have already done to configure everything)?

    ReplyDelete
    Replies
    1. Rex, Thanks. I definitely would like to share, though it's Windows XP and I don't think the licensing allows for that.

      That part of the honeypot was the easiest. Use a base Windows XP image, install some FTP software with a weak username/password and allow RDP in.

      Configuring Security Onion was the more time consuming task, though it still did not take long. If you run into any snags, let me know and I'd be willing to help. Also - let me know if you find anything interesting!

      Delete
  2. Thanks for the quick answer, Brett. I have been struggling for 2 solid weeks (and many, many installs, both in VMs and on metal) trying to install OpenFPC in Security Onion. I am using Ubuntu 12.04 both as host and guest, so it's all open source. Bridging the network and installing Security Onion is relatively easy and well documented, but installing OpenFPC (for full packet capture) is the bottleneck for me (I keep getting an error saying I have a duplicate node configured, even immediately after I change the node name in the config file (and there's only one config file in /etc/openfpc/). I'd be happy to share a ready-built appliance to spare others this hassle, if only I could successfully configure OpenFPC. I had planned a separate honeypot VM with tools for forensics and reverse engineering malware, so your project looked like a great integration. I have found 3 separate but similar installation documents (4 if you count the readme file), and I get the same error with each, and I can't find anything relevant when I Google "openfpc duplicate node". I'm stumped. I'll try yet another install. I'll let you know if I end up with anything to share with your 'nix readers. If you can think of anything, I won't be the only one to benefit from your help.

    ReplyDelete
    Replies
    1. E-mail the security-onion mailing list (http://code.google.com/p/security-onion/wiki/MailingLists) with the output of "sostat" and we can have a look. I'd be happy to continue the discussion there.

      Delete