Do you need a honeypot?

It might seem like a strange question, but I wonder how many readers are running a honeypot network in their infrastructure? If you’re not then let me be the first to say that you really should.

This could be a slightly controversial view as, all too often, honeypots are misunderstood and mistrusted. People across the IT security space are very good at raising concerns about why they shouldn’t be used and why they’re not a good idea, but I really couldn’t disagree more I’m afraid! I firmly believe that honeypots have a key role to play in any organization’s security arsenal.

Let’s start at the beginning, what is a honeypot? Put simply, it is a machine that is designed to tempt any unknowing attacker to target it, whilst being configured to trace the origins of the attacker and identify them. However, this can lead to the perception that honeypots can be a quagmire of risk and liability, as well as raising understandable concerns about willingly allowing an attacker to access your system under your control.

However, there are many forms of honeypots, and they can be used in many different ways. The idea of the honeypot as merely a host designed to be breached; sitting on the perimeter of your network is far from the whole picture. Let’s take a look over some different uses of honeypot style systems and consider their place in a well-equipped enterprise security program.

Building a fully-functional and interactive honeypot that resembles a real production system can be a daunting task, replete with risk (you would be, after all, building a machine with the intention of it falling under the control of an attacker) but there are many other levels of honeypots before this level of complexity, and all of them present value to security monitoring.

The first type are known as ‘low-interaction’ honeypots. They are designed to present a minimal network presence and are actually best thought of as ‘tripwires’ – but they still fall into the honeypot’s goal of providing rapid, reliable notification of unwanted activity on the infrastructure.

1. The armored alarm bell – A single host, sitting unnoticed in the middle of the data centre – It runs a scant few basic services and the system is locked down to a minimal level. It appears absolutely ordinary in all regards but one – the machine serves no purpose at all – it doesn’t exist in asset tracking or CMDB, the hostname follows the local sequencing scheme with no overtly identifying information. It just sits there inside your network, doing absolutely nothing – until someone or something connects to it.

By definition, this host should see no activity – there are few legitimate reasons this system should see a single packet on the network (apart from local broadcast traffic). In the sea of alerts produced by security controls today, veracity and priority can be a rare thing; every last connection log from this system however bears investigation.

True, you may discover more broken business processes and deployed systems than actual hostile actors on the network, but no experienced security analyst would count the discovery (and rectification) of these as wasted effort; for the more silent you become the more you can hear.

2. The correlation correlator – One of the great (yet underutilized) features of the modern SIEM is the correlation engine: a good correlation implementation allows for alerting on behaviour over time or across a scope of systems. A honeypot system allows easy prioritization of correlated alerts from many systems across the enterprise by cross-checking against the honeypot system – if the same source host in the alert you are analyzing has also connected to a honeypot system, then there is good reason to consider the alert valid.

3. The virtual weather vane – virtual infrastructure is everywhere these days and deploying one additional machine template amongst many is an effortless task. Virtualization also provides a valuable tool to the honeypotter – rapid rollback to a snapshot of prior machine state.

Placing an extra, minimally configured (except for logging remotely) VM onto each hypervisor (configured for the absolute minimum of resource usage) that only accepts connections from other machines on the same hypervisor can provide a simple way of gaining more visibility into events that never leave the server.

With many security controls still requiring to be deployed in-line on physical networks, activities inside the hypervisor that never leave the virtual switch can go unnoticed for some time. A honeypot system that merely reports what happens to it, and then is rolled back to a default state every hour or so, can provide easy early-warning on attempts by intruders to migrate from systems to system within the same hypervisor.

4. The imaginary administrator – Spearphishing requires information about who to target for maximum effect at malware delivery. To a spearphisher, obtaining the contact details of someone with elevated network access (and additional information with which to social engineer them into clicking links) is the prime goal in any campaign.

Creating a non-existent person on the internet is easy these days – perhaps in the recesses of your public website you can make mention of a fictional administrator of your two-factor authentication system, provide contact details for them, and set up an email inbox – then take a close look at everything coming in to that account and cross-reference with who else in the organization receives email with the same content, originating host, etc.

Doing this effectively is an art in itself however, but there are many organizations that are high profile targets for spear phishing attacks using methods such as this to rapidly identify when and where their employees are being targeted.

5. The ghost page – A honeypot does not have to be an entire system, sometimes content itself can perform the job – especially if it is content that a normal user would never discover. Most web vulnerability scanning tools will access a list of common locations for forms in known-vulnerable web applications.

While common Intrusion Detection systems will detect these (and a good SIEM correlation ruleset can look for these URIs in the logs from the webservers themselves), there is a missing piece of the puzzle here – the webserver will report ‘404 not found’ to these pages – and the scanner moves on to the next system. But what if the webserver reported with Error 500 – indicating that the page is present, but a server-side error has occurred? Our attacker may stay focussed on this one system (wasting their time and effort) and providing us with much more information. (a technique often referred to in other contexts as ‘tarpitting’).

These honeypot methods, while all cheap to build and deploy, and requiring little additional analysis to make the intelligence they generate useful, are merely the tip of the iceberg of the art and science of building effective honeypot systems. There are few organizations making extensive use of honeypot deployments and those that do are mature enough that they tend toward the more complex installations.

This has led to the intimidation factor for many organizations to forego the use of honeypots as a security monitoring control. However, there are many levels of sophistication with this technique and a company does not have to implement something massively complex, to still obtain valuable information.

The use of honeypots, like everything in information security, is always evolving and the technique has a lot of potential to disrupt attackers by wasting their time and resources, directing them away from their true targets and forcing them to reveal themselves.

Collaborative projects such as The HoneyNet Project continue to develop tools to capture both directed and automated attacks and integrate honeypots directly into malware analysis sandboxes. Sinkholes and tarpits to redirect and trap command and control channels for botnets are a cousin to the honeypot that is proving to be an effective active countermeasure against malicious software networks.