10 decisions you’ll face when deploying a honeypot

Honeypots provide the best way I know of to detect attackers or unauthorized snoopers inside or outside your organization.

For decades I’ve wondered why honeypots weren’t taking off, but they finally seem to be reaching critical mass. I help a growing number of companies implement their first serious honeypots — and the number of vendors offering honeypot products, such as Canary or KFSensor, continues to grow.

If you’re considering a honeypot deployment, here are 10 decisions you’ll have to make.

1. What’s the intent?

Honeypots are typically used for two primary reasons: early warning or forensic analysis. I’m a huge proponent of early-warning honeypots, where you set up one or more fake systems that would immediately indicate maliciousness if even slightly probed.

Early-warning honeypots are great at catching hackers and malware that other systems have missed. Why? Because the honeypot systems are fake — and any single connection attempt or probe (after filtering out the normal broadcasts and other legitimate traffic) means malicious action is afoot.

The other major reason companies deploy honeypots is to help analyze malware (especially zero days) or help determine the intent of hackers.

In general, early-warning honeypots are much easier to set up and maintain than forensic analysis honeypots. With an early-warning honeypot, when you detect a probe or connection attempt, the mere connection attempt gives you the information you need, and you can follow the probe back to its origination to begin your next defense.

Forensic analysis honeypots, which can capture and isolate the malware or hacker tools, are merely the beginning of a very comprehensive analysis chain. I tell my customers to plan on allocating several days to several weeks for each analysis performed using a honeypot.

2. What to honeypot?

What your honeypots mimic is usually driven by what you think can best detect hackers earliest or best protect your “crown jewel” assets. Most honeypots mimic application servers, database servers, web servers, and credential databases such as domain controllers.

You can deploy one honeypot that mimics every possible advertising port and service in your environment or deploy several, with each one dedicated to mimicking a particular server type. Sometimes honeypots are used to mimic network devices, such as Cisco routers, wireless hubs, or security equipment. Whatever you think hackers or malware will most likely to attack is what your honeypots should emulate.

3. What interaction level?

Honeypots are classified as low, medium, or high interaction. Low-interaction honeypots only emulate listening UDP or TCP ports at their most basic level, which a port scanner might detect. But they don’t allow full connections or logons. Low-interaction honeypots are great for providing early warnings of malicious behavior.

Medium-interaction honeypots offer a little bit more emulation, usually allowing a connection or logon attempt to appear successful. They may even contain basic file structures and content that could be used to fool an attacker. High-interaction honeypots usually offer complete or nearly complete copies of the servers they emulate. They’re useful for forensic analysis because they often trick the hackers and malware into revealing more of their tricks.

4. Where should you place the honeypot?

In my opinion, most honeypots should be placed near the assets they are attempting to mimic. If you have a SQL server honeypot, place it in the same datacenter or IP address space where your real SQL servers live. Some honeypot enthusiasts like to place their honeypots in the DMZ, so they can receive an early warning if hackers or malware get loose in that security domain. If you have a global company, place your honeypots around the world. I even have customers who place honeypots that mimic the CEO’s or other high-level C-level employees’ laptops to detect if a hacker is trying to compromise those systems.

5. A real system or emulation software?

Most honeypots I deploy are fully running systems containing real operating systems — usually old computers ready for retirement. Real systems are great for honeypots because attackers can’t easily tell they’re honeypots.

I also install a lot of honeypot emulation software; my longtime favorite is KFSensor. The good ones, like KFSensor, are almost “next, next, next” installs, and they often have built-in signature detection and monitoring. If you want low-risk, quick installs, and lots of features, honeypot emulation software can’t be beat.

6. Open source or commercial?

There are dozens of honeypot software programs, but very few of them are supported or actively updated a year after their release. This is true for both commercial and open source software. If you find a honeypot product that’s updated for longer than a year or so, you’ve found a gem.

Commercial products, whether new or old, are usually easier to install and use. Open source products, like Honeyd (one of the most popular programs) are usually much harder to install, but often far more configurable. Honeyd, for example, can emulate nearly 100 different operating systems and devices, down to the subversion level (Windows XP SP1 versus SP2 and so on), and it can be integrated with hundreds of other open source programs to add features.

7. Which honeypot product?

As you can tell, I’m partial to commercial products for their feature sets, ease of use, and support. In particular, I’m a fan of KFSensor. If you choose an open source product, Honeyd is great, but possibly overly complex for the first-time honeypot user. Several honeypot-related websites, such as Honeypots.net, aggregate hundreds of honeypot articles and link to honeypot software sites.

8. Who should administer the honeypot?

Honeypots are not set-and-forget it solutions — quite the opposite. You need at least one person (if not more) to take ownership of the honeypot. That person must plan, install, configure, update, and monitor the honeypot. If you don’t appoint at least one honeypot administrator, it will become neglected, useless, and at worst, a jumping-off spot for hackers.

9. How will you refresh the data?

If you deploy a high-interaction honeypot, it will need data and content to make it look real. A one-time copy of data from somewhere else isn’t enough; you need to keep the content fresh.

Decide how often to update it and by what method. One of my favorite methods is to use a freely available copy program or a copy commands to replicate nonprivate data from another server of a similar type — and initiate the copy every day using a scheduled task or cron job. Sometimes I’ll rename the data during the copy so that it appears more top secret than it really is.

10. Which monitoring and alerting tools should you use?

A honeypot isn’t of any value unless you enable monitoring for malicious activity — and set up alerts when threat events occur. Generally, you’ll want to use whatever methods and tools your organization routinely uses for this. But be warned: Deciding what to monitor and alert on is often the most time-consuming part of any honeypot planning cycle.