Many of you might be familiar with the terms "honeypots" and "honeynets". While some may see them as a tool strictly for security researchers, when used properly, they can benefit enterprises as well. In this month's tip, we will offer a brief overview of honeypots, general design considerations to take into account when you are attempting to deploy one on your network, as well as introduce you to a couple of their uses. For purposes of this article we will be using "honeypots" and "honeynets" interchangeably, though a honeynet generally attempts to mimic a larger and more diverse network, providing an attacker with a more believable environment to exploit.
Honeypots are an isolated collection of systems, the primary purpose of which is to elicit exploitation from attackers either by the use of real or simulated vulnerabilities or by weaknesses in system configurations, like easily guessed passwords. They attract attackers and log their activity in order to be able to better understand their attacks. Honeypots are generally categorized into two types: high-interaction and low-interaction honeypots.
Types and trade-offs
High-interaction honeypots are systems with a real operating system (OS) (not emulated) that can be fully compromised. The attacker is interacting with a real system with a complete service stack. This system is designed to capture exhaustive details on an attacker's activity on the system. Low-interaction honeypots only simulate portions of a real OS (e.g., the network stack, processes and services), such as emulating an FTP service advertising a vulnerable version of code. This could attract a worm looking to exploit that particular vulnerable version of the service, thereby giving insight into the worm's behavior.
There are trade-offs to be made with either deployment. High-interaction honeypots for network security offer the advantage of real OS services and applications, which lend themselves to a more authentic experience for the attacker. It allows for the capture of extensive amount of information on the attacker's behavior on the compromised system. This can be helpful, for instance, if an organization wants to gather detailed real-world data on how attackers seek to compromise certain types of systems in order to mount the proper defense. At the same time, these systems are hard to deploy and maintain, while the risk of collateral damage is also high: For example, the compromised system could be used to attack other systems on the Internet.
A low-interaction honeypot is easy to set up and maintain and is generally immune to compromise by attackers. However, emulation might not be sophisticated enough and might cause the attacker to bypass the system, thereby rendering the honeypot ineffective in such scenarios. Deciding between which deployment to pursue depends on the end goal: If the goal is to capture an attacker's interaction with a system in detail, then a high-interaction honeypot would be the better choice. If the goal is to capture malware samples targeting specific vulnerable versions of services, a low-interaction honeypot would be sufficient.
Another important consideration to keep in mind while deciding which honeypot deployment type is best for you is whether the honeypot would be hosted on a single physical system or on several virtual machines on a single physical system. This directly affects the effort required to maintain the system. While it's true that any virtualized system brings its own set of security concerns, a virtual system also allows for easy rollback of system state and significantly shorter deployment and redeployment timeframes.
The basic design philosophy for any honeypot, be it high interaction or low interaction, is that the system is designed with no conventional purpose on the network. In other words, the system should not have any unusual processes, services or daemons running outside of those required by the OS. Neither should it generate any network traffic outside of that used by the existing daemons or services. This assumption helps in detecting attacks by treating any interaction with the honeypot as suspicious and indicative of malicious activity. Before going into some deployment best practices for honeypots, however, here is a run-down of some commonly used high- and low-interaction honeypots.
High-interaction honeypots generally do not require specialized software to begin the base OS installation. Typically, employing a VMware workstation installation or using a virtualizer like QEMU should be sufficient to get the base OS going for the honeypot members (typically guest OS members on the host machine running the virtualization software). Once the base OS is set up, focus next on setting up the appropriate monitoring of the honeypot, which is the guest OS. This is typically broken up into two parts: monitoring the host OS and monitoring the guest OS. Host OS monitoring should focus on capturing all traffic entering and leaving the honeypots. This can be accomplished by using a traffic-capture utility like tcpdump or Wireshark. Also, you'll want to be warned of any potential collateral damage as a result of outbound malicious connections made by the compromised guest OSes (also called extrusion detection). This can be accomplished through the use of local access control lists like iptables (or a host-based firewall). Enforcing inbound filtering allows some control over what attacks are allowed to hit the honeypots. You can also combine host OS traffic filtering with an intrusion detection system (IDS) like Snort to provide additional alerting capabilities for known attack vectors (i.e., signature-based alerting).
Monitoring the guest OS, or the actual target of the attacks, requires all the attacker's actions be captured: tracking any keylogging activity, logging which tools the attacker executes and recording any privilege escalation attempts, to name a few. Sebek is one such tool that can enable this level of extensive data collection. Some other examples of virtual high-interaction honeypots worth looking into are user-mode Linux and Argos.
Low-interaction honeypots, unlike high-interaction honeypots, require special software to be installed on the host OS, as well as further configuration in order to effectively emulate vulnerable services. Some popular low-interaction honeypot technologies include Nepenthes, its successor Dionaea and mwcollectd.
Low-interaction honeypots come with a lot of monitoring capabilities out of the box. These include extensive logging capabilities, malware capture capabilities, real-time event notification and submission of malware for remote analysis. Their capabilities can be extended further through add-on modules like built-in IRC support within Nepenthes, using the log-IRC module, and the capability to passively identify remote OS types using the p0f module with Dionaea. Dionaea also supports the Extensible Messaging and Presence Protocol (XMPP) module, which allows for malware binary sharing within the security community or between enterprises to enhance awareness.
I have briefly touched upon some deployment best practices as they relate to the monitoring of high-interaction honeypots, i.e., enforcing inbound and outbound filtering and implementing network-based intrusion detection. These capabilities need to be augmented with sufficient isolation of honeypots from the any production networks. Ideally, the honeypot environment should be deployed with its own dedicated Internet drop and a separate network for the host OS for management purposes. Low-interaction honeypots, on the other hand cannot be fully compromised by an attacker, thus making them easier to protect. Typically, low-interaction honeypots are isolated to a small portion of the file system through the use of utilities like chroot. Care should be taken to isolate the honeypot fully from any production networks, since the low-interaction honeypot will still be exposed to the same kind of threats as the high-interaction honeypots.
One of the primary uses of honeypots is to collect malware samples. These samples could target zero-day vulnerabilities or known exploit vectors. Honeypots can provide a researcher with a better understanding of such attacks. For example, they could provide real-time attack flows by monitoring the IRC control channel. They could also support the ability to passively identify an attacking system's OS type or have the capability to store and replay an attack. In addition, they provide a researcher the capability to share threat information (e.g., XMPP) and submit samples to online sandboxes and multi-antivirus scanners for further analysis (VirusTotal, Jotti, ThreatExpert and CWSandbox to name a few).
Honeypots' ability to collect malware can be extended into the realm of bots and botnets as well. The architecture of botnets -- their distributed nature, use of a remote command channel (typically IRC and HTTP) and propagation capabilities that leverage zero-day or known exploits -- lends itself to tracking and analysis by using honeypots.
A honeypot's usefulness to the enterprise extends beyond the examples given above, but its effectiveness is dependent on a good design. Any design weaknesses, such as insufficient isolation, or lack of monitoring and real-time alerting capabilities, could cause the honeypot to become a serious liability rather than a threat management asset. Proper care and caution should be taken when implementing any honeypot, and those looking to do so without the proper experience should always consult a trained professional.
About the author:
Anand Sastry is a Senior Security Architect at Savvis Inc. Before joining Savvis, he worked for clients in several industries (large and mid-sized enterprises in financial, healthcare, retail and media) as a member of the security services group for a Big 4 consulting firm. He has experience in network and application penetration testing, security architecture design, wireless security, incident response and security engineering. He is currently involved with network and web application firewalls, network intrusion detection systems, malware analysis and distributed denial of service systems. He tweets at http://twitter.com/cptkaos.
This was first published in November 2010