Is it helpful (or dangerous) to use honeypots to direct potential Web application attackers away from legitimate applications and toward these fake targets?
A honeypot is a decoy system with false data. It is set up to detect, monitor, deflect and counteract attempts at unauthorized use of a real system. It can provide insight into the levels and types of threats your systems face, while distracting them away from your real assets. It can certainly have a role in improving your system’s overall security, but should be seen as a variant and not a replacement for a standard intrusion detection system (IDS).
As a honeypot focuses on intelligence gathering, it can provide valuable insight into attack methodologies being used against your organization, which can then be used to build specific countermeasures to make your system less vulnerable. The information gathered can also be useful in catching and prosecuting anyone trying to attack you.
To be effective, the honeypot needs to simulate the behavior of a real system and appear to contain information or a resource of value. This will attract and occupy external and internal hackers so you are able to gather as much information as possible. Obviously, it shouldn't contain anything of actual value.
As there isn't any reason for legitimate traffic going to or from your honeypot, the firewall in front of it should be set to send alerts when traffic is detected so you can view intruder activity while it’s happening. All honeypot traffic needs to be logged so firewall and system logs can be analyzed to identify the intruder’s tools, methodology and intentions. Marked records in a honeypot can help you follow the data flow and identify connections between different participants in an attack. You do have to spend time analyzing logs generated by your honeypot, otherwise you won’t get the most out of its deployment.
A pen test on your honeypot is a good idea prior to deployment to ensure it is truly sealed off from your production servers. Careful monitoring and analysis of traffic once it is deployed will provide data on the type and frequency of attacks you experience and whether the honeypot is reducing the number against your real servers. If it doesn't, then you will either need to make its contents appear more interesting to would-be attackers, or abandon the experiment to reduce the risks to the main infrastructure.
There are several open source honeypots worth considering, including a variety of low- and high-interaction honeypots from the Honeynet Project. If you’re unfamiliar with setting up a honeypot, or just need to demo one to your boss, there’s the HoneyStick, a portable honeynet demonstration and incident response tool that includes a complete OS platform, GenIII honeywall and one or more honeypots all contained on a single bootable USB stick.
As noted above, honeypots can be quite helpful, but they do carry risks. If not configured correctly, they can be used to access the real production system or be used as a launch pad for attacks against other systems. The key elements necessary for operating a Web application honeypot securely are a layer-two gateway and firewall; this is what separates the honeypot from the rest of your network. All traffic entering or leaving the honeypot must go through the gateway and firewall and it’s vital that these are correctly configured to isolate the honeypot from the real production servers. Also use different usernames and passwords to those used on your real systems, and do not make them a member of your domain or Active Directory.
As attackers grow in sophistication, so must the methods used to detect and stop them. Enterprises can no longer sit and wait for an attack; organizations must research, like your attackers, to find where and how the next attack is likely to arrive.
This was first published in November 2010