Low-cost, low-fuss honeypots are highly effective early-warning systems against external attacks and insider threats. We review three.
Intrusion detection is a complex business. Whether you deploy an intrusion detection system (IDS), or you collect and analyze the computer and device logs on your network, identifying malicious traffic in a sea of legitimate activity can be both difficult and time consuming.
A honeypot makes identifying malicious traffic dead simple. That's because any traffic to a honeypot, after some initial quick tuning to rule out false positives, is suspicious. A honeypot is a fake computer asset that exists only to alert its owner if it is touched. Nobody should be touching it or attempting to log on. Because all activity is illegitimate, no analysis is needed to tell good traffic from bad. The only question is, how dangerous is the intruder?
As a longtime security professional (and author of the book "Honeypots for Windows"), I've maintained eight different honeypots on the Internet to track hacker and malware behavior. I was able to watch as Internet malware evolved from script-kiddie viruses to professional crimeware. I was able to see and learn about bank account stealing Trojans long before they were well known in the security world, and I've seen carders (credit-card-dealing thieves) operate firsthand.
More important, I've seen the impact of honeypots in the corporate environment, where they shine as basic early-warning systems. I've seen honeypots on a corporate LAN catch foreign industrial spies, snare trusted insiders gone bad, and alert security teams to the presence of a roving malware program that had gone unseen. In nearly 10 years of deploying honeypots, I've yet to create one that didn't find something malicious within a few days of being installed.
In short, when used as early-warning systems, honeypots are low cost, low noise, and low maintenance, yet highly effective at drawing attention to threats in the network environment. They belong in any defense-in-depth program.
With this recommendation in mind, I reviewed three available honeypot software solutions: Keyfocus' KFSensor, MicroSolved's HoneyPoint Security Server, and free open source Honeyd. I tested all three honeypots in a closed lab environment, running them inside of virtual machines hosted by Windows Server 2008 R2's Hyper-V. KFSensor and HoneyPoint were run on Windows 7 Enterprise, and Honeyd was run on Ubuntu 9.1. Attack probes were simulated using Nessus 4.2.2, BackTrack 4 tools, and manual connections from remote physical machines on the same private LAN. All host-based firewalls were disabled, and User Account Control (UAC) was disabled on the Windows computers, because of the likelihood they would thwart various attacks and probes that might otherwise succeed.
Why use specialized honeypot software? You don't need a KFSensor, Honeyd, or HoneyPoint Security Server to set up a honeypot. I often recommend to readers that they take an old computer they're getting ready to throw away and use it as an early-warning honeypot instead. You've already paid for the hardware and software, so why not put it to good use? (See my tips in the sidebar, "Intrusion detection on the cheap: Roll your own honeypot.")
Specialized honeypot software has a number of advantages over that old PC. For one, honeypot software usually does the hard work for you. They set up the services, provide a range of fake functionality, and simplify logging and alerting. Most honeypot software programs come with low- and medium-interaction services and allow easy customization.
Secondly, honeypot software usually excels at data capture, sometimes offering intrusion detection signatures, packet capture and network protocol analysis, and easy filtering and fine-tuning. For example, some GUI-based honeypots allow you to click an event message to create "ignore rules" to filter out legitimate traffic. Compared to configuring an old PC for honeypot duty, a specialized honeypot program squeezes what might be a two-day process into 10 or 15 minutes of actual work.
High-interaction honeypots vs. low-interaction honeypots When people think of honeypots, they often think of complex, highly realistic "traps" where the hacker encounters a range of fully functional services (a realistic website, an email server with updated emails, and so on) and his every move can be tracked. These types of high-interaction honeypots provide realistic emulation of high-value network assets in return for significant administrator effort. Their sophistication is intended to better determine the hacker's motivations and to better document what the hacker did.
For example, once when I was onsite at a large defense contractor, a newly installed honeypot caught someone probing the SharePoint Web server. We quickly set up three areas of the site designed to help us profile our intruder: a section with computer games, a section hosting "secret" NASA Space Shuttle plans, and a section that purported to have F17 fighter pilot communication codes. The secret Space Shuttle plans were simply page redirects from NASA's public website. The hacker quickly went to the Space Shuttle plans and began using SharePoint's search feature to look for Middle East topics. This was no gamer. The hacker was later found to be a foreign spy working in the company's accounting department as a temp worker.
Because high-interaction honeypots require a lot of work and carry increased risk that an attacker will use the exploited honeypot to do harm (for example, attacking other companies, installing a password sniffer, and more), I encourage most companies to use low- or medium-interaction honeypots. A medium-interaction honeypot fakes common tasks, but doesn't implement a full service. For example, a fake FTP service might allow the prober to attempt to logon, or it might allow them to logon anonymously and offer up fake files to download. A fake email server might even let the attacker read and send emails. KFSensor allows a few emails to be sent on the fake service so that a potential spammer might be tricked into thinking he's found a real email server. The idea is to provide enough functionality to determine whether an intruder poses a threat, but not enough to allow the intruder to take things too far.
Low-interaction honeypots are the simplest of all. Honeypots that serve as early-warning systems are usually low interaction, meaning that they monitor one or more network ports and alert when something has tried to connect to a particular port. Low-interaction honeypots don't attempt to look like fully formed, legitimate services. Attackers rarely understand why the remote port isn't responding correctly, and they move on after a few attempts. That's OK, because you've hopefully logged the origination point of the probes and are now exploring it yourself.
While low-interaction honeypots don't do a whole lot to convince an intruder that they're the real thing, they don't have to. Their only job is to alert the computer security or incident response team when something touches them.
Honeypot software features All honeypots have a few core functions in common. First, they must publish one or more ports and services that will attract intruders. Next, they must capture at least the intruder's origination address (usually IP address), date, time, and data sent in the connection attempt. All connection attempts should be logged (unless instructed to be ignored) and generate alerts so that an incident response team can get involved. Lastly, a great honeypot helps in data analysis, whether it's through detailed packet analysis, password attempt analysis, or aggregating related probes into a single incident. How well each honeypot does this and with what finesse is where the evaluation takes place.
Platforms and installation. Honeypot software should be easy to install and configure. KFSensor leads the pack in this regard with the best GUIs across the board, although it runs only on Windows (XP and later). HoneyPoint and Honeyd run on Windows, Linux, and Mac OS X, and Honeyd supports BSD and Solaris as well. HoneyPoint is fairly simple to install, but requires minor text file manipulation for licensing. Honeyd is the most versatile honeypot of the three; unfortunately, it's also the most difficult to install and configure. Longtime Linux command-line users will find familiarity, but Windows users will usually be daunted by the downloading, compiling, and configuration work, all at the command line. All three honeypots could run as a user-mode program or as a system service or daemon. Running as a system service makes it easier for them to resume operations after a reboot.
Emulation levels and services. Most honeypot programs are low interaction to medium interaction -- or it's more accurate to say that some services are emulated at a low level and others at medium. All three honeypots reviewed fall into the low to medium range of emulation. KFSensor and Honeyd allow routing of probes to external real systems if high interaction is desired for particular services. The forwarded attacker still thinks he is connected to the same target system and IP address, and the honeypot continues to capture data so that the administrator can get a complete picture of what the attacker is doing.
All honeypots must emulate one or more services, and to do so, they must listen on the TCP or UDP (or ICMP) ports for those services. Many honeypots emulate only a limited set of ports. KFSensor, Honeyd, and HoneyPoint all claim to emulate the entire range of TCP and UDP ports (0 through 65,535). I didn't test these claims in this review, but I have verified this on KFSensor and Honeyd in the past. Honeyd did all ports easily with the best performance. Although early versions of KFSensor could not do all ports, the latest enterprise versions can. Again, I have not tested HoneyPoint's claim.
Note: A honeypot cannot bind to a port that the underlying host operating system has already bound to. For example, Windows-based honeypots cannot emulate NetBIOS services unless file and printer sharing have been disabled on the host and SMB/CIFS have been turned off. This is to be expected.
I have noted in the accompanying honeypot features table whether or not the honeypot came with a particular emulated service built-in, without needing additional software or scripts. For a low-interaction honeypot, the more services you can emulate the better. In a Windows shop, it's almost essential to cover all of the popular Microsoft applications and services -- that's what the attackers will be looking for. KFSensor comes with the most built-in services, followed by HoneyPoint. A broad range of open source emulation scripts are available for Honeyd, but only a few come preinstalled.
Network emulation. KFSensor and HoneyPoint don't have any network emulation features at all, relying completely on the host and host network for all routing. Honeyd has extensive network emulation, faking not only entire routing schemes (including routes, hops, latency, and packet loss) but also the network stack of each emulated OS. It can fool Nmap and Xprobe fingerprinting scans. A single instance of Honeyd can make it appear as if 100 different systems are operating across a wide range of virtualized IP addresses. No other honeypot product can match it.
It bears noting, however, that most attackers don't do network fingerprinting and analysis. They look for a port, find it, and quickly try to see what it's running -- just a little bit of discovery, if that. In a small percentage of cases the attacker will run a detailed fingerprinting tool (such as Nmap or Xprobe2), and in those cases network stack emulation is important. But in the vast majority of attacks, Honeyd's detailed network-level emulation and granular accuracy is overkill. For honeypot purists or honeypot admins trying to hide well, it is an essential feature. For most of the rest of us, it's unnecessary.
Alerting and logging. A honeypot is useless without strong alerting and logging. All honeypots display connection attempts as alerts, either on the sensor or on a centralized console. Alerts should allow criticality levels to be set for each sensor, origination IP address, port, and even intrusion signature. All probes to a honeypot should be investigated, though some probes are more suspicious than others. A probe originating from a more secure network might indicate a more serious compromise, for example. For this reason, a defense industry client with a honeypot on a nongovernment network wanted the highest priority set on traffic originating from a distant government network that was classified. The client wanted their incident response team to be alerted immediately if a probe originated from the more sensitive network. KFSensor provided the most versatility in setting criticality levels, followed by Honeyd and then HoneyPoint.
Most honeypots allow alerts to be sent via syslog, email, and Windows Event logs (if hosted on a Windows computer). All alerts should be logged to a local database, and bonus points were given if logs could also be saved to an external database, especially if the database supported was SQL-based. All three products reviewed allow you to throttle alert messages so that one probing event -- say, a port scan -- doesn't trigger thousands of emails to the on-call support person.
It's a topsy-turvy world where Amazon sells budget reader-tablets and Barnes & Noble offers high end...
Software developers can become quite attached to the keyboards they use to bang out code all day. Here...
Catch a glimpse of what flourishes in the shadows of the Internet.
An effort to help developers get the most out of heterogeneous processors inched forward this week,...
Microsoft's foray into notebooks with the Surface Book is certain to tick off its computer-making...
AT&T kicked off Wi-Fi calling on newer-model iPhones running iOS 9 after winning permission from the...