Sweeten your security strategy with a honeypot security system
Implementing honeypots and honeynets as part of your network intrusion prevention/detection process
We’ve all heard the old saying that you can attract more flies with honey than with vinegar. When the pests we’re dealing with are network attackers and intruders, most of us focus on using the vinegar (firewalls, encryption, multi-factor authentication) to repel them. However, sometimes you may actually want to attract them – as a means of identifying and prosecuting them and/or as a way to divert them from your valuable digital assets.
That’s where honeypots and honeynets (networks of honeypots) come in.
What is honeypot security and how is it used?
Outside of computing, honeypot security is often used to refer to “bait” of different kinds, designed to attract and then trap someone (or something). In the IT security world, it’s a system (usually a server, which can be a dedicated machine or may be running in a virtual machine) that is set up specifically to present an attractive target for hackers and attackers.
When you have two or more honeypots that form a network or network segment, it’s called a honeynet.
Honeypots and honeynets can be used in several different ways:
- Security researchers use honeypot security and honeynets to observe and analyze types of attacks and learn more about attackers and attack methods.
- Law enforcement personnel use honeypot security and honeynets in “sting” operations, to collect forensics information to help track and catch cybercriminals and evidence used to prosecute them.
- Organizations use honeypot security and honeynets to divert attackers from their production networks and systems and to confuse or mislead them with false data.
Honeypots can be valuable in detecting insider attacks as well as outside intrusions.
Sweetening the pot
Simply setting up a fake server on your network may not be enough to attract attackers. This is best done by making the honeypot security system appear to contain information that is useful or valuable to the attacker, such as customers’ credit card information, human resources records, company financial data, trade secrets, confidential email and documents, and so forth.
Giving the server an enticing name, running services and applications that are generally used for such purposes, naming files to indicate they hold this type of data, and actually providing false information in the contents of the files will get the attention of hackers.
Next, you want to make your honeypot accessible. There is a fine line to walk here: you don’t want to make the system too enticing or it might look too much like what it is – a trap. Don’t leave your fake critical information unencrypted, for example. Instead, you can use weak encryption and passwords that are easy for a competent hacker to defeat. The rule of thumb is that the honeypot must appear to hackers to be a real production machine that is vulnerable to attack.
NOTE: There are some situations where an organization wants it to be obvious that honeypots are in use. This strategy is aimed at scaring attackers away because they know they will be monitored and could be caught.
There are software products available that make it easy to create honeypots. Honeyd is an open source tool that was created over a decade ago but is still in use. The NOVA project built on Honeyd, and there are many more honeypot tools available as free or commercial software. However, you don’t need special software to create a honeypot security system.
It’s easiest to set up your honeypots as virtual machines, especially if you need to deploy more than one. You can have a whole honeynet of VMs running on one physical machine, at a lower cost and easier maintenance than multiple physical machines.
Because a honeypot security system is intended to be compromised, be sure to create an image backup of the server before deploying it, so that you can restore it easily when needed after you’ve obtained all the data you need following an attack.
The most important thing to remember when setting up a honeypot or honeynet is that it must have no legitimate production usage or access. Also, remember that the goal of using a honeypot is to enhance your security, not compromise it. You do not want the honeypot to serve as an intentional conduit for attackers to get to your actual production systems.
Honeypots are often deployed within a DMZ to help detect attacks on servers that are accessible to the public. However, you don’t want to set up a server on your DMZ that’s been left deliberately unpatched, making it easy for attackers to get in, if you have other legitimate servers – such as your mail server or web server – on that DMZ that could be infiltrated by a honeypot attacker.
If not properly implemented, your honeypot can be used by attackers not only to get into other systems on your network but also to launch attacks against other organizations’ networks across the Internet. The risks are greater if the honeypot’s configuration is complex. The old adage K.I.S.S. (“Keep it simple, sweetheart) definitely applies here.
It’s very important to have real-time monitoring of the honeypot, including human monitoring in addition to automated. This is so you can quickly terminate the attacker’s connection if activities indicate a risk to your production systems.
Monitoring honeypot security activities
Because honeypot security has no legitimate function, any access to it is either accidental or it’s an attempt at intrusion/attack. A multi-layered logging system will help you to track the activities of anyone who is accessing the honeypot server and determine what they are doing or trying to do on the system. Ideally, you will capture all data inbound and outbound data packets going to and from the honeypot to provide you with more information for analyzing the attacks.
This is, in fact, the big advantage of honeypots; with a production system, it’s difficult if not impossible to monitor everything because of the high volume of legitimate traffic, which then has to be differentiated from the unauthorized traffic. With the honeypot security, all traffic is suspect and the overall volume is much lower, making comprehensive monitoring feasible.
It’s recommended that the monitoring data be sent to a separate server rather than stored on the honeypot itself. There are a number of open source and commercial logging programs and services that can be used for this.
You can use many traditional network monitoring solutions to monitor honeypots, such as GFI EventsManager with your SIEM solution, or commercial software made specifically for this purpose such as the LogRhythm Honeypot Security Analytics Suite
In addition to the risks to your own network that can be associated with deploying a honeypot, another risk to be aware of is that of civil liability, in case your honeypot (a deliberately non-secure system) is used by attackers to attack others. It’s conceivable that the target victim could name your organization in a lawsuit, claiming your negligence enabled the attack on their network. Configuring the honeypot to prohibit or restrict any outbound connections can help protect you in this regard.
Another issue to think about is that, ironic as it might sound, there is the remote possibility of an intruder suing you for invasion of privacy by monitoring his network activity. Some countries and some states have laws prohibiting the interception of communications content. These laws are generally complex and have exceptions, so any detailed discussion of them is beyond the scope of this article, but it goes without saying that you should have your legal counsel involved when you deploy a honeypot, especially for the purpose of catching the bad guys.
That brings us to another legal consideration that some may be concerned about (but need not be): that if you do identify and bring charges against an intruder, he might claim the defense of entrapment because the honeypot was set up for that purpose. The entrapment defense applies only to the actions of law enforcement personnel, not to a private citizen or organization who sets a trap to entice a criminal to commit a crime.
On the other hand, there is a way in which an attacker could “entrap” you – by storing illegal data (such as child pornography) on your honeypot security systems. Possession of such material is a serious crime and that’s another reason that the honeypot and its contents should be very closely monitored. Any such material that is found should be immediately reported to law enforcement. Although the first impulse would be to delete such files (and this is what some might advise), remnants may still remain on the system that could be recovered through forensics analysis and your failure to report the crime could be used as evidence that you were aware of the material or even that it was yours. With severe penalties in most states for child pornography offenses, it’s best to take no chances.
A honeypot, if properly deployed, can be a valuable element in your overall security strategy. Honeypot security is not a comprehensive security solution; It doesn’t take the place of strong perimeter defenses, a network intrusion detection and prevention system, good multi-factor authentication, system-level and file-level access controls, and strong encryption for mission-critical and sensitive data. It does provide a tool for greatly extending the amount of information you can gather about attempted and successful attacks beyond what an IDS can provide, and it can draw attackers away from your real resources and keep them occupied without doing harm to your production network.
Because an improperly configured honeypot security system could pose a high security risk to your network and other systems or be used as part of a botnet to attack other networks, you should follow best practices and consult both an IT professional with expertise in honeypot deployment and a legal advisor before going “live” with your honeypot.
You might also like: